Hi Jeni, Please can you clarify something for me? (I am not very good at reading these formal documents - a bear of little brain, perhaps.)
Am I right in thinking that, under your Change Proposal, the following sort of thing becomes possible (I hope I am getting it right). Taking a site such as myexperiment.org (but it could very easily by the eprints software, BBC, or even dbpedia.) See http://www.myexperiment.org/workflows/16 A huge barrier to adoption of LD for them was that their users would be exposed to the intricacies of the different URIs, and in particular that if myexperiment.org moved over to using LD URIs completely, users would not be able to cut and paste them from the address bar etc.. Great confusion would ensue, especially as their workflows already offered XML in addition to the HTML. This was a Bad Thing for them - their users were only just coming to terms with all this online workflow stuff, and could easily get spooked. They nearly didn't do it, but because many of their technology providers were Linked Data people, it went ahead (a few years ago now). The current outcome is what you see at the bottom of the workflow page - a panel offering the different URIs, with a link to a page describing the Linked Data world (to Chemists), which they are expected to understand. (Hash URIs might have been a bit better, but introduced a different mechanism from the XML.) As a result of your Change Proposal, it would have been acceptable (*if they wanted*), to simply add RDF as a Content Negotiation option, and deliver an RDF document with 200, in response to -H Accept:application/rdf+xml http://www.myexperiment.org/workflows/16, just as they did for XML, I think. And this would enable them to use http://www.myexperiment.org/workflows/16 as the anchor throughout the site (as they do) and have the same URI in the address bar, and in fact have http://www.myexperiment.org/workflows/16 as the only thing users see. Is that right? Apropos Doing It Wrong: It is interesting to note that I see myexperiment.org have made the practical decision to 303 to the RDF from curl -i -L -H Accept:application/rdf+xml http://www.myexperiment.org/workflows/16.html which suggests that they are already subverting things to get round some sort of problem. Few sites I can find (apart from dbpedia) actually return 406 when you ask the HTML URI for RDF: they usually return the HTML. It is a foolish agent that relies on RDF coming back from a 200 OK when it has asked for application/rdf+xml. Apropos Risk. You say there is no risk. Is this a risk?: There may be a serious increase in the number of URIs for current sites. Taking Freebase as another example. (In fact any of these sites that have worked hard to conform to the current regime will have a decision to make.) Presently, if I curl -i -L -H Accept:application/rdf+xml http://www.freebase.com/view/en/engelbert_humperdinck it gives me back HTML. What will it do in future? I know this Change Proposal is not proposing that they need to change, but will they? They already have http://rdf.freebase.com/ns/en.engelbert_humperdinck (and http://rdf.freebase.com/ns/m.047vj6 and another longer one). Effectively http://www.freebase.com/view/en/engelbert_humperdinck becomes yet another URI that people can use, since it would return RDF (as myexperiment). Obviously I am viewing this a bit from the sameAs.org viewpoint. I know that the resource in the RDF document will (should) never be the HTML URI, but people can and possibly will start passing around the HTML URI as if it was the "proper" URI, and so a sensible sameAs service would have it as a way of looking up the "proper" URIs. In fact I have sometimes toyed with the idea of allowing look up by HTML URL on sameAs.org (giving back only the "real" Linked Data URIs) - it is what a user expects from such a query, after all. (I hope all that makes sense.) My view of this potential Risk, however, is that it is a long-term risk of the way we are doing things now. If Linked Data is really successful, we will be at best in a myexperiment world. And so the sooner we make the change, the more manageable the Risk is. Best Hugh -- Hugh Glaser, Web and Internet Science Electronics and Computer Science, University of Southampton, Southampton SO17 1BJ Work: +44 23 8059 3670, Fax: +44 23 8059 3045 Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652 http://www.ecs.soton.ac.uk/~hg/
