Resolvers are subject to the same problems as URIs
A lot of people look at the Web, and at formats that rely on URIs (including but not limited to RDF) for identification of resources, with a lot of scepticism.
The argument goes something like this: “But, what happens if the resource goes away? What if the domain expires? What if the guy who runs the site becomes an evil psychopath and replaces his nice XML schema with a bunch of child pornography?”
The proponent of this line of thought uses these doubts as a premise for then suggesting that instead of the URI, we should instead have an alternative method for identifying resources, some kind of generic numerical or string identifier, perhaps namespaced in the URN space.
To which the proponent of URIs says “Ah, but the neat thing about URIs is you can load them up and get back data in {your favourite format of the week} about that resource. And you can use the semantics of HTTP to tell people the status of the thing: it can return a 302 if it moves, or if the person is polling too hard, return a different status. And, well, URIs free us from having to decode what this cryptic number or string means.”
The other fellow sits back for a few seconds and then says “I know, why don’t we set up a service that takes the identifier and converts it into a URI, which you can then do all the HTTP stuff you like doing. We’ll call this thing a resolver. It can return documents or metadata or whatever.”
The interlocuter responds: “Yes, that sounds better. So, we set up this resolver. Let’s say it is at resolver.sexyexample.org/. Now, each of these IDs get passed to it as paths. So, to resolve the resource with the ID of “12345”, we simply point our user agent to resolver.sexyexample.org/12345. You know what, we’ve got a URI now. Rather than refer to it as 12345, we may as well just refer to it as resolver.sexyexample.org/12345. Others don’t have to learn that urn:sexyexample:12345 needs to be looked up through resolver.sexyexample.org/12345, because they can just go to resolver.sexyexample.org/12345 and be done with it. And, well, people can link to it from their web pages and stuff. It’s not just like a URI, it is a URI.”
He continues: “Now it’s a URI, we have a problem. What happens if the resolver resource goes away? What if the domain expires? What if the guy who runs the resolver site becomes an evil psychopath and replaces his nice resolver service with a bunch of child pornography?”
The proponent of the resolver responds: “But that won’t happen! We won’t let the domain expire! I’ve renewed it for the next ten years, and we’ve got assurance from the government that they’ll renew it for the next fifty. We’ve incorporated as a legal corporation. And, err, we are taking all sorts of steps to make sure it all remains up.”
Then, in an ideal world, the resolver proponent suddenly lets the little hamster wheel inside his head spin a bit more and for those synaptic connections to just click into place. Sadly, it never seems to quite happen like that. And that, ladies and gents, is why we have DOIs, GUIDs, XRIs, i-names and people who persist in using URNs, and vague promises of resolver services. They are on the web, but haven’t quite discovered that the neat thing about the Internet is that it’s not centralised. The anti-logic goes a bit like this: if something has a problem, the best way to solve it is to introduce a few more layers of indirection to mask the underlying problem, rather than finding ways to ameliorate the problem.
You can solve the problem of resources that disappear by creating infrastructure that backs up and mirrors content and metadata. You then have domain-specific resolving services for URIs. If example.org/12345 goes down, you can go to example.net/resolver and say “Hey, have you got example.org/12345?” And it’d say “200! Sure!” or maybe, “404! Sorry mate.” If it says “200! Sure!”, you could then say to it “Well, you know that example.org/12345 is pretty much gone forever. Any chance you could rehost it?”. And it could say “Okay then. It’s at example.net/12345. Hand that out to people. We pretty-promise we won’t fuck up like example.org did.” Now, if you’ve read this far, you are undoubtedly a fairly smart person, and you probably have access to enough code, smarts, specifications and resources to jerry-rig something that’d do this. It doesn’t introduce indirection in everyday use. The indirection comes when something goes wrong. And that’s fine. It’s kind of weblike too. I mean, perhaps I don’t trust example.net, but I’m impressed by the service provided by example.com - so I use them to resolve disappearing resources. And, well, if the previously dead resource comes back online at example.org again, then both example.net and example.com can just redirect with the the right 3xx status.
