W3C WBS Home

Results of Questionnaire The Future of RDF Standards

The results of this questionnaire are available to anybody.

This questionnaire was open from 2010-08-17 to 2010-09-13.

128 answers have been received.

Jump to results for question:

  1. Your Name and Organization
  2. Official Response
  3. Your Expertise
  4. Additional Comments
  5. What do you like about RDF?
  6. What do you dislike about RDF?
  7. Most Important Addition to RDF
  8. Priorities
  9. Add Core Support for Working With Multiple Graphs
  10. Make Well-Known Repairs To The Specification Text
  11. Create a Standard JSON RDF Syntax
  12. Make Turtle a W3C Standard
  13. Indicate Which RDF Features Are No Longer Best Practice
  14. Extend RDF/XML
  15. Revise Semantics for Blank Nodes
  16. Create Standards for Deployment of Linked Data
  17. Define Some Useful Similarity/Equivalence Properties
  18. Define a Namespace Packaging Mechanism
  19. Change RDF Semantics to Plain Data (SPARQL) Style
  20. Explain How to Determine What a URI Means
  21. Allow Literals as Subjects
  22. Improve Integration with Syndication Systems (Atom)
  23. Other Comments?

1. Your Name and Organization

If you are signed in to your W3C account as you fill out this questionnaire, your name and organization will be public along with your answers, so please leave this field blank.

If you are not signed in, and you want your answers to be associated with your name and organization, you may provide them here.

Details

Responder Name and Organization
Sandro Hawke
Melvin Carvalho
Axel Polleres DERI Galway at the National University of Ireland, Galway, Ireland
Eric Prud'hommeaux
James Leigh
Christoph Lange Christoph Lange, Jacobs University Bremen, Germany
Manu Sporny Digital Bazaar, Inc. http://blog.digitalbazaar.com/
Paul Tyson
Holger Knublauch TopQuadrant
Lee Feigenbaum
Masahide Kanzaki
Abhik Banerjee Abhik Banerjee , Cincinnati Children's Hospital and Medical Center R&D
Pierre-Yves Chibon
Olaf Hartig
stéphane pouyllau
Philipp Schaffner PHILIPP-SCHAFFNER.COM
Paul Hermans Paul Hermans, ProXML
Gautier Poupeau Gautier Poupeau, Antidot
Nina Jeliazkova
Olivier Grisel
Jeen Broekstra
Armen Martirosyan Armen Martirosyan, Impeva Labs
Josh Jonte
Bob DuCharme Bob DuCharme, TopQuadrant
Brian Peterson Brian J. Peterson, Next Century Corporation
Quentin Reul
Yann Mombrun
Peter Andersen Peter Bruhn Andersen, Mind Creatures
Colm Kennedy
Ruben Verborgh
Gunnar Grimnes Gunnar Grimnes, DFKI
Patrick Stickler Patrick Stickler, Nokia
Jean-Paul DECLE Jean-Paul Dècle & Associés
Rinke Hoekstra Rinke Hoekstra, VU University Amsterdam/University of Amsterdam
Renaud Delbru
Jochem Liem
Axel Klarmann Axel Klarmann, zwonull media
Chimezie Ogbuji
James Hendler
Mike Dean
Andrew Perez-Lopez
Hassan Ait-Kaci Hassan Aït-Kaci
Jamie Taylor Jamie Taylor
David Wood David Wood, currently independent
Mischa Tuffield Garlik Ltd
Kjetil Kjernsmo Kjetil Kjernsmo, currently ABC Startsiden AS, from Oct 1, University of Oslo
Renato Iannella
Ivan Herman
Toby Inkster
Peter Mika
Steve Harris
Bob Ferris
Charles Nepote Charles Nepote, Fing
Jun Zhao Jun Zhao. Department of Zoology, University of Oxford
Chris Beer
Christopher Welty
James Myers
Ryan Kohl Ryan Kohl, Alion Science & Technology
Lowell Vizenor Alion Science and Technology
jans aasman
Marco Neumann KONA
David Peterson David Peterson
Kai Eckert
Irene Celino Irene Celino, CEFRIEL
Dave Reynolds Dave Reynolds, Epimorphics Ltd
De Roo Jos
David Booth
Sergio Fernández Fundación CTIC
Ted Guild
Gregg Kellogg
Ian Horrocks
Micah Herstand Micah Herstand, DERI Galway
Aidan Hogan Aidan Hogan, DERI Galway
Graham Klyne
Andy Seaborne
Mohamed ZERGAOUI
Christophe THOVEX
Richard Cyganiak
Nathan Rixham
Paul Trevithick Paul Trevithick, Azigo
Jérôme Mainka Jérôme Mainka, Antidot
Antoine Zimmermann Digital Enterprise Research Institute, National University of Ireland, Galway
Henry Story
Frank Olken Frank Olken - Lawrence Berkeley National Laboratory
Gavin Carothers
Enrico Franconi
Bryan Copeland National Research Council of Canada
Emmanuelle BERMES
Vojnisek Péter
hodder mary
Paul Wilton
Antoine Isaac Antoine Isaac, VU University amsterdam / Europeana
Fabien Gandon
Palmisano Davide Davide Palmisano Fondazione Bruno Kessler
Egon Willighagen Egon Willighagen, Uppsala University
Reto Bachmann
William Waites
Sarven Capadisli
Ji���­ Proch�¡zka
Stasinos Konstantopoulos
Olivier Berger
Michael Hausenblas
Janne Saarela
François Scharffe François Scharffe, INRIA
Ora Lassila
Ivan Mikhailov
Pierre-Antoine Champin
Drew Perttula
John Goodwin Ordnance Survey
Dodds Leigh
Arpad Tamasi Árpád Tamási; Progos Kft.
Dave Pawson Dave Pawson
Yves Raimond British Broadcasting Corporation
michel bercovier
Bernhard Haslhofer
Martín Álvarez
Stéphane Corlosquet Massachusetts General Hospital
Paul Reeves
Nicholas Humfrey Nicholas Humfrey
Evren Sirin Evren Sirin, Clark & Parsia, LLC
Niklas Lindström
Michael Schneider
Vadim Eisenberg
Steve Speicher Steve Speicher, IBM Rational, OSLC
Peter Jeszenszky
Raphaël Troncy Raphael Troncy, EURECOM
1 1 1
555-555-0199@example.com 555-555-0199@example.com 555-555-0199@example.com

2. Official Response

If you are answering this survey officially, speaking on behalf of your organization, please say so here. Otherwise, it is understood you are just speaking for yourself.

Are you answering on behalf of your organization?

Summary

ChoiceAll responders
Results
yes 24
no 101

(3 responses didn't contain an answer to this question)

Details

Responder Official Response
Sandro Hawke no
Melvin Carvalho no
Axel Polleres no
Eric Prud'hommeaux no
James Leigh no
Christoph Lange no
Manu Sporny yes
Paul Tyson no
Holger Knublauch no
Lee Feigenbaum yes
Masahide Kanzaki no
Abhik Banerjee no
Pierre-Yves Chibon no
Olaf Hartig no
stéphane pouyllau no
Philipp Schaffner yes
Paul Hermans yes
Gautier Poupeau no
Nina Jeliazkova no
Olivier Grisel no
Jeen Broekstra no
Armen Martirosyan no
Josh Jonte no
Bob DuCharme no
Brian Peterson no
Quentin Reul no
Yann Mombrun no
Peter Andersen yes
Colm Kennedy no
Ruben Verborgh no
Gunnar Grimnes no
Patrick Stickler no
Jean-Paul DECLE yes
Rinke Hoekstra no
Renaud Delbru no
Jochem Liem no
Axel Klarmann yes
Chimezie Ogbuji no
James Hendler no
Mike Dean no
Andrew Perez-Lopez no
Hassan Ait-Kaci no
Jamie Taylor no
David Wood no
Mischa Tuffield no
Kjetil Kjernsmo no
Renato Iannella yes
Ivan Herman no
Toby Inkster no
Peter Mika no
Steve Harris yes
Bob Ferris no
Charles Nepote no
Jun Zhao no
Chris Beer no
Christopher Welty no
James Myers
Ryan Kohl no
Lowell Vizenor no
jans aasman yes
Marco Neumann yes
David Peterson yes
Kai Eckert no
Irene Celino no
Dave Reynolds no
De Roo Jos no
David Booth no
Sergio Fernández no
Ted Guild
Gregg Kellogg no
Ian Horrocks no
Micah Herstand no
Aidan Hogan no
Graham Klyne no
Andy Seaborne no
Mohamed ZERGAOUI yes
Christophe THOVEX no
Richard Cyganiak no
Nathan Rixham no
Paul Trevithick yes
Jérôme Mainka yes
Antoine Zimmermann no
Henry Story no
Frank Olken no
Gavin Carothers no
Enrico Franconi
Bryan Copeland no
Emmanuelle BERMES no
Vojnisek Péter no
hodder mary no
Paul Wilton no
Antoine Isaac no
Fabien Gandon no
Palmisano Davide no
Egon Willighagen no
Reto Bachmann no
William Waites yes
Sarven Capadisli no
Ji���­ Proch�¡zka no
Stasinos Konstantopoulos yes
Olivier Berger no
Michael Hausenblas yes
Janne Saarela yes
François Scharffe no
Ora Lassila no
Ivan Mikhailov yes
Pierre-Antoine Champin no
Drew Perttula no
John Goodwin no
Dodds Leigh no
Arpad Tamasi yes
Dave Pawson no
Yves Raimond yes
michel bercovier no
Bernhard Haslhofer no
Martín Álvarez no
Stéphane Corlosquet no
Paul Reeves no
Nicholas Humfrey no
Evren Sirin yes
Niklas Lindström no
Michael Schneider no
Vadim Eisenberg no
Steve Speicher no
Peter Jeszenszky no
Raphaël Troncy no
1 1 yes
555-555-0199@example.com 555-555-0199@example.com no

3. Your Expertise

Please express your level of expertise in the follow topics.

Scale:

  1. I do not know anything about this subject
  2. I have spent at most a few hours thinking about this subject
  3. I have spent days or weeks on this subject
  4. I have spent months on this subject
  5. I have worked in the area in depth for years

Summary

ChoiceAll responders
12345No opinion
RDF 1 1 11 31 81 2
OWL 2 10 32 41 39 3
SPARQL 2 9 26 44 43 3
W3C Semantic Web technologies, in general 1 1 11 40 70 4
Semantic Web Community and Industry 1 9 22 39 48 8
XML Technologies 2 7 26 40 48 4
Database Technologies 2 7 26 43 44 5
Website Development Technology 2 8 24 35 53 5
Software Development 4 5 12 27 74 5
W3C Recommendation-Track Process 18 26 29 22 24 8
W3C Community and Industry 17 26 31 26 18 9

Averages:

Choices All responders:
Value
RDF4.52
OWL3.85
SPARQL3.94
W3C Semantic Web technologies, in general4.44
Semantic Web Community and Industry4.04
XML Technologies4.02
Database Technologies3.98
Website Development Technology4.06
Software Development4.33
W3C Recommendation-Track Process3.07
W3C Community and Industry 3.02

Details

Responder RDFOWLSPARQLW3C Semantic Web technologies, in generalSemantic Web Community and IndustryXML TechnologiesDatabase TechnologiesWebsite Development TechnologySoftware DevelopmentW3C Recommendation-Track ProcessW3C Community and Industry Comments
Sandro Hawke 5 4 3 5 5 4 4 5 5 5 5 I was staff contact for the WebOnt, RIF, OWL, and SPARQL WGs.
Melvin Carvalho 3 2 3 4 4 2 2 4 4 3 2
Axel Polleres 5 5 5 5 4 4 4 3 3 5 3
Eric Prud'hommeaux 5 3 5 5 4 5 5 3 5 5 5 thinks he's a know-it-all
James Leigh 5 5 5 5 5 5 5 5 5 3 4
Christoph Lange 5 4 4 5 3 5 4 4 5 4 2
Manu Sporny 5 3 3 5 5 5 5 5 5 4 4 is secretly compensating for something :P
Paul Tyson 4 5 3 4 No opinion 5 3 3 5 1 1
Holger Knublauch 5 4 5 4 5 3 3 4 5 3 2
Lee Feigenbaum 5 5 5 5 5 5 5 5 5 5 5
Masahide Kanzaki 5 4 5 5 4 5 4 5 4 3 3
Abhik Banerjee 4 3 4 3 2 3 5 5 5 No opinion No opinion Have worked with RDF , SPARQL and OWL specifically in data related to genes , proteins and their interactions , representing these data sets in RDF and OWL for better interaction and query (using SPARQL and SPARQL Motion)
Pierre-Yves Chibon 3 3 3 4 2 4 4 4 4 1 1
Olaf Hartig 5 3 5 4 3 2 5 3 3 3 2
stéphane pouyllau 3 1 2 4 2 5 4 4 4 3 1
Philipp Schaffner 5 2 3 4 3 5 5 5 4 2 2
Paul Hermans 5 4 5 4 4 5 2 2 2 2 2
Gautier Poupeau 5 4 5 5 5 5 3 5 4 3 3
Nina Jeliazkova 4 4 3 No opinion No opinion 5 5 5 5 No opinion No opinion
Olivier Grisel 4 3 4 4 4 4 4 5 5 2 2
Jeen Broekstra 5 5 5 5 5 4 4 5 5 4 4
Armen Martirosyan 5 5 4 5 3 5 5 5 5 5 3
Josh Jonte 4 3 4 5 3 5 5 5 5 3 3
Bob DuCharme 5 4 5 5 5 5 4 4 5 4 4 4 and 5 have a large gap between them; it's possible to work in an area for years without working in it in depth for years.
Brian Peterson 5 3 3 3 3 3 4 2 4 1 2
Quentin Reul 4 5 4 5 5 3 4 3 4 3 3
Yann Mombrun 4 3 2 3 3 3 3 4 5 4 4
Peter Andersen 5 5 5 5 5 5 5 4 5 3 3
Colm Kennedy 3 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Ruben Verborgh 4 4 4 4 3 5 5 5 5 2 2
Gunnar Grimnes 5 3 4 5 5 4 3 5 4 2 2
Patrick Stickler 5 4 4 5 5 5 4 5 5 5 5
Jean-Paul DECLE 4 4 3 5 4 5 5 5 5 No opinion No opinion
Rinke Hoekstra 5 5 4 4 4 4 3 4 3 4 3
Renaud Delbru 5 5 5 5 5 4 5 4 5 1 1
Jochem Liem 5 5 3 5 3 3 3 4 5 1 1
Axel Klarmann 4 4 3 4 3 4 3 5 4 2 3
Chimezie Ogbuji 5 5 5 5 4 4 3 3 5 5 4
James Hendler 5 5 4 5 4 4 4 3 3 4 4
Mike Dean 5 5 4 5 5 4 4 3 5 5 5
Andrew Perez-Lopez 5 5 5 5 4 5 4 4 5 3 2
Hassan Ait-Kaci 5 5 5 5 5 5 4 4 No opinion 3 5 I have been part of the RIF WG and I and very interested in Linked Data and Topic Maps (for more info on my activities and interests, see http://www.google.ca/search?aq=f&q=Hassan+Ait-Kaci).
Jamie Taylor 4 3 4 4 5 4 4 5 5 No opinion 3
David Wood 5 4 4 5 5 3 3 3 5 4 4
Mischa Tuffield 5 4 5 5 5 4 4 5 5 1 4 Been involved with building things in both academia (Southampton UK, on the AKT project since 04) whilst a postgrad, and in industry with Garlik.

(/me didn't want to come across like a "know it all" [as i haven't been doing W3C stuff for that long] - but i have been using SW tech for a few years - and do like this stuff.

http://mmt.me.uk/foaf.rdf#mischa
Kjetil Kjernsmo 4 2 4 4 5 4 3 5 3 4 5 I've been a member of WCL XG, POWDER WG, SWEO IG, eGov IG and SPARQL 1.1 WG.
Renato Iannella 5 4 2 5 5 5 3 3 4 5 5
Ivan Herman 5 5 5 5 5 3 1 4 4 5 5
Toby Inkster 5 3 4 5 3 4 5 5 4 2 2
Peter Mika 5 5 5 5 5 5 4 4 4 3 3 "W3C Community and Industry" is a bit vague, not what is meant here
Steve Harris 5 3 5 5 5 4 5 5 5 4 4
Bob Ferris 5 5 5 5 No opinion 5 5 5 5 No opinion No opinion dealing with Semantic Web technologies since autumn 2007 (see links in additional comments)
Charles Nepote 3 3 3 3 3 2 3 3 2 2 2
Jun Zhao 4 3 4 4 4 3 4 4 4 2 3
Chris Beer 4 3 3 3 4 4 3 4 2 2 4
Christopher Welty 5 5 4 5 5 2 4 3 4 5 5
James Myers No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Ryan Kohl 5 5 5 5 4 5 5 3 4 3 4
Lowell Vizenor 5 5 5 4 5 4 5 4 5 3 3
jans aasman 5 4 4 3 5 3 5 3 5 1 1
Marco Neumann 5 4 4 5 5 3 4 4 4 3 3
David Peterson 5 3 4 4 3 3 4 5 5 2 2
Kai Eckert 4 3 4 5 4 5 5 5 5 2 3
Irene Celino 5 4 5 5 5 4 4 5 5 2 2 Some of the results achieved within my group in the field of Semantic Web technologies are available at http://swa.cefriel.it
Dave Reynolds 5 5 5 5 5 4 4 4 5 5 4
De Roo Jos No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
David Booth 5 3 3 5 4 4 4 4 5 5 5
Sergio Fernández 5 3 5 5 5 4 4 5 4 3 2
Ted Guild
Gregg Kellogg 5 4 3 4 5 5 5 5 5 4 5 RDF Lists are broken. N3/Turtle depend on rdf:first/rdf:next lists, which are not kind to SPARQL queries and can't be well expressed in RDFa. Even in RDF/XML, they're only easily expressed when rdf:first is not a literal. rdf:_n is also not useful for managing real-world collections, as there is no way to assert information on the predicate itself (short of reification). RDF should obsolete existing list representations (if possible) and move to something more like the Ordered List Ontology [1]. This maintains a constant distance between the subject and object of a collection (through an intermediate node), and allows for a much richer semantics. Ideally N3 lists, represented by (...), would naturally represent as such a collection. Of course, this would require some keyword to invoke, or other hook to allow for backwards compatibility.
Ian Horrocks 5 5 4 5 5 3 4 3 3 5 5
Micah Herstand 4 4 3 4 4 5 5 5 5 2 3
Aidan Hogan 4 4 4 4 4 2 4 2 3 1 1
Graham Klyne 5 4 5 4 5 4 4 4 5 5 5 Experience rather than expertise. per scale :)
Andy Seaborne 5 4 5 5 4 4 5 4 5 5 4
Mohamed ZERGAOUI 4 3 4 3 3 5 5 5 5 5 4
Christophe THOVEX 4 5 4 5 4 4 5 4 5 3 3
Richard Cyganiak 5 4 5 5 5 3 4 2 5 3 3
Nathan Rixham 4 3 4 4 4 4 4 4 4 3 2
Paul Trevithick 5 4 2 5 4 4 No opinion No opinion 5 3 3
Jérôme Mainka 5 4 5 5 5 5 5 5 5 3 3
Antoine Zimmermann 5 5 4 4 3 3 4 3 4 4 2
Henry Story 5 3 4 4 5 3 3 4 5 2 2
Frank Olken 4 3 3 4 5 5 5 4 4 4 4
Gavin Carothers 4 2 4 4 3 5 4 4 5 1 1
Enrico Franconi 5 5 5 5 4 1 5 1 1 4 2
Bryan Copeland 5 5 3 4 4 5 5 5 5 2 1
Emmanuelle BERMES 4 3 2 4 4 5 3 5 1 2 3 I don't have a technological background, so I look at these topics mainly from an outsider point of view. My focus is data and data management rather than technology. I'm also interested in the uptake of technology in my community (libraries) and that requires at least a broad knowledge of how things work.
Vojnisek Péter 5 5 4 5 5 5 5 5 5 4 4
hodder mary 3 2 2 3 4 4 2 5 5 2 2
Paul Wilton 4 4 4 4 4 5 5 5 5 1 2
Antoine Isaac 5 4 3 5 3 2 2 2 2 4 3
Fabien Gandon 5 4 5 5 4 4 3 4 3 4 4 (see http://fabien.info for more)
Palmisano Davide 5 4 5 5 3 5 4 3 5 2 3
Egon Willighagen 4 3 3 5 4 5 5 5 5 1 1
Reto Bachmann 5 4 4 5 4 4 4 5 5 2 2
William Waites 5 4 4 4 4 4 5 5 5 3 3
Sarven Capadisli 4 2 4 4 4 4 3 5 3 2 2 Scale has gaps (e.g., 4 and 5 are too wide apart).
Ji���­ Proch�¡zka 4 3 3 4 3 3 4 5 4 1 3
Stasinos Konstantopoulos 5 5 4 5 4 4 3 2 5 5 4
Olivier Berger 3 2 2 4 2 3 3 3 4 1 1
Michael Hausenblas 5 5 5 5 5 No opinion No opinion No opinion No opinion 5 5
Janne Saarela 5 5 5 5 5 5 5 5 5 5 4
François Scharffe 4 4 4 5 5 3 3 3 4 3 4
Ora Lassila 5 5 4 5 5 5 5 5 5 5 5
Ivan Mikhailov 5 4 5 5 5 5 5 4 5 4 4 I'm responsible for most of SPARQL and XML functionality of OpenLink Virtuoso family of products.
I also participated in some W3C groups, mostly in order to provide early implementations of XQuery, URIQA, SPARQL 1.0 and SPARQL 1.1 language and web service endpoint, a fast and flexible RDB2RDF mapping, experimental SPARQL extensions for XSLT, diff and patch for RDF graphs.
Pierre-Antoine Champin 5 5 4 5 5 4 5 5 5 3 No opinion
Drew Perttula 5 3 5 4 4 3 3 5 5 2 3
John Goodwin 5 5 5 4 5 3 3 3 3 2 3 I am responsible for producing Ordnance Survey's linked data offerings, and have been active in the use of RDF and OWL mainly for a number of years.
Dodds Leigh 5 4 5 5 5 5 5 5 5 3 3
Arpad Tamasi 4 4 2 4 4 5 5 5 5 3 3
Dave Pawson 3 3 3 3 2 5 4 4 5 4 4
Yves Raimond 5 5 5 5 5 4 5 5 5 3 3
michel bercovier 3 2 1 3 2 3 2 3 4 4 4
Bernhard Haslhofer 5 4 5 5 4 4 4 3 5 1 1
Martín Álvarez 3 3 3 4 2 4 3 5 4 4 5
Stéphane Corlosquet 5 3 4 5 4 3 4 5 5 1 1
Paul Reeves 3 3 3 3 2 3 3 2 3 1 2
Nicholas Humfrey 5 2 3 4 3 3 3 4 3 2 1
Evren Sirin 5 5 5 5 5 4 4 3 5 4 4
Niklas Lindström 5 5 5 5 4 5 4 5 5 3 4
Michael Schneider 5 5 4 5 No opinion 5 5 4 5 5 No opinion I do not understand what expertise means with regard to "Community and Industry". So I have left the two points unanswered.
Vadim Eisenberg 4 4 4 4 3 3 4 3 5 1 1
Steve Speicher 4 4 3 4 4 5 5 5 5 5 5 I work from within IBM's Software division around tools (Rational). We have been delivered RDF-based solutions, proponents of Linked Data (http://open-services.net) and looking to extend this approach for open tool interoperability.
Peter Jeszenszky 5 4 4 5 No opinion 5 5 4 5 2 3
Raphaël Troncy 5 4 4 5 3 4 2 4 1 5 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2 2 2 2 2 2 2 2

4. Additional Comments

Additional comments on your background and expertise:

Details

Responder Additional Comments
Sandro Hawke
Melvin Carvalho
Axel Polleres
Eric Prud'hommeaux
James Leigh
Christoph Lange http://kwarc.info/clange/
Manu Sporny Currently a Chair of the RDFa Working Group
Paul Tyson
Holger Knublauch
Lee Feigenbaum
Masahide Kanzaki
Abhik Banerjee Have worked with RDF , SPARQL and OWL specifically in data related to genes , proteins and their interactions , representing these data sets in RDF and OWL for better interaction and query (using SPARQL and SPARQL Motion)
Pierre-Yves Chibon I am a PhD studend in bioinformatics. I started to look at the semantic web technology a year ago and I am still in the learning phase and the exploring phase on what I could do with it.
Olaf Hartig
stéphane pouyllau
Philipp Schaffner
Paul Hermans
Gautier Poupeau
Nina Jeliazkova http://vedina.users.sourceforge.net
Olivier Grisel
Jeen Broekstra
Armen Martirosyan
Josh Jonte
Bob DuCharme
Brian Peterson Ontology, Complexity of Query Languages, Finite Model Theory, Descriptive Complexity, Logic Programming
Quentin Reul I was a member of the W3C Semantic Web Deployment Working Group that developed the SKOS meta-language.
Yann Mombrun
Peter Andersen
Colm Kennedy
Ruben Verborgh
Gunnar Grimnes
Patrick Stickler Member RDF Core Working Group, November 2001 to May 2004
Member RDF Data Access Working Group, March 2004 to June 2004
Applying RDF and Semantic Web technologies in real-world solutions for 10+ years.
Jean-Paul DECLE
Rinke Hoekstra
Renaud Delbru
Jochem Liem
Axel Klarmann
Chimezie Ogbuji
James Hendler
Mike Dean Semantic Web developer since 2000. I attended the RDF Next Steps Workshop.
Andrew Perez-Lopez I've been writing software using Semantic Web technologies at BBN for the last 5 years, and first started working with OWL during the summer of 2004. I co-authored a book called Semantic Web Programming that was published in the beginning of 2009. I also co-authored a paper that was accepted to OWLED 2008 about adding unit support to RDF. That said, many of the components in the system that I work on that deal with OWL and with ontology development have been mature for some time, so the Semantic Web technologies that I work with most often are RDF/S and SPARQL.
Hassan Ait-Kaci http://ca.linkedin.com/in/hak2007
Jamie Taylor
David Wood
Mischa Tuffield
Kjetil Kjernsmo Have followed Semantic Web since August 1998 and worked actively with the technologies for several employers. I've accepted a ph.d. fellowship position at the University of Oslo, and will start on the 1st of October. It will deal with SPARQL Federation.
Renato Iannella
Ivan Herman
Toby Inkster
Peter Mika
Steve Harris
Bob Ferris http://smiy.wordpress.com/
http://infoserviceonto.wordpress.com/
http://musicontology.com/
http://www-mmt.inf.tu-dresden.de/Lehre/Wintersemester_07_08/KP_MMT/index.xhtml
Charles Nepote
Jun Zhao
Chris Beer W3C e-Gov Interest Group Member (Public)
Christopher Welty
James Myers
Ryan Kohl
Lowell Vizenor
jans aasman
Marco Neumann
David Peterson
Kai Eckert
Irene Celino
Dave Reynolds
De Roo Jos
David Booth
Sergio Fernández
Ted Guild
Gregg Kellogg I have implemented N3 [1], RDF/XML [2] and RDFa [3] parsers in Ruby, and am pretty familiar with the mechanics of parsing and serializing RDF graphs. More about me on my blog [4]. I'm also Technical Working Group chair of the Connected Media Experience [5], using RDF to describe media releases.
Ian Horrocks
Micah Herstand
Aidan Hogan
Graham Klyne Was member of RDFCore working group about 2000 timeframe
Andy Seaborne SPARQL editor
Jena developer
Support to users on the jena-dev mailing list
Mohamed ZERGAOUI
Christophe THOVEX
Richard Cyganiak
Nathan Rixham
Paul Trevithick
Jérôme Mainka
Antoine Zimmermann
Henry Story Worked on Atom syntax and sepcification. Developed foaf+ssl protocol, aka WebID
Frank Olken
Gavin Carothers
Enrico Franconi
Bryan Copeland Have developed some sample ontologies and rich internet applications using Semantic Web methodologies.
Emmanuelle BERMES
Vojnisek Péter
hodder mary
Paul Wilton
Antoine Isaac
Fabien Gandon It should be stressed that I come more from a research background.
Palmisano Davide
Egon Willighagen I have been member of the HCLSig for a bout a year now.
Reto Bachmann
William Waites For Open Knowledge Foundation, strong background in promoting open access to data.

For myself, expertise in network engineering, unix systems and software development since 1995
Sarven Capadisli http://csarven.ca/cv
Ji���­ Proch�¡zka I'm a university student interested in Semantic Web.
Stasinos Konstantopoulos
Olivier Berger
Michael Hausenblas
Janne Saarela
François Scharffe I did my PhD on ontology alignment at the Semantic technology institute and DERI at the university of Innsbruck.
Ora Lassila http://www.sciamdigital.com/index.cfm?fa=Products.ViewIssuePreview&ARTICLEID_CHAR=A0B26E34-EBC3-4D54-A854-5CEAA66A32A

Also, I was co-editor of the original RDF spec.
Ivan Mikhailov
Pierre-Antoine Champin
Drew Perttula
John Goodwin I am responsible for producing Ordnance Survey's linked data offerings, and have been active in the use of RDF and OWL mainly for a number of years.
Dodds Leigh
Arpad Tamasi
Dave Pawson
Yves Raimond The BBC has been publishing RDF data since 2007, in a variety of domains: programmes, music, nature, etc. The BBC is also using Semantic Web technologies to drive some of its web sites, including the 2010 World Cup web site.
michel bercovier
Bernhard Haslhofer worked with RDF & co. mainly in the digital libraries area...for quite some years (7) now
Martín Álvarez I have developed several applications using Semantic Web technologies. Now we are involved in Open Government Data projects using Linked Data, modelling the information in RDF, using simple OWL ontologies o RDF Schemas, and exposing it by a SPARQL endpoint.
Stéphane Corlosquet Graduated from DERI Galway (M.Sc.) on the topic of integrating Semantic Web technologies into Drupal. This work led to the integration of RDFa in Drupal 7 core.
Paul Reeves General programming CAD industry - C++ some xml STEP
Nicholas Humfrey I am the author of EasyRdf (a PHP library) and Redstore (a Triplestore powered by Redland), and a committer to Redland.
Evren Sirin
Niklas Lindström I have worked for 10+ years with web development, and doing all kinds of data related stuff (XML transformations, legacy format processing etc). During most of this time I've followed and dabbled with RDF technologies for pure interest. Around 4 years ago I started working with it in earnest for a government project.
Michael Schneider I have been a member of the W3C OWL Working Group, where I became the editor of the OWL 2 RDF-Based Semantics spec, the OWL semantic extension of the RDF semantics. I have also created a comprehensive conformance test suite for the OWL 2 RDF-Based Semantics, including coverage for all the entailment regimes of the RDF semantics specification. At the moment, I am working in the EU project SEALS, where I am involved in the development of evaluation suites for RDF reasoners. My current research interests center around the investigation of the features and the level of implementability of expressive extensions of the RDF semantics up to the level of OWL 2 Full.
Vadim Eisenberg I am an M.Sc. student at the Technion - Israel Institute of Technology. The topic of my thesis is programming applications over Semantic Web. I am interested in using Semantic Web technologies for Enterprise Information Integration and in bridging the gap between Object Oriented programming languages and the Semantic Web.
Steve Speicher
Peter Jeszenszky
Raphaël Troncy I'm working with RDF and OWL technologies since 10 years. I have developed tools for aligning automatically OWL ontologies. I have modeled numerous ontologies for representing metadata for multimedia, news and events.
1 1 1
555-555-0199@example.com 555-555-0199@example.com

5. What do you like about RDF?

What do you like about RDF?

Please feel free to answer in as much or little detail as you like. Even if you are not an expert, your "first impression" is valuable.

Details

Responder What do you like about RDF?
Sandro Hawke The generality: everything is a triple.
Melvin Carvalho Universality
Axel Polleres flat, graph-style, potentially ubiquitous data model that abstracts away from data structure. allows to easily merge and combine data, and is declarative.
Eric Prud'hommeaux explicit.
decentralized extensibility.
James Leigh
Christoph Lange Widely accepted standard for graph-based data models
Lots of vocabularies/ontologies exist (albeit with varying quality)
Not committed (= constrained) to any logic by default, but one is free to choose e.g. from OWL, N3Logic, etc.
Manu Sporny RDF (the data model) is the most powerful data organization tool that we've been exposed to... once you understand it, you think about data storage, retrieval and structure very differently. It is a very powerful information processing tool. We had no idea it existed until roughly 2-3 years ago (after being in the Web industry for more than a decade - a shame, really).
Paul Tyson
Holger Knublauch Simplicity - everything is a triple. No hidden magic.
Lee Feigenbaum
Masahide Kanzaki simplicity and universality
Abhik Banerjee RDF , best part is the representation in triples form , which specifically helps when I am trying to join 2 or more rdf graphs using sparql , and u can totally write a SPARQL query as long as u inderstand how the data is represented in rdf format ( how the triples are formed)
Pierre-Yves Chibon RDF seems simple to. It is pretty logical, easy to read even for an unused eye.
Olaf Hartig * Its simplicity.
* The use of URIs.
stéphane pouyllau A very good impression, but all tools around triple store techno. are very obscure.
Philipp Schaffner Its modularity and versatility. E.g. the practical usage of different namespaces.
Paul Hermans
Gautier Poupeau I like the possibilities of RDF to offer an interoperability framework to exchange, link and process data in a network environment. Thanks to RDF, the interoperability is at the data level and anymore at the document level. This differences open lots of perspectives in data aggregation and exchange. In RDF, in contrary RDBMS or XML, we have to express all the data, nothing is implicit and the structure of the data is in the data. We don't have the structure in one side and the data in other side, like RDBMS technology.
The big strenght of RDF is its integration with HTTP architecture (URI, decentralization, graph model), its simplicity (the triple model) and its flexibility.
Nina Jeliazkova The expressiveness and flexibility of triples as common data model, flexibility in merging data, reasoning.
Olivier Grisel The ability to define universal vocabularies that can be used across distributed databases (a.k.a linked data) with dereference-able machine readable URIs.
Jeen Broekstra Its simplicity and its flexibility: easy adaptation of data models in running systems, easy integration of heterogeneous data, etc.
Armen Martirosyan Simplicity of design. New generation for knowledge representation in the Web. I think the best part is the "RDF Semantics": it was fun to prove theorems on my own. Cool thing! More seriously, it's well written and is very important but is misused in apps.
Josh Jonte It enables the ability to encode information in a machine interpretable way. No other standard does that.
Bob DuCharme I mostly like the ability to combine data from disparate sources. In a related issue, although I like the modeling abilities of RDFS and OWL, I like how RDF lets you get a lot done without requiring a data model first.
Brian Peterson Uses URIs, graph data model, formalizes notions of links.
Quentin Reul The advantage of RDF is that it allows people to easily create data in a machine processable way, thus allowing database or file content to be published on the Web. The fact that it can be easily extended to provide schema to understand the data itself. OWL/FOAF/SKOS/DC are all perfect example of this extensibility.
Yann Mombrun I like the fact that almost everything can be described using this formalism.
I like the triple model.
Peter Andersen It's the Lego brick we build upon. Versatile and very useful
Colm Kennedy Missing is not broken !
Ruben Verborgh Simplicity.
Gunnar Grimnes
Patrick Stickler One of the greatest strengths of and benefits from RDF, from many years of real-world experience, is the flexibility it provides for incremental evolution of ontologies with minimal or no impact to existing data or systems (if engineered properly), and its flexibility for integrating disparate data sets into existing solutions.

Support for explicit and precise datatyping of literals and reification (albeit via an overly verbose mechanism) are other features that have provided high value over more traditional "field and string" metadata methodologies.
Jean-Paul DECLE Simple and pleasant to use to describe resources in a web environment once you understood the concept of URI, server redirection and content negociation
Rinke Hoekstra I think the best features of RDF is its flexibility to accomodate a multitude of different data models without making too many commitments. The integration with other web technology makes that RDF is currently the only language available for expressing things about stuff on the web, that is itself also web-enabled. This 'aboutness' makes RDF a very powerful language for describing things about things about things about things and so on.

RDF has a very active user community, good software libraries, and an adequate query language.
Renaud Delbru generic graph data model, simple to understand, make more easy data integration
Jochem Liem Easy to parse, easy to work with when programming, vastly superior to plain XML as a representation, love it basically.
Axel Klarmann I think of RDF as a wonderful way to interconnect systems/agents, that are stationary or mobile. The reasoning is not too complex, so that one is focused on deducing facts in a timely/energy saving manner. The syntax is straight forward.
Chimezie Ogbuji
James Hendler linkability as a data platform, flexibility for building other languages on
Mike Dean
Andrew Perez-Lopez I appreciate the flexibility and the simplicity of RDF.
Hassan Ait-Kaci RDF is the perfect level for representing labeled graph. Since *everything* is a labeled graph in CS it is therefore most adequate. In addition, it lends itself perfectly to my own contribution (OSF Constraint Logic) so that my work may be the basis providing an efficient and scalable implementation of reasoners over Internet-connected graph-based data and knowledge bases (all this is furtehr explained in more details in: http://list.cs.brown.edu/people/pvh/CPL/Papers/v1/hak.pdf).
Jamie Taylor Triples are wonderfully simple and powerful for expressing knowledge/data. Explaining the basic concept of RDF (to the point that they can generate proper RDF expression themselves) is a very quick process.
David Wood A common data format for the Web is critical to addressing data interoperability, and scalable data architectures.
Mischa Tuffield URIs, triples, and the Web. The "?s ?p ?o" pattern of representing data seems both natural and logical to me. From a developer's point of view, it encourages me to both design systems based on webservices and web resources, and allows me to make use of the massive technology stack that runs the Web, whilst maintaining a standard way to represent data and talk about things.
Kjetil Kjernsmo Very flexible and very simple data model. "The simplest thing that could actually work".
Renato Iannella Simple model
Ivan Herman Its flexibility, ie, the fact that it easily adapts to change of the data, structures, new information, etc
Toby Inkster A very simple data model, yet one that makes it possible to record any type of data.

I like the emphasis on the data model rather than a serialisation, thus allowing different serialistions to be developed which work well in different niches.
Peter Mika
Steve Harris Flexibility, level of standardisation, relative simplicitly
Bob Ferris Well for me it is not only RDF, it the whole Semantic Web stack, which is important. So RDF, RDFS, OWL, SPARQL, RIF etc.
Only by using the whole stack, one will get the full power of Semantic Web. The RDF thing in general, is more or less just about relations - complex nets of relations, which are difficult the project on a relational database schema. So RDF reflects more or less perfectly the structure of the distributed, interlinked knowledge base, which we call currently Linked Data Cloud. However, this is at the end always the Web, which we are talking about - and that's it. So I have still the dream that every dereferencable URI will deliver someday also a Semantic Graph (N3, RDF, whatever) in different representation formats (N3/Turtle, RDF/Turtle, ...) and not only a HTML page as it is the case nowadays.
Charles Nepote An (apparently) simple model to express things. URIs. Proximity between natural language and RDF.
Jun Zhao Its graph-based data model has the potential to make the data integration task easier.
Chris Beer Linkages via triples - its logical, everything is connected, everything has a need to be described. Makes metadata real and relevant and useful.
Christopher Welty Simplicity. URIs.
James Myers
Ryan Kohl The robust software support for semantic technologies that use RDF is a big point of attraction for me. The SPARQL language is nice, particularly with its CONSTRUCT and ASK clauses. A standard way to go about statement reification is also welcome. Most of all, I appreciate the elegance of RDF and RDFS.
Lowell Vizenor
jans aasman [1] By far the most important thing is that RDF offers flexibility to represent information (data, metadata, knowledge, whatever you want to call it)
[2] It is a standard, so you can share information with others
[3] It allows to to self describe data elements
Marco Neumann Flexible and powerful information modeling
David Peterson The reason I continue to use and research into RDF is because it allows for a shared understanding of anything really. This opens up so many possibilities and allows for a much more expressive form of software development.
Kai Eckert I like the possibility to mix data from different sources and relate them to each other without much problems.
Irene Celino its simplicity
Dave Reynolds Schemaless, open world model allows extensibility and easy integration.

Logical foundations means we can use ontologies to both constrain and
enrich the semantics. And can do so incrementally. Depth of modelling
can be varied to suit domain and requirements while still allowing for
extensibility.

Core notion of triples pretty easy to grasp and communicate.

Decent, if not perfect, universe of tools support with active
enthusiastic developers (if I'm allowed to say that :))
De Roo Jos
David Booth
Sergio Fernández The flexible data model to share information across the web
Ted Guild
Gregg Kellogg I really like the idea of having documents describe themselves, particularly within the context of a human-readable document.
Ian Horrocks Simple schemaless data exchange
Use of URIs (obviously)
Micah Herstand I like that it is so easily extensible and that any data that can be represented, can be represented with RDF.
I like that entities and relationships are both representable as URIs.
I like the emphasis (at least recently) on dereferencable URIs.
I like that it is as simple or as complicated as the user wants it to be.
I like how easy it is to write n3.
Aidan Hogan At its core, a simple, flexible model.
Graham Klyne Schema-free, unconstrained in terms of what can be recorded
Standard mechanism for merging/remixing
"Missing isn't broken" (per danbri)
Evolvable data content
Improving software tool support (now)
Andy Seaborne IRIs
Mohamed ZERGAOUI to be able to store graphs of informations
RDFa
Christophe THOVEX Linked data, semantic networks, social semantic networks analysis.
Richard Cyganiak Allows agreement on data representations independently from underlying technology
Nathan Rixham The triple, (dereferencable) URIs as identifiers, use of ontologies/schemas, ^^typed literals, various different serializations.
Paul Trevithick Powerful foundation for advanced software systems. Standardized. Great tools and community.
Jérôme Mainka * Schema-free
* IRIs
* HTTP
Antoine Zimmermann Simple, generic, flexible format.
Henry Story The simplicity and beauty of the relational model. The semantics based on URIs. The open world assumption. GRDDL as a method of ending the syntax wars. N3, Turtle serialisation syntax. SPARQL. XSPARQL looks very promising, but have not used it.
Frank Olken simplicity of the graph model
Gavin Carothers Merging datasets is simpler then anything else I've used so far. Making use of other groups hard work on vocabularies and ontologies rather then needing to always reinvent the wheel.
Enrico Franconi Simple relational language with existential placeholders. Simple semantics for metadata, leading to a unique ternary table. Challenging issues on indexing for access and update.
Bryan Copeland It is a clear path to more semantically meaningful content and discussions. It is obviously more powerful and can sometimes even be easier to use for certain tasks (using the right tools) than Relational Database Management systems.
Emmanuelle BERMES Its simplicity and flexibility. Triples, URIs, vocabularies give us the greatest way to express structured data.
Vojnisek Péter do not need to deal too much with syntax
easy handling
hodder mary it is a more complex description framework than xml
Paul Wilton 1. the data interoperability -
abiltiy of RDF consumers to be able to read in data drawn from the set of all schemas in a standard fashion. Modifying an underlying schema will not break a consumer.
2. I like the variety of flavours of RDF representations, from more human readble formats (n3), to rdf/xml, and the (almost standardardised) rdf/json format introduced by Talis - making it very easy andn efficient for php or javascript clients to consume and process rdf graphs.
Antoine Isaac Simplicity - Flexibility
Fabien Gandon (I was at the workshop)
Simple, natural, open, graph data model.
Palmisano Davide It's unparalleled potential for URI-driven data integration and its power for modeling claims about Web resources.
Egon Willighagen Combination of simplicity and expressiveness. The layered nature of the family of RDF technologies is very important, and should not be touched.
Reto Bachmann Graph structure of data, freedom from hierarchies
William Waites * Generality for representing information
* Use of URIs for a global namespace means correlation of data in different places is possible
* Consistency of representation means inferencing (evaluation of FOPL or DL rules) is possible

The last two are clear advantages over e.g. XML and JSON representations
Sarven Capadisli First impression:
* RDF has a lot of potential but it is complex to implement.

Current view:
* The directed graph data model works well with the existing Web architecture, and is a fairly close way to represent statements in a language.

* Data can be serialized in different ways.
Ji���­ Proch�¡zka I like RDF as simple universal model for information representation for machines, as a universal language.
It's simplicity and flexibility are the key points.
I like how it reflects the relativity of information and world itself.
Stasinos Konstantopoulos
Olivier Berger Semantics embedded in data allow to integrate data and meta-data.
Extensibility is great.
It provides a great means for interoperability.
Web-compatible nature is great, as allowing many use cases from linked data to mashup, etc.
Michael Hausenblas Potentially ubiquitous abstract data model.
Janne Saarela
François Scharffe It is intuitive and easy to write statements. It is a graph language.
Ora Lassila - Simple metamodel allows lot of data management to be insulated from applications' data models.
- Good for intergration cases.
- Good for *simple* KR.
Ivan Mikhailov It is the simplest representation of knowledge as connected data, the result of evolution from more expressive Marvin Minsky's variants to the level appropriate even for undereducated application developer.
Pierre-Antoine Champin * RDF being a simple data model, and yet having a well defined semantics.
* The fact that you can explain RDF by drawing graphs.
* The N3/Turtle syntax.
Drew Perttula We don't need anything lower-level or more atomic for linked data. All systems could converge on RDF and we'd get useful interoperability.
John Goodwin RDF is simple to produce, query and understand especially compared to technologies like XML or RDBMS. RDF doesn't solve all data integration problems, but having a simple common triple data modelcertainly solves many of them.
Dodds Leigh The simplicity of the model. That decentralisation is an underlying assumption
Arpad Tamasi It can be a way out from the current fragmented IT by global identifiers and high expressivity.
Dave Pawson Its flexibility, ability to describe things in as much detail as is needed, with as many references as are appropriate.
Yves Raimond * The ability of linking heterogeneous data sources, therefore enabling cross-domain content aggregations.
* Very expressive, with a very small and simple model.
* Accessible to non-technological people.
* Web-scale unique identifiers.
* Provides a standard way of opening up data, very relevant to a public organisation.
* A number of tools are available to deal with RDF-related technologies.
* Strength of related specifications, e.g. SPARQL and OWL.
* Quality of specifications and documentations (e.g. the RDF Primer)
michel bercovier availability
Bernhard Haslhofer Its flexibility (schema-less) and Web-based nature.

Martín Álvarez The simplicity of the 'triple' model, the concept itself (Subject-Property-Object).
Stéphane Corlosquet universal data model. RDF is syntax agnostic. HTTP URIs.
Paul Reeves Ability to model Graph type data structures and query in a general manner with SPARQL
Nicholas Humfrey I like the simplicity of the core of RDF and the flexibility of opting into various associated technologies, formats and vocabularies.
Evren Sirin
Niklas Lindström The simple, logical foundation of triples. The unique precision which the use of URI:s gives enables data description and integration to scale to a world-wide level.

This ability to extensibly link and describe resources in a decentralized way makes web(s) of data possible to build, both by using bottom-up and top-down approaches (and combinations thereof). It empowers collaboration on vocabularies and sharing data without binding any of it to specific implementations.

(The current state of data handling in the industry is often encumbered by narrow and procedural perspectives on what data is about. There, data quality is often very poor, conflating identity and failing to be coherent regarding meaning of properties. The pure perspective on data RDF is about can help solve a lot of these issues.)
Michael Schneider its conceptual simplicity, genericness and Web-suitability
Vadim Eisenberg
Steve Speicher Its simplicity at its core and open ability to extend.
Peter Jeszenszky It's simplicity and flexibility.
Raphaël Troncy I like the simple triple (data) model of RDF (subject, predicate, object).
I like the possibility of identifying any component of a triple with a URI, which offers a decentralized unique identifier system.
1 1 1
555-555-0199@example.com 555-555-0199@example.com

6. What do you dislike about RDF?

What do you dislike about RDF?

Please feel free to answer in as much or little detail as you like.

Details

Responder What do you dislike about RDF?
Sandro Hawke The complexity, especially from historical baggage. This stuff should be simple!
Melvin Carvalho bnodes
Axel Polleres I am quite happy with RDF, but some things on top are missing.
Eric Prud'hommeaux ambiguity around expressing sets.
James Leigh
Christoph Lange RDF/XML with its well-known flaws. It's ugly for human authors/readers and hard to process with XML tools.
The incoherent treatment and incomplete support of containers and collections (at least SPARQL 1.1 will improve that a bit).
Manu Sporny The lack of good tutorials, lessons, videos and clear explanations and information on the data model. Evangelizing the benefits of RDF have clearly not been a priority for W3C, but perhaps that is because it's use isn't clear at first... it takes a deep understanding of RDF to understand why it's powerful and that knowledge isn't being distributed in a way that is good and efficient. Part of the blame is probably because of the RDF/XML serialization format - which is often associated as one and the same with RDF.
Paul Tyson
Holger Knublauch
Lee Feigenbaum
Masahide Kanzaki language tag in literal (and some of datatypes)
Abhik Banerjee only thing I dislike , is people cant agree on standards and mostly after the extension of RDFa , it seems to be more challenging and bright scope. yet to explore the functionalities of RDFa though.
Pierre-Yves Chibon There are a huge number of how-to out there and it is not always clear where is the best source of information.

I am having trouble sometime to find the structure used in a rdf when it is embedded in a sparql endpoint.
Olaf Hartig * It has no proper mechanism to make statements about existing RDF triples.
stéphane pouyllau the confusion with XML.
Philipp Schaffner To the public, RDF doesn't seem to come across very applied resp. user friendly. A nice handbook/manual like 'http://rdfmanual.w3.org' with a minimum on information (reduced to the max!) would be important. Especially the practical part (namespaces and the usage of qualified vocabularies) would be essential there!
Paul Hermans
Gautier Poupeau We need lots of time to understand all the aspects of RDF technologies. Contrary to XML, you can't just make an example to understand what RDF can offer to you, maybe, because, you need and a solid background in different domains to see all possibilities. We may need more examples, use cases and official primers with comparisons (like http://www.w3.org/DesignIssues/RDF-XML.html or http://www.w3.org/TR/sw-oosd-primer/) to explain the interest of this technology.

The semantic and the status of some RDF features are not clear (bag, list, reification) and it is very difficult to use them in a production environment.

The RDF/XML syntax are not predictive and it's difficult to explain we can express the same things in RDF/XML with different ways. People using XML see just XML syntax and don't understand why we can't validate the RDF/XML file.

The desynchronization between the different W3C recommandations is a problem, even if I understand the reasons. For example, SPARQL introduces officially the named Graph feature but we can't serialize it with a CONSTRUCT. OWL 2 introduces some new syntax, but it's hard to see the status of these syntax with RDF.
Nina Jeliazkova A. Personal dislikes:
1) RDF tools are generally heavy, require substantial computing and memory resources.
2) related to 1) - All RDF serialization currently is way too verbose.
3) No tools, supporting RDF parsing within web browser (e.g. compared to JSON/XML)
4) Lack of streaming parsers/writers.
5) Reasoning generally require gathering triples in a single storage. Stream reasoning is in its very early days.

