#URIs & redirections: why syntax changes are needed for http-range-14 resolution

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/