Search

Whoever invented RDF vocab URIs using a hash? Seems like a bad idea.

Just tripped over the problem with hash-based vocab URI's - since the fragment id is not passed from a browser to the server, its impossible to dereference the full URI on the server - in my case by providing a model-based explanation of the term.  So I'll have to switch to a proper path for the vocab and reload.

On the surface, this seems like a pretty bad idea - what am I missing?

My thanks to Norm Walsh who pointed out that hash-based and slash-based namespaces are discussed at the w3c TAG . http://www.w3.org/2001/tag/issues.html#httpRange-14 lists key documents in a long-running debate of which the culmination is the paper on Cool URIs http://www.w3.org/TR/cooluris/

I'd seen it of course, but sometimes information only become relevant when you have to make a design decision, choose the wrong way and you get bitten in the bum.

It seems to me naively that there are two aspects:

-one is about what URIs refer to - documents or things. Is ambiguity good or bad, necessary or able to be eliminated? Freud defined Neurosis as the inability to tolerate ambiguity - the danger of the Semantic web becoming the Neurotic web lurks here.My own view is that ambiguity is inherent, context matters and can't be defined away.

-the other is engineering - a hash URI does not mean the same thing to client and server - the server doesn't see the fragment id so they don't share the same value. Using references within a vocabulary document for vocab terms rather than a fully shared URI seems a short-term cludge to allow vocabularies to be fully defined in a single document. But that's not scalable when the number of tags increases or you want to provide a response based on a server-side lookup of, say a model.

Developers have to decide on which form to use - in my view your should not bother with hash namespaces. Now to think about 303 redirects and all that apparatus.