> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Mike Taylor > Sent: Wednesday, April 01, 2009 10:17 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] registering info: uris? > > Houghton,Andrew writes: > > Again we have moved the discussion to a specific resolution > mechanism, > > e.g., OpenURL. OpenURL could have been defined differently, such > > that rft_id and rft_idScheme were available and you used the actual > > DOI value and specified the scheme of the identifier. Then the > issue > > of extraction of the identifier value from the URI goes away, > because > > there is no URI needed. > > Yes, that would have been OK, too. But no doubt there are other > contexts where it's possible to pass in an identifier without also > being able to say "and by the way, it's of type XYZ". Surely you > don't disagree that it's good for identifiers to be self-describing?
Ok, now we moved the discussion back to identifiers rather than resolution mechanisms. Absolutely agree that it's good for identifiers to be self-describing, I wasn't saying otherwise. However, lets take the following URIs: http://any.identifier.org/?scheme=doi&id=10.1111/j.1475-4983.2007.00728.x info:doi/10.1111/j.1475-4983.2007.00728.x urn:doi:10.1111/j.1475-4983.2007.00728.x All three are self describing URI. The HTTP URI does exactly the same thing as the info URI without having to create a new URI scheme, e.g., info, and the argument made by IETF and W3C against the creation of info URIs. Also, since the info URI folks actually created a domain name for registering info URIs you could have easily changed "any.identifier.org" to "info-uri.info" to achieve the same effect as the info URI. > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Mike Taylor > Sent: Wednesday, April 01, 2009 10:44 AM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] registering info: uris? > > Imagine your web-browser extended by a plugin that knows how to > resolve particularly kinds of info: URLs. If you just paste the raw > DOI into the URI bar, it won't have a clue what to do with it, but the > wrapped-in-a-URI version stands alone and self-describes, so the > plugin can pull it apart and say, "ah yes, this URI is a DOI, and I > know how my user has configured me to resolve those." Sure you can imagine a web-browser plugin, but these things never happen due to a) the cost of developing or, b) in order for it to work you need a plugin to work for every type of browser. This is why the Architecture of the Web document states: "While Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a large amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [RFC2718] for other considerations and costs related to URI scheme design" > What you seem to be suggesting (are you?) is that in the former case, the > resolver should recognise that the HTTP URL matches the regular expression > ^http://dx\.doi\.org\.(.*)$/ > and so extract the match and go off and do something else with it. Back to resolution mechanisms... I'm not suggesting anything. You are suggesting a resolution mechanism implementation which uses regular expressions. That is one of many ways a resolution mechanism can retrieve the embedded DOI or identifier of choice. URI Templates is another and given this URI: http://any.identifier.org/?scheme=doi&id=10.1111/j.1475-4983.2007.00728.x any Web library on the planet can pull the query parameters out of the URI. > as the "actionable identifier" might be something uglier... A URI is just a token with a predefined syntax, per RFC 3986, used to identify a resource which can be an abstract "thing", e.g., Real World Object or a representation of a resource, e.g., a Web Document. One could postulate that all URIs are ugly. Whether a URI is ugly or not is irrelevant. Andy.