B. General impressions from dealing with RDF within an international multidisciplinary project (http://opentox.org)

1) The concept of triples / ontologies as description of domain objects seems to be hard to grasp for some. Computer science background helps, since the education normally include notion of predicate logic.
2) People look for "structure" (like tabular one) in the RDF /XML file and are discouraged by not finding such. The concept of the "structure" as relationships defined by triples seems to be an obstacle.
3) There is a preference for human readable representation and RDF doesn't have a strong point here.
4) RDF technologies are still not mainstream and not so familiar in general, as e.g. relational databases. Advantages are not always obvious.
Olivier Grisel The lack of official & intuitive JSON serialization format with namespace support to make it trivial for standard web developers to use RDF as the lingua franca for RESTful APIs. The turtle concision is nice but turtle parsers are not available by default in web browsers. A JSON version of turtle is lacking.

I also think that the triple-focused way of introducing RDF makes it hard for developers to grasp the RDF concepts while the entity/properties or resource/properties ways of thinking is ubiquitous among developers thanks to the widespread usage of Object Relation Mappers.

Also it would be great to have a standard way to trace provenance of triples and tooling or recommendations to make it easy to incrementally sync triple stores (RDF diff?) using standard web APIs such as SPARQL endpoints.
Jeen Broekstra RDF/XML syntax, blank nodes in their current form, and the fact that it takes so dratted long to "get" this stuff (not sure if that is because of RDF or because I'm a lousy teacher, to be honest :))
Armen Martirosyan (a) Misuse of semantics in apps. (b) The separation of RDF and RDFS vocabularies. Sometimes it seems to me artificial and not intuitive and I think it could be done better and sometimes it's hard to remember what names are from what vocabularies: for instance, rdf:Property vs. rdfs:Class. (c) Literals can't be in "subject" position, blank nodes can't be in "predicate" position.
Josh Jonte The inability for people to acknowledge what it enables. The lack of appreciation around it, it seems to get very little respect.

The lack of industry support from big players: Microsoft, Google, etc.
Bob DuCharme Representation of containers and lists is just too complicated, and that's why no one uses them.
Brian Peterson Reification should be easier to use; associating a URI with a statement should be more efficient than generating another 3 statements. In particular, saying something about a triple should be more efficient.
Quentin Reul Although the introduction of n3 or turtle solve this problem to some extension, XML/RDF serialisation of RDF is very difficult to use and to know when modifications have been made to contents. Plus, most of the existing RDF editors tend to rewrite (serialise) content as they please.
Yann Mombrun There are too many way to serialize graphs. That the reason why it's difficult to use.
For instance handling Bag, Anonymous Resources, Reifications... are kind of advanced features thare are not always easy to understand (and to process).
Peter Andersen The lack of a proper XML schema for RDF. Let it be optional in the same way that OWL/XML is.
Colm Kennedy
Ruben Verborgh It is hard to represent vague statements.
Representation of reification is cumbersome.
Gunnar Grimnes
Patrick Stickler The lack of a standardized RDF query language that is optimized to serve the needs of, and is easily approachable by, common software developers and "power users". SPARQL is a huge disappointment due to the often horrifically baroque and convoluted forms of expression needed to capture otherwise simple query expressions common in other database query languages.
Jean-Paul DECLE Many users need a methodology to validate their descriptions. Sometimes it seems the language needs more constraints
Rinke Hoekstra The part about *how* you should publish RDF online, access it online, and refer to 'bags' of triples was never part of the RDF specification. This makes RDF rather old fashioned, and has had impact on standards that depend on it: the owl:Ontology element in OWL ontologies is one example. It had to be created to be able to identify the set of statements that make an ontology, as RDF did not provide such a mechanism.

Also, I feel it is a pity that the semantics of RDF reification is so troublesome. I know there are very good reasons for why it is the way it is, but it has caused a lot of confusion (and still does). Its main use case is the ability to point at a particular triple, and make statements about it. Some solution along the lines of named graphs seems better.

The lack of a way to state 'sameness' (to whatever degree) between two resources is a big problem on the Linked Data web. The owl:sameAs construct is now being (mis)used all over the place, but it has a much stronger semantics than what one needs.

The last thing I don't like about RDF is its official syntax. I understand the political reasons for having an XML serialisation of RDF graphs, and I doubt there could be a better one, but it is overly verbose and cumbersome to deal with.

Renaud Delbru blank node. blank nodes are a hell to manage during data integration and underlying backend systems. the only working and viable solution is to rename all blank nodes into URIs. So, why not remove blank nodes and simplify data processing.
Jochem Liem RDF:List seems to me to be a datastructure, and does not give the ability to add semantics. A list with three cities does not give any information about what this set/sequence represents. The representation of sequences and sets could be improved.

It is not possible to have 'instances' of properties. The URI of the property definition is always used in (subject, property, object). There are many instances when you would want to refer to a particular instance of a property. E.g. to add properties of the relationship (probabilities, strengths, or features) or to represent n-ary relationships. Having the possibility to (optionally) create an instance of a property would make life much easier (R1, instance_of, R).
Axel Klarmann It does not embed into existing documents very well, standards like RDFa are jumping into this gap already but a recommandation would be great. Finding an appropriate ontology is difficult, as there is no central repository and people are not encouraged to join forces and develop a common ontologies. Maybe it is possible to build a hierachy of ontologies from meta-meta to specific ontologies, with an index.
Trust and verfication is a big concernc, i thought on xmlsig already, to enable those features.
Chimezie Ogbuji
James Hendler RDF (including RDFS) missing some critical functionality, OWL adds too much - need a simpler middle level for many key apps and RDFa uptake
Mike Dean
Andrew Perez-Lopez I feel like the notion of a RDF document is one that should be better defined. I also think that RDF literal typing and units can be problematic. I understand why literals of different datatypes should be considered unequal, but in practice it often means that systems must either fully implement data validation thoughout, or not use typed literals, neither of which is a desirable outcome.
Hassan Ait-Kaci RDF has a uselessly complicated formal semantics. Its notion of "blank node" is silly, useless, confused, and confusing (including and especially in the "official" formal semantics provided by its designers and logician helpers).

In addition, it restricts types of nodes depending on where they are (subjects or objects) and makes a useless difference between sets and individuals. Also RDF lacks a clear treatment of how to merge RDF graphs (which OSF graph unification is precisely designed for by extending unification to work over arbitrarily constrained graph objects).
Jamie Taylor The tremendous amount of baggage that W3C RDF usage carries with it.
- The emphasis on serialization in the explanations of RDF dilutes the simplicity and power of the message (you don't teach an OO language by looking at the output of the compiler.)
- RDF works without DL, but too often people who simply want to make basic factual assertions get an earful about vocabulary design, OWL, DL...at which point they drop out of the conversation since they don't have a need for that, but don't understand what is possible without it.
- Words like "inference" creep into W3C discussions of simple RDFS constructs. While true, no one talks about the ontological commitments their compiler's type system is making for them when learning to program.
- Colloquial usage of W3C vocabularies would be better than no usage. The subtle debates/advice people get over sameAs, seeAlso, SKOS, etc. don't provide much guidance for practitioners who simply want to use the technologies. Early browser vendors subscribed to the motto of "render anything" - bad HTML was better than no HTML. The RDF community should be focused on uptake, less on the message that "you are doing it wrong."
David Wood The RDF/XML serialization format's verbosity, and silly arguments over esoterica.
Mischa Tuffield In short SPARQL and RDF should be more closely aligned. I feel that standardizing turtle would help do this. I dislike that there are things I can write in a legal RDF (lets say RDF/XML given rec status) document that I can subsequently import into a standards compliant triplestore, which I can't SPARQL. This is touched upon in :

http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#RDF.2FXML_and_RDF_Concepts_Errata


For example (in turtle - like RDF/XML accepts the below triple):

<http://example.com/doc/#foafperson> foaf:page <http://example.com/html/this`page> .

Where <http://example.com/html/this`page> is a legal URI Ref

and where it is not a legal IRI as per its RFC.

If written in RDF/XML it would be valid, as per the spec, due to the use of the term URI Ref, given that it pre-dated the IETF IRI spec.

So, this wasn't that big a problem for me, up until the coming of SPARQL Update. Update is great (all be it work in progress), but it is moving to a world, where not only querying, but uploading/updating data can be done in a standard way.

Sadly, the above triple if used in an INSERT function (below) in SPARQL (given that the original SPARQL rec mandates the use of IRIs, I can't see the current WG moving to a world of URI Refs and not IRIs) :

INSERT DATA {
<http://example.com/doc/#foafperson> foaf:page <http://example.com/html/this`page> .
}

Is not valid SPARQL. It should be noted that I don't feel that this means that there should be a revision to RDF/XML, but I do feel that what ever future rec's are developed to make sure that their is alignment in what is exactly meant by the term URI in both the data format and in the query language.
Kjetil Kjernsmo RDF/XML syntax :-)
Renato Iannella Over promising by the community!
Ivan Herman
Toby Inkster Seemingly arbitrary exclusion of literals from triple subjects.

The ability to use blank node predicates would be good too.
Peter Mika
Steve Harris RDF/XML syntax
Bob Ferris The problem that people often don't like RDF, because they are thinking that RDF == RDF/XML. That was from my point of view the biggest mistake, which have been done until now. We have N3 and RDF is only a subset of N3. So I would like to prefer N3 and Turtle instead of RDF. However, this change will still take some time. So we still have to deal with RDF right now.

To mention also some specific examples:
rdf:List and rdf:Seq ;)
Charles Nepote Triples lacks of context. Reification is complex.
Jun Zhao Unable to express context information for triples, in any level of granularity, be one triple or a collection of triples.
Chris Beer Not easy enough for non-technical users to implement as say, <meta> html / dublin core etc was. Hasn't gotten a wide enough exposure yet.
Christopher Welty Lack of named graphs.
James Myers
Ryan Kohl Statement reification is unfortunately ugly, and introduces obvious impediments to querying. I REALLY hate the syntax for lists, with the 'first' and 'rest' predicates. I do understand how this syntax allows for a direct closure of the list, but damn these structures are hard to parse in sparql or wholecloth code.
Lowell Vizenor
jans aasman [1] It sometimes is a little too verbose. Especially the datatypes.
Marco Neumann the documentation at w3c is difficult to access. But it has to said that this has recently changed to the better with the new site.
David Peterson It can be quite verbose and there are not a lot of main stream tools that produce or consume it.
Kai Eckert
Irene Celino complexity of reification
blank nodes
Dave Reynolds RDF/XML is pain for the generic XML tool stack to work with.

The difficulty of communicating the RDF-as-lightweight-KR approach to
communities who think in terms of data models. IMHO the benefits of the KR approach outweigh the costs but I acknowledge the cost of the mismatch in styles.

The fact that, for whatever reason, there seems to be an impression of
past overhyping which leads to allergic aversions to RDF.
De Roo Jos
David Booth
Sergio Fernández The serializations historical issue is something that confuse people (still many people thinks that RDF is just a XML schema), many stuff is not so useful (collections for instance), many issues related with SPARQL/SPARUL, etc
Ted Guild
Gregg Kellogg Terminology is too academic/arcane for the general web community. Background and general direction is set by academics with a long-term stake in RDF, but whom are also responsible for the glacial pace of roll-out and adoption of RDF within the web community.
Ian Horrocks Blank node semantics make it not so simple
Idiosyncratic restrictions on use of literals and blank nodes
Lack of any quotation mechanism (e.g., named graphs)
Micah Herstand I don't like the ambiguity as to what, exactly, RDF refers to - whether it is just an EAV + URI data model or whether there is more implied in the name.
I don't like that it is being sold as a "data triple" model - I believe the standard should be quads, with the fourth parameter a URI to provenance data; I don't like how little provenance figures into day-to-day RDF use and discussion.
I don't like that RDF is considered a "graph" in common parlance, since, as TBL says "data is relationships", whereas relationships (edges) on graphs are usually meaningless, except for potentially having weight or direction. We need a new metaphor.
I don't like that there are so few resources online for teaching RDF, as compared to other web technologies and that there aren't clear, easy to find, in-depth use cases for every day uses, such as posting a CV online.
I don't like that the tools, such as protege, are so crippled (do not allow quads or full UTF-8 support, etc.)
I don't like that there isn't a top-down effort to provide a repository for ontologies and use cases.
I don't like that the online tools for validation and inferencing don't work on large data-sets.
I would like to see a greater emphasis on the attribute/predicate part of triples and such that blank nodes are not such a big deal and are actually dynamic parts of the language even when not necessary.
Aidan Hogan Too much baggage on every level. Hides what is, at its core, an intuitive model to grasp.
Graham Klyne XML syntax - but I can live with it
Over-complex mechanism for handling data types - wish we had adopted an "interpretation properties" approach advocated by DanC and others - but I can live with it.
Reification - but I can ignore it
Inconsistent status of "named graphs" - but I can fudge it
Andy Seaborne RDF/XML
RDF collections 9but we must live with what we have)
Mohamed ZERGAOUI Strange relationship with namespaces
Slow
Christophe THOVEX Needs enrichment such as OWL or FOAF to be used in powerful applications design.
Richard Cyganiak 1. Total flexibility, extensibility and generality means that simple things often are hard; 2. Useless baggage from RDF's roots in knowledge representation; 3. RDF/XML
Nathan Rixham documentation is pretty much serialization specific (RDF/XML) should be serialization independent
reification, bags and sequences in the rdf/xml specification
subject and object definitions do not match (lack of literal subjects, lack of collections in the subject position, lack of graph literals)
Paul Trevithick Uneven support for named graphs in tooling and community. Datatypes and "units" support isn't great. Linked data is great for reading but nowhere near enough support for writing, access control, provenance, publish-subscribe, authorization, etc--all the upper layers. XML serialization should be moved away from.
Jérôme Mainka * XML serialization has some flaws which are difficult to bypass (qnames for properties: how do you encode <http://somepath/1> ?)
* tools are not always in sync with specs
* inference : RDFS is not enough (no transitivity, for example). OWL is too much.
Antoine Zimmermann The reification vocabulary is meaningless. Containers (Alt, Bag, Seq) are very bad. RDF/XML is awkward to use.
Henry Story the rdf/xml got people to confuse the syntax with the semantics. It is probably more complex than it should be, and difficult for people to parse using XML tools, though that can be solved with crystallizations http://blogs.sun.com/bblfish/entry/crystalizing_rdf

OWL should stop squatting rdf:List. They invented it, but to use it for parsing seems wrong.

The problem is not necessarily one that can be overcome by simplifying RDF. It has to do with the problem of people trying to use it with the wrong tools (XSLT, DOM). So most of this is being solved by better tools, but this is where the confusion stems from.

Also RDF/XML is just too difficult for people to understand. It would be much better if all formal documents used the Turlte notation (N3 if graphs are required) to explain things together with graph notations. The simplicity of the concepts are just lost in the rdf/xml notation.

Better distinction between RDF the model, and RDF/XML syntax.

The ugliness of not having subject string literals, which complicates the syntax. Better incorporation of graph notation - though it would be good to have the simplest notation make it more difficult to use graph notation or not even have it, in order to reduce the likelyhoold of people making statements about statements (pointing to statements is a better policy)

Things to be improved: the xsd spec could have an ontology published at its namespace
Frank Olken reification
Gavin Carothers Explaining that RDF/XML isn't RDF only a serialization of RDF.
Enrico Franconi Standard explained in a too complex way, as opposed to the equivalent way I mentioned above. RDFS is a mess and a non-intuitive language with bizzarre semantics; mistakes in the algorithm for RDFS.
Bryan Copeland RDF has a noble goal but something seems to be missing from its widespread adoption. The benefits of using RDF need to be more immediate and publicized. W3C and the Semantic Web community in general need to provide a venue for Semantic Web projects and collaboration around them. Something along the lines of a social portal where projects can be added and managed and/or a platform from which mashups can easily be created (and just use a sourceforge or github type site to do the community).

The Linked Data initiative was a positive step in the right direction, but it merely lists data sources and seems to lack the ability to attract developers, investors, mentors and evangelists to the Semantic Web as a platform. Going one step further to provide something like what Mashable did for XML/JSON Web Services which provides directories of APIs and mashup examples, only to do it for RDF-enriched Semantic Web content and some useful open source Linked Data mashup examples would lead to significant innovations and advancements in RDF adoption.

Lastly, one of the biggest challenges for me has been discovering and choosing the most appropriate vocabularies for certain types of data. More guidance in this area in the terms of an auto-suggest type search tool and/or taxonomy listing with specific appropriate vocabulary options (i.e. under the Careers category use this ontology, when marking up videos about science-fiction use this generic video ontology and this science-fiction ontology, etc...) and trust/semantic quality scores.
Emmanuelle BERMES RDF isn't actually that simple. Once you get passed the triple and URI first look, everything becomes overwhelmingly complex, especially when you need to express metadata provenance, complex statements, sequenced lists, etc.
Managing interoperability in such a flexible environment is not that simple either. There is a need to build community oriented best practices to manage that.
Finally, a thing I dislike with RDF is having always to explain its difference with XML - and often, explaining is just not enough. It's such a different way of thinking that people who are accustomed to XML just can't grab the RDF model. Especially with RDF/XML syntax, there is too much confusion.
Vojnisek Péter - rdf/xml is hard to process with xslt. needs to be standardized more.
- working with quantative properties is a bit out of the rdf space as literals.
hodder mary my engineers complain that it's too hard, too complicated and yet we need something like it for the data work we are doing

also.. some of the people promoting RDF are very snooty and it doesn't make it easy to advocate to funders and business people why we are using it.
Paul Wilton
Antoine Isaac Constructs were introduced counting on community uptake to clarify their usage (sets/lists) but that never really came.
Lack of appropriate tools to represent provenance/context (reification was here but never took off).
Fuzzy status of the syntaxes everyone is using but are not really official (Turtle)
Fabien Gandon non canonical XML syntax, mixted rdf/rdfs namespaces, blank nodes, half-baked reification
Palmisano Davide That's its formal W3C-endorsed serialization is XML.
Egon Willighagen
Reto Bachmann - that people still think it has to do with XML

William Waites * Making statements about triples (of particular interest, the time period when a statement is taken to be true and confidence in the truth of the statement) is hard. Reification is ugly and some say ambiguous.
* The concept of a graph - which I understand as a container of triples - which can be named or anonymous is ill-defined
* Many people still confuse RDF with a serialisation or data format when it is actually a data model
Sarven Capadisli It naturally appears complex because the immediate benefits are not obvious without diving head into Web architecture.
Ji���­ Proch�¡zka I dislike language tags, literal datatypes. Preferential treatment of some relation and their inclusion in the core is a mistake in my opinion.
I dislike the trend of increasing the number of standard serialization which raises the difficulty of maintaining autonomous systems.
Stasinos Konstantopoulos
Olivier Berger Too many people think RDF == XML, so they prefer no discard it and go JSON or YAML directly, and miss some key feature : semantics, ontologies and likes... whereas they could have done RDF in JSON or in TTL... probably a "marketing" problem
Michael Hausenblas RDF/XML as the standard and default serialization has harmed adoption of RDF since it is difficult to teach and hides the abstract model.
Janne Saarela
François Scharffe its XML syntax because it's too verbose and reads badly.
There is no negation, I would like to be able to say that a triple is false, ex: "Mary does not have blue eyes."
Ora Lassila I would like to be able to have more "contained" class definitions (class + properties). This might be solvable using syntactic means only.
Ivan Mikhailov I dislike RDF every time I'm trying to store some physical data in it, like 0.15 kg/(V*A*h). However, the standardization of notation for these data should be separated from RDF core.

I also dislike RDF every time when I deal with pointers to some features of a resources, not to the whole resources. The problem is actually much deeper than some lack of specific features in a specific knowledge representation. That's more about our "inaccurate" habits. For centuries, a correct and complete reference to a whole book was rated as a "precise" pointer to the data. Now we frequently refer to pages, not to a book, and the precision will grow. HTTP anchors are just first examples. I guess that "#fragment" parts of IRIs will become more standardized as it happened already with whole resources, maybe the fragment string will be parseable as "access method + delimiter + protocol-specific text". This will require no changes in RDF core as well as in transfer of whole resources over network, but it will affect query languages, we will split and merge IRI strings more frequently and we will frequently join descriptions of resources with descriptions of their fragments comparing resource IRI and part of fragment IRI. This change will affect existing RDF storages.
Pierre-Antoine Champin Its XML syntax -- or rather the fact that it is the only official syntax.
Drew Perttula Currently too inaccessible to most developers. Needs better tools for viewing and editing, or for conversion to and from other systems.
John Goodwin
Dodds Leigh That the alternate syntaxes are not standardised.

That certain aspects of the model, particularly RDF containers and collections have specialised syntaxes but no support in, e.g. SPARQL, and poor support in tools.
Arpad Tamasi I think the community overestimated the promise of AI and went toward it like gold diggers to Alaska. I would prefer first going toward the computer itself, describing its low-level services, making them accessible accessed via triple-based protocols. It would be a good foundation to describe the world.
Dave Pawson It does not form a tree for more regular XML processing, and XML has not yet defined a directed graph syntax.
Yves Raimond * A lack of a good standard serialisation. It is bad that a non-standard serialisation (N-Triples) is being used in W3C recommendations such as the RDF Primer. Right now, the only standard serialisation for "raw" RDF data (which excludes RDFa) is RDF/XML.
* Lots of core RDF concepts ended up in 3rd-party ontologies, such as FOAF.
* The tools are not yet good enough. In particular the tools for managing OWL ontologies and associated RDF data are perhaps more impenetrable than they need to be.
* Contradicting specifications. For example, literals as subjects are valid in SPARQL, but not valid in RDF, therefore making it possible to write two standard-compliant softwares that won't be able to talk to each other.
michel bercovier heavy to implement
Bernhard Haslhofer In general: the predominant AI aspect in the last decade. Discussions always ended up whether or not reasoning is possible over large RDF data (knowledge?) sets and users never really understood the reasoning aspects of OWL.

wrt. RDF:
* Bnodes: I believe that BNodes should always have at least some urn:uuid identifier (...just think of calculating fingerprints for graphs with non-identifiable nodes)
* Reification: can't we simply get rid of it? I never used it so far....
* Collections: isn't there a better way to represent sets of literals or resources?
* RDF/XML: explaining to people that RDF is NOT XML is quite challenging because whenever they see RDF/XML they say: "but it is XML". Either get rid of it or better align it with the XML world (e.g., by introducing an XML Schema)
* No validation possibility: developers want to know whether or not the data they receive are complete or valid wrt. to some schema/vocabulary. I know that an XML-style validation is not possible because RDF is based on the open world assumption; but still: it would be great to give developers something like that...

Martín Álvarez The first impression is frightening, representing information in RDF is not trivial. It's a mess of namespaces, vocabularies, instances, etc.

The lack of tools to make edition easier.
Stéphane Corlosquet RDF/XML. lack of solid, easy to use implementations.
Paul Reeves seems complex although recent tools & apis help hide this
Nicholas Humfrey The perceived complexity and technical barrier of getting started with it. Still a lack of 'real-world' tools.
Evren Sirin
Niklas Lindström RDF requires an understanding of the triple model (and the open world etc.), as well as the precisions of URI:s, which although not truly hard, is still difficult to grasp for many people having more common, instrumental perspectives on data (e.g. relational or object-oriented).

I think the current specifications, data formats, and the existing API:s and tools for working with RDF have some way to go to bridge this conceptual gap. I do not suggest changing RDF itself for this, but to enable e.g. programming techniques for handling RDF which resembles more common data practices to a larger extent. And that RDF serialization formats are improved so they make more sense to a non-RDF expert (JSON, *simpler* XML, and Turtle).

.. RDF/XML should possibly even be declared legacy...

This also needs to be reflected in documentation/specifications, so that people coming to RDF can be gradually introduced to the foundation and possibilities which the underlying RDF model is about. (I think the RDFa working group is a good example of how to work towards this, and the Linked Data movement in general.)

(Also, the higher-levels of the stack, i.e. reasoning, OWL etc., probably needs to be (even more) clearly defined as "advanced usage" on top of RDF core, so that people e.g. don't expect OWL to be "just a schema language for data records"..)
Michael Schneider * the syntactic restrictions on triples: no literal subjects, no blank predicates
* RDF/XML as the primary serialization
Vadim Eisenberg
Steve Speicher Even though the basic concepts are simple, often it is often seen as being very difficult and academic (suffered from this initially).
Support for W3C non-XML formats
Variability in XML format (most in bringing in people with strong XML background)
Peter Jeszenszky
Raphaël Troncy 1/ Primarily, its official syntax. I have nothing against XML, but if an XML syntax was to be chosen as the official syntax, I would have preferred to have it constrained with an XML Schema. There has been a XML presentation syntax proposed by Euzenat et al. but this one has rarely been used. The problem with this unconstrained XML syntax has blocked simple interoperability for years, the time we had parsers that could barely parse all possible variants.

2/ The (or lack of) way collections, sets, bags, lists are managed

3/ The lack of mechanism for attaching provenance to graphs and the fuzziness in interpreting reification
1 1 1
555-555-0199@example.com 555-555-0199@example.com

7. Most Important Addition to RDF

Is there some addition or backward-compatible change to RDF that you think is very important? If so, you may state it here. (Later in the survey, we ask your opinion about specific proposals people have made.)

If you state a proposal, please include your rationale.

Details

Responder Most Important Addition to RDF
Sandro Hawke JSON syntax
Melvin Carvalho WebID support
Axel Polleres Personal priorities:

1) The ability to identify graphs.... my proposal is to start with named graphs, see http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist , i.e. making "datasets" (in the sense of SPARQL) an upwards compatible replacement of the single notions of "Graphs"

2) Adding time to RDF (could be realised on top of 1) probably)

