W3C
Site Navigation
Nearby
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.
127 answers have been received.
Jump to results for question:
- Your Name and Organization
- Official Response
- Your Expertise
- Additional Comments
- What do you like about RDF?
- What do you dislike about RDF?
- Most Important Addition to RDF
- Priorities
- Add Core Support for Working With Multiple Graphs
- Make Well-Known Repairs To The Specification Text
- Create a Standard JSON RDF Syntax
- Make Turtle a W3C Standard
- Indicate Which RDF Features Are No Longer Best Practice
- Extend RDF/XML
- Revise Semantics for Blank Nodes
- Create Standards for Deployment of Linked Data
- Define Some Useful Similarity/Equivalence Properties
- Define a Namespace Packaging Mechanism
- Change RDF Semantics to Plain Data (SPARQL) Style
- Explain How to Determine What a URI Means
- Allow Literals as Subjects
- Improve Integration with Syndication Systems (Atom)
- 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 | |
| Martin Alvarez | |
| 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 |
| 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
| Choice | All responders |
|---|---|
| Results | |
| yes | 23 |
| 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 |
| Martin Alvarez | 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 |
| 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:
- I do not know anything about this subject
- I have spent at most a few hours thinking about this subject
- I have spent days or weeks on this subject
- I have spent months on this subject
- I have worked in the area in depth for years
Summary
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| RDF | 1 | 11 | 31 | 81 | 2 | |
| OWL | 1 | 10 | 32 | 41 | 39 | 3 |
| SPARQL | 1 | 9 | 26 | 44 | 43 | 3 |
| W3C Semantic Web technologies, in general | 1 | 11 | 40 | 70 | 4 | |
| Semantic Web Community and Industry | 9 | 22 | 39 | 48 | 8 | |
| XML Technologies | 1 | 7 | 26 | 40 | 48 | 4 |
| Database Technologies | 1 | 7 | 26 | 43 | 44 | 5 |
| Website Development Technology | 1 | 8 | 24 | 35 | 53 | 5 |
| Software Development | 3 | 5 | 12 | 27 | 74 | 5 |
| W3C Recommendation-Track Process | 17 | 26 | 29 | 22 | 24 | 8 |
| W3C Community and Industry | 16 | 26 | 31 | 26 | 18 | 9 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| RDF | 4.55 |
| OWL | 3.87 |
| SPARQL | 3.97 |
| W3C Semantic Web technologies, in general | 4.47 |
| Semantic Web Community and Industry | 4.07 |
| XML Technologies | 4.04 |
| Database Technologies | 4.01 |
| Website Development Technology | 4.08 |
| Software Development | 4.36 |
| W3C Recommendation-Track Process | 3.08 |
| W3C Community and Industry | 3.03 |
Details
| Responder | RDF | OWL | SPARQL | W3C Semantic Web technologies, in general | Semantic Web Community and Industry | XML Technologies | Database Technologies | Website Development Technology | Software Development | W3C Recommendation-Track Process | W3C 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 | |
| Martin Alvarez | 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 | |
| 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 |
| Martin Alvarez | 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. |
| 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. |
| Martin Alvarez | 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. |
| 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... |
| Martin Alvarez | 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 |
| 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) |
| Martin Alvarez | |
| 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 |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| Make RDF smaller/simpler | 36 | 19 | 12 | 12 | 23 | 24 |
| Make RDF larger/more powerful | 37 | 34 | 16 | 6 | 10 | 23 |
| Redesign some parts of the RDF/XML syntax | 27 | 22 | 17 | 21 | 11 | 28 |
| Redesign some parts of the RDF model | 27 | 20 | 15 | 30 | 9 | 25 |
| Improve RDF's suitability for data/database work | 10 | 9 | 17 | 31 | 32 | 27 |
| Improve RDF's suitability for semantic/KR work | 17 | 28 | 17 | 19 | 15 | 30 |
| Provide better syntaxes for RDF | 10 | 14 | 21 | 23 | 33 | 25 |
| Provide better documentation | 13 | 12 | 21 | 24 | 31 | 25 |
| Explain the business case better | 10 | 13 | 21 | 22 | 34 | 26 |
| Provide better communication, community support | 11 | 16 | 22 | 21 | 21 | 35 |
| Help people find or develop RDF vocabularies | 8 | 8 | 16 | 33 | 38 | 23 |
| Develop more compelling applications | 13 | 9 | 18 | 29 | 33 | 24 |
| Develop standard vocabularies | 9 | 14 | 17 | 35 | 32 | 19 |
| Work on RDF Security | 14 | 12 | 29 | 29 | 12 | 30 |
| Work on RDF Trust & Provenance | 5 | 9 | 24 | 44 | 26 | 18 |
| Work on Synchronization, Distribution, and Versioning of RDF Data | 6 | 9 | 30 | 35 | 23 | 23 |
| Work on bridging between RDF and XML | 30 | 13 | 20 | 13 | 14 | 36 |
| Standardize RDF API in Javascript | 12 | 17 | 20 | 28 | 21 | 28 |
| Standardize RDF APIs in other languages | 15 | 12 | 21 | 21 | 23 | 34 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| Make RDF smaller/simpler | 2.68 |
| Make RDF larger/more powerful | 2.20 |
| Redesign some parts of the RDF/XML syntax | 2.66 |
| Redesign some parts of the RDF model | 2.74 |
| Improve RDF's suitability for data/database work | 3.67 |
| Improve RDF's suitability for semantic/KR work | 2.86 |
| Provide better syntaxes for RDF | 3.54 |
| Provide better documentation | 3.48 |
| Explain the business case better | 3.57 |
| Provide better communication, community support | 3.27 |
| Help people find or develop RDF vocabularies | 3.83 |
| Develop more compelling applications | 3.59 |
| Develop standard vocabularies | 3.63 |
| Work on RDF Security | 3.14 |
| Work on RDF Trust & Provenance | 3.71 |
| Work on Synchronization, Distribution, and Versioning of RDF Data | 3.58 |
| Work on bridging between RDF and XML | 2.64 |
| Standardize RDF API in Javascript | 3.30 |
| Standardize RDF APIs in other languages | 3.27 |
Details
| Responder | Make RDF smaller/simpler | Make RDF larger/more powerful | Redesign some parts of the RDF/XML syntax | Redesign some parts of the RDF model | Improve RDF's suitability for data/database work | Improve RDF's suitability for semantic/KR work | Provide better syntaxes for RDF | Provide better documentation | Explain the business case better | Provide better communication, community support | Help people find or develop RDF vocabularies | Develop more compelling applications | Develop standard vocabularies | Work on RDF Security | Work on RDF Trust & Provenance | Work on Synchronization, Distribution, and Versioning of RDF Data | Work on bridging between RDF and XML | Standardize RDF API in Javascript | Standardize RDF APIs in other languages | Comments |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 2 | 15 | 35 | 60 | 14 | |
| How much will this benefit you/your organization? | 1 | 8 | 15 | 51 | 33 | 18 |
| How easy will this be? | 3 | 20 | 32 | 32 | 8 | 31 |
| How much do you expect to help? | 16 | 35 | 31 | 15 | 2 | 27 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 4.37 |
| How much will this benefit you/your organization? | 3.99 |
| How easy will this be? | 3.23 |
| How much do you expect to help? | 2.52 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 1 | 7 | 19 | 34 | 23 | 42 |
| How much will this benefit you/your organization? | 10 | 8 | 32 | 18 | 12 | 46 |
| How easy will this be? | 2 | 6 | 17 | 23 | 30 | 48 |
| How much do you expect to help? | 26 | 28 | 12 | 7 | 1 | 52 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 3.85 |
| How much will this benefit you/your organization? | 3.18 |
| How easy will this be? | 3.94 |
| How much do you expect to help? | 2.04 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 1 | 6 | 15 | 39 | 40 | 25 |
| How much will this benefit you/your organization? | 3 | 12 | 32 | 30 | 18 | 31 |
| How easy will this be? | 2 | 11 | 36 | 25 | 9 | 43 |
| How much do you expect to help? | 24 | 26 | 16 | 12 | 4 | 44 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 4.10 |
| How much will this benefit you/your organization? | 3.51 |
| How easy will this be? | 3.34 |
| How much do you expect to help? | 2.34 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 7 | 5 | 15 | 30 | 51 | 18 |
| How much will this benefit you/your organization? | 11 | 7 | 29 | 27 | 27 | 25 |
| How easy will this be? | 2 | 8 | 4 | 34 | 40 | 38 |
| How much do you expect to help? | 24 | 30 | 15 | 8 | 3 | 46 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 4.05 |
| How much will this benefit you/your organization? | 3.51 |
| How easy will this be? | 4.16 |
| How much do you expect to help? | 2.20 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 4 | 6 | 20 | 48 | 27 | 20 |
| How much will this benefit you/your organization? | 7 | 25 | 22 | 26 | 15 | 30 |
| How easy will this be? | 3 | 14 | 22 | 32 | 11 | 43 |
| How much do you expect to help? | 28 | 36 | 14 | 7 | 40 | |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 3.84 |
| How much will this benefit you/your organization? | 3.18 |
| How easy will this be? | 3.41 |
| How much do you expect to help? | 2.00 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 22 | 15 | 21 | 30 | 12 | 26 |
| How much will this benefit you/your organization? | 24 | 19 | 31 | 11 | 10 | 31 |
| How easy will this be? | 13 | 19 | 27 | 14 | 4 | 49 |
| How much do you expect to help? | 33 | 26 | 13 | 2 | 1 | 51 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 2.95 |
| How much will this benefit you/your organization? | 2.62 |
| How easy will this be? | 2.70 |
| How much do you expect to help? | 1.83 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 19 | 15 | 21 | 25 | 14 | 32 |
| How much will this benefit you/your organization? | 19 | 13 | 27 | 19 | 9 | 39 |
| How easy will this be? | 17 | 28 | 17 | 9 | 3 | 52 |
| How much do you expect to help? | 32 | 17 | 15 | 9 | 2 | 51 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 3.00 |
| How much will this benefit you/your organization? | 2.84 |
| How easy will this be? | 2.36 |
| How much do you expect to help? | 2.09 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 1 | 4 | 13 | 39 | 53 | 16 |
| How much will this benefit you/your organization? | 4 | 11 | 17 | 35 | 35 | 24 |
| How easy will this be? | 7 | 8 | 43 | 25 | 6 | 37 |
| How much do you expect to help? | 17 | 24 | 25 | 17 | 7 | 36 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 4.26 |
| How much will this benefit you/your organization? | 3.84 |
| How easy will this be? | 3.17 |
| How much do you expect to help? | 2.70 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 7 | 11 | 22 | 39 | 19 | 28 |
| How much will this benefit you/your organization? | 10 | 8 | 31 | 31 | 15 | 31 |
| How easy will this be? | 7 | 21 | 26 | 21 | 3 | 48 |
| How much do you expect to help? | 20 | 28 | 18 | 8 | 4 | 48 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 3.53 |
| How much will this benefit you/your organization? | 3.35 |
| How easy will this be? | 2.90 |
| 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 | 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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 2 | 11 | 29 | 27 | 14 | 43 |
| How much will this benefit you/your organization? | 7 | 15 | 27 | 21 | 7 | 49 |
| How easy will this be? | 3 | 6 | 30 | 18 | 4 | 65 |
| How much do you expect to help? | 26 | 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.08 |
| How easy will this be? | 3.23 |
| 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 | 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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 15 | 17 | 24 | 17 | 5 | 48 |
| How much will this benefit you/your organization? | 17 | 15 | 28 | 9 | 4 | 53 |
| How easy will this be? | 16 | 26 | 11 | 6 | 4 | 63 |
| How much do you expect to help? | 30 | 15 | 9 | 4 | 3 | 65 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 2.74 |
| How much will this benefit you/your organization? | 2.56 |
| How easy will this be? | 2.30 |
| How much do you expect to help? | 1.93 |
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 | |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 10 | 19 | 15 | 24 | 16 | 42 |
| How much will this benefit you/your organization? | 13 | 19 | 22 | 16 | 7 | 49 |
| How easy will this be? | 16 | 21 | 17 | 7 | 5 | 60 |
| How much do you expect to help? | 28 | 18 | 13 | 3 | 3 | 61 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 3.20 |
| How much will this benefit you/your organization? | 2.81 |
| How easy will this be? | 2.45 |
| How much do you expect to help? | 2.00 |
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/ |
| Martin Alvarez | 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 | |
| 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
| Choice | All responders | |||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | No opinion | |
| How much will this benefit the community? | 36 | 25 | 13 | 11 | 9 | 32 |
| How much will this benefit you/your organization? | 43 | 16 | 16 | 8 | 6 | 37 |
| How easy will this be? | 24 | 20 | 14 | 18 | 4 | 46 |
| How much do you expect to help? | 40 | 16 | 11 | 4 | 1 | 54 |
Averages:
| Choices | All responders: |
|---|---|
| Value | |
| How much will this benefit the community? | 2.28 |
| How much will this benefit you/your organization? | 2.08 |
| How easy will this be? | 2.48 |
| How much do you expect to help? | 1.75 |
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 | 4 | 3 | 5 | 4 | |
| Jamie Taylor | No opinion | No opinion | No opinion | No opinion | |
| David Wood | 2 | 1 | 2 | 2 | |
| Mischa Tuffield | 1 | 1 | 3 | 1 | |
| Kjetil Kjernsmo | 2 | 1 | 3 | 1 | I have not felt that I need it, and is also a change too intrusive for RDF NG, I feel. |
| Renato Iannella | No opinion | No opinion | No opinion | No opinion | |
| Ivan Herman | 3 | No opinion | 3 | No opinion | |
| Toby Inkster | 4 | 4 | 1 | 3 | |
| Peter Mika | 1 | 1 | 2 | 3 | |
| Steve Harris | 2 | 1 | 1 | 1 | The cost of implementing this is far, far too great to justify the benefit. |
| Bob Ferris | 5 | 5 | No opinion | No opinion | Remember my initial words to the freedom of that users expect. |
| Charles Nepote | 1 | 1 | No opinion | No opinion | |
| Jun Zhao | 4 | 3 | 4 | 1 | |
| Chris Beer | 3 | 3 | 3 | 2 | This is one of those things which people realise reality kind of dictates as useful, but how to do it with breaking RDF / makin |