I’ve been skimming through the info URI scheme RFC. From the Cover Pages we learn that the scheme “was developed within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation.“.
We also learn that “The motivation behind developing the info URI scheme is “to allow legacy identification systems to become part of the Web global information architecture so that the information assets they identify can be referenced by Web-based description technologies such as XLink, RDF, or Topic Maps. The scheme is concerned with ‘information assets’, not ‘digital assets’ per se, so the information assets may be variously digital, physical or conceptual.”“.
I’m trying to get my head around why it’s necessary to have a new URI scheme for this purpose — why not use a URN or an HTTP URI? For further discussion on that we have to look at “Section 7 Rationale” of the RFC.
One main reason seems to be passed on a desire to avoid any expectation of dereferencing semantics. Info scheme URIs cannot be dereferenced, they are for identification only. So the reason for not using an HTTP URI is because they can be dereferenced; one reason for not using a URN is because they’re encouraged to have a mapping to a dereferencable form.
Another reason for not using a URN is persistence of the identifier. A URN is supposed to be a stable identifier for a resource, but an info URI has no claims to stability. To be precise: “The “info” URI scheme is neutral with respect to identifier persistence”
Unfortunately I’m still none the wiser to the actual benefits here. It seems that the info scheme gives me a non-deferencable, and in all likelihood non-stable identifier for a resource. Um, doesn’t that give us the worst possible scenario?
Being able to dereference a URI is an important quality IMO; and thats one reason I like RDDL. If I can do a GET request and get the resource, or some metadata then that resource is bound into the web infrastructure. If the location isn’t stable then following HTTP 3XX codes can lead me to the correct location. Redirection is one of the client-server co-ordination mechanisms that’s built into the guts of the web, why not use it?
More discussion on info URIs here.
I’ve not encounted a URI discussion that doesn’t have all sorts of hidden complexities so no doubt I’m missing something. Anyone else see any strong benefits of having a new scheme here?
The Info URI Scheme, Why?
Published
Lost Boy 
Nope, you’re bang on. It’s a dumb idea.
The info: FAQ answers some of your questions including comparisons to URNS and TAG URIs. I still don’t see the benefit of a not resolvable URI; and they cannot guarantee it will never be. At some point nothing stops these URIs becoming machine resolvable. The http://info-uri.info/ web site (note the http) has a registration page for registering the resolving the info: namespaces. Resolvable by humans only that is. If you look at the URL of that registration page it does not look like a Cool URI, lots of mechanism in it, it won’t last. Irony of basing this non-resolvable scheme in a non-stable http space.
First one to scrape that into some useful XML format, wins the prize.
Registry entries are machine harvestable using the Open Archives Protocol for Metadata Harvesting (OAI-PMH). The baseURL from which to harvest is http://info-uri.info/registry/OAIHandler , and information on the OAI-PMH is at http://www.openarchives.org/OAI/openarchivesprotocol.html . All responses are XML. Do I get a prize now?
It also seems distinctly odd that there’s an info URI scheme for the DOI, which is itself a URN.
Whats the benefit of packing one URI inside another?
Reading the FAQ I see that it is possible that some info schemes can define a resolution mechanism. So it’s entirely possible for these URIs to be dereferenced in some way. And I’d put money on that dereferencing scheme using HTTP, and further that it’s going to be desirable to have a way to dereference each scheme.
Last time I checked, doi was not a URI nor a URN. But please check for yourself at and . They have tried hard to get an RFC through the – IETF – system to make it a URI, but they have failed so far. Hence, the reason that doi is in info is that the OpenURL Standard solely relies on URIs to identify items. Many public identifiers are not URIs (PubMed ids and LCCN ids are other good examples), and via info the idea is to turn them into URIs . Now, unfortunately info is itself not a URI – yet? – because the IETF doesn’t like like the idea (just like you guys) and has decided to just ignore the two Internet Drafts we have posted. I am not sure how they can actually do that, but they just do. This is especially annoying because we have consulted with them before starting the info effort as it was so crucial to the OpenURL Standard.
One of the reasons some rather sensible people and organizations _do_ like the info concept of decoupling identification from resolution is that they have a rather long term horizon. They don’t feel like using identifiers for their assets that are tied to a specific resolution mechanism, understanding that resoltuon mechanisms may very well change over time, while they definitely don’t want the identifiers of their assets to change over time.
Apologies Herbert, my mistake, I’d read that the DOI was likely to be registered as a URN, but hadn’t followed the progress of the registration.
Don’t get me wrong, I do understand the benefit of having a stable global identifier for a resource, I’m just of the opinion that a URN fits that purpose perfectly well. The URN can have a normative mapping to a resolution scheme, which presumably can change over time dealing with the fact that resolution mechanisms may change.
However, there’s a huge network effect to be gained by using HTTP based identifiers. I don’t see HTTP going away anytime soon, why not embrace it?
I like the OpenURL as a standardised query string for encoding particular kinds of metadata. I think this works very well. And, as I noted in a previous comment, protocol level support for communicating temporary and permanent changes to a resources location can be used to deal with changes of ownership of assets.