3) Adding other common contextual information to RDF.
Eric Prud'hommeaux sets, extensible lists.
James Leigh
Christoph Lange
Manu Sporny JSON-LD is vital to furthering RDF adoption (and PaySwarm):

http://rdfa.digitalbazaar.com/specs/source/json-ld/
Paul Tyson Named graphs, bounded graphs, provenance, reification
Holger Knublauch
Lee Feigenbaum
Masahide Kanzaki graph identification
Abhik Banerjee the annotations as described in RDFa
Pierre-Yves Chibon - I believe the negation is not present in rdf.
Olaf Hartig * A proper reification mechanism.
stéphane pouyllau predicate
Philipp Schaffner
Paul Hermans
Gautier Poupeau Named Graph, to clarify or to deprecate some features (reification, bag, list), to simplify or to restrict RDF/XML, new official syntax (JSON, Turtle), better explanations what an URI means
Nina Jeliazkova Streaming read/write tools;
SPARQL update ;
Web Browsers support for RDF;
Recommend/develop standards for secure (read/write) access of distributed resources; possible integration with FOAF/SSL, RDF ACLs
Olivier Grisel An easy JSON syntax to be used as gateway drug for web developers.
Jeen Broekstra Standardisation of a friendlier RDF syntax (Turtle, or a more sane XML serialization, like TriX). One of the things (in my experience) that most often puts newcomers off RDF is the unreadably RDF/XML syntax.
Armen Martirosyan There are things I'd like to see in RDF, but I can't choose one and say that that one is the most important or critical.
Josh Jonte
Bob DuCharme Make turtle a standard.
Brian Peterson
Quentin Reul The aim of RDF is to have data published on the Web, and thus it is primordial that backward-compatibility is ensured.
Yann Mombrun As it's done in OWL (with profile) there should be profile to define what kind of feature are enable in RDF. (reification, anonymous resources...)
Peter Andersen
Colm Kennedy
Ruben Verborgh Vagueness.
Gunnar Grimnes
Patrick Stickler Make named graphs standard.

Allow literals as subjects.

Standardize well defined query response options to SPARQL DESCRIBE (including Concise Bounded Descriptions and Symmetric Concise Bounded Descriptions) as well as allow for the specification of other custom system supported response options.

Standardize other non-XML serializations.
Jean-Paul DECLE
Rinke Hoekstra Named graphs, and a sameness relation that takes context (i.e. named graph) into account. Turtle as official syntax.
Renaud Delbru
Jochem Liem As mentioned in 9.

1. Have the possibility to define a URI for an instance of a property, and to give this property instance relationships of its own.

2. Adding better representations for sequences, sets, etc. compared to RDF:List. Perhaps by adding more semantics on the RDFS or OWL level to indicate what a particular set/sequence of instances mean.
Axel Klarmann Trust and verification should be added, maybe a binary format is a good option. There are some additions that may come from topic maps, like scope of predicats, realtions, objects (for different languages for example)
Chimezie Ogbuji
James Hendler RDFS extended to include slightly (but only slightly) more functionality - a named sublanguage in this area is crucial
Mike Dean
Andrew Perez-Lopez
Hassan Ait-Kaci My proposal is to approach RDF formulating it as a Typed Graph-Constraint formalism. RDF objects ought to be mergeable and unifiable according to a simple approximation semantics refining graphs accroding to their information contents.
Jamie Taylor
David Wood Named graphs.
Mischa Tuffield I think that RDF/XML should stay how it is. I feel that there are plenty of mature codebases which use RDF/XML, and it should remain untouched.

I would like to see Turtle standardised, and possibly aligned with SPARQL.

I would like to see some standard format which supports named graphs, even if it is as verbose as nquads. I feel that nearly all triplestores implement named graphs, and it would be nice to have it standardised. I don't think this implies that there should be any changes to existing rec's/standards, i.e. RDF/XML or RDFa. Given
Kjetil Kjernsmo Named graphs support.
Renato Iannella
Ivan Herman
Toby Inkster
Peter Mika
Steve Harris Nothing.

RDF is so widely deployed that adding anything will cause significant disruption, and potentially harm future adomption.
Bob Ferris Context is always important (which is also provenance and versioning etc.), so we need a technique, which deals with that issue. This can be e.g. Named Graphs.
We are also always struggling with hard distinctions between datatype and object properties (but this is probably more related to the OWL). I won't really want to make a contributor rules, how he/she has to describe resource. We need freedom as we have also freedom in the real world to describe things (e.g. there should always exist an inverse property). So the technology must be able to deal with that freedom. As more freedom the user of a technology has, as more he/she will feel comfortable with that technology. This will hopefully lead at the end to more satisfaction and this should be the overall goal (always).
Charles Nepote Named graphs.
Jun Zhao It's important to remain the RDF/XML representation backward-compatible and any new recommendations shouldn't break the current triple stores and SPARQL etc W3C recommendations.
Chris Beer RDFa
Christopher Welty Add named graphs.
James Myers
Ryan Kohl A better list syntax would make my life 12 times better.
Lowell Vizenor
jans aasman [1] I'm tempted to say that we might get rid of the blank nodes as they sometimes add more confusion than that they help.
[2] Make reification less clumsy (although the triple store vendors should come up with an alternative to represent reification efficiently with the current rdf standard)
[3] Come up with a way to represent sequences (and arrays) efficiently, again: from a triple store vendor perspective this should be fixed at the storage layer.
[4] Get rid of RDF/XML, just use ntriples, or turtle or anything else but not RDF/XML.
Marco Neumann better standard for sorted and unsorted lists
David Peterson
Kai Eckert
Irene Celino named graphs
Dave Reynolds [Covered in existing proposals]
De Roo Jos RDF in N3
David Booth
Sergio Fernández lightweight serializations, make rdf/xml easier, take car of linked data principles, and so on
Ted Guild
Gregg Kellogg RDF/XML, broken as it is, should be updated to allow the full use of QNames/CURIES wherever URIs or QNames are used now.
Ian Horrocks Change blank node semantics to be Skolem rather than existential -- strictly speaking this is not backwards compatible, but in practice this is the semantics that almost *all* users of RDF use without even realising that it is strictly speaking incorrect.
Micah Herstand I think provenance needs to be built-in, supported, and evangelized by the W3C. My vote would be to use quads, where the fourth parameter is a URI to a provenance vocabulary (where each provenance "triple" would also be a quad and have its own meta-provenance). Queries like "give me all data published by ReadWriteWeb between 2008 and 2009 that has been quoted by CNN, as asserted by Google News and as scraped by DataProviderX" should be built-in to the language.
Aidan Hogan Addition of named graphs. Some recognition of Linked Data principles and best-practices for publishing RDF data on the Web. Recognise simpler fragment of RDFS -- along the lines of rhoDF -- which omits ContainerMembershipProperty hocus pocus, etc.
Graham Klyne
Andy Seaborne
Mohamed ZERGAOUI
Christophe THOVEX
Richard Cyganiak Named Graphs
Nathan Rixham subject and object both taking the same values (literal subjects), graph literals, collections in the subject position, and variables allowed even if not supported by specific or existing serializations.

Tidy up RDFS and add in much needed values which currently reside in owl and a few other ontologies - RDF should come with a base vocab that covers most rdf specific needs.
Paul Trevithick
Jérôme Mainka
Antoine Zimmermann A meaningful way of annotating triples or graphs (see http://www.w3.org/2009/12/rdf-ws/papers/ws09 for use cases).
Henry Story subjects as uris. Better support for graphs.
Frank Olken named graphs
Gavin Carothers
Enrico Franconi I like RDF as it is. Maybe triple reification/ids could be done better. RDFS should be left behind.
Bryan Copeland SPARQL, RDF & RDFa parsers, authoring tools and editors (Protege, OntoStudio, TopBraid, etc).
Emmanuelle BERMES
Vojnisek Péter Semantically described query language. (query described in rdf)
hodder mary
Paul Wilton in no particular order, just some ideas really:
1. Standardising an RDF/JSON format (eg prefer that forward by Talis )
2. incorporate OWL into RDF
3. Improved support for schema versioning
Antoine Isaac Context/provenance/containment info.
Clarifying the situation wrt. sets/lists and the alternative syntaxes to RDF/XML.
Fabien Gandon Graph identification / Named Graphs
Palmisano Davide
Egon Willighagen
Reto Bachmann - named resources: a resource should be allowed to have 0 - n names. Currently there's no unique name assumtion but no way in rdf to express multiple names of a resource
- datatypes: should be mapped to properties. The architecture could be generalized / simplified by defining x^^eg:t a being a shortcut for [eg:t x], this would bring avanatages especially when multiple dataypes can be used to express a value.
William Waites * add an rdf:graph predicate so that reification can extend to the notion of quads where reification is required
* pull rdfg:Graph into the main spec.
* explicitly codify the notion of a graph as a container of triples. where, in a document, no graph is specified, it can be taken to be an anonymous graph
* determine to what extent it is sane to make statements about a graph that apply to all contained statements as a possible alternative to reification, possibly with the rule (abusing and extending the notation):

{ ?g a rdf:Graph .
?g { ?s ?p ?o } .
?g ?x ?y } =>
{ ?S a rdf:Statement .
?S rdf:subject ?s .
?S rdf:predicate ?p .
?S rdf:object ?o .
?S rdf:graph ?g
?S ?x ?y }.

(this example conflates statements about the graph with
statements about the triples in the graph, which might be
expressed with a suitable restriction on ?x or in some other
manner, but I think it conveys the gist of the idea)
Sarven Capadisli
Ji���­ Proch�¡zka RDF simplification, weak deprecation of RDF/XML (no redesign),
better documentation especially for ways of working with named graphs.
Stasinos Konstantopoulos
Olivier Berger
Michael Hausenblas 1. Ability to identify graphs (e.g., via named graphs), because
this is a necessary foundation for the representation of time,
provenance, and other aspects of context.

2. W3C should take steps to ensure that full-featured alternatives to RDF/XML exist for all current uses of RDF/XML.
Janne Saarela
François Scharffe
Ora Lassila
Ivan Mikhailov I'd freeze the model. Syntax (or multiple syntaxes) is not the issue, especially if the dialect can be easily identified, but the model should stay as it is.
Pierre-Antoine Champin Named graphs.
(2nd choice: standardize N3/Turtle)
Drew Perttula
John Goodwin
Dodds Leigh Standardise the alternate syntaxes that are already in common usage.

Properly integrate the notion of Named Graphs into the core specification.
Arpad Tamasi A good foundation by a vocabulary for describing computers and services on the low level.
Dave Pawson
Yves Raimond * A good standard serialisation for raw RDF data.
* Ability to group statements, using SPARQL-like Named Graphs, N3-like graph literals, or a similar mechanism. This should also include the ability of specifying graphs within graphs, or to make a single triple belong to several graphs. We should be able to cluster triples according to several dimensions - for ACL, provenance, etc. Ability to serialise this information.
michel bercovier interactive pre processor
Bernhard Haslhofer * named graphs (most systems already implement it, so the spec should also define it)
* JSON serialization (useful for Web (JS) developers)
Martín Álvarez
Stéphane Corlosquet Turtle, Named graphs
Paul Reeves not to RDF as sucg but SPARQL must be able to modify/update graphs
Nicholas Humfrey Official standardisation of additional serialisation formats, such as JSON, Turtle and N-Triples.
Evren Sirin
Niklas Lindström Make named graphs (contexts) a part of how to *use* RDF. Like a specified practice for how to "package" bounded descriptions and share them (i.e. relating them to representations, and defining how to deal with provenance by using them).
Michael Schneider Among the concrete work items presented later in this survey, I see as most relevant:

* "generalized" RDF triples (including literals as subjects);

* standardizing Turtle.

I will comment on these points at the respective work items. Further points relevant to me but not mentioned in this survey are:

A) a small collection of normative datatypes, consisting of at least xsd:string and xsd:integer;

