- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 26 Nov 2012 11:40:27 +0100
- To: "www-tag@w3.org List" <www-tag@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
- Message-Id: <7B328E11-352A-4C79-97B7-1D8AA007ADD5@bblfish.net>
Dear Tag, dear public-ref-comments, The TAG and many groups, including recently the WebID group, have spent innumerable hours debating HTTP-range-14 issues. I have just come to the conclusion that a large part of this problem could be solved by an improvement in RDF-syntax. I know this may sound like a crazy idea, but when one is dealing with an issue that has used up so many unicode characters, it may be time to look at solutions that are off the beaten path. I started off by seeing where following Tim Berners' Lee's intuitions that anything that is served by HTTP is a document would lead me to. It is the simplest solution, it is elegant, and it is easy to explain. See for example the WebID editors draft [2]. Tim has been around the longest on the web, so it is my view that one should try to align with his intuitions as far as possible. Sadly though this does not work well, for a reason that has nothing to do with http-range-14, and all to do with syntax, as I argue below. Some people have argued that hash uris give one some necessary freedom to enable server side indirection. But note that hash uris do not remove 301 or 303s or any other HTTP code for that matter. But this is mistaken since one can get exactly the same freedom with #hash URIs. Say we hash-URIzed ( a new word !) the foaf ontology. Instead of - http://xmlns.com/foaf/0.1/knows - http://xmlns.com/foaf/0.1/mbox - http://xmlns.com/foaf/0.1/Person - http://xmlns.com/foaf/0.1/Agent - ... We could use - http://xmlns.com/foaf/0.1/knows#• - http://xmlns.com/foaf/0.1/mbox#• - http://xmlns.com/foaf/0.1/Person#• - http://xmlns.com/foaf/0.1/Agent#• Now imagine that Danbri still finds it useful to group all the terms in one document at http://xmlns.com/foaf/spec/ Then each of the corresponding documents would now be - http://xmlns.com/foaf/0.1/knows - http://xmlns.com/foaf/0.1/mbox - http://xmlns.com/foaf/0.1/Person - http://xmlns.com/foaf/0.1/Agent What used to be URIs identifying relations and classes are now URIs identifying documents. These could now redirect to http://xmlns.com/foaf/spec/ And you'd get the same effect as what Danbri has now. The nice thing is that Danbri would now have the option of also returning the individual definitions at the local URIs, and he would not be forced to redirect. Instead he could put a <> rdfs:seeAlso <http://xmlns.com/foaf/spec/> in each of the definitions. In any case the problem becomes clear. The problem is that the foaf files would have to be written as: @prefix foaf: <http://xmlns.com/foaf/0.1/> <#i> a foaf:Person#•; foaf:knows#• you . Which does not make for very nice Turtle and would be difficult to explain. This is I believe why the non #• solution was preferred . So why did Danbri not put all those relations in the same foaf document? Perhaps he was worried he'd end up with too big a document in the end, and he was not sure how many relations he was going to end up with. So he thought he'd rather split his definitions up initially to avoid some difficult to correct issues later. For proponents of hash URIs it seems then that what is really needed is what RDFa now offers and that is a prefix import functionality, or an aliasing functionality, so that somehow one could get foaf:Person#• and foaf:knows#• to be written as foaf:Person and foaf:knows. I am not sure how this could be written, and this should be up to the Turtle group to decide, as they are quickly taking over the mantle of RDF/XML as the default RDF syntax. It does not matter that RDF/XML would be unreadable - it always has been. But Turtle could still be changed to make this possible. Perhaps something like: @prefix foaf: <http://xmlns.com/foaf/0.1/{name}#•> or something along those lines would do. I believe I came across this issue in the past, and so have many others. ( Danbri first of all) But it is difficult to remember this issue when one is working on 1000 other things, and so this solution may never have been considered in depth by the Turtle group. Furthermore the Turtle group's mission would be so far removed from http-range-14 that they would may not have seen it as their mission to solve this issue. So I believe we here have a problem that falls in the cracks between WGs. Since the TAG is saddled with the http-range-14 issue, I believe they should help encourage the Turtle editors ( together with the RDFa editors ) to solve this problem with a syntatic fix, which we could all implement quickly and easily. Henry [1] http://www.w3.org/2001/tag/doc/httpRange-14/HttpRange-14.html [2] we are still considering the status of #uris, if we need a SHOULD, MUST or nothing, so please don't get sidetracked into this http://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html Begin forwarded message: Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 26 November 2012 10:41:03 UTC