Houghton,Andrew writes:
 > > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
 > > Mike Taylor
 > > Sent: Wednesday, April 01, 2009 9:35 AM
 > > Subject: Re: [CODE4LIB] registering info: uris?
 > > 
 > > Houghton,Andrew writes:
 > >  > So creating an info URI for it is meaningless, it's just another
 > >  > alias for the DOI.
 > > 
 > > Not quite.  Embedding a DOI in an info URI (or a URN) means that the
 > > identifier describes its own type.  If you just get the naked string
 > >    10.1111/j.1475-4983.2007.00728.x
 > > passed to you, say as an rft_id in an OpenURL, then you can't tell
 > > (except by guessing) whether it's a DOI, a SICI, and ISBN or a
 > > biological species identifier.  But if you get
 > >    info:doi/10.1111/j.1475-4983.2007.00728.x
 > > then you know what you've got, and can act on it accordingly.
 > Now you are changing the argument to a specific resolution mechanism,
 > e.g., OpenURL.

Not at all.  It applies to any situation where an identifier must
stand alone, without the benefit of additional metadata.

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

 > OpenURL could have easily defined rft_idType where you specified
 > DOI, SICI, ISBN, etc. along with its actual identifier value in
 > rft_id.

Happily, the committee appreciate all the reasons why it's better for
identifiers to be self-describing.

Note, by the way, that OpenURL 1.0 does provide a bolt-hole for doing
something like what you describe here, using the rft_dat element to
provide a private identifier together with an rfr_id saying what
referer provided the identifier, which is a proxy for saying what the
type of the private identifier is.  Z39.88-2004, Part 1, Section 5.2
gives this example:
        rft_dat = cites/8///citedby/12
        rfr_id = info:sid/elsevier.com:ScienceDirect
As the standard rather optimistically says, "Knowing the identity of
the Referrer might help the Resolver to interpret the Private Data.

It seems clear to me that this mechanism is pretty nasty.  Apart from
anything else, rft_id's, which are self-describing URIs, can repeat --
you can give multiple IDs, each self-contained -- whereas you can't
provide repeating _pairs_ of rft_dat/rfr_id, because the order of
elements may not be defined depending on your transport (e.g. query
parameters in an HTTP GET transport).

 > However, given that OpenURL didn't do this, there is no difference
 > plugging either of the following URIs into rft_id:
 > http://dx.doi.org/10.1111/j.1475-4983.2007.00728.x
 > info:doi/10.1111/j.1475-4983.2007.00728.x 
 > when I identify the HTTP URI as a Real World Object.

I think there is a difference at least in connotation.  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
and so extract the match and go off and do something else with it.
Notice that in general you do need something like regular expressions
for this -- simple prefix matching won't do it -- as the "actionable
identifier" might be something uglier like:

I think that inviting resolvers to parse HTTP URLs and look for
special cases is not a wise direction to go.

 _/|_    ___________________________________________________________________
/o ) \/  Mike Taylor    <m...@indexdata.com>    http://www.miketaylor.org.uk
)_v__/\  "There is hopeful symbolism in the fact that flags do not wave
         in a vacuum" -- Arthur C. Clarke, on the moon landings.

Reply via email to