B) merging the RDF Schema spec and the RDF Semantics spec into a single document (editorial).

Rational for A: Currently, the RDF spec does not mandate any datatypes (note, the list of XSD datatypes in the RDF semantics specification is /not/ a normative list). The RDF semantics (more specifically D-entailment) only defines a semantic framework for introducing datatypes called datatype maps. Many people seem to expect that at least xsd:string and xsd:integer can safely be used in an RDF context, and many RDF systems offer support for these and other datatypes. At the moment, however, the only W3C-official semantic extension of RDFS that supports these two datatypes is OWL (1/2) Full.

Rational for B) The RDF Schema spec and the RDF Semantics spec talk pretty much about the same thing, just providing different perspectives and levels of detail. The content of the RDF Schema spec is much more intuitive and easier to understand for most people while the RDF Semantics spec is technically much more precise to the level of allowing for exact mathematical analysis and for proper semantic extensions and combinations with other formalisms. Having two documents, both being W3C Recs, always looked strange and redundant to me. I would like to see a single document with basically the content of the RDF Schema spec as the main informative explanation of the RDF semantics (non-normative), while the model-theoretic semantic conditions of the current RDF Semantics spec, together with some more technical explanation, could then be given concisely (e.g. in tabular form) in a single normative appendix.
Vadim Eisenberg Procedural Attachment - similar to Stored Procedures in the relational databases. To enable RDF properties to be "procedures" in some programming language and be equal sitizens to the regular RDF properties. This way RDF "procedures" could participate in SPARQL queries and in reasoning.

For example, foaf:age could be defined as "procedure" that would return currentDate() - foaf:birthDay in some programming language. foaf:age would be equal citizen to other properties, so it could be queried via regular SPARQL syntax: SELECT ?age WHERE { <www.example.com/persons/1> foaf:age ?age }

foaf:age defined as procedure could also participate in OWL ontologies and be subject to reasoning. For example, for class SeniorCitizen a restriction on foaf:age could be >= 65.

The "procedure" foaf:age would be called both during the SPARQL queries and during application of the reasoners and would return the current age of the person.

The code of the "procedure" property could be specified in an ontology as a property of the property (here a non existing property owl:code is used):

foaf:age owl:code "return currentDate() - foaf:birthday"

The SPARQL query processors and reasoners could be changed to run the code of the property once they encounter a property with owl:code property attached to it. The procedures could be integrated more naturally in Semantic Web than the stored procedures in relational databases due the fact that the "procedure" properties will be transparent to the writers of queries/ontologies. The writers of queries/ontologies involving foaf:age could be oblivious to the fact that foaf:age is a "procedure" property and not a regular property as it is today.
Steve Speicher Support of Linked Data and further adoption of HTTP binding (SPARQL, SPARQL Update or ???).
Peter Jeszenszky
Raphaël Troncy 1) Clean syntax (based on turtle)
2) Named graphs
3) Collections/list/set/bags
1 1 1
555-555-0199@example.com 555-555-0199@example.com

8. Priorities

How important are each of these goals? (1=not at all important ... 5=very important)

Summary

ChoiceAll responders
12345No opinion
Make RDF smaller/simpler 37 19 12 12 23 24
Make RDF larger/more powerful 38 34 16 6 10 23
Redesign some parts of the RDF/XML syntax 28 22 17 21 11 28
Redesign some parts of the RDF model 28 20 15 30 9 25
Improve RDF's suitability for data/database work 11 9 17 31 32 27
Improve RDF's suitability for semantic/KR work 18 28 17 19 15 30
Provide better syntaxes for RDF 11 14 21 23 33 25
Provide better documentation 14 12 21 24 31 25
Explain the business case better 11 13 21 22 34 26
Provide better communication, community support 12 16 22 21 21 35
Help people find or develop RDF vocabularies 9 8 16 33 38 23
Develop more compelling applications 14 9 18 29 33 24
Develop standard vocabularies 10 14 17 35 32 19
Work on RDF Security 15 12 29 29 12 30
Work on RDF Trust & Provenance 6 9 24 44 26 18
Work on Synchronization, Distribution, and Versioning of RDF Data 7 9 30 35 23 23
Work on bridging between RDF and XML 31 13 20 13 14 36
Standardize RDF API in Javascript 13 17 20 28 21 28
Standardize RDF APIs in other languages 16 12 21 21 23 34

Averages:

Choices All responders:
Value
Make RDF smaller/simpler2.66
Make RDF larger/more powerful2.19
Redesign some parts of the RDF/XML syntax 2.65
Redesign some parts of the RDF model2.73
Improve RDF's suitability for data/database work3.64
Improve RDF's suitability for semantic/KR work2.85
Provide better syntaxes for RDF3.52
Provide better documentation3.45
Explain the business case better3.54
Provide better communication, community support3.25
Help people find or develop RDF vocabularies3.80
Develop more compelling applications3.56
Develop standard vocabularies3.60
Work on RDF Security3.11
Work on RDF Trust & Provenance3.69
Work on Synchronization, Distribution, and Versioning of RDF Data3.56
Work on bridging between RDF and XML2.63
Standardize RDF API in Javascript3.27
Standardize RDF APIs in other languages3.25

Details

Responder Make RDF smaller/simplerMake RDF larger/more powerfulRedesign some parts of the RDF/XML syntax Redesign some parts of the RDF modelImprove RDF's suitability for data/database workImprove RDF's suitability for semantic/KR workProvide better syntaxes for RDFProvide better documentationExplain the business case betterProvide better communication, community supportHelp people find or develop RDF vocabulariesDevelop more compelling applicationsDevelop standard vocabulariesWork on RDF SecurityWork on RDF Trust & ProvenanceWork on Synchronization, Distribution, and Versioning of RDF DataWork on bridging between RDF and XMLStandardize RDF API in JavascriptStandardize RDF APIs in other languagesComments
Sandro Hawke 4 2 2 3 4 4 4 4 4 4 5 5 5 3 3 5 4 3 3
Melvin Carvalho No opinion No opinion No opinion No opinion No opinion No opinion No opinion 4 No opinion No opinion 4 5 No opinion 4 4 No opinion No opinion No opinion No opinion I think Web of Trust can play an important role
Axel Polleres 2 2 2 1 1 1 3 2 3 3 4 No opinion 4 3 3 2 4 1 1
Eric Prud'hommeaux 1 1 3 2 3 2 2 1 3 3 2 4 3 4 5 2 5 2 2
James Leigh No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Christoph Lange 2 2 5 4 5 5 5 3 5 3 5 5 5 5 5 4 5 4 3 RDF/XML must die (if it were not for the backwards compatibility), so improvements are fine.
It is not your responsibility to develop standard vocabularies, but helping people to do so is something that you could possibly encourage.
On bridging RDF and XML: I consider this very important, and I still haven't understood what's so great about GRDDL. In the end it seems that most people don't understand what it is but mention that buzzword and think that it solves the XML→RDF translation problem. I haven't really seen the schema- and profile-specific features being used, and without them, it's just about getting the specific XML→RDF translation hard-coded in some language, e.g. XSLT. _That_ one could also do without a GRDDL "recommendation".
Manu Sporny 5 1 1 3 5 4 5 5 5 5 5 4 5 3 3 3 1 5 5
Paul Tyson 1 1 1 1 3 2 1 3 4 4 2 4 2 2 5 3 4 4 4
Holger Knublauch 4 2 3 2 No opinion No opinion 4 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Lee Feigenbaum 1 1 1 5 5 3 5 5 No opinion 5 1 1 1 1 3 1 1 2 2
Masahide Kanzaki 3 2 2 4 3 3 2 3 4 3 3 4 3 3 5 3 2 3 3 in my case, "parts of the RDF model" are lang tag and datatypes
Abhik Banerjee 1 5 2 2 5 5 2 2 4 5 5 5 5 No opinion 5 3 3 5 5
Pierre-Yves Chibon 5 5 3 5 5 No opinion 3 5 No opinion 3 5 3 5 5 No opinion 3 No opinion 1 5
Olaf Hartig 2 1 2 4 3 2 5 2 2 2 4 4 4 4 4 3 1 3 3
stéphane pouyllau 5 2 2 2 3 3 No opinion No opinion No opinion No opinion No opinion 5 2 2 No opinion No opinion 5 5 5
Philipp Schaffner 1 3 3 4 4 4 2 5 5 5 4 4 5 4 4 3 3 4 4
Paul Hermans No opinion No opinion 4 4 No opinion No opinion 5 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion 3 5 No opinion No opinion
Gautier Poupeau 1 4 4 4 5 4 5 5 4 4 5 4 5 3 4 5 1 2 4
Nina Jeliazkova 5 3 No opinion No opinion 5 3 5 4 4 No opinion No opinion 3 5 4 3 3 No opinion 5 5 "Develop more compelling applications" - this will come naturally with better / more efficient tools
Olivier Grisel 5 No opinion 4 No opinion 5 2 5 No opinion 5 No opinion 3 No opinion No opinion No opinion 5 5 No opinion 5 5
Jeen Broekstra 2 2 4 No opinion No opinion No opinion 4 5 5 4 5 5 5 3 3 4 5 2 2
Armen Martirosyan 1 5 1 1 5 5 1 1 4 4 4 5 5 5 5 4 5 5 4
Josh Jonte 5 2 1 No opinion 5 5 4 5 5 5 2 5 4 1 1 4 1 4 3
Bob DuCharme 4 3 4 3 3 2 4 4 5 3 4 3 4 2 2 4 3 4 4 "Help people find or develop RDF vocabularies" should be two entries, not one. The difficulty in finding (and identifying appropriate) vocabularies is what leads so many people to developing them.
Brian Peterson 2 2 3 4 4 2 2 1 1 1 4 2 4 1 1 1 1 4 1
Quentin Reul 2 2 5 1 4 2 3 3 2 2 1 4 4 5 5 4 4 2 3 Security, Trust and data protection are areas where SW technologies is lacking behind traditional knowledge representation systems (e.g. DB). Although the data should be made public, companies will want to have some of their data protected from outsiders. Similarly people consuming the data will want to know whether the can trust the provider of the data. This is especially important for companies developing mash-ups based on costumer's needs.
Yann Mombrun 5 2 2 1 1 1 3 5 3 2 3 3 5 2 3 4 5 3 5 Standardize syntaxes for RDF and restrict the use of this one.
Peter Andersen No opinion No opinion 5 5 5 5 No opinion No opinion No opinion 3 3 4 2 3 4 No opinion 5 4 No opinion
Colm Kennedy No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion 3 No opinion No opinion No opinion No opinion No opinion No opinion
Ruben Verborgh 1 5 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Gunnar Grimnes 5 1 1 1 4 2 5 5 5 4 4 5 4 3 4 4 1 5 5 RDF2 must in some way be backwards compatible to RDF1, focus on making current best-practises more formal and well document. I.e. deprecating bnodes + rdf collections seems like a good idea. Hammer home the point that schema URIs should in fact be URLs. Try to push (but do not change) rdf/xml as the format that works everywhere, but you never have to see. Use turtle for documentation + examples.

A usable ontology editor that does RDFS well would be great - now everyone takes protege, ends up with OWL and gets lost in a complexity they never needed. This should be backed up with better documentation of best-practises.
Patrick Stickler 1 1 1 2 5 2 4 1 1 1 1 1 1 3 4 3 3 2 1
Jean-Paul DECLE 5 1 4 1 1 1 5 5 5 4 5 4 5 3 4 3 1 4 5
Rinke Hoekstra 2 2 2 4 4 4 4 3 3 2 2 2 2 2 4 4 3 3 2
Renaud Delbru 1 1 No opinion 4 4 No opinion 1 1 3 3 4 3 3 No opinion 3 3 3 2 2
Jochem Liem 1 5 1 No opinion 4 5 1 1 1 1 1 1 1 No opinion 5 5 1 1 5
Axel Klarmann 2 4 No opinion 4 2 4 3 4 2 3 5 1 4 5 5 3 4 3 2
Chimezie Ogbuji 1 3 1 1 5 5 5 3 3 3 2 3 5 5 5 3 1 2 5
James Hendler 3 1 2 1 3 2 1 3 2 2 4 2 3 4 3 5 3 2 2 These questions are hard to answer as "RDF" is not actually defined (think of asking the same questions about XML). Does this include RDFS? SPARQL? OWL? RDFa? I answered the above assuming a narrowly scoped RDF-only charter, the minute it includes any of RDFS, SPARQL or RDFa my anwers would change (see above and below)
Mike Dean No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Andrew Perez-Lopez 2 2 4 4 5 3 5 5 3 3 4 4 4 4 4 4 2 2 2
Hassan Ait-Kaci No opinion No opinion No opinion 5 No opinion 5 4 4 No opinion 4 No opinion 4 5 4 4 5 No opinion No opinion No opinion Some questions in this list do not make sense to me -
- Make RDF smaller/simpler: simpler, yes!
- Make RDF larger/more powerful: more powerful, yes! - but this does not mean larger nor more complicated!
- Redesign some parts of the RDF/XML syntax: XML syntax is not for humans, so it is not so crucial to be readable except by machines, but a universally accepted and used human-readable notation would by all means be a plus.

Jamie Taylor No opinion No opinion No opinion No opinion No opinion No opinion No opinion 3 5 No opinion No opinion 5 No opinion No opinion No opinion No opinion No opinion 3 3
David Wood 3 1 4 2 5 2 3 3 5 3 5 4 4 4 3 3 1 4 3
Mischa Tuffield 2 2 1 1 5 4 5 No opinion 3 No opinion 4 5 No opinion 4 4 4 1 No opinion No opinion
Kjetil Kjernsmo 1 2 3 4 3 4 5 3 2 4 4 4 2 3 4 2 1 4 2 RDF APIs in other languages, business case and standard vocabularies are all very important, but should be done outside of W3C WGs.

Arguably, compelling applications should be done outside of WG work too, but that's the most important thing, so I think that W3C should commit some resources to it too.
Renato Iannella 5 1 5 4 4 3 5 5 5 5 5 5 5 3 5 5 5 4 3
Ivan Herman 3 2 2 2 4 1 4 5 5 5 4 5 4 4 4 3 3 4 3
Toby Inkster No opinion No opinion No opinion 5 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion 4 4 4 No opinion No opinion No opinion No opinion There are some things on the above list that I think should be actively avoided - for example any changes to RDF/XML's syntax would be a bad idea. It's certainly not my favourite serialisation, but I think it's important not to break it.

Something like literal subjects could be slotted into RDF/XML in a backwards-compatible way. e.g.

<rdf:Description>
<rdf:about-literal>Hello</rdf:about-literal>
<ex:string-length>5</ex:string-length>
</rdf:Description>

