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?
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.