John Sheridan is pondering URIs and URNs. I have pondered that a lot too. The idea of having another degree of independence between names (e.g. cites to legislation) and actual dereferencable identifiers makes a lot of sense of course. We don't want to tie ourselves down to implementations or platforms or server hosts if we can avoid it. Especially if the goals is to have very long lived identifiers.
However, a few things worry me about the standard "lets use URNs" reaction to long term identifiers.
1) URL's are already completely and utterly devoid of any direct connection to the underlying assets they point to. The number of levels of indirection present in your average resolution of a URL to a stream of bytes in RAM is already very large and many of them are under our control. I.e. we can change the mappings at will. The days of "static" IP addresses are long gone. So, the notion that URNs help because you can change the resolution process without touching the assets themselves doesn't sit well with me because I can do that with plain old URLs...At many levels from DNS to VLANs to NATting to HOSTS files to http redirects etc. etc.
Given the plethora of mappings already present in the (URL->Resource Representation) resolution process, do we gain much adding another one in the form of a URN mapping?
2) URN schemes need resolvers and in many systems I have seen that use URNs, representations get served up with embedded hyperlinks. The embedded hyperlinks often use URLs to access the URN resolver. I.e. http://.../resolve_urn?urn=foo. But of course, in order to do that, the representation ends up creating a dependency on the URL that accesses the resolver :-) If I save that asset, I now have a rendering that is dependent on the URL resolve - despite the presence of the URNs in the asset. So, have I gained anything?
3) It is true of course that domains are rented not owned and this makes folks uneasy about long term reliance on a namespace that is not fully under their control. However, the world is now so utterly dependent on DNS that a fair amount of caselaw exists to protect entities against cybersquats and loss of access to DNS rental rights. Plus standing up your own DNS inside a firewalled environment is straightfoward. Plus creating local mappings in a hosts file is very staightforward. And so on. Lots of options if you need to take control of the resolution process and re-map it.
4) Finally, a non-technical argument that also plays into my skepticism about URNs. They have been around forever. So have identifier schemes like DOI and SSN etc. The internet seems to have voted with its feet already and subsumed all these into URL based resolvers of various kinds. Witness the recent explosion in link shorterners. They map a URL to another URL...I just don't see market pressure out there for a different way to control de-referencing on the Internet.
All in all, with all the mappings already present and the malleability/configurabilty of same, I don't see the compelling rationale for adding other one in the form of URNs.
What am I missing?
6 comments:
It always struck me that the notion of a URN resolver somehow misses the whole point of URNs; if something needs to be resolved, it should be a URL, not a URN.
URNs are useful for things like XML namespaces, OIDs and GUIDs (that don't really point to anything), or for things like SGML PUBLIC identifiers (where it's assumed that the consumer already knows, or can arrange to know locally what the well-known public name resolves to).
Couldn't agree more.
At MMI* we made this same call about 4 years ago, based on all the same thinking -- from a mathematical perspective, I couldn't see any advantages to a URN, and the huge disadvantage was resolvability (and therefore usability). So far, trend in geosciences since then favors the URL approach (but DOIs are definitely winning a space in publications!).
I haven't heard anything that convinces me otherwise since.
Aw, this was a really great post. In theory I’d like to write like this also – taking time and real effort to make a good article… but what can I say… I procrastinate alot and never seem to get something done.
Echoing that, and following on from
What Do URIs Mean Anyway?
Would it not make sense to use a URN for non-web things, and keep the URL for web resources about/related to the thing?
URNs aren't another level of indirection, they're a different level of indirection.
You can use http: or ftp: or data: or whatever, but if you want to have naming authority which has some non-DNS administrative method for determining what a URI identifies, you can use urn:naming-authority:string.
I think the permanence issue is a matter of opinion and administration; some http URLs can be long lived and some URNs can be short lived.
If something's worth identifying globally, it's worth giving it a representation on the Web. DNS is a pain though :)
Post a Comment