An RDF 1 parser would see this as a blank node with an rdf:about-literal property, whereas an RDF 2 parser would interpret it as providing a literal subject.
Peter Mika No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Steve Harris 5 1 3 1 2 2 5 4 1 1 3 1 2 4 2 2 1 1 1 Standardising a Turtle-like language would be helpful.
Bob Ferris 5 5 3 4 3 3 5 5 5 5 5 5 5 5 5 5 1 2 5 Well mostly every thing you've mentioned here is very important, because we need the whole stack to deliver a powerful application. However, often some issues will help to solve also issues, e.g. if we will have better documentations, then probably more people will apply this technique. Hence, they will hopefully develop good application with it.
Especially standardization, will help to deploy a good distributed, interlinked knowledge base.
Charles Nepote 5 1 No opinion No opinion 5 No opinion No opinion 1 3 2 4 3 2 No opinion 3 5 1 No opinion 5
Jun Zhao 1 1 2 2 5 4 4 4 4 4 5 5 4 3 4 4 3 2 2
Chris Beer 5 5 3 2 4 4 2 5 4 5 5 2 5 3 4 4 4 4 4 Q1 = Simpler
Q2 = More powerful
(You can do that can't you? Simpler AND more powerful? ;) )
Christopher Welty 4 1 No opinion No opinion 2 4 No opinion No opinion No opinion No opinion No opinion No opinion 4 No opinion No opinion 4 No opinion 3 4
James Myers No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Ryan Kohl 1 3 5 2 4 5 3 1 1 1 1 1 1 3 3 2 4 4 4
Lowell Vizenor 1 5 4 4 4 2 2 4 4 3 5 5 4 4 4 4 5 3 3
jans aasman 1 1 1 1 4 1 1 2 5 3 4 4 4 4 4 5 4 5 5
Marco Neumann 3 4 4 3 4 4 3 5 4 5 4 3 3 3 4 4 3 4 4
David Peterson 4 2 4 No opinion 5 No opinion No opinion 5 4 No opinion 5 4 5 No opinion No opinion No opinion No opinion 5 No opinion
Kai Eckert No opinion No opinion 4 4 No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion 4 No opinion 5 5 No opinion No opinion No opinion
Irene Celino 1 1 4 2 3 3 4 2 5 2 5 5 5 5 5 3 1 4 No opinion
Dave Reynolds 1 1 1 1 1 1 2 1 2 2 4 2 3 3 3 5 3 1 1 Some of these would be good goals during initial development but not good goals at the current state of deployment. Plus the context implies "goals for W3C" which is very different from goals in general. For example "compelling applications" is a great goal in general but not one for W3C.
De Roo Jos No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
David Booth No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
Sergio Fernández 4 2 5 4 4 2 5 5 5 3 2 2 3 4 4 3 3 1 3
Ted Guild
Gregg Kellogg 4 1 3 3 4 2 4 4 4 3 3 3 5 5 4 4 1 5 5
Ian Horrocks 4 2 No opinion 5 4 4 2 2 2 2 2 2 2 1 1 1 No opinion 1 1 In many cases where I gave low "ratings" it isn't because I think that the work is unimportant, just that I don't think that it is the job of W3C and/or a standardisation WG.
Micah Herstand 1 5 1 4 4 No opinion 5 5 3 5 5 5 5 4 5 5 No opinion No opinion No opinion
Aidan Hogan 4 2 3 4 4 2 4 4 3 5 4 No opinion 2 No opinion 4 No opinion No opinion No opinion No opinion Before tackling Security, Versioning, etc., look for the "low hanging fruits": named graphs, better documentation, community outreach, standardise Turtle.
Graham Klyne 2 1 1 1 No opinion No opinion 3 4 5 No opinion 4 5 4 No opinion 4 No opinion No opinion 3 3 At this stage, stability trumps functionality. Existing valid data must continue to be valid, and existing software tools must continue to be able to consume any newly generated RDF that is expressible using current RDF - i.e. no new structures for representing what is already commonly represented using RDF as-is.

Re: RDF API in Javascript - suggest using rdfQuery as starting point. Possibly also for other languages.

Security, trust, provenance, synchronization, versioning I think should not be specific to RDF, except to the extent that they may use RDF vocabularies to represent concepts; i.e. should also be applicable to non-RDF data. In the long run, I think the jury is still out that the RDF triple model is the right solution for the web of data, even if it's the best we have right now, hence I wouldn't want to bet the whole technology stack on the RDF model.

I want to actively oppose making RDF larger/more powerful, but don't know how to score that.

Not sure what is meant by "redesigning the RDF model" - if talking about the abstract syntax, then I oppose. If talking about improving the definition of RDF semantics (in compatible ways, e.g. per Pat Hayes ISWC presentation) then maybe.
Andy Seaborne 1 2 1 2 3 2 5 5 3 5 4 3 4 3 3 3 1 2 1 "Improve RDF's suitability for data/database work" without a proposal is quite unclear

"Work on" may include scoping possibilities as well as actual change.

API design is not best done in W3C.
Mohamed ZERGAOUI 1 4 5 4 5 3 1 1 5 2 3 5 5 1 5 1 5 4 5
Christophe THOVEX 1 1 1 1 4 4 No opinion No opinion 3 No opinion 3 4 3 2 2 4 3 4 4
Richard Cyganiak 5 2 1 1 5 1 4 3 1 1 3 3 3 1 2 3 2 2 1
Nathan Rixham No opinion No opinion No opinion 5 1 1 5 5 No opinion No opinion 4 No opinion 5 No opinion 3 3 1 5 No opinion re: Improve RDF's suitability for X, if you improve the model this should happen automatically.

re: Make RDF smaller/simpler/larger/more powerful, again this is conflating issues, RDF should be looser so that serializations can tighten up by supporting certain features.

re: trust, provenance, synchronisation, distribution, versioning - imho this is all out of scope, work could begin on this if the model was loosened up to be more n3-like (graph literals); get the model right and these headaches become much easier to handle.

re: backwards compatibility, this should be a non issue as any looser definition of RDF can be countered by defining existing serializations as including a subset of RDF's features - to limit the next decade based on the mistakes or lessons learned from the last decade is, imho, unethical.
Paul Trevithick No opinion 4 3 4 No opinion 4 5 3 4 No opinion No opinion No opinion No opinion 4 5 5 No opinion No opinion No opinion
Jérôme Mainka 1 1 4 3 4 4 5 4 4 4 5 5 4 5 5 4 5 4 4
Antoine Zimmermann 3 3 2 3 3 2 4 3 2 2 4 1 1 1 1 1 1 1 1 Redesigning the model to include a meaningful mechanism for annotating triples or graphs. Standardise Turtle as an alternative syntax (especially for presenting RDF in documentation). The low grades mean that these goals are not to be tackled by the future Working Group. They are important goals otherwise.
Henry Story 1 4 4 4 No opinion No opinion 4 4 No opinion No opinion 4 4 4 4 4 4 4 3 No opinion all the above questions are very tricky.

A lot of those are solved already: bridging RDF/XML is done with GRDDL, though it may need some tweaks (have not tried it yet)

Better syntaxes exist: perhaps standardising N3 and turtle.

Tweaking RDF/XML could lead to a lot of confusion. So one should be very careful.

Good use case: Social Web based on RDF.

Perhaps standardising RDF API in Javascript, though the issue of rdf javascript crystalisation may just reapear there as it does with XML.
http://blogs.sun.com/bblfish/entry/crystalizing_rdf
Frank Olken 2 5 2 4 4 5 2 3 2 2 4 4 4 1 4 3 2 3 3 Need better toolsets, standards for rendering RDF comparable to XSLT, path expressions, and CSS for XML
Gavin Carothers 1 1 5 1 2 1 3 4 5 4 3 3 2 4 4 3 1 5 5
Enrico Franconi 5 1 1 3 5 1 3 5 1 1 1 1 1 3 3 3 3 4 4
Bryan Copeland 2 3 1 2 4 3 3 4 5 4 5 4 1 1 4 2 3 4 4
Emmanuelle BERMES 3 2 2 2 No opinion No opinion 4 3 5 5 4 5 3 3 4 5 3 No opinion No opinion
Vojnisek Péter 2 1 1 1 2 3 5 1 1 1 5 No opinion 5 5 5 3 4 1 1
hodder mary 5 3 4 3 5 5 3 4 4 4 4 4 4 3 3 3 4 4 4
Paul Wilton 2 3 4 4 No opinion 5 4 4 3 4 4 3 4 4 5 5 2 4 4
Antoine Isaac 2 2 1 2 2 1 3 2 2 2 4 5 4 2 4 4 2 3 3
Fabien Gandon 1 1 5 4 2 3 5 3 3 3 5 4 4 3 4 3 4 5 5
Palmisano Davide 1 1 5 1 4 2 3 5 5 5 5 4 5 1 1 5 1 3 5
Egon Willighagen 1 1 1 1 1 1 3 3 3 1 1 3 2 3 3 5 1 5 5 I like the family of standards and tools quite as they are now. If the W3C does want to continue, I think a focus on standardizing APIs and work on RDF data versioning are interesting efforts. A good RDF API in JavaScript would be rather important to simplify integration into the HTML5 world.
Reto Bachmann 1 3 2 4 4 2 No opinion No opinion No opinion No opinion 4 No opinion No opinion 4 4 4 No opinion No opinion No opinion
William Waites No opinion No opinion 1 3 5 5 No opinion 5 No opinion No opinion 5 5 5 No opinion 5 5 No opinion 4 No opinion Provenance is a crucial component in our work with data.gov.uk and the EU. It is an incompletely developed area though some important strides have been recently made at the Universität Leipzig and Oxford University. However as we are concerned here with talking about statements, where they come from, how they came to be, what degree of confidence we have in their accuracy, we are pushed into reification which is an area where RDF is weak. See previous comment for some ideas on how the core RDF could be slightly extended to facilitate this.
Sarven Capadisli 3 3 No opinion 1 1 1 1 5 5 5 5 5 3 5 5 5 No opinion No opinion No opinion There should be more focus on user interactions and how everyday people can benefit directly where it wasn't possible before.
Ji���­ Proch�¡zka 5 1 2 4 4 4 3 5 4 5 5 2 3 3 4 4 2 1 1
Stasinos Konstantopoulos No opinion No opinion No opinion 5 No opinion 5 No opinion No opinion No opinion No opinion No opinion 5 No opinion No opinion 4 No opinion No opinion No opinion No opinion
Olivier Berger No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion 5 No opinion No opinion 4 No opinion No opinion No opinion 4 No opinion No opinion No opinion
Michael Hausenblas 3 2 2 1 3 1 4 2 3 2 3 No opinion 3 2 4 3 3 1 1 We understand this question as asking whether deliverables from working groups in these areas would be important to our organisation.
Many aspects are clearly important for the future of RDF, but W3C may not be the best place for them.
Janne Saarela No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion No opinion
François Scharffe 2 1 3 4 1 1 1 3 2 No opinion 5 5 4 1 4 4 2 5 4
Ora Lassila 1 2 2 4 5 3 3 1 4 1 3 3 4 4 5 4 1 3 3
Ivan Mikhailov 1 1 No opinion 1 5 No opinion 2 2 4 4 5 No opinion 5 3 3 4 No opinion 3 3
Pierre-Antoine Champin No opinion 3 No opinion 5 3 2 4 No opinion No opinion 3 3 4 No opinion No opinion 3 2 No opinion No opinion No opinion * about making RDF more powerful: I like the idea of Pat Hayes to extend the semantics of RDF (http://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk) in order to get rid of multiple "inference regimes"

* about redesigning the RDF/XML syntax: not sure it can be "fixed" without making it backward-incompatible; I would rather leave it untouched and work on standardized alternative syntaxes (Turtle/N3)

* about redesigning the RDF model: the standardization of named graphs would require that.
Drew Perttula 3 1 1 1 4 2 3 3 5 3 3 4 2 1 4 4 1 3 3
John Goodwin 1 3 2 2 4 3 2 5 5 5 4 5 3 3 2 4 3 3 4 While things like trust and provenance are important I think we have a lot more important work to do before we worry about those sorts of things. I think as a community we must concentrate of proving the technology works with good (non-trivial) usecases and applications. Only once we've shown RDF really works should we start to worry about provenance etc.
Dodds Leigh 3 1 1 1 3 3 5 5 5 5 5 3 4 No opinion 4 5 1 4 4
Arpad Tamasi 3 1 3 3 5 3 4 3 3 3 5 5 5 4 4 5 No opinion 5 5
Dave Pawson No opinion No opinion No opinion No opinion No opinion 3 5 4 4 No opinion 5 No opinion 4 No opinion 4 No opinion 5 No opinion No opinion
Yves Raimond 1 3 1 4 No opinion No opinion 5 5 5 5 5 1 4 1 5 4 1 5 4 With regards to RDF/XML, the focus should be on other serialisations. RDF/XML is in many aspects a bad serialisation, but it is currently the only standard one, which a very good support in most RDF tools.
michel bercovier 5 2 3 3 1 2 4 4 5 3 3 4 3 4 4 No opinion No opinion 4 No opinion
Bernhard Haslhofer 5 2 5 3 5 1 5 4 5 4 5 5 2 1 3 4 5 4 2
Martín Álvarez 5 3 4 2 5 2 2 5 3 4 5 1 4 2 2 2 3 5 3
Stéphane Corlosquet 5 1 4 No opinion 4 No opinion 5 4 4 No opinion 5 3 4 4 5 No opinion 1 3 No opinion
Paul Reeves 4 2 No opinion No opinion 4 4 No opinion 4 5 4 5 5 5 4 3 4 No opinion 3 3
Nicholas Humfrey 2 2 4 2 3 No opinion 5 4 5 4 3 4 5 2 2 4 2 5 4
Evren Sirin 5 1 3 3 5 5 3 3 3 1 No opinion 1 1 No opinion No opinion No opinion 2 No opinion 1
Niklas Lindström 4 2 1 1 5 2 5 5 4 5 5 5 4 3 4 5 4 4 4
Michael Schneider 1 2 3 3 1 1 3 No opinion 1 No opinion 1 1 1 2 2 1 1 1 1 In my opinion, the following points are off-topic for an RDF core WG: "database work", "KR work", "RDF vocabularies", "applications", "Javascript API", and "APIs in other languages". The points "security", "trust&provenance", and "versioning" seem to be research topics in an unclear state, so I consider them beyond the scope of an RDF core WG as well. The point "explaining the business case" sounds peculiar to me, since I consider RDF a fundamental policy-neutral technology (what are the business cases of XML or C++?).
Vadim Eisenberg No opinion No opinion No opinion No opinion 5 No opinion No opinion No opinion 5 No opinion No opinion 5 5 4 4 4 No opinion 5 5
Steve Speicher 4 3 2 2 3 2 4 2 2 2 4 3 3 4 3 3 2 2 1
Peter Jeszenszky 1 2 2 No opinion No opinion 4 1 1 1 3 4 4 4 3 3 3 3 2 3
Raphaël Troncy No opinion No opinion 4 1 2 2 5 2 3 4 5 1 5 3 4 4 2 5 5
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

9. Add Core Support for Working With Multiple Graphs

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 1 2 15 35 60 14
How much will this benefit you/your organization? 2 8 15 51 33 18
How easy will this be? 4 20 32 32 8 31
How much do you expect to help? 17 35 31 15 2 27

Averages:

Choices All responders:
Value
How much will this benefit the community?4.34
How much will this benefit you/your organization?3.96
How easy will this be?3.21
How much do you expect to help?2.50

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke 5 2 4 2
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 4 4 4 4 My proposals have been in http://www.w3.org/2009/12/rdf-ws/papers/ws09 and in http://www.w3.org/2001/sw/wiki/RDF/NextStepWorkshop/AxelWishlist
Eric Prud'hommeaux 3 2 4 2
James Leigh 4 3 3 2
Christoph Lange 5 4 4 1 High importance wrt. LOD and provenance. Seems easy because it's already in operation. Not sure how I should answer "how much I could help". I am an underprivileged member of a non-W3C member organization. Wrt. RDF in general I wouldn't qualify as an invited expert. Wrt. very specific issues on integrating RDF with XML (in various ways, not just XML→RDF translation), I think I would. I _might_ also have the chance to get an affiliation with a member organization.
Manu Sporny 5 3 2 2 While this work is interesting, we've solved the problem without a spec. Perhaps it would be useful for people that are not deeply involved in working with graph-based data structures.
Paul Tyson 4 4 No opinion 1
Holger Knublauch 4 4 3 No opinion
Lee Feigenbaum 5 5 No opinion 3
Masahide Kanzaki 5 4 4 No opinion
Abhik Banerjee 4 4 2 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 5 4 4 3
stéphane pouyllau 3 4 No opinion No opinion
Philipp Schaffner 3 3 3 1
Paul Hermans 4 4 No opinion 4 Named Graphs are mentioned as solutions to two problems:
- adding context by indicating to which graph a statement belongs; the graph baring then info on the provenance, ...
- as an alternative to reification of individual statements
What if I need both?
I would like to see a move from a triple to a quint as already implemented in the AllegroGraph store.
idstatement - idgraph - subject - predicate - object
idgraph to be used for provenance/trust
idstatement for reification
Gautier Poupeau 5 5 3 2
Nina Jeliazkova No opinion No opinion No opinion No opinion
Olivier Grisel No opinion No opinion No opinion No opinion
Jeen Broekstra 4 4 5 2
Armen Martirosyan 5 1 3 2
Josh Jonte 5 4 5 1
Bob DuCharme 5 4 3 2
Brian Peterson 2 2 2 1
Quentin Reul 4 5 3 3 This will allow to modularise data into smaller (and thus more manageable) graphs.
Yann Mombrun 3 3 1 1
Peter Andersen 4 4 2 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 5 5 4 3 Multiple graphs quickly become necessary for any non-trivial scenario.
We did some work on NRL - an extension to RDF+named graphs for mixing different types of inference in the same knowledge base, see:

http://www.semanticdesktop.org/ontologies/nrl/

and

Michael Sintek, Ludger van Elst, Simon Scerri, Siegfried Handschuh: Distributed Knowledge Representation on the Social Semantic Desktop: Named Graphs, Views and Roles in NRL. ESWC 2007
Patrick Stickler 5 3 5 2
Jean-Paul DECLE 5 5 5 4
Rinke Hoekstra 5 4 4 2
Renaud Delbru 5 5 4 2
Jochem Liem 5 5 No opinion 1
Axel Klarmann 3 2 1 2 In context of linked open data and trust/verification this is a big concern, but it some pounds on the discussion how unique subjects in reality are, maybe this issue have to be solved first. This is a part were some thoughts from the topic maps community are worth consideration
Chimezie Ogbuji 4 5 3 4 A clear theory for named graphs is needed
James Hendler 3 3 2 3
Mike Dean 4 5 2 2
Andrew Perez-Lopez 5 4 3 No opinion
Hassan Ait-Kaci 5 4 4 3 I would welcome discussing all issues, proposals, and ideas with the rest of the interest folks on all issues described in http://www.w3.org/2001/sw/wiki/RDF_Core/Work_Area_1 ...
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 5 5 3 4
Mischa Tuffield 5 4 5 3
Kjetil Kjernsmo 5 4 4 3
Renato Iannella No opinion No opinion No opinion No opinion
Ivan Herman 5 No opinion 3 No opinion
Toby Inkster 5 5 2 2
Peter Mika 5 4 3 2
Steve Harris 3 3 2 3 The community appears to be evolving this on it's own, e.g. though practical deployments of SPARQL-based systems. Standardising at this point may do more harm than good.
Bob Ferris 5 5 No opinion No opinion
Charles Nepote 5 5 3 2
Jun Zhao 5 5 3 2
Chris Beer 4 3 No opinion 2
Christopher Welty 5 5 4 5
James Myers 5 5 No opinion 3 A mechanism to define a graph of RDF information that can be canonicalized and signed (with warrents) is critical in managing provenance and supporting electronic record needs.
Ryan Kohl 5 5 2 3
Lowell Vizenor 3 4 3 1
jans aasman 4 4 4 4 Some consider a graph to be the same as an individual knowledge unit, some consider it just to be the fourth element of a triple that you can use in various ways (like a confidence measure, or the weight of a connection).. The use cases are rather different
Marco Neumann 4 3 3 3
David Peterson 5 4 No opinion No opinion
Kai Eckert 5 5 4 3
Irene Celino 5 5 4 3
Dave Reynolds 5 4 4 2 This the basis for versioning and provenance in a lot of applications, including data.gov.uk. Important to place it on a firm footing.
De Roo Jos 5 5 No opinion No opinion
David Booth 5 4 4 2
Sergio Fernández 4 4 3 3
Ted Guild
Gregg Kellogg 4 4 2 4 My RDF libraries include support for Named Graphs.
Ian Horrocks 5 5 3 3
Micah Herstand 5 5 3 2
Aidan Hogan 5 4 4 2
Graham Klyne 3 3 No opinion 2 To the extent that clarifies and regularizes existing practice, I think this would be a good thing, but if it has the effect of adding further complexity and incompatibilities to deployed data and applications, I think it could be harmful.
Andy Seaborne 4 5 3 4 Too much of this is is a technical solution. The problem to be solved needs defining. At its simplest, a basic hook to work with multiple graphs. But WG dynamics will tend to inflate the intent.
Mohamed ZERGAOUI 4 4 4 3
Christophe THOVEX 3 2 No opinion No opinion
Richard Cyganiak 5 4 4 4 Yes, codify existing practice! This means, do this as an extension to the RDF abstract syntax. Current practice in triple stores, RDF search engines, crawlers, distributed query engines and so on is to use named graphs for local processing of data from heterogenous sources. This works without a model-theoretic semantics or mostly even without an exchange syntax, so W3C should avoid trying to standardize these things. Repeat: DO NOT get into research adventures like providing a model-theoretic semantics. And if you MUST standardize an exchange syntax for sets of graphs, then make it the simple N-Quads.
Nathan Rixham No opinion No opinion No opinion No opinion graph literals, anything else is a work-around imho. if graph literals +5 in every respect, else, meh.
Paul Trevithick 4 5 5 1
Jérôme Mainka 5 5 4 3
Antoine Zimmermann 4 4 3 3 I am in favour of including support for multiple graphs in the RDF model and semantics but the task of formalising the semantics of multi-graph documents will be difficult. As a data model for storing and querying multi-source RDF documents, it should be fairly easy to define since SPARQL already has a model for it.
Henry Story 5 No opinion No opinion No opinion This is a well understood problem now. Databases implement it already. But it needs to be covered clearly.
Frank Olken 5 4 4 3
Gavin Carothers 4 5 3 3
Enrico Franconi 5 4 4 3
Bryan Copeland 3 2 2 2
Emmanuelle BERMES 5 5 3 1
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary 3 4 4 2 i'm not an expert in this.. so i don't feel i can be helpful
Paul Wilton 4 5 2 1
Antoine Isaac 5 4 3 2
Fabien Gandon 5 5 5 5
Palmisano Davide 4 4 4 2
Egon Willighagen 4 4 3 1 I have seen Graphs used for identifying the original of a triple. As such, it seems it may be useful for aggregating data sets.
Reto Bachmann 4 4 2 3
William Waites 5 5 3 4
Sarven Capadisli 4 3 No opinion No opinion
Ji���­ Proch�¡zka 5 No opinion 2 3
Stasinos Konstantopoulos 4 5 3 4 Although it would be far more interesting and useful to work out the semantics of multi-graph docs (based on, eg, modal logics), simply codifying existing data models would also help. Wrt. the reification vs. context issue, it should be possible to get both by, eg, allowing graph subsumption.
Olivier Berger 4 4 No opinion 1
Michael Hausenblas 5 4 3 4 See the subsection on Named Graphs in http://www.w3.org/2009/12/rdf-ws/papers/ws30 for rationale. One major difficulty will be to decide whether to address this only on the level of the abstract syntax (as a data model to describe local processing of multiple triple-based RDF graphs of different provenance), or also on the level of the semantics and serialization syntaxes (essentially extending RDF files from triple-based to quad/multi-graph based).

Defining a semantics for multiple graphs would be a complex question; starting points for the semantics discussion can be found in http://www.w3.org/2009/12/rdf-ws/papers/ws09 .

There are concerns about extending existing RDF syntaxes with support for multiple graphs, because this would allow the publishing of files where the authority of the graph name and the authority of the file could differ, defeating the purpose of using named graphs as a means of tracking the actual provenance of an RDF file. One approach to address these concerns would be not to support named graphs at all in the usual serialization formats (RDFa, Turtle, RDF/XML, JSON-based). Another approach would be to add a syntactic constraint that allows only graph names that have the same authority as the containing file, e.g., file.rdf#someGraphName in file.rdf.
Janne Saarela 5 4 5 2
François Scharffe 5 3 4 3
Ora Lassila 5 4 4 3 Must coordinate with broader provenance work
Ivan Mikhailov 4 4 2 2 We will extend SPARQL to support quad construction (like CONSTRUCT { GRAPH ?g { ?s ?p ?o } } where { ... } and SPARUL tweaks of this sort, and we're reading TriG already. But I don't want to see bnodes as graph names or have some regulations about repeated/unique bnodes across graphs.
Pierre-Antoine Champin 5 5 2 4 I hesitate between 2 and 3 for "How easy will this be?". It seems to me that the idea is broadly accepted, and somehow implemented in many RDF frameworks.

However, the exact semantics varies among people and implementations, and I'm not too what extent reconciling them will be easy.
Drew Perttula 4 4 4 No opinion
John Goodwin 5 4 4 3 OWL 2 has done lots on annotation - not sure how much we can borrow...probably most of it.
Dodds Leigh 5 4 4 2
Arpad Tamasi 5 4 3 3
Dave Pawson 3 No opinion No opinion No opinion
Yves Raimond 5 5 2 2 As mentioned above, this should also include the ability of specifying graphs within graphs, or to make a single triple belong to several graphs. We should be able to cluster triples according to several dimensions - for ACL, provenance, etc. This should also include the standardisation of a serialisation.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 4 4 1
Martín Álvarez No opinion No opinion No opinion No opinion
Stéphane Corlosquet 4 4 2 2
Paul Reeves 3 2 4 2
Nicholas Humfrey 4 4 3 3
Evren Sirin 3 3 2 3 From our perspective, an important use case is to annotate assertions with various types of information such as probability intervals, temporal validity, etc. The named graph extension should allow (or at least not prohibit) such possibilities. Named graphs could be used for this purpose (each triple can belong to one named graph in the most extreme case) but less heavy-weight solution would be preferred,
Niklas Lindström 4 4 3 2
Michael Schneider 4 3 1 4 I sometimes have the feeling that this is a bit of an overrated topic with a couple of important open technical questions. The addition of something like named graphs to the RDF model will probably affect the simplicity of RDF ("everything is a triple"). I also do not yet see a serious approach to update RDF/XML, in particular if it comes to the use of large numbers of named graphs, e.g. one named graph per triple within a graph to associate provenance information with these triples. And there is the technically demanding question of how to best extend the current RDF semantics to treat named graphs. Anyway, the WG should clearly give this topic a try. However, people should be prepared that the outcome may be negative.

Personally, I would offer help on getting the semantics right.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky 4 3 No opinion 1
Raphaël Troncy 5 4 3 3
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

10. Make Well-Known Repairs To The Specification Text

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 2 7 19 34 23 42
How much will this benefit you/your organization? 11 8 32 18 12 46
How easy will this be? 3 6 17 23 30 48
How much do you expect to help? 27 28 12 7 1 52

Averages:

Choices All responders:
Value
How much will this benefit the community?3.81
How much will this benefit you/your organization?3.15
How easy will this be?3.90
How much do you expect to help?2.03

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 3 3 5 2 Will/Should benefit teaching/explaining.
Eric Prud'hommeaux 2 4 5 3
James Leigh 4 3 4 1
Christoph Lange 4 3 5 2 Seems that it just has to be done.
Manu Sporny 3 3 4 1 We've never found RDF spec text errors to be a limiting factor in implementing or using the technology.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch 4 4 5 No opinion
Lee Feigenbaum 3 1 No opinion 1
Masahide Kanzaki 3 3 3 No opinion
Abhik Banerjee 4 4 4 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 5 3 5 2
stéphane pouyllau 3 5 2 No opinion
Philipp Schaffner 4 4 3 2
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau 4 4 5 1
Nina Jeliazkova No opinion No opinion No opinion No opinion
Olivier Grisel No opinion No opinion No opinion No opinion
Jeen Broekstra 4 3 5 1
Armen Martirosyan No opinion No opinion No opinion No opinion
Josh Jonte No opinion No opinion No opinion No opinion
Bob DuCharme 4 5 5 2
Brian Peterson 4 4 4 4
Quentin Reul 2 2 2 3
Yann Mombrun 5 3 3 1
Peter Andersen 5 5 5 1
Colm Kennedy 3 No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 4 1 5 1
Patrick Stickler 4 3 3 1
Jean-Paul DECLE 5 5 5 4
Rinke Hoekstra 4 4 4 2
Renaud Delbru 3 3 4 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 3 1 1 1 It is necessary from a logical/kr point of view, practicaly RDF is in use in its current state.
Chimezie Ogbuji 2 2 3 1
James Hendler 5 1 4 1
Mike Dean No opinion No opinion No opinion No opinion
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 5 4 3 3 I would welcome discussing all issues, proposals, and ideas with the rest of the interest folks on all issues described in http://www.w3.org/2001/sw/wiki/RDF_Core/Work_Area_2 ...
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 2 1 4 2
Mischa Tuffield 5 5 3 3 Specifically I am interested in :

RDF/XML and RDF Concepts Errata - http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#RDF.2FXML_and_RDF_Concepts_Errata

Kjetil Kjernsmo 3 No opinion 5 1
Renato Iannella 5 No opinion No opinion No opinion
Ivan Herman 5 No opinion 5 No opinion
Toby Inkster 4 3 5 1
Peter Mika 5 3 5 2
Steve Harris 4 3 3 4
Bob Ferris 5 5 No opinion No opinion
Charles Nepote No opinion No opinion No opinion No opinion
Jun Zhao 3 1 3 1
Chris Beer 5 4 4 2
Christopher Welty 4 4 4 5
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 5 5 5 2
Lowell Vizenor No opinion No opinion No opinion No opinion
jans aasman No opinion No opinion No opinion No opinion
Marco Neumann 4 4 3 4
David Peterson No opinion No opinion No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino 4 3 No opinion No opinion
Dave Reynolds 4 3 1 2
De Roo Jos No opinion No opinion No opinion No opinion
David Booth 4 4 5 2
Sergio Fernández 5 5 4 3
Ted Guild
Gregg Kellogg 5 3 2 3 I'm actively involved in RDFa spec discussions.
Ian Horrocks 5 3 5 3
Micah Herstand No opinion No opinion No opinion No opinion
Aidan Hogan 3 3 4 1
Graham Klyne 5 3 3 2 Avoid mission-creep. Clarify intent of current text, not improve intent!
Andy Seaborne 4 4 3 3
Mohamed ZERGAOUI 5 5 3 3
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak No opinion No opinion No opinion No opinion
Nathan Rixham 4 2 2 No opinion
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 5 4 5 3
Antoine Zimmermann No opinion No opinion 5 No opinion
Henry Story No opinion No opinion No opinion No opinion
Frank Olken 4 4 4 2
Gavin Carothers 3 1 5 1
Enrico Franconi 5 3 4 2
Bryan Copeland 3 3 5 4
Emmanuelle BERMES 5 5 5 1
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 4 4 4 1
Antoine Isaac 4 2 4 2
Fabien Gandon 4 4 No opinion No opinion
Palmisano Davide 4 1 4 1
Egon Willighagen 5 5 5 1 I do not feel I have enough background in knowledge management and reasoning to actually help out here (4th question), but would support any effort to remove confusion from standards. If these repairs are well-know, they should be applied ASAP.
Reto Bachmann No opinion No opinion No opinion 2
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 4 No opinion 4 2
Stasinos Konstantopoulos 4 3 5 3
Olivier Berger No opinion No opinion No opinion No opinion Didn't understand the title of this question : too bad it's unclear... better phrasing may have helped want to know more... but no time, sorry
Michael Hausenblas 3 3 5 No opinion
Janne Saarela 3 3 5 2
François Scharffe 4 3 4 2
Ora Lassila 2 2 3 1
Ivan Mikhailov 1 1 4 2 The community will not notice the change anyway: that would require a seldom phenomenon like reading the whole text. The repair is mostly for our own perfectionism.
Pierre-Antoine Champin 4 3 No opinion 3
Drew Perttula No opinion No opinion No opinion No opinion
John Goodwin 3 3 4 2
Dodds Leigh 4 3 3 2
Arpad Tamasi No opinion No opinion No opinion No opinion
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond 4 3 5 1
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 3 3 5 2
Martín Álvarez No opinion No opinion No opinion No opinion
Stéphane Corlosquet No opinion No opinion No opinion No opinion
Paul Reeves No opinion 2 4 2
Nicholas Humfrey 3 2 4 2
Evren Sirin 2 1 5 1
Niklas Lindström 4 4 3 2
Michael Schneider 5 5 2 4 This is the least thing a new RDF Working Group could do.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky 4 3 3 1
Raphaël Troncy 3 3 No opinion 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

11. Create a Standard JSON RDF Syntax

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 2 6 15 39 40 25
How much will this benefit you/your organization? 4 12 32 30 18 31
How easy will this be? 3 11 36 25 9 43
How much do you expect to help? 25 26 16 12 4 44

Averages:

Choices All responders:
Value
How much will this benefit the community?4.07
How much will this benefit you/your organization?3.48
How easy will this be?3.31
How much do you expect to help?2.33

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke 5 4 3 5
Melvin Carvalho 4 No opinion No opinion No opinion
Axel Polleres 3 No opinion No opinion No opinion probably good to have, but don't really have a strong opinion here.
Eric Prud'hommeaux 4 2 3 1
James Leigh 2 3 2 1
Christoph Lange 4 3 2 2 I think it will only be _easy_ for a subset of RDF. The more named graphs, bnodes, containers, collections, reification (heaven forbid!), the harder it gets. I can't judge on the real benefit. Maybe all web developers out there are fine with using their own ad hoc JSON encodings in their own applications, and exchanging RDF/XML or Turtle otherwise.
Manu Sporny 5 5 4 5 Most of the work is already done (I know, I know - we need to reach consensus - but there are already specs out there that we can use as a basis for the work): http://rdfa.digitalbazaar.com/specs/source/json-ld/
Paul Tyson 3 3 No opinion No opinion
Holger Knublauch 4 3 5 No opinion
Lee Feigenbaum 4 2 No opinion 1
Masahide Kanzaki 4 3 3 No opinion
Abhik Banerjee 5 5 3 4
Pierre-Yves Chibon 4 3 3 1
Olaf Hartig 4 3 5 2
stéphane pouyllau 4 3 No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans 3 2 No opinion No opinion
Gautier Poupeau 4 4 No opinion 1
Nina Jeliazkova 5 5 3 3
Olivier Grisel 5 4 3 2
Jeen Broekstra 5 4 4 2
Armen Martirosyan 4 1 3 2
Josh Jonte 4 4 2 1
Bob DuCharme 4 3 3 1
Brian Peterson 4 4 4 4
Quentin Reul 2 2 2 1
Yann Mombrun 3 3 No opinion No opinion
Peter Andersen 5 4 3 2
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 4 3 4 1
Patrick Stickler 4 4 4 2
Jean-Paul DECLE 1 1 1 1
Rinke Hoekstra 4 4 4 2
Renaud Delbru 3 2 4 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 5 4 4 4 I would let fall my request for a binary container, when this feature could be implemented. It is necessary to have an official proposal for this.
Chimezie Ogbuji 4 2 5 2
James Hendler 3 4 3 2
Mike Dean 4 3 3 2 A standard mapping between RDF and JSON would be helpful. I don't believe JSON should be a normative syntax for RDF.
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 4 3 3 3
Jamie Taylor 5 No opinion 4 2
David Wood 5 5 4 4
Mischa Tuffield 3 3 3 2
Kjetil Kjernsmo 5 4 5 1
Renato Iannella 4 No opinion No opinion No opinion
Ivan Herman 5 No opinion 4 No opinion
Toby Inkster 4 3 4 2 Talis' RDF/JSON format has already become a defacto standard for representing RDF in JSON. There would be some benefit in having an "official" spec.
Peter Mika 5 5 3 3
Steve Harris 4 2 3 3
Bob Ferris 5 5 No opinion No opinion JSON is simply a hype! However, if the consumer like to have such a serialization the we should be able to serve such a serialization.
Charles Nepote 3 3 3 1
Jun Zhao 5 4 2 1
Chris Beer 4 3 No opinion 1 It would certainly assist in greater/wider RDF uptake
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 5 5 No opinion 1
Lowell Vizenor 3 3 No opinion 1
jans aasman 4 3 4 4 AllegroGraph already use JSON in our client server protocol. Would be nice if there was a standard representation. We would instantly adhere to that.
Marco Neumann 4 2 2 2
David Peterson 5 5 No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino 4 5 2 1
Dave Reynolds 4 4 3 3 There are a lot of these around, the challenge is finding the right compromise. Given that the requirements differ I am sceptical there is one solution. I'd like to help, given that we support one candidate, but time/funding is an issue.
De Roo Jos No opinion No opinion No opinion No opinion
David Booth No opinion No opinion No opinion No opinion
Sergio Fernández 5 4 4 5
Ted Guild
Gregg Kellogg 5 4 4 2
Ian Horrocks 2 1 5 1
Micah Herstand No opinion No opinion No opinion No opinion
Aidan Hogan No opinion No opinion No opinion No opinion
Graham Klyne 5 4 4 3 I think the focus here should be on easing the migration path for existing web applications that already use JSON. As such, I would strongly advocate an approach that comes from a JSON standpoint, sucj as JRON, rather than a mechanism that copmes from an RDF standpoint and simply encodes RDF triples in JSON. (I have some development experience in this area.)

I think the focus for RDF/JSON should be as an application-exchange format rather than as a publication format. (see comments on Turtle)
Andy Seaborne 4 5 4 3
Mohamed ZERGAOUI 3 3 3 3
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 2 2 No opinion No opinion The wrong approach. We need standard technology for mapping JSON to RDF, not for serializing RDF in JSON.
Nathan Rixham 5 5 3 4 critical imho, unsure if it should come under this working group though.. but if it's the only place and time then here it must be, as RDF/JSON is the most important serialization for the next decade of the web, easily.
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 3 3 3 3
Antoine Zimmermann No opinion No opinion No opinion No opinion
Henry Story No opinion No opinion No opinion No opinion could be useful, but one should consider if the problem of crysalising rdf won't just reappear here:

http://blogs.sun.com/bblfish/entry/crystalizing_rdf

Perhaps finding a neat way to give JSON namespaces would be very useful.

But my guess is that without a minimal browser rdf store (or javascript library) treating rdf even in JSON is going to be difficult. If the clients expect their data to be in a tree format, then this forces them into a client/server mode of thinking, at which point the generality of rdf won't seem interesting.
Frank Olken 3 3 4 2
Gavin Carothers 4 3 3 4
Enrico Franconi 5 3 3 1
Bryan Copeland 4 3 3 4
Emmanuelle BERMES No opinion No opinion No opinion No opinion
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 5 5 5 2
Antoine Isaac 4 3 1 1
Fabien Gandon 5 4 No opinion No opinion
Palmisano Davide 5 3 5 3
Egon Willighagen 5 5 4 2 Further integration of RDF with HTML/JS technologies is of utmost importance. Like the suggested work on standardizing JavaScript/RDF integration, a standardized JSON serialization of RDF is very important.

This will make is far more trivial to visualize RDFa embedded in HTML pages as charts and plots with existing graphics toolkits that already handle JSON data sources. I would certaintly start using such technologies.
Reto Bachmann 4 4 4 4
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 3 No opinion 3 1
Stasinos Konstantopoulos No opinion No opinion No opinion No opinion
Olivier Berger 5 4 No opinion No opinion
Michael Hausenblas 3 2 3 No opinion Agreement at this time will be difficult due to large number of existing proposals without sufficient experience.
Janne Saarela 4 3 3 2
François Scharffe 4 4 2 2
Ora Lassila 5 5 4 4
Ivan Mikhailov 4 4 5 4 We implement both JSON for SPARQL result sets and JSON for triples. There might be a need for JSON for quads, mostly to prevent the community from re-invention of bicycles. There might be also a need for JSON as input for SPARQL 1.1 web service endpoints with BINDINGS support.
Pierre-Antoine Champin 5 4 4 3 A JSON syntax may appeal to Web 2.0 developpers and foster new applications.
It should not be too hard, as several proposals have already been published.
A major benefit is that it would overcome the lack of robust support for RDF in java-/ecmascript.
Drew Perttula 4 4 2 No opinion
John Goodwin 2 2 4 2 I can't get too excited about a JSON RDF syntax. I've always thought of them both as very different things with different uses.
Dodds Leigh 5 4 4 3
Arpad Tamasi 5 4 4 5
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond 5 5 3 3 Our preference goes to the Talis JSON serialisation - http://n2.talis.com/wiki/RDF_JSON_Specification
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 4 3 3
Martín Álvarez 5 5 3 2
Stéphane Corlosquet 5 4 No opinion 2
Paul Reeves 5 4 3 3
Nicholas Humfrey 5 5 3 3
Evren Sirin 3 3 2 No opinion JSON syntax is attractive for many reasons (light-weight, would play nicely with JSON tools, etc.). But due to various complications in representing RDF in JSON (namespaces, limitation to unique keys in JSON objects, etc.) the resulting syntax may not have those benefits. Trying to sort out all those details can be very time-consuming.
Niklas Lindström 5 4 3 4 I have working ideas on this, see Gluon: http://purl.org/oort/wiki/Gluon

There are a couple of important design decisions to be made, e.g.: general suitability for all scenarios versus customizable mapping profiles; whether the format should be two-way or one-way (translate to JSON and back or not).
Michael Schneider 4 3 3 1 I consider this at most optional work. In my opinion, a future RDF core WG should not try to create too many RDF serializations. AFAICS, JSON is neither a W3C language, nor is it a standard. It may be popular, but this does not justify that an RDF core WG should be responsible for doing the specification work. The RDF WG should focus on the more important serializations, which are RDF/XML (updates, extensions to named graphs) and Turtle. Of course, if there are people in the WG who want to do this, there is still the option to create a W3C WG Note.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher 5 5 3 2
Peter Jeszenszky 4 3 3 1
Raphaël Troncy 5 3 5 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

12. Make Turtle a W3C Standard

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 8 5 15 30 51 18
How much will this benefit you/your organization? 12 7 29 27 27 25
How easy will this be? 3 8 4 34 40 38
How much do you expect to help? 25 30 15 8 3 46

Averages:

Choices All responders:
Value
How much will this benefit the community?4.02
How much will this benefit you/your organization?3.49
How easy will this be?4.12
How much do you expect to help?2.19

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 5 4 5 1 Doesn't need much help, I guess.... it's there, let's rubber-stamp it! :-)
Eric Prud'hommeaux 3 3 5 5
James Leigh 5 4 4 2
Christoph Lange 5 5 5 2
Manu Sporny 4 3 5 3 Whether or not TURTLE becomes a standard, it's already pretty easy to implement and use.
Paul Tyson 4 3 4 1
Holger Knublauch 5 5 4 No opinion
Lee Feigenbaum 5 3 No opinion 4 Standardizing the TriG syntax would be more important to my organization.
Masahide Kanzaki 5 4 4 No opinion
Abhik Banerjee 2 2 5 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 5 5 5 3
stéphane pouyllau 4 3 No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans 5 5 No opinion No opinion
Gautier Poupeau 4 3 4 1
Nina Jeliazkova 3 3 No opinion No opinion
Olivier Grisel No opinion No opinion No opinion No opinion I like turtle for human debugging with curl but I think concise JSON is a much higher priority to drive widespread adoption among web developers.
Jeen Broekstra 5 5 4 3 To be honest, even better would be to make TriG a standard (or at least, to standardize an extended version of Turtle with NG support).
Armen Martirosyan 5 1 5 2
Josh Jonte 1 1 No opinion No opinion
Bob DuCharme 5 5 4 2
Brian Peterson 4 4 4 4
Quentin Reul 4 4 5 3 Not sure if turtle should be a standard, but think that n3, Manchester syntax (for OWL), and turtle should be combined into a standard format allowing that resolve some of the XML/RDF serialisation issues.
Yann Mombrun 3 3 4 No opinion
Peter Andersen 3 3 4 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 5 5 5 1
Patrick Stickler 5 3 5 1
Jean-Paul DECLE 1 1 1 1
Rinke Hoekstra 5 4 5 2
Renaud Delbru 1 1 4 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 1 1 No opinion 1 I favor JSON format personaly :o)
Chimezie Ogbuji 4 2 5 4
James Hendler 2 1 5 1
Mike Dean 4 4 4 2
Andrew Perez-Lopez 4 3 2 No opinion
Hassan Ait-Kaci No opinion No opinion No opinion No opinion
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 5 5 5 5
Mischa Tuffield 5 5 4 3 I think that Turtle should consider :

http://www.w3.org/2001/sw/wiki/index.php?title=RDF_Core_Work_Items&oldid=1990#RDF.2FXML_and_RDF_Concepts_Errata

So, that it is aligned with SPARQL. If is a solution is found, the implementations shouldn't be too hard to fix.
Kjetil Kjernsmo 5 5 5 3
Renato Iannella 1 No opinion No opinion No opinion
Ivan Herman 5 No opinion 5 No opinion
Toby Inkster 4 3 4 2 Turtle's already widely and interoperably implemented. I'd expect it to reach Rec very quickly.
Peter Mika 5 4 4 2
Steve Harris 5 4 4 4 As long as the issues with URI/URI references are sorted out it should be straightforward. Turtle is widely deployed.
Bob Ferris 5 5 5 No opinion Well sometimes it seems to me that this is already a defacto standard in the community, because everyone prefers it.
Charles Nepote No opinion No opinion No opinion No opinion
Jun Zhao 5 5 2 1
Chris Beer 4 4 2 2 Great for machines, but WSYWIYG / easy human authoring tools need to thought about too. Standard would make it easier for venders / oss communities to provide editors/authoring tools
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 4 4 No opinion 2
Lowell Vizenor 3 3 2 1
jans aasman 3 2 4 2
Marco Neumann 5 4 3 3
David Peterson 5 5 No opinion No opinion
Kai Eckert 4 4 4 No opinion
Irene Celino 5 4 2 No opinion
Dave Reynolds 4 4 2 1 Turtle is used as a de facto standard already, should make an honest spec of it :)
De Roo Jos 5 5 No opinion No opinion
David Booth 4 4 5 2
Sergio Fernández 5 4 4 4
Ted Guild
Gregg Kellogg 5 3 4 4 I implement Turtle as a subset of my N3 parser, and could help identify areas of ambiguity.
Ian Horrocks 4 3 5 3
Micah Herstand 5 5 4 2 N-Quads!
Aidan Hogan 5 5 5 3 Long overdue.
Graham Klyne 3 3 5 1 This is difficult to assess: technically, Turtle is nicer to use than RDF/XML, and is pretty well supported. But, just as we are starting to see large amounts of RDF data deployed, I am concerned that "blessing" an alternative publication format will lead to interoperability problems. Unless *every* application has support for both RDF/XML *and* Turtle, then there will be some data that is not accessible to some applications.

On the other hand, there are a number of applications that already use Turtle (or near-equivalents), so to standardize Turtle may be to regularize what is already happening. Is it plausible to make Turtle a W3C Recommendation (sic) yet also to "recommend" that RDF be published as RDF/XML?
Andy Seaborne 5 5 5 5 This is not an automatic matter - there are still some small issues in the Turtle submission to sort out but there are not major.
Mohamed ZERGAOUI 3 3 3 3
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 5 3 5 2 Long overdue.
Nathan Rixham 4 3 4 No opinion great yes, but only after getting the core model sorted out, tweaking turtle to handle the changes (should be v easy given n3 heritage) then standardize under separate cover if possible - else, if not possible under separate cover, then imho must happen - the "why not" train of thinking comes to mind. Turtle *should* already be a standard.
Paul Trevithick 4 5 No opinion No opinion
Jérôme Mainka 5 5 5 3
Antoine Zimmermann 5 4 5 2 This should be straightforward and I very much encourage the future working group to provide all examples in multiple syntaxes (RDF/XML and Turtle) following the precedent of the OWL 2 specifications where each syntax can be switched ON and OFF.
Henry Story 5 No opinion No opinion No opinion
Frank Olken No opinion No opinion No opinion No opinion
Gavin Carothers 4 3 5 3
Enrico Franconi 1 1 No opinion 1
Bryan Copeland 3 1 2 1
Emmanuelle BERMES 4 3 No opinion 1
Vojnisek Péter 5 5 5 2
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 5 4 4 2
Antoine Isaac 4 4 4 1
Fabien Gandon 5 5 4 No opinion
Palmisano Davide 2 1 5 1
Egon Willighagen 4 4 3 1 RDF/XML is not always the best approach to integrate various tools, and the availability of Turtle is very welcome from my point of view. I find it very readable and have used it in several presentations already.
Reto Bachmann 3 3 5 No opinion
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli 4 No opinion No opinion No opinion
Ji���­ Proch�¡zka 4 No opinion 5 2
Stasinos Konstantopoulos 4 4 5 3
Olivier Berger 5 3 No opinion No opinion
Michael Hausenblas 5 5 5 No opinion We support making Turtle a recommendation pretty much as-is (with a possible extension to support multiple graphs, but see the concerns raised in Q13). W3C should explicitly embrace the use of Turtle as the serialization of choice for teaching materials, examples, and similar material. This includes replacing RDF/XML examples with Turtle examples in any documents that are revised as part of this round of standard updates.
Janne Saarela 3 2 5 2
François Scharffe 3 2 No opinion No opinion
Ora Lassila 1 1 5 1 Why do this if we are going to do JSON. Proliferation of syntaxes is not good.
Ivan Mikhailov 3 3 5 1 Placing W3C logo will change nothing, I guess.
Pierre-Antoine Champin 5 5 4 4 I found that the XML syntax of RDF is a real hindrance to people understanding and adopting RDF in general.
Turtle, on the other hand, is easy to grasp and understand.
It needs to be legitimated by the W3C.
Drew Perttula 3 3 4 No opinion
John Goodwin 4 4 4 3
Dodds Leigh 5 4 5 2
Arpad Tamasi 4 3 5 3
Dave Pawson 5 4 No opinion No opinion
Yves Raimond 5 5 4 2 Standardising Turtle would provide a good serialisation for raw RDF data. It would also ensure that current RDF recommendations use a standard serialisation.
michel bercovier 3 No opinion No opinion No opinion
Bernhard Haslhofer 5 4 5 2
Martín Álvarez 4 3 4 2
Stéphane Corlosquet 5 3 No opinion 2
Paul Reeves 4 No opinion 4 2
Nicholas Humfrey 5 5 4 2
Evren Sirin 2 1 4 1 Turtle is already being supported nearly by all RDF tools. I really doubt that Turtle being a submission has any impact on its adoption which is why I say it will not benefit the community too much. if the goal here is taking the current submission and making it a recommendation document with minimal change then this would easy enough to justify the cost.
Niklas Lindström 5 4 4 2 I really love Turtle and strongly hope for it to be standardized.

(I'm not sure whether it will be *more* important than JSON (or even a new XML format) for boosting general adoption though. But it is the most attractive syntax so far.)
Michael Schneider 5 5 3 2 There are several W3C standards that use either a Turtle-style representation of RDF or an N-TRIPLE representation in their documents (e.g. SPARQL and OWL). By making Turtle a W3C Recommendation, there would then finally be a standard to refer to from within these documents (with N-TRIPLE being a subset of Turtle).
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher 4 2 5 2
Peter Jeszenszky 5 3 1 1
Raphaël Troncy 5 5 5 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

13. Indicate Which RDF Features Are No Longer Best Practice

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 5 6 20 48 27 20
How much will this benefit you/your organization? 8 25 22 26 15 30
How easy will this be? 4 14 22 32 11 43
How much do you expect to help? 29 36 14 7 40

Averages:

Choices All responders:
Value
How much will this benefit the community?3.81
How much will this benefit you/your organization?3.16
How easy will this be?3.39
How much do you expect to help?1.99

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho 4 No opinion No opinion No opinion
Axel Polleres 2 2 2 No opinion Might not be so easy, what should also be considered to be checked is how far those features are used, and how much burden it would be to convert datasets using those features by replacements of those features, i.e. deprecation shall involve suggesting viable alternatives.
Eric Prud'hommeaux
James Leigh 4 3 4 1
Christoph Lange 4 3 5 2 On XML literals, I would appreciate if there were eventually some standard support for querying XML inside RDF, e.g. what the Virtuoso and Corese engines already do. Certain complex knowledge representations (I know that from math) cannot easily be completely represented in RDF, so one will always need RDF and XML combinations. Therefore it would eventually be good to be able to do SPARQL queries with e.g. embedded XPath and sharing of variables.
Manu Sporny 4 3 3 2 Any sort of guidance on RDF would be good - stuff like: Use RDFa :P
Paul Tyson 4 2 4 1
Holger Knublauch 4 4 4 No opinion
Lee Feigenbaum 5 1 No opinion 3
Masahide Kanzaki 3 3 3 No opinion
Abhik Banerjee 4 4 4 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 4 4 4 2
stéphane pouyllau 4 5 No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans 5 5 No opinion No opinion
Gautier Poupeau 5 2 3 2
Nina Jeliazkova 2 2 No opinion No opinion
Olivier Grisel 5 4 No opinion 2 I could help by reading the deprecation recommendation and applying them in the couple opensource projects I am working home and propagating the info to the other developers I work with.
Jeen Broekstra 4 4 No opinion 2
Armen Martirosyan 1 1 3 2
Josh Jonte 5 No opinion No opinion No opinion
Bob DuCharme 4 4 2 2
Brian Peterson 4 4 4 4
Quentin Reul 1 1 5 1 I think that rdf:XMLLiteral and xsd:string are very useful in organisation combining RDF with other XML-based paradigms.
Yann Mombrun 5 5 4 2
Peter Andersen 4 3 4 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 5 4 5 1
Patrick Stickler 3 3 No opinion 1
Jean-Paul DECLE 5 4 5 4
Rinke Hoekstra 4 3 4 2
Renaud Delbru 3 2 4 No opinion
Jochem Liem 5 5 No opinion 1
Axel Klarmann 3 No opinion No opinion 2
Chimezie Ogbuji 2 1 4 2
James Hendler 4 4 3 3
Mike Dean No opinion No opinion No opinion No opinion
Andrew Perez-Lopez 4 3 3 No opinion
Hassan Ait-Kaci No opinion No opinion No opinion No opinion
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 3 2 4 3
Mischa Tuffield 4 2 4 2
Kjetil Kjernsmo 3 3 3 2 It will benefit my organisation in that RDF will be easier to sell, and that will benefit them in ways they don't know yet.
Renato Iannella 5 No opinion No opinion No opinion
Ivan Herman 3 No opinion 4 No opinion
Toby Inkster 4 4 3 2
Peter Mika 5 5 4 3
Steve Harris 3 2 2 2 Some of these changes are potentially confusing to users.
Bob Ferris 5 5 No opinion No opinion Best practices standards are very important for new developers to get into this technology. So it should be very easy for them to access them to get to know them. Hence, a differentiation and a update will be very good.
Charles Nepote 3 2 No opinion No opinion
Jun Zhao 3 3 4 1
Chris Beer 4 3 2 2 Anything hampering RDFa I'd like to see deprecated (because I love RDFa)
Christopher Welty 3 3 2 2
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 5 4 3 1
Lowell Vizenor 4 4 4 3
jans aasman No opinion No opinion No opinion No opinion
Marco Neumann 4 4 3 3
David Peterson 5 4 No opinion No opinion
Kai Eckert 4 4 No opinion No opinion
Irene Celino 5 5 No opinion No opinion
Dave Reynolds 2 1 2 1 Several of the candidates are in routine use, deprecating will cause disruption to no significant benefit. As a tool provider we would bear some of the brunt of explaining to users why this feature is no longer desirable while *still* having to support them all.
De Roo Jos No opinion No opinion No opinion No opinion
David Booth 4 4 4 2
Sergio Fernández 4 4 2 1
Ted Guild
Gregg Kellogg 5 5 3 3
Ian Horrocks 4 2 4 2
Micah Herstand 5 4 5 2 I just want there to be a standard for provenance, so if reification is off the table, that will at least narrow the scope of community uses.
Aidan Hogan 4 4 2 2
Graham Klyne 4 3 3 1 I'd agree with the comments by Jeremy Carroll referenced by the issue description
Andy Seaborne 2 2 1 3 RDF has grown to the point where all features are in use to some extent.
No longer best practice implies an alternative and at that point, I do not see that consensus is strong.
Mohamed ZERGAOUI 5 5 5 4
Christophe THOVEX 3 2 2 1
Richard Cyganiak 5 5 3 4 This would be a big win.
Nathan Rixham 3 2 No opinion 1 either deprecate them or leave them be, "weak deprecation" is nothing more than politics; keeping them for BC and allowing a new generation to use them a poor choice imho, deprecate them, mark them as deprecated, then if implementation want to be backwards compatible they still can (and probably are).
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 5 5 5 3
Antoine Zimmermann No opinion No opinion No opinion No opinion
Henry Story 4 No opinion No opinion No opinion
Frank Olken 3 2 3 1
Gavin Carothers 3 2 4 2
Enrico Franconi 4 2 4 1
Bryan Copeland 3 2 4 1
Emmanuelle BERMES 5 5 No opinion 1
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary 5 No opinion No opinion No opinion
Paul Wilton 3 2 4 1
Antoine Isaac 4 2 4 2
Fabien Gandon 4 4 4 No opinion
Palmisano Davide 4 2 4 1
Egon Willighagen 5 5 3 1 Yes, this is quite valuable... you do not want to see people walk into dead alleys... like fixing known errors in specifications, I think the community will clearly benefit from such knowledge.
Reto Bachmann No opinion No opinion 1 3
William Waites 4 4 3 2
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 4 No opinion 2 2
Stasinos Konstantopoulos 4 3 2 3 It is important to clean up before moving on. It might also be a good idea to forbid mixing new features with deprecated ones, so that the people working out new features of RDF do not have to worry about how they interact with deprecated features. Reaching a consensus about what is obsolete is usually harder than it sounds.
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 4 4 1 4 Can have a large payoff, but agreement will be very difficult.
Janne Saarela 5 3 5 2
François Scharffe 4 3 4 2
Ora Lassila 3 2 3 1
Ivan Mikhailov 1 1 5 1 I'd like to keep XMLLiterals "alive", as th mix of XSLT and SPARQL is found to be quite useful and it is practical to store (pre-persed) XML and plain texts in different ways.

Re. deprecation of the rest, I'm afraid we can repel some developers from RDF if we officially make it "unstable". Early days of Java should give us examples.
Pierre-Antoine Champin 4 3 5 3
Drew Perttula 3 No opinion No opinion No opinion
John Goodwin 3 2 3 2
Dodds Leigh 4 3 4 2
Arpad Tamasi 5 3 5 3
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond 4 2 2 1 We should investigate why these features are no longer best practices, and whether it is fixable - or can be deprecated in favor of another mechanism.
It would be good, in that it would keep the specification up-to-date with current best practices, and it would show that the standard process is active rather than stale.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 5 4 3
Martín Álvarez 5 5 4 2
Stéphane Corlosquet 4 No opinion No opinion 1
Paul Reeves 4 4 3 2
Nicholas Humfrey 4 2 4 1
Evren Sirin 4 4 4 2 It would be good to deprecate the mentioned features that are not commonly used and mostly misused. The benefit here is less confusion for users and less work for developers/experts educating newcomers on these features.
Niklas Lindström 4 3 3 2
Michael Schneider 1 1 3 4 I am generally against deprecation of features just for the reason that they do not seem to be used much, regardless of the question how deprecation could best be performed (removal vs. marking them "archaic"). RDF is around with these features for more than a decade now, and one should not believe that the features are not used just because no one ever jumps up loudly announcing that she really uses the feature. Rather, there /are/ uses: reification is specifically supported by the Top Braid Composer ontology editor for years, and I have also seen some use of RDF containers and some more use of rdf:value. rdf:XMLLiteral has even just been deliberately added to OWL 2 and RIF as a normative datatype. I might think differently if some of these features were in some way harmful, but this is not really the case: containers, reification and rdf:value have only trivially weak normative semantics, and the rest of RDF does hardly depend on them. On the other hand, I do not see any benefit coming from deprecating these features. If one does not want to use them, one can easily ignore them (as many people seem to do, anyway, without having any trouble). There are many technologies around that have old and rarely used features but are still not deprecated. So the safe path is as well the easiest path: do nothing. The danger of undesirable side effects from deprecation is much too high.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher 4 4 3 1
Peter Jeszenszky 4 3 2 1
Raphaël Troncy 4 3 No opinion 2
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

14. Extend RDF/XML

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 23 15 21 30 12 26
How much will this benefit you/your organization? 25 19 31 11 10 31
How easy will this be? 14 19 27 14 4 49
How much do you expect to help? 34 26 13 2 1 51

Averages:

Choices All responders:
Value
How much will this benefit the community?2.93
How much will this benefit you/your organization?2.60
How easy will this be?2.68
How much do you expect to help?1.82

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 3 3 3 3 Support for named graphs/graph identification should be added to describe datasets in RDF/XML.
Eric Prud'hommeaux 3 2 1 2
James Leigh 3 2 2 2
Christoph Lange 3 2 4 2 I'd rather deprecate RDF/XML (*) than improve it, but I guess you can't deprecate it, so improving is OK.
(*) Turtle is likely to become a standard. If we want an XML encoding of RDF for machine-friendliness, let's take one that is actually machine-friendly, e.g. RXR, or a constrained subset of RDF/XML that does not have 10 ways to express the same facts.
Manu Sporny 1 1 1 1 I'd be happy if RDF/XML were burned at the stake. I can't count the number of hours spent convincing people of the difference between RDF and RDF/XML or convincing people that RDFa has nothing to do with RDF/XML and the (insert horrible experience here) people have had with it. Outmode RDF/XML completely with a simple JSON syntax... JSON-LD, for instance.
Paul Tyson 2 2 3 No opinion
Holger Knublauch No opinion No opinion No opinion No opinion
Lee Feigenbaum 1 1 No opinion No opinion
Masahide Kanzaki 2 2 2 No opinion
Abhik Banerjee 4 4 2 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 4 3 4 2
stéphane pouyllau 4 4 No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans No opinion No opinion No opinion No opinion A more predictable RDF/XML format to be used within the XML technology stack would be more helpful.
Gautier Poupeau 4 4 2 3
Nina Jeliazkova 2 2 No opinion No opinion
Olivier Grisel 4 3 5 1
Jeen Broekstra 3 3 2 1 I'd rather keep RDF/XML as it is and instead come up with a better XML syntax for RDF, e.g. based on TriX.
Armen Martirosyan 4 1 3 2
Josh Jonte 1 No opinion No opinion No opinion
Bob DuCharme 4 3 3 2 The two items listed at http://www.w3.org/2001/sw/wiki/RDF_Core/Work_Area_6 are excellent goals.
Brian Peterson 2 2 4 2
Quentin Reul 4 4 3 4
Yann Mombrun 5 5 3 2
Peter Andersen No opinion No opinion No opinion 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 1 1 1 1 RDF/XML is nice as a legacy interchange format, but introducing a new version would just make API support for any of two versions worse, and introduce more confusion. Leave RDF/XML ALONE! :)
Patrick Stickler 3 3 No opinion 1
Jean-Paul DECLE 1 1 1 2
Rinke Hoekstra 4 4 3 2
Renaud Delbru 4 4 4 No opinion Is this covering the addition of named graphs in RDF ? looks like a duplicate question.
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 4 3 4 2 I think the multiple graph representation would be great, i don't really care about the rdf:list issue
Chimezie Ogbuji 4 2 4 1
James Hendler 2 2 2 2 I am very unimpressed and uninterested in the particular extensions. I believe resources would be much better spent working where the action is, which is out where RDFa and "just enough" RDF/RDFS?OWL are meeting the real world (cf. the new OReilly Programming the Semantic Web book)
Mike Dean 5 5 4 2
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 5 5 4 3
Jamie Taylor 1 No opinion No opinion No opinion
David Wood 1 1 1 1
Mischa Tuffield 1 1 No opinion No opinion
Kjetil Kjernsmo 1 1 2 1 Can't we just leave that dead horse, please?
Renato Iannella 5 5 No opinion No opinion
Ivan Herman 2 No opinion 3 No opinion
Toby Inkster 3 3 1 2 I think any extension that breaks legacy parsers is a non-starter.
Peter Mika 5 5 4 3
Steve Harris 1 1 1 1
Bob Ferris 1 1 No opinion No opinion I get rid of RDF/XML!
Charles Nepote 3 3 3 No opinion
Jun Zhao 4 3 3 1
Chris Beer 3 3 2 1
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl No opinion No opinion No opinion 1
Lowell Vizenor 5 5 No opinion No opinion
jans aasman No opinion No opinion No opinion No opinion we should get rid of rdf/xml. Turtle and Ntriples are good enough.
Marco Neumann 4 4 3 3
David Peterson No opinion No opinion No opinion No opinion
Kai Eckert 5 5 No opinion No opinion
Irene Celino 4 3 No opinion No opinion
Dave Reynolds 2 2 2 1 See no great value in multiple graphs in one RDF/XML document, just point to multiple documents. Improved list syntax would be a minor help but doesn't seem worth the cost of disrupting the spec.
De Roo Jos 1 1 No opinion No opinion
David Booth 1 2 2 1
Sergio Fernández 4 3 3 1
Ted Guild
Gregg Kellogg 2 2 3 3
Ian Horrocks 2 2 2 1
Micah Herstand 5 1 No opinion 1 Ugh, can't we just deprecate RDF/XML for N3/N-quads?
Aidan Hogan 2 2 1 1 Can backwards compatibility be maintained? I can't see how. Breaking backwards compatibility is unacceptable.
Graham Klyne 4 3 2 2
Andy Seaborne 1 1 1 1 Just leave it as it is. Compatibility matters, both old software/ new data and new software/old data. The track record of WG's on compatibility is not good (e.g. rdf:PlainLiteral).
Mohamed ZERGAOUI 4 4 4 5
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 1 1 No opinion No opinion Leave RDF/XML alone. It's a turd. Expend energy on the other syntaxes.
Nathan Rixham 3 1 3 1 would much rather see RDF defined without any changes to serializations, let serializations conform and revise under separate cover.
Paul Trevithick 5 5 No opinion 1
Jérôme Mainka 5 5 3 3
Antoine Zimmermann 3 3 4 2 RDF/XML should only be extended to cover the new features.
Henry Story No opinion No opinion No opinion No opinion perhaps some information about how one can use literals to get the same effect as named graphs. What is the realtionship between an rdf/xml literal in and rdf/xml document to a graph?
Frank Olken 3 3 3 2
Gavin Carothers 4 4 1 3
Enrico Franconi 4 3 2 2
Bryan Copeland 3 3 2 3
Emmanuelle BERMES No opinion No opinion No opinion No opinion
Vojnisek Péter 4 1 3 No opinion
hodder mary 4 No opinion No opinion No opinion
Paul Wilton 4 3 3 1
Antoine Isaac 4 4 3 2
Fabien Gandon 4 4 1 No opinion
Palmisano Davide 1 1 5 1
Egon Willighagen 3 3 3 1 Extensions that simplify using the standard would make sense, but I would caution against adding too many alternatives to do one thing.
Reto Bachmann 1 2 2 No opinion
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli 3 3 No opinion No opinion
Ji���­ Proch�¡zka 2 No opinion 2 1
Stasinos Konstantopoulos 3 3 3 2
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 2 2 No opinion No opinion We have reservations about the cost to existing implementations. Limited developer resources should better be concentrated on the new serializations. Adding support for new features of the abstract data model (e.g., graph identification, but see our concerns in Q13) should be considered, but we discourage any attempts to try to "fix" RDF/XML.
Janne Saarela 3 2 5 2
François Scharffe 2 1 No opinion No opinion
Ora Lassila 4 2 3 1
Ivan Mikhailov 3 3 3 1 The convenience of graphs in RDF/XML will be compensated by headache with parsers. It's late.
At the same time, it's trivial to make a separate format with whatever at the top level and RDF/XML subtrees; thus no need in tweaking the spec.
Pierre-Antoine Champin 3 3 4 3
Drew Perttula 4 3 No opinion No opinion
John Goodwin 4 3 3 2
Dodds Leigh 1 1 No opinion 1
Arpad Tamasi 5 3 3 3
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond 1 1 1 No opinion RDF/XML is in many aspects a broken serialisation, but it is currently the only standard one for raw RDF data, and widely supported across many RDF tools. The focus of the Working Group should be on other serialisations.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 5 3 3
Martín Álvarez No opinion No opinion No opinion No opinion
Stéphane Corlosquet 1 1 No opinion 1
Paul Reeves 3 3 4 2
Nicholas Humfrey 1 1 5 1
Evren Sirin 2 1 2 1 Extending RDF/XML to support lists with literals seems very little benefit (easier to read/write manually) with significant cost (backward compatibility). RDF/XML is already hideous enough to work manually so this little improvement will not make too much difference. Named graph extension for RDF/XML depends on the resolution for 13.
Niklas Lindström 1 1 2 1 I fear RDF/XML as it stands has too much shortcomings, especially for general adoption (it's basically one of the most alien XML syntaxes people ever see). It should be frozen as it is, and perhaps even be declared a legacy format.

(I do respect its relative merits at the time of creation though (as I was so much into XML namespacing at the time that I was actually drawn *to* RDF by it)..)
Michael Schneider 4 3 1 2 It looks to me that this is mainly the desire to have a named-graph extension to RDF/XML. So I regard this point as an addition to point #13 and give it similar values, except that I am offering less help. :-)
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky 4 3 3 3
Raphaël Troncy 3 3 4 2
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

15. Revise Semantics for Blank Nodes

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 20 15 21 25 14 32
How much will this benefit you/your organization? 20 13 27 19 9 39
How easy will this be? 18 28 17 9 3 52
How much do you expect to help? 33 17 15 9 2 51

Averages:

Choices All responders:
Value
How much will this benefit the community?2.98
How much will this benefit you/your organization?2.82
How easy will this be?2.35
How much do you expect to help?2.08

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 3 No opinion 2 No opinion Although appealing, and I liked the related talk on, http://www.w3.org/2009/12/rdf-ws/papers/ws23 not sure how easy this will be... it would simplify things, probably.
Eric Prud'hommeaux 2 2 1 1
James Leigh 1 2 1 2
Christoph Lange 3 2 1 1 Not sure about this. From a knowledge interchange point of view blank nodes should be deprecated altogether; they create trouble, and RDF also works without them. But they are just _so_ convenient to read and write for humans, so I really don't know.
Manu Sporny No opinion No opinion No opinion No opinion We've never had the problem that the proposal is attempting to solve, even though we know someone else must have that problem, it's not a practical concern for us.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch 5 5 No opinion No opinion
Lee Feigenbaum No opinion 1 No opinion No opinion
Masahide Kanzaki 2 2 2 No opinion
Abhik Banerjee 4 4 2 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 4 3 3 2
stéphane pouyllau No opinion No opinion No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau 4 3 No opinion 1
Nina Jeliazkova 2 2 No opinion No opinion
Olivier Grisel No opinion No opinion No opinion No opinion I don't use blank nodes since I mostly work with DBpedia data and related projects that don't use blank nodes either (AFAIK).
Jeen Broekstra 4 4 1 1
Armen Martirosyan 1 1 1 2
Josh Jonte 4 No opinion 2 No opinion
Bob DuCharme 3 3 3 1
Brian Peterson 2 2 2 2
Quentin Reul 1 1 1 1
Yann Mombrun 3 3 1 1
Peter Andersen 4 4 4 2
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 3 1 1 1 if "revise" means deprecate ...

We already avoid bnodes and recommend that everyone else does the same. Making up internal URIs for nodes that represent more-than-binary relations is not pretty - but it's much better than the alternative.
Patrick Stickler 4 4 No opinion 2
Jean-Paul DECLE 4 4 4 4
Rinke Hoekstra 3 3 2 1
Renaud Delbru 5 5 3 2
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 1 3 No opinion 2 Maybe it is a good idea, how systems have to handle blank nodes. Isomorphic graphs are necessary if two systems build there own graph of external information and try to match those graphs in transactions between them
Chimezie Ogbuji 4 2 2 3 Not worth it, not well scoped
James Hendler 1 1 2 1 If large-scale Web-app developers ever actually start worrying about formal semantics I might change my mind, but that date isn't around for a while
Mike Dean 2 2 3 1
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 4 3 4 4
Jamie Taylor 4 No opinion No opinion No opinion
David Wood No opinion No opinion No opinion No opinion
Mischa Tuffield 1 1 3 1
Kjetil Kjernsmo 3 1 No opinion 1 Nice to have feature, but we have URIs for everything :-)
Renato Iannella 4 3 No opinion No opinion
Ivan Herman 3 No opinion 2 No opinion
Toby Inkster No opinion No opinion No opinion No opinion
Peter Mika 5 5 2 3
Steve Harris 4 4 2 2
Bob Ferris 3 3 No opinion No opinion Blank nodes are an useful concept (locally). However, if I like to make every content somehow accessible (in the distributed, interlinked knowledge base called Linked Data Cloud), then we should use URIs the most of the time, else it would be bit more difficult.
Charles Nepote No opinion No opinion No opinion No opinion
Jun Zhao 4 2 3 1
Chris Beer 3 3 3 1 Unsure what the long term effects would be - I'm on the fence here
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 3 3 No opinion 1
Lowell Vizenor 3 3 No opinion No opinion
jans aasman 5 3 1 3
Marco Neumann 4 4 3 3
David Peterson 4 3 No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino 5 4 1 No opinion
Dave Reynolds 2 3 3 1 Change propagation would be *really* useful. Seems like this needs a syntactic mechanism which could be outside core model. Approaching this as a semantic change and potentially disrupting existing usage and tools seems like too brutal an approach.
De Roo Jos 1 1 No opinion No opinion
David Booth 4 4 4 5 WHOA! BIG problem: This question does not at all reflect the original intent of the blank node discussion. It was not at all about revising the *semantics* of blank nodes. It was about providing standard alternatives (such as skolomization) so that the negative effects of blank nodes (such as the inability to round-trip a graph without blank node labels changing) could be avoided. The unfortunate phrasing of this question is likely to very seriously bias the results of this survey.
Sergio Fernández 4 4 2 2
Ted Guild
Gregg Kellogg 5 4 3 3
Ian Horrocks 5 4 4 4
Micah Herstand 5 5 2 3 If we get away from the graph metaphor, blank nodes could become much more powerful and easy to understand items. I like looking at them as sets instead of as something that is necessary lacking a data piece.
Aidan Hogan 3 3 1 1
Graham Klyne 2 3 2 1
Andy Seaborne 3 1 2 3 Skolemization to URIs would be an incompatibility.

Existing software is based on the invariant that literals, IRIs and blank nodes are disjoint sets. This is pervasive.

No community consensus, likely to be a lot of heat for unclear value.
Mohamed ZERGAOUI 5 4 2 2
Christophe THOVEX 1 No opinion No opinion No opinion
Richard Cyganiak 2 3 2 1 Seems unlikely to make the life of most users easier.
Nathan Rixham 1 1 5 1 this issue is imo nothing to do with RDF.
Paul Trevithick 5 5 No opinion 1
Jérôme Mainka 5 5 1 3 * Should emphasize the fact that blank nodes would lead to serious drawbacks in linked data framework in documentation...
Antoine Zimmermann No opinion No opinion 2 3 For this one, I suggest a dual semantics, one following the current existential semantics (compatible with the OWL 2 RDF-based semantics) and one following the skolemised semantics (compatible with the SPARQL semantics and various actual implementations). Please notice that a dual semantic approach was chosen for OWL (Direct Semantics and RDF-based semantis).
Henry Story 1 No opinion No opinion No opinion
Frank Olken 4 4 3 3
Gavin Carothers 2 5 1 4
Enrico Franconi 1 1 1 5 DON'T DO THIS!
Bryan Copeland 1 1 5 4
Emmanuelle BERMES 2 2 1 1
Vojnisek Péter 1 1 3 1
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 4 4 2 1
Antoine Isaac 1 1 No opinion 1
Fabien Gandon 4 4 1 No opinion
Palmisano Davide 5 5 4 1
Egon Willighagen 1 1 3 3 I am not convinced this is the right idea... I would argue that an blank node is blank for a reason; the other way around, there is a very simply reason to persist the identity of a resource: give it a URI.
Reto Bachmann 1 1 No opinion No opinion I consider the suggested changes pointless and dangerous. nobody is forced to use blank nodes, but blank nodes can be an effective way to express knowledge preventing redundant naming of entities. Redundant naming of entities can bring some advantages in some situations , but being able to create lean graphs (which would be loosing information with the proposal) is a powerfull way to maintain data compact an easily processable.
William Waites 4 4 3 2
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 3 No opinion 2 2
Stasinos Konstantopoulos 1 1 1 4 Blank nodes should keep their existential semantics. Adding a mechanism for automatically and systematically constructing URIs that are just indexes and not human-readable names is an orthogonal issue.
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 2 3 2 No opinion This item is closely related to Q23. The input from http://www.w3.org/2009/12/rdf-ws/papers/ws23 would be worth considering. Although potentially beneficial and better reflecting current practice, this is probably highly controversial.
Janne Saarela 2 2 3 2
François Scharffe 4 4 2 1
Ora Lassila 3 3 2 3
Ivan Mikhailov 1 1 3 1 Do we really want to bring the order to the thing designed for producing mess? The attempt will fail :) Let the bNodes stay as is, i.e., as a quick and dirty way to place something into a temporary grap, do somethingh and then zap the whole graph.
Pierre-Antoine Champin No opinion No opinion 2 3
Drew Perttula 3 No opinion No opinion No opinion
John Goodwin 3 3 3 2
Dodds Leigh 2 3 No opinion No opinion
Arpad Tamasi 5 3 4 3 No blank nodes at all.
Dave Pawson 3 3 No opinion No opinion
Yves Raimond 4 5 2 3 We are not sure this is a semantics question. However, a standard mechanism for identifying blank nodes would be good, as it would allow for the easy implementation of RDF diff tools (which are currently made very tricky by the presence of blank nodes).

One of the main thing we want to be able to do when storing data is to keep multiple stores up-to-date with the same information. In order to do so, we need to be able to efficiently compute deltas and propagate them - this is currently made very difficult by the lack of simple and fast RDF diff algorithms.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 4 5 4
Martín Álvarez No opinion No opinion No opinion No opinion
Stéphane Corlosquet No opinion No opinion No opinion No opinion
Paul Reeves 3 3 4 2
Nicholas Humfrey 4 3 2 1
Evren Sirin No opinion No opinion No opinion No opinion
Niklas Lindström No opinion No opinion No opinion No opinion Blank nodes as they are now have definite uses. Named blank nodes are more cumbersome IMHO, but are needed for certain serializations.
Michael Schneider 1 1 2 4 Other W3C standards that are closely related to RDF follow the current interpretation of blank nodes by seeing them as existential variables, including RIF (in RIF+RDF combinations), OWL (both Direct and RDF-Based Semantics) and SPARQL (explicitly "defined for matching RDF graphs with simple entailment"). The SPARQL 1.1 WG is even providing extended entailment regimes, all of them using existential blank node semantics.

Technical ramifications: Skolemizing blank nodes would mean that even trivial expected semantic conclusions would not hold anymore. For example, { :s :p _:x . } |= { :s :p _:x . } would become a non-entailment, since the scopes of the two occurrences of "_:x" would be their respective graphs (locality of blank nodes, which is a feature of blank nodes orthogonal to the existential-vs-skolem question). So they would be distinct constants, despite their equally named identifiers. A consequence for today's reasoners which provide this result would be that they would become unsound. But even if the scope would be the whole entailment query, then examples such as { [] foaf:name "Alice" } |= { [] foaf:name "Alice" } would become non-entailments, since the two occurrences of "[]" would mark distinct bnodes and would therefore become distinct Skolem constants. So the semantics of RDF would change significantly and in unexpected (and probably undesirable) ways.

For OWL, it would not be possible anymore to prove a correspondence theorem between OWL DL and OWL Full, since OWL Full, if then being based on top of the changed RDFS semantics, would then not have existential semantics for anonymous individuals anymore, while OWL DL would still have. Further, it would not be possible for OWL Full to provide composite constructs, such as complex class expressions, in semantic conclusions anymore, neither by means of OWL 1 Full-style semantic comprehension conditions (due to the then non-existential semantics of blank nodes), nor by means of OWL 2 Full-style "syntactic balancing" (due to the graph-locality of blank nodes).
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky 3 3 4 1
Raphaël Troncy 2 2 No opinion 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

16. Create Standards for Deployment of Linked Data

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 2 4 13 39 53 16
How much will this benefit you/your organization? 5 11 17 35 35 24
How easy will this be? 8 8 43 25 6 37
How much do you expect to help? 18 24 25 17 7 36

Averages:

Choices All responders:
Value
How much will this benefit the community?4.23
How much will this benefit you/your organization?3.82
How easy will this be?3.14
How much do you expect to help?2.68

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho 5 No opinion 2 3 Also add a social aspect
Axel Polleres 3 4 3 2
Eric Prud'hommeaux 3 4 2 1
James Leigh 5 5 4 3
Christoph Lange 5 5 4 3 Not sure whether that _has_ to be part of any RDF standard, but it would definitely be a good guidance to LD publishers.
Manu Sporny 3 3 No opinion 1 If everybody is already doing it, placing it into a W3C document will have little effect.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch 4 4 No opinion No opinion
Lee Feigenbaum No opinion 2 No opinion No opinion
Masahide Kanzaki 3 3 3 No opinion probably not RDF Core
Abhik Banerjee 4 4 2 4
Pierre-Yves Chibon 5 5 3 4
Olaf Hartig 4 4 3 3
stéphane pouyllau 4 4 No opinion No opinion
Philipp Schaffner 4 4 4 2
Paul Hermans 3 3 No opinion No opinion
Gautier Poupeau 5 3 3 2
Nina Jeliazkova 5 5 5 3
Olivier Grisel 4 4 4 2 Would be great to have official recommendations for URI dereference mechanisms.
Jeen Broekstra 5 5 3 3
Armen Martirosyan 4 1 1 2
Josh Jonte No opinion No opinion No opinion No opinion
Bob DuCharme 4 3 3 2
Brian Peterson 3 3 2 4
Quentin Reul 5 5 3 5
Yann Mombrun 4 4 3 2
Peter Andersen 4 3 2 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 4 2 3 1
Patrick Stickler 4 3 No opinion 1
Jean-Paul DECLE 5 5 5 4
Rinke Hoekstra 3 3 3 1
Renaud Delbru 3 3 4 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 5 4 No opinion 4 I think it is important to have an explicite URI building schema and try to explicate it in a documentation, maybe one could start with a research on what schemes are currently adopted
Chimezie Ogbuji 4 1 4 1
James Hendler 4 4 1 3 Unclear what this really means - but since it seems to be going well in the real world without standardization, and as an academic community screwing it up could only hurt, I'm not inclined to think this is a big deal. My 3 in "expect to help" is that I would feel inclined to be dragged in to make sure we don't break things by trying to fix them
Mike Dean 5 5 3 2 I assume this would include making a document like Cool URIs for the Semantic Web a Recommendation.
Andrew Perez-Lopez 5 2 3 No opinion
Hassan Ait-Kaci 5 5 4 4
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 3 4 3 4
Mischa Tuffield 4 2 5 3
Kjetil Kjernsmo 4 3 3 2 I would have helped a lot in my current organization, but not my future.
Renato Iannella 4 3 No opinion No opinion
Ivan Herman 4 No opinion 3 No opinion There should be an emphasis that this work, if done, would not lead to recommendations, but merely documentation of the state of the art in terms of tutorials, primers, and such. Thing may evolve dynamically in future, and <strong>standards</strong> may make this more difficult.
Toby Inkster No opinion No opinion No opinion No opinion
Peter Mika 5 5 4 3
Steve Harris 3 2 3 1 This should evolve, if it hasn't already.
Bob Ferris 5 5 No opinion No opinion This is the most powerful grounding for many use cases, I guess.
Charles Nepote 5 5 3 3
Jun Zhao 3 2 3 2
Chris Beer 5 4 3 2 Yes. Standards r good mm'kay! (Seriously standard l-data deployment = machine readable friendliness for all)
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 5 5 No opinion 1
Lowell Vizenor 5 5 No opinion No opinion
jans aasman 5 5 1 4
Marco Neumann 5 4 3 3
David Peterson 5 5 No opinion No opinion
Kai Eckert 5 5 4 4
Irene Celino 5 5 3 1
Dave Reynolds 2 2 4 1 The title is deceptive compared to the wiki page. The wiki page implies things like automatic dereference of URIs affecting semantics and inference. I've no idea how the declarative semantics of the base document is supposed to interact with the procedural semantics of whether I can get through that particular URL today. As described on the wiki page this sounds like it would have substantial impact on existing toolkits.
De Roo Jos 5 5 No opinion No opinion
David Booth 4 4 4 3
Sergio Fernández 5 5 3 5
Ted Guild
Gregg Kellogg 5 5 2 4
Ian Horrocks 1 1 1 1
Micah Herstand 5 4 3 2 I think the w3c needs to come out with recommendations (not necessarily standards) more quickly and more forcefully. Waiting to standardize everything just allows businesses (like Facebook) to set the agenda.
Aidan Hogan 5 5 4 3
Graham Klyne No opinion No opinion No opinion No opinion
Andy Seaborne 5 5 4 4
Mohamed ZERGAOUI 5 5 5 5
Christophe THOVEX 5 No opinion 4 2
Richard Cyganiak 4 4 3 5 We have learned enough about this and it's time to document it in a REC.
Nathan Rixham No opinion No opinion No opinion No opinion great idea but nothing to do with RDF core imho and would add way to much scope. can't rate it as a +5 because I view it as orthogonal.
Paul Trevithick 5 5 No opinion 2
Jérôme Mainka 4 4 4 3
Antoine Zimmermann No opinion No opinion No opinion No opinion
Henry Story 5 No opinion No opinion No opinion yes, but also explain how one should deal with indirect statements. Ie: how can one say that one does not believe a graph, that a graph is fictitious, that one would like the graph to happen, etc...
Frank Olken 3 3 3 3
Gavin Carothers 4 4 3 4
Enrico Franconi 5 4 3 3
Bryan Copeland 4 4 4 3
Emmanuelle BERMES 4 4 3 2
Vojnisek Péter 3 1 3 1
hodder mary 5 No opinion No opinion No opinion
Paul Wilton 5 4 1 2
Antoine Isaac 5 5 3 3
Fabien Gandon 4 4 4 No opinion
Palmisano Davide 4 4 4 1
Egon Willighagen 2 2 4 3 I quite like the concepts of Linked Open Data, and would welcome a formal specification of the requirements for Linked Open Data. However, I would *not* make this part of the RDF itself; it should be an additional specification, as people must not loose the freedom to use URIs as URIs, instead of URLs.
Reto Bachmann No opinion No opinion No opinion No opinion
William Waites 5 5 3 3
Sarven Capadisli 4 No opinion No opinion No opinion Should be just best practices.
Ji���­ Proch�¡zka 4 No opinion 3 2
Stasinos Konstantopoulos 5 5 3 4 The POWDER Rec is also very relevant, as it can be used to not only infer properties from the URI structure, but could be reversed to help construct meaningful URIs based on a resource's properties.
Olivier Berger 4 3 No opinion No opinion
Michael Hausenblas 4 4 3 5
Janne Saarela 5 5 5 3
François Scharffe 5 5 3 4
Ora Lassila 4 2 4 1 May not belong in an RDF group specifically
Ivan Mikhailov 4 4 1 2 It's enough to mention LD as a good practice but leave semantics as is.
Pierre-Antoine Champin 5 5 3 4
Drew Perttula 4 3 No opinion No opinion
John Goodwin 5 5 4 4
Dodds Leigh 4 4 4 3
Arpad Tamasi 5 4 No opinion 3
Dave Pawson 4 No opinion No opinion No opinion
Yves Raimond 5 3 4 2 This probably should only be an appendix - a best practice document, hosted by the W3C. This document should point to other (more specific) documentations and specifications.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 5 4 5
Martín Álvarez 4 4 3 2
Stéphane Corlosquet 5 5 3 3
Paul Reeves 5 4 5 2
Nicholas Humfrey 5 4 3 2
Evren Sirin 4 4 2 4 This is a very common and hard to work around problem. Without a stable way to refer bnodes makes it very hard to build distributed applications where information about these bnodes need to be shared. This is likely to be a difficult change but it is wort the effort.
Niklas Lindström 4 4 3 2 Linked Data practises are very important for adoption and general understanding of how to deploy RDF.
Michael Schneider 2 2 1 1 RDF is a core technology, usable for a large range of applications and should not specifically support a certain form to use it. RDF is used for Linked Data, knowledge representation, as a base for other standards and technologies, can be used within technical systems as a data representation format, and may have other unknown uses in the future. If one of these forms to use it is preferred by the standard, then this may easily be to the detriment of the other forms to use it. For example, the "full description" mentions the desire of some people to see a URI as more than just an opaque identifier, but this may be unjustified from a KR perspective or when using RDF for technically representing data models.
Vadim Eisenberg 5 No opinion No opinion No opinion
Steve Speicher 5 4 3 3
Peter Jeszenszky 4 3 4 1
Raphaël Troncy 5 5 3 5
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

17. Define Some Useful Similarity/Equivalence Properties

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 8 11 22 39 19 28
How much will this benefit you/your organization? 11 8 31 31 15 31
How easy will this be? 8 21 26 21 3 48
How much do you expect to help? 21 28 18 8 4 48

Averages:

Choices All responders:
Value
How much will this benefit the community?3.51
How much will this benefit you/your organization?3.32
How easy will this be?2.87
How much do you expect to help?2.32

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres No opinion No opinion No opinion No opinion I am unsure whether this topic is mature enough for standardisation.
Eric Prud'hommeaux 1 2 4 1
James Leigh 3 3 3 1
Christoph Lange 4 3 4 2 "best practice" document seems the most reasonable approach to me
Manu Sporny 3 3 No opinion 1 It seems as if this proposal is attempting to create a "perfect" semantic web, which we don't believe in. Data is going to be dirty and messy and if owl:sameAs continues to be abused (which it will be, regardless of whether or not W3C does anything about it), the term will become useless and abandoned in the future. If guidance can be provided now, great... but even if it exists, owl:sameAs is difficult to grok for most people, myself included.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch No opinion No opinion No opinion No opinion
Lee Feigenbaum 3 2 No opinion No opinion
Masahide Kanzaki 4 3 4 No opinion that's true, owl:sameAs is too much overloaded in LOD community
Abhik Banerjee 4 4 3 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 5 4 2 2
stéphane pouyllau No opinion No opinion No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans 3 3 No opinion No opinion
Gautier Poupeau 5 5 1 2
Nina Jeliazkova 3 3 No opinion No opinion
Olivier Grisel 5 4 No opinion 2 There is indeed a need for an official best practice document that explains when to use owl:sameAs and when to use SKOS.
Jeen Broekstra No opinion 4 No opinion 1
Armen Martirosyan 1 1 No opinion 1 To me owl:sameAs is sufficient.
Josh Jonte 3 No opinion 5 No opinion
Bob DuCharme 4 3 4 1
Brian Peterson 2 2 2 2
Quentin Reul 1 1 1 4 I think that SKOS already provide a wide range of mapping properties and not sure that we need to re-invent the wheel. The only issue relates to the domain and range (i.e. skos:Concept) of these properties.
Yann Mombrun 3 3 4 1
Peter Andersen 4 4 3 2
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 4 4 2 1
Patrick Stickler 5 5 5 2
Jean-Paul DECLE 4 4 4 4
Rinke Hoekstra 4 4 3 2
Renaud Delbru 2 2 4 No opinion
Jochem Liem 5 5 No opinion 1
Axel Klarmann 2 3 No opinion 2 From a pragmatic point of view, i don't think a more elaborate equivalence property is necessary, because one would catch some philosophical issues, which lead to endless debate. On the other side some temporal distinctions would be nice (owl:willBe, owl:wasSame) and what about fuzzy equivalence, it's an endless tie of questions
Chimezie Ogbuji 3 1 No opinion 1
James Hendler 4 5 2 5 It would actually be better to find a way to bring owl:sameAs into RDF with a suitably simplified semantics - but since I see that as nearly impossible with the community available, I would settle for some new RDFs solution (note - I think this could better be done in RDFs than in "pure" RDF - but again, that seems very ambiguous in the scope of this questionnaire.
Mike Dean 4 4 3 2 I'd rather re-use the existing OWL vocabulary than introduce equivalent RDF terms. Weaker forms such as similarTo would also be helpful.
Andrew Perez-Lopez 5 4 3 No opinion
Hassan Ait-Kaci 5 5 3 3
Jamie Taylor 4 4 No opinion 2 Constraining the discussion may prove very challenging. Eliciting concrete usecases which focus the construction on specific scenarios may help.
David Wood 3 4 No opinion 3
Mischa Tuffield No opinion No opinion No opinion No opinion
Kjetil Kjernsmo 4 4 3 2 Another nice to have feature. We could certainly use that, owl:sameAs is overused now.
Renato Iannella 5 4 No opinion No opinion This is interesting as it will then beg the question....What else from OWL should we put in RDF?
Ivan Herman 4 No opinion 4 No opinion I say 'easy' because, I believe, SKOS has already done the groundwork, and a good 80/20 cut might be made by simply adapting those to a general use. I would not want to see a fundamentally new work here (it may not be ripe for standardization, for example)
Toby Inkster 4 4 2 2
Peter Mika 5 5 2 3
Steve Harris 2 1 2 2
Bob Ferris 3 3 No opinion No opinion I mean we have already some in OWL and SKOS. So an OWL-SKOS alignment will here be more important. Although, these statement are in general often a bit difficult.
Charles Nepote 3 3 3 No opinion
Jun Zhao 3 2 4 1
Chris Beer 4 4 3 2 This would help everyone
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 4 4 No opinion 2
Lowell Vizenor No opinion No opinion No opinion No opinion
jans aasman 3 3 3 3
Marco Neumann 4 4 3 3
David Peterson No opinion No opinion No opinion No opinion
Kai Eckert 4 4 3 3
Irene Celino 4 4 4 No opinion this should definitely build on skos!
Dave Reynolds 3 3 4 1 Would need more details on a specific proposal to give a good evaluation of this. In principle some better alternatives would be good but the devil is in the details.
De Roo Jos No opinion No opinion No opinion No opinion
David Booth No opinion No opinion No opinion No opinion
Sergio Fernández 4 3 4 3
Ted Guild
Gregg Kellogg 4 3 2 2
Ian Horrocks 1 1 1 1
Micah Herstand 5 5 3 3 Not just weak/strong equivalence, but there should be intelligent relationships built in as well. For example, being able to have a superClass-like relationship but for individuals with instance data would be amazing. Not to mention "sameConcept" to equate the concept behind two URIs without equating all of their triples (most conspicuously once provenance is more common, we're gonna see hell trying to make sense of it if owl:sameAs is used everywhere)
Aidan Hogan 3 3 1 No opinion Grading depends heavily on what direction this will take... Think a non-symmetric (and perhaps non-transitive) version of owl:sameAs might be useful... but is this not for OWL?
Graham Klyne 3 3 3 1 I think it's too early for new _standards_ - HOWTO-style documents seem to be anough for now.
Andy Seaborne 4 4 1 2 Very hard to reach agreement.

No point until httpRange-14 is settled properly.
Mohamed ZERGAOUI 5 5 5 5
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 3 3 3 1 This is useful but should better happen outside of W3C.
Nathan Rixham 5 4 2 2 100% behind this one, as per J Hendler's RDFS3 proposal - nigh on critical to the wider community moving forwards.
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 5 5 4 3 * owl:sameAs is overused and this leads to serious inconsistencies
Antoine Zimmermann 2 2 No opinion No opinion This is out of the scope of RDF, in my opinion.
Henry Story 2 No opinion No opinion No opinion
Frank Olken 3 3 2 3
Gavin Carothers 2 1 2 1
Enrico Franconi 1 1 1 5 DON'T DO THIS!
Bryan Copeland 4 5 3 4
Emmanuelle BERMES 5 4 2 2 Better to provide guideline on the use of owl:sameAs vs. skos, rather than create new properties that will add more confusion.
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 5 5 4 2
Antoine Isaac 4 4 2 3
Fabien Gandon 4 4 3 No opinion
Palmisano Davide 1 1 4 1
Egon Willighagen 2 3 3 3 I do not know if defining more properties is going to fix the current misuse of owl:sameAs. I think this is more the field of best-practices and making people understand standards, than it is a matter of defining more standards. I'm tempted to think that more standards will only confuse people more.
Reto Bachmann No opinion No opinion No opinion No opinion
William Waites 5 5 2 4
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 4 No opinion 4 2
Stasinos Konstantopoulos 1 1 3 3 This doesn't sound like a piece of vocabulary that belongs in RDF, but way further up.
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 3 3 2 No opinion As a first step, provide clear guidance on cases where use of owl:sameAs is indeed correct according to the intended OWL semantics. It is not clear wether this is in scope of an RDF WG.
Janne Saarela 4 3 4 2
François Scharffe 4 5 3 5
Ora Lassila 5 5 2 4
Ivan Mikhailov 4 4 4 3 Good practice doc (refs to SKOS) would be sufficient.
Pierre-Antoine Champin 5 4 2 4 This is a difficult problem, but I believe that it should be addressed by RDF (and not by upper layers such as OWL).
Drew Perttula No opinion No opinion No opinion No opinion
John Goodwin 4 4 3 3 I think this could be very useful, and I would be interested in the semantics of said properties. Not sure how useful it is keeping the RDF/OWL worlds separate though.
Dodds Leigh 4 4 4 3
Arpad Tamasi 4 3 No opinion No opinion
Dave Pawson 3 3 No opinion No opinion
Yves Raimond 5 5 3 3 Whether it needs to be in the RDF specification is another question - it should probably be in a separate namespace.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 2 2 4 2
Martín Álvarez 4 3 4 2
Stéphane Corlosquet 4 4 No opinion 2
Paul Reeves 4 4 3 2
Nicholas Humfrey 3 3 3 1
Evren Sirin 2 1 2 1 Similarity and equivalence is extremely hard to define. It is true that sameAs is abused in practice but the solution should be a best practices document not a standard. The interaction of this extension with OWL would be very tricky too.
Niklas Lindström 4 3 No opinion No opinion
Michael Schneider 4 3 1 3 I remember some discussions in forums along these lines and they did not lead to any concrete acceptable results. We cannot really expect a W3C working group to spend much time on inventing things that may afterwards be highly controversial. There is also a difficult technical aspect: the resulting properties need to be given a semantics that fits well into the rest of the semantic framework, and without bringing the relationships between RDF and other standards (e.g. OWL and RIF) in danger. Of course, the WG can give it at least a try, but only if time and resources permit.

I would offer some help in getting the semantics right.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher 4 3 2 No opinion
Peter Jeszenszky 4 3 3 1
Raphaël Troncy 3 3 2 4
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

18. Define a Namespace Packaging Mechanism

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 2 11 30 27 14 43
How much will this benefit you/your organization? 8 15 27 21 7 49
How easy will this be? 4 6 30 18 4 65
How much do you expect to help? 27 23 12 2 4 59

Averages:

Choices All responders:
Value
How much will this benefit the community?3.48
How much will this benefit you/your organization?3.05
How easy will this be?3.19
How much do you expect to help?2.01

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres No opinion No opinion No opinion No opinion
Eric Prud'hommeaux 3 1 4 1
James Leigh 3 4 4 2
Christoph Lange 3 2 3 2 The way this is done in RDFa 1.1 does not convince me. The @prefix attribute as something that does not rely on xmlns is fine, but I have never understood why we need @vocab and what the actual benefit is.
Manu Sporny 5 3 3 4 Don't use the term namespace... there's this religious hatred for it out there that defies rational explanation. People don't seem to be scared of 'terms' or 'prefixes'... perhaps use those terms. Initial feedback on RDFa Profiles is very positive.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch No opinion No opinion No opinion No opinion
Lee Feigenbaum No opinion No opinion No opinion No opinion
Masahide Kanzaki 3 2 3 No opinion separate profile document would easily be a trouble maker
Abhik Banerjee 3 3 No opinion 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 2 2 4 2
stéphane pouyllau 4 5 No opinion No opinion
Philipp Schaffner 4 4 3 2
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau 3 1 3 1
Nina Jeliazkova No opinion No opinion No opinion No opinion
Olivier Grisel 5 4 No opinion 1
Jeen Broekstra 3 3 No opinion No opinion
Armen Martirosyan 1 1 3 1
Josh Jonte No opinion No opinion No opinion No opinion
Bob DuCharme 3 3 3 1
Brian Peterson 2 2 2 2
Quentin Reul 1 1 1 1
Yann Mombrun 3 3 3 1
Peter Andersen 3 3 3 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes No opinion No opinion No opinion No opinion
Patrick Stickler 4 4 4 1
Jean-Paul DECLE 3 3 3 1
Rinke Hoekstra 3 3 3 1
Renaud Delbru No opinion No opinion No opinion No opinion
Jochem Liem 4 No opinion No opinion No opinion
Axel Klarmann 3 3 No opinion 2 It sounds interesting and a nice to have mechanism, as a programmer i think it could be a good extension of the RDF standard
Chimezie Ogbuji 5 5 4 3 Managing namespaces in ontologies in current SW toolkits is painful
James Hendler 3 3 No opinion No opinion
Mike Dean 5 4 3 2
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 5 4 3 3
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 3 4 3 3
Mischa Tuffield No opinion No opinion No opinion No opinion
Kjetil Kjernsmo 5 2 4 1 I suppose it is needed, though I don't see what's so hard about being explicit about namespaces...
Renato Iannella 4 No opinion No opinion No opinion
Ivan Herman 3 No opinion 4 No opinion The overall reaction on the RDFa profile document ideas were fairly positive, though some of the features (eg, 'terms') might require more change on the hosting syntaxes that might be a minus.
Toby Inkster No opinion No opinion No opinion No opinion
Peter Mika 5 5 4 3
Steve Harris 2 2 No opinion 1
Bob Ferris 5 5 No opinion No opinion Yes, this will be very good, because many "normal" web developers are struggling with the namespace. However, there might some limits re. expressiveness.
Charles Nepote 2 2 No opinion No opinion
Jun Zhao 2 1 3 1
Chris Beer 4 3 3 1
Christopher Welty 3 3 2 5
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 4 4 No opinion 2
Lowell Vizenor No opinion No opinion No opinion No opinion
jans aasman 3 2 3 2
Marco Neumann 4 4 3 3
David Peterson 5 4 No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino 2 2 4 No opinion
Dave Reynolds 3 3 2 1
De Roo Jos No opinion No opinion No opinion No opinion
David Booth No opinion No opinion No opinion No opinion
Sergio Fernández 2 2 4 2
Ted Guild
Gregg Kellogg 5 5 5 5 Work mostly done by RDFa group already.
Ian Horrocks 4 2 4 2
Micah Herstand 4 No opinion No opinion No opinion
Aidan Hogan No opinion No opinion No opinion No opinion
Graham Klyne No opinion No opinion No opinion No opinion
Andy Seaborne 2 2 No opinion 1
Mohamed ZERGAOUI 5 5 5 5
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 4 4 5 5 RDFa is already doing most of this work item (RDFa profiles), it's just a matter of making sure that this work can be used in other/future syntaxes as well (certainly in the JSON syntax)
Nathan Rixham 3 1 3 1 personally view it as a bell and whistle proposal, v low priority imho - however loosening the rdf spec to all namespaces to be either included or pointed to in order to allow future work like this would be a good idea.
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 4 4 3 3
Antoine Zimmermann No opinion No opinion No opinion No opinion
Henry Story 5 No opinion No opinion No opinion could be very very useful
Frank Olken 3 3 3 2
Gavin Carothers 2 1 1 1
Enrico Franconi 4 3 3 1
Bryan Copeland 4 4 1 3
Emmanuelle BERMES No opinion No opinion No opinion No opinion
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 4 3 3 1
Antoine Isaac No opinion No opinion No opinion No opinion
Fabien Gandon 4 4 4 No opinion
Palmisano Davide 4 4 4 1
Egon Willighagen 3 3 3 1 This seems to be a proposal about addressing a social problem, while at the same time, is seem to remove explicit facts from RDF containers, referring to external documents (profiles). The latter sounds like a good source of error as I expect misuse (see owl:sameAs); and as it is addressing a mere social (human) problem, I am not convinced about the need by the linked 'full description'.
Reto Bachmann No opinion No opinion No opinion No opinion
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli No opinion No opinion No opinion No opinion
Ji���­ Proch�¡zka 3 No opinion 3 2
Stasinos Konstantopoulos 3 3 3 1
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 4 4 4 3 RDFa Profiles should be used as a basis for any such mechanism.
Janne Saarela 3 3 4 2
François Scharffe 3 3 No opinion No opinion
Ora Lassila 2 2 3 1
Ivan Mikhailov 4 3 2 2 Separate namespace declarations means compound RDF document. Disadvantages are well known from XML. Advantages will be questionable if RDF will be compound only for this tiny purpose. A generic "include" mechanism would add more flexibility for same implementation cost.
Pierre-Antoine Champin 3 3 3 3 I see the benefits of this proposal, but I am not sure they overcome the impact it may have on deployed implementations...
Drew Perttula 4 3 No opinion No opinion
John Goodwin No opinion No opinion No opinion No opinion
Dodds Leigh 4 4 4 3
Arpad Tamasi 5 5 No opinion 3
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond 4 4 3 1 A mechanism similar to RDFa profiles would be welcome. This work should be bundled in other serialisation work that needs to happen anyway.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 4 3 5 3
Martín Álvarez 4 4 3 2
Stéphane Corlosquet 4 3 No opinion 2
Paul Reeves 3 2 4 2
Nicholas Humfrey 5 4 4 2
Evren Sirin No opinion No opinion No opinion No opinion
Niklas Lindström 4 3 2 2 This may simplify authoring and adoption, as well as form a basis for more convenient syntaxes. I'm not sure about how general it can made to be. The terminology for this mechanism must be carefully chosen.

(For some definition of profiles, this is what I have in Gluon <http://purl.org/oort/wiki/Gluon>.)
Michael Schneider 4 4 No opinion 2 This sounds like a nice thing to have. But this topic seems to be in a pretty early stage? This should only be done, if it is doable in a natural way. Sort of a "bonus topic".
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky No opinion No opinion No opinion No opinion
Raphaël Troncy 3 3 No opinion 2
1 1 3 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

19. Change RDF Semantics to Plain Data (SPARQL) Style

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 16 17 24 17 5 48
How much will this benefit you/your organization? 18 15 28 9 4 53
How easy will this be? 17 26 11 6 4 63
How much do you expect to help? 31 15 9 4 3 65

Averages:

Choices All responders:
Value
How much will this benefit the community?2.72
How much will this benefit you/your organization?2.54
How easy will this be?2.28
How much do you expect to help?1.92

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres 3 No opinion 2 No opinion Isn't this almost the same as question 19. ?
Eric Prud'hommeaux No opinion No opinion No opinion No opinion
James Leigh 4 4 2 1
Christoph Lange 3 2 3 1 I don't understand the background well enough.
Manu Sporny No opinion No opinion No opinion No opinion Don't grok the issue well enough to have an opinion on it.
Paul Tyson 1 1 No opinion No opinion
Holger Knublauch 5 5 5 No opinion
Lee Feigenbaum No opinion No opinion No opinion No opinion
Masahide Kanzaki 2 2 2 No opinion changing semantics would be very dangerous
Abhik Banerjee 3 3 No opinion 4
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 2 2 2 1
stéphane pouyllau 1 1 No opinion No opinion
Philipp Schaffner 1 1 5 1
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau No opinion No opinion No opinion No opinion
Nina Jeliazkova No opinion No opinion No opinion No opinion
Olivier Grisel No opinion No opinion No opinion No opinion
Jeen Broekstra 3 3 2 No opinion
Armen Martirosyan 1 1 1 1 It's bad idea to sacrifice semantics for "trivial" usability reasons. People should understand the importance of semantics.
Josh Jonte No opinion No opinion No opinion No opinion
Bob DuCharme 4 3 2 2
Brian Peterson 2 2 2 2
Quentin Reul 3 4 3 4
Yann Mombrun 3 3 1 1
Peter Andersen 4 4 1 2
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 4 3 1 1
Patrick Stickler No opinion No opinion No opinion No opinion
Jean-Paul DECLE 1 1 1 No opinion
Rinke Hoekstra 2 2 2 1 Bad idea
Renaud Delbru 3 3 2 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 2 1 No opinion 2 I don't think we should reduce RDF to a data description language, in practise there are currently RDF schemes in use and it would break most of the implementations
Chimezie Ogbuji 1 1 4 1
James Hendler 1 1 No opinion 1 I would actively oppose a charter that included this- so I need a "-1" option - this is not because I love RDF semantics, but rather because they are not hurting anything serious at the moment, and doing more academic crap in this space could only help to antagonize the large companies and the many govts that are just starting to get serious in this space.
Mike Dean No opinion No opinion No opinion No opinion
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 4 4 4 3
Jamie Taylor No opinion No opinion No opinion No opinion
David Wood 3 2 No opinion 3
Mischa Tuffield 1 1 2 2
Kjetil Kjernsmo 2 1 1 1 It sounds like a rather intrusive change to do now, and I'd rather not have that at this time.
Renato Iannella 3 3 No opinion No opinion Simple Semantics is best...may lead to greater deployments....If you want comples semantics...use OWL...
Ivan Herman 2 No opinion 2 No opinion Creating uncertainty in the landscape of RDF implementations might be a significant problem.
Toby Inkster No opinion No opinion No opinion No opinion
Peter Mika 5 5 2 3
Steve Harris 3 3 2 3
Bob Ferris No opinion No opinion No opinion No opinion
Charles Nepote 3 No opinion No opinion No opinion
Jun Zhao 4 5 4 1
Chris Beer 3 3 3 1
Christopher Welty 4 3 2 5
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl 4 4 No opinion No opinion
Lowell Vizenor 3 3 No opinion No opinion
jans aasman 4 3 2 1
Marco Neumann 3 3 3 3
David Peterson 4 3 No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino No opinion No opinion 1 No opinion
Dave Reynolds 2 2 4 1
De Roo Jos No opinion No opinion No opinion No opinion
David Booth 5 4 3 2
Sergio Fernández 2 2 5 1
Ted Guild
Gregg Kellogg No opinion No opinion No opinion No opinion
Ian Horrocks 3 2 2 2
Micah Herstand No opinion No opinion No opinion No opinion
Aidan Hogan 4 3 2 1 Aligning standards with current prevalent adoption is worthwhile, but could be difficult and could have knock-on consequences.
Graham Klyne 2 2 1 1
Andy Seaborne 3 3 3 3 Wiki page is poorly written and is opinion.
Mohamed ZERGAOUI 3 3 3 3
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 5 5 2 5 This is hard and will face considerable opposition, but is worth fighting for. The KR roots are a millstone around RDF's neck, and it's time to officially get rid of that baggage. Languages like OWL can layer their own semantics on top of a neutral/data-structure-only RDF semantics.
Nathan Rixham 1 1 No opinion 1
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 4 4 3 3
Antoine Zimmermann No opinion No opinion No opinion No opinion This is very much related to Q19. See my comments there.
Henry Story 1 No opinion No opinion No opinion Not sure I understand this proposal in detail. I like the RDF semantics, and open world assumption. Am worried what this brings too much change.
Frank Olken 3 3 2 2
Gavin Carothers No opinion No opinion No opinion No opinion
Enrico Franconi 1 1 1 5 DON'T DO THIS!
Bryan Copeland 1 1 1 1
Emmanuelle BERMES No opinion No opinion No opinion No opinion
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 3 3 3 1
Antoine Isaac No opinion No opinion No opinion No opinion
Fabien Gandon No opinion No opinion No opinion No opinion
Palmisano Davide 2 2 1 1
Egon Willighagen 3 3 3 1 The current proposal is not clear whether the current SPARQL practice is wrong (incorrect with respect to the RDF standard) or not. I do not think changing the scope of a core standard because if current practices is a good idea. That said, I think the current practical problems outlined are worth exploring.
Reto Bachmann 1 1 2 No opinion If anything we should fix sparql, but I don't really see the issue. Sparql works well on system doing leaninfication as well as on those who don't.
William Waites No opinion No opinion 2 2
Sarven Capadisli No opinion No opinion No opinion No opinion Sounds like openning a can of worms
Ji���­ Proch�¡zka 4 No opinion 1 2
Stasinos Konstantopoulos 1 1 1 1 It is hard to foresee the consequences of opening such a big can of worms, for no apparent benefit.
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 3 3 2 3 Changing the semantics would better reflect current practice, but would be controversial, and there are concerns about the effects on the semantics of OWL and RIF. We note this is closely related to Q19.
Janne Saarela 2 2 4 2
François Scharffe 3 3 1 1
Ora Lassila 2 2 4 1 Greatly reduces the usefulness of RDF
Ivan Mikhailov 3 3 1 1
Pierre-Antoine Champin 2 2 No opinion 4 Aligning RDF semantics and SPARQL semantics sounds like the thing to do.
However, I think that it is important for RDF not to be "just a syntax", and it seems to me that it is what this proposal implies.

This is basically a first impression; I have not given much thought to that before.

In any case, I'd be interested to participate to the debate.
Drew Perttula 4 3 2 No opinion
John Goodwin 4 4 No opinion 2
Dodds Leigh 2 3 No opinion No opinion
Arpad Tamasi No opinion No opinion No opinion No opinion
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond No opinion No opinion No opinion No opinion The description on the wiki page is very unclear.
michel bercovier No opinion No opinion No opinion No opinion
Bernhard Haslhofer 5 4 2 2
Martín Álvarez No opinion No opinion No opinion No opinion
Stéphane Corlosquet No opinion No opinion No opinion No opinion
Paul Reeves 4 3 5 2
Nicholas Humfrey No opinion No opinion No opinion No opinion
Evren Sirin 3 3 2 1 Many (if not all) RDF systems don't fully implement the RDF semantics. so this change would not have much impact in practice. But it would still be good to make the semantics align with practice especially because there isn't any obvious benefit to the more complicated things in RDF semantics.
Niklas Lindström No opinion No opinion No opinion No opinion Aren't RDF triples/quads plain data, and SPARQL just one way of querying/processing such? If not, I may be in favour of this without fully understanding it..

(Though it seems more important to finalize SPARQL "syntactic sugar" for e.g. List chains and following paths already present in these structures..)
Michael Schneider 1 1 1 4 The current form of the RDF semantics is being used by several other important standards, including SPARQL (explicitly "defined for matching RDF graphs with simple entailment"), RIF (RIF+RDF combinations), OWL (the OWL 2 RDF-Based Semantics is a semantic extension of RDF D-entailment), and POWDER (POWDER-S IRI set semantics). The SPARQL 1.1 Working now even extends the standard to be used with other entailment regimes, including all the entailment regimes defined in the current RDF Semantics. So, changing the semantics for RDF in a strong way would in fact be a step in the opposite direction to where the SPARQL language moves, and it would entirely remove the semantic foundation for the mentioned other W3C standards.

From the "full description" it does not become fully clear to me what the actual proposal is precisely. There are different points that seem to be in some conflict, and they do not all sound much as what I would call "plain data style". But in any case, the different points there suggest to me that the changes would be quite strong with significant consequences that I am just starting to understand.

For example, I wonder whether a unique-interpretation (Herbrand) semantics would mean that from a graph G := { :c1 a rdfs:Class . :c2 a rdfs:Class . } would follow that both :c1 and :c2 have empty class extensions and that therefore :c1 and :c2 are mutually subclasses of each other? But when I add another triple ":w a :c1" to G, then :c1 would not be a subclass of :c2 any longer, since :c1 is non-empty now, so this approach seems to make the RDF semantics non-monotonic? And wouldn't this approach introduce a unique name assumption (UNA), provided that a Herbrand interpretation would set I(:c1) := ":c1", I(:c2) := ":c2", and with distinct URIs ":c1" and ":c2" we would receive I(:c1) != I(:c2)?

Other proposals like making the current non-normative rules the normative one seem unmotivated to me, but would make semantic extensions on top of RDFS (e.g. OWL Full) or the integration with other formalisms (e.g. RIF+RDF combinations) much harder up to impossible. Going even further by removing the current model-theory would then mean that other languages using the RDF semantics, and which themselves use model-theories (the use of model-theories is quite standard), would have to reconstruct the RDF(S) model-theory every time for their own purposes. Without a model-theory but only with a set of rules, analyzing the RDF(S) semantics mathematically (e.g. proving that an entailment holds or not) will become hard, and very hard to impossible for semantic extensions or combinations. In particular, in current RDF the model-theory is used to prove the correctness of the rule-set (entailment lemma). Without a model-theory (for which an adaptation to an updated language is typically rather straight-forward, as one can see from OWL 2 Full and RIF), it may become difficult to build a new rule-set that people are willing to believe that it correctly represents the intended semantics of RDFS.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher No opinion No opinion No opinion No opinion
Peter Jeszenszky 4 3 3 1
Raphaël Troncy 2 1 No opinion 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

20. Explain How to Determine What a URI Means

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 11 19 15 24 16 42
How much will this benefit you/your organization? 14 19 22 16 7 49
How easy will this be? 17 21 17 7 5 60
How much do you expect to help? 29 18 13 3 3 61

Averages:

Choices All responders:
Value
How much will this benefit the community?3.18
How much will this benefit you/your organization?2.78
How easy will this be?2.43
How much do you expect to help?1.98

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho No opinion No opinion No opinion No opinion
Axel Polleres No opinion No opinion No opinion No opinion
Eric Prud'hommeaux 1 2 1 1
James Leigh 4 3 4 3
Christoph Lange 2 2 2 1 Where this goes beyond the standardization of Linked Data (which I'd appreciate), I don't understand its relevance.
Manu Sporny 3 3 5 1 We've never had to calculate the transitive closure or perform inference on our RDF graphs... perhaps that will change in time, but we use RDF more as a data/storage model than as a KR format. The KR part is more embodied in source code, not the data model.
Paul Tyson No opinion No opinion No opinion No opinion
Holger Knublauch No opinion No opinion No opinion No opinion
Lee Feigenbaum 3 1 No opinion No opinion
Masahide Kanzaki 1 1 1 No opinion
Abhik Banerjee 3 3 No opinion 4
Pierre-Yves Chibon 5 5 3 3
Olaf Hartig 4 3 2 2
stéphane pouyllau 4 5 No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau 5 2 2 2
Nina Jeliazkova 5 3 No opinion 1
Olivier Grisel 4 4 No opinion 1
Jeen Broekstra 3 3 2 No opinion
Armen Martirosyan 5 1 1 1 Not an easy issue. I think this one is hard to standardize and probably this is subject to convention rather than a specification, although...
Josh Jonte No opinion No opinion No opinion No opinion
Bob DuCharme 4 3 2 2
Brian Peterson No opinion No opinion No opinion No opinion
Quentin Reul 1 1 1 1 Thought Cool URIs (http://www.w3.org/TR/cooluris/) were defined for this
Yann Mombrun 2 2 1 1
Peter Andersen 1 1 1 1
Colm Kennedy 5 4 No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes No opinion No opinion No opinion No opinion
Patrick Stickler 5 4 5 3 C.f. URIQA (http://sw.nokia.com/uriqa/URIQA.html)
Jean-Paul DECLE 2 3 2 2
Rinke Hoekstra 3 3 3 1
Renaud Delbru 2 2 3 No opinion
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 3 3 1 3 The URI schema should be defined, as in question 20. I don't think one could "define" the only naming schema. Maybe it's necessary to abstract from the URL, the URI is only a name for an identity. If one would like to embed information in the URI schema, it is necessary to define a hierarchy of things e.g. http://thing/animal/bird/owl … that a task too big to handle
Chimezie Ogbuji 1 1 1 1 RDF semantics and the various RDF semantic extensions already do this and have for a long time
James Hendler 4 1 2 3
Mike Dean No opinion No opinion No opinion No opinion
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci 5 5 3 3
Jamie Taylor No opinion No opinion No opinion No opinion I don't fully understand the description of the work area - but one thing is clear: in practice, URIs are not opaque, they are generally created through the use of templates using well-known cross-web identifiers. (e.g., everyone knows that DBPedia URIs are constructed from Wikipedia wikiwords and that BBC music URIs are constructed from MusicBrainz identifiers.

When the rules for template creation are well described by the information provider, the structure of the URI can be used to understand the identity of the resource. It would nice if 1) the standards documents took this highly utilized and leveragable practice into account. 2) provided mechanism for using these practices directly.
David Wood 2 4 No opinion No opinion
Mischa Tuffield No opinion No opinion No opinion No opinion
Kjetil Kjernsmo 4 4 5 1
Renato Iannella 3 No opinion 5 No opinion Too Hard
Ivan Herman 3 No opinion 2 No opinion
Toby Inkster No opinion No opinion No opinion No opinion
Peter Mika 4 3 3 2
Steve Harris 2 1 3 1
Bob Ferris 5 5 No opinion No opinion Since we can have a Semantic Graph behind every URI someday, we can explain what a specific URI stands for.
Charles Nepote No opinion No opinion No opinion No opinion
Jun Zhao 4 2 4 1
Chris Beer 5 4 3 2
Christopher Welty No opinion No opinion No opinion No opinion
James Myers No opinion No opinion No opinion No opinion
Ryan Kohl No opinion No opinion No opinion No opinion
Lowell Vizenor No opinion No opinion No opinion No opinion
jans aasman 4 4 2 2
Marco Neumann 4 3 2 3
David Peterson 5 3 No opinion No opinion
Kai Eckert No opinion No opinion No opinion No opinion
Irene Celino 4 4 2 No opinion
Dave Reynolds 2 2 4 1 This seems like a similar issue to 20 but the description is very unclear. Mixing up "social meaning" and semantics seems like a recipe for confusion and non-terminating working groups. I believe RDF Core back off from "social meaning" for good reasons.
De Roo Jos No opinion No opinion No opinion No opinion
David Booth 4 4 3 5
Sergio Fernández 2 2 4 1
Ted Guild
Gregg Kellogg 5 4 3 3 Not clear if/when a URI should be canonicalized. Differences in RDF-URI/IRI representation and escaping to URI should be resolved.
Ian Horrocks 1 1 1 1
Micah Herstand 5 5 2 3
Aidan Hogan No opinion No opinion No opinion No opinion
Graham Klyne No opinion No opinion No opinion No opinion
Andy Seaborne 4 3 2 1
Mohamed ZERGAOUI 4 4 4 4
Christophe THOVEX No opinion No opinion No opinion No opinion
Richard Cyganiak 2 2 1 2 A rat's nest. Solves no real problem. Potentially harmful by creating new baggage that stands in the way of simply using RDF as a data structure.
Nathan Rixham 1 1 No opinion 1 ? give something a uri, describe it with RDF, consult that RDF to read it's description, meaning is different in every context and.. unsure why this is on the list tbh.
Paul Trevithick No opinion No opinion No opinion No opinion
Jérôme Mainka 4 4 1 3
Antoine Zimmermann 2 2 No opinion No opinion URIs should be opaque identifiers. If an application wants to do something special with the form of the URI, fine. But this should not be part of the standard.
Henry Story 3 No opinion No opinion No opinion sounds like more of a best practices document.
Frank Olken 3 3 3 3
Gavin Carothers No opinion No opinion No opinion No opinion
Enrico Franconi 2 2 2 2
Bryan Copeland 5 5 5 5
Emmanuelle BERMES 2 2 No opinion 1
Vojnisek Péter No opinion No opinion No opinion No opinion
hodder mary No opinion No opinion No opinion No opinion
Paul Wilton 5 4 4 2
Antoine Isaac 3 2 No opinion No opinion
Fabien Gandon No opinion No opinion No opinion No opinion
Palmisano Davide 1 1 No opinion 1
Egon Willighagen 3 4 3 1 I think this addresses interesting points, at least for my work. I have been using URIs in a loose way, and some guidance on best-practices are most welcome here. For many issues like these, the current best approach is to ask around, and a more formal documentation would remove the problem of 'who did you ask'...
Reto Bachmann No opinion No opinion No opinion No opinion
William Waites No opinion No opinion No opinion No opinion
Sarven Capadisli No opinion No opinion No opinion No opinion Doesn't belong in RDF.
Ji���­ Proch�¡zka 4 No opinion 1 2
Stasinos Konstantopoulos 2 2 3 3 Why would one want to do this in the RDF spec?
Olivier Berger No opinion No opinion No opinion No opinion
Michael Hausenblas 2 2 1 No opinion
Janne Saarela 2 2 3 2
François Scharffe 4 4 2 3
Ora Lassila 4 3 3 2
Ivan Mikhailov 3 3 2 1 The WG can not propose anything better than an evolving "best practices" list.
Pierre-Antoine Champin 5 5 3 4
Drew Perttula 3 3 1 No opinion
John Goodwin No opinion No opinion No opinion No opinion
Dodds Leigh 2 2 No opinion 1
Arpad Tamasi No opinion No opinion No opinion No opinion
Dave Pawson No opinion No opinion No opinion No opinion
Yves Raimond No opinion No opinion No opinion No opinion If work needs to happen here, it should happen in item 20. This item is not very clearly explained either.
michel bercovier 4 No opinion No opinion No opinion
Bernhard Haslhofer 4 4 3 5 I am not 100% sure whether or not this falls into this category, but currently there is a discussion on addressing complex fragments in media objects via URIs: http://blog.mediaspaces.info/2010/09/09/web-annotations-addressing-complex-regions-with-uris/
Martín Álvarez 5 3 4 2
Stéphane Corlosquet 4 No opinion No opinion 2
Paul Reeves 4 3 3 2
Nicholas Humfrey No opinion No opinion No opinion No opinion
Evren Sirin 2 1 2 1
Niklas Lindström 3 No opinion 2 No opinion Practical best practice advice and focus on technological (protocol) aspects could be good.

Stating where "there be philosophy" might help people understand the importance of the precision of URI:s/identity and discoverability, while avoiding some of the lengthy discussions...
Michael Schneider 2 2 1 1 In RDF, a URI is just some name and can denote everything, and this is also the case in OWL and RIF. More specific interpretations should be up to applications. Defining such a specific meaning can easily get in conflict with the RDF semantics. I do not see some obvious path forward here, and I cannot foresee the consequences. For me, this is clearly out of scope for an RDF core WG.
Vadim Eisenberg No opinion No opinion No opinion No opinion
Steve Speicher 4 3 2 2
Peter Jeszenszky 1 3 2 1
Raphaël Troncy 1 1 1 1
1 1 1 1 1 1 1
555-555-0199@example.com 555-555-0199@example.com 2 2 2 2

21. Allow Literals as Subjects

See full description (on wiki) for details.

See above for the 1-5 scale.

Summary

ChoiceAll responders
12345No opinion
How much will this benefit the community? 37 25 13 11 9 32
How much will this benefit you/your organization? 44 16 16 8 6 37
How easy will this be? 25 20 14 18 4 46
How much do you expect to help? 41 16 11 4 1 54

Averages:

Choices All responders:
Value
How much will this benefit the community?2.26
How much will this benefit you/your organization?2.07
How easy will this be?2.46
How much do you expect to help?1.74

Details

Responder How much will this benefit the community?How much will this benefit you/your organization?How easy will this be?How much do you expect to help?Comments
Sandro Hawke No opinion No opinion No opinion No opinion
Melvin Carvalho 1 No opinion No opinion No opinion
Axel Polleres 2 2 3 No opinion It might not be so hard to allow this, but it has consequences that I am still unsure about.
Eric Prud'hommeaux 2 2 4 2
James Leigh 1 1 1 2
Christoph Lange 2 2 3 1
Manu Sporny 1 1 4 1 We've never had a need for literals as subjects.
Paul Tyson 1 1 No opinion No opinion
Holger Knublauch 1 1 1 No opinion
Lee Feigenbaum 1 1 1 1
Masahide Kanzaki 2 2 2 No opinion not quite sure, but seems less benefit, more confusion
Abhik Banerjee No opinion No opinion No opinion No opinion
Pierre-Yves Chibon No opinion No opinion No opinion No opinion
Olaf Hartig 3 3 3 1
stéphane pouyllau No opinion No opinion No opinion No opinion
Philipp Schaffner No opinion No opinion No opinion No opinion
Paul Hermans No opinion No opinion No opinion No opinion
Gautier Poupeau 3 4 2 1
Nina Jeliazkova 1 No opinion No opinion No opinion Not sure this will be an advantage.
Olivier Grisel 1 1 No opinion 1
Jeen Broekstra 1 1 1 1 I've never understood the clamoring for this. I find it completely unnecessary and counter-intuitive.
Armen Martirosyan 5 1 2 2
Josh Jonte 3 No opinion 4 No opinion
Bob DuCharme 1 2 4 2
Brian Peterson 3 2 2 2
Quentin Reul 1 1 No opinion 1
Yann Mombrun 1 1 1 No opinion
Peter Andersen 1 1 1 1
Colm Kennedy No opinion No opinion No opinion No opinion
Ruben Verborgh No opinion No opinion No opinion No opinion
Gunnar Grimnes 1 1 1 1 This would enable some scenarios of limited usefulness at the terrible cost of complete loss of backwards compatibility. Avoid!
Patrick Stickler 4 4 4 2
Jean-Paul DECLE 1 1 1 1
Rinke Hoekstra 2 2 2 1
Renaud Delbru 3 3 1 No opinion I don't really see a negative point towards allowing literals as subjects, but I don't see a huge benefits also. I am more neutral about this point.
Jochem Liem No opinion No opinion No opinion No opinion
Axel Klarmann 1 1 4 1 I don't think its worth doing, because the problems that arise are the same as in question 19 and 21, that would lead to many ambiguities
Chimezie Ogbuji 1 1 1 1
James Hendler No opinion No opinion 5 No opinion
Mike Dean 1 1 2 1
Andrew Perez-Lopez No opinion No opinion No opinion No opinion
Hassan Ait-Kaci