> > The point is that (I argue) the identifier shouldn't tie itself
> > to a particular dereferencing mechanism (such as dx.doi.org, or
> > amazon.com) but should be dereferenced by software that knows
> > what's the most appropriate dereferencing mechanism _for you_ in
> > your situation, with your subscriptions, at particular distances
> > from specific libraries, etc.
> Lets separate your argument into two pieces. Identification and
> resolution. The DOI is the identifier and it inherently doesn't
> tie itself to any resolution mechanism.
Yes. So far, we agree :-)
> 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
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
then you know what you've got, and can act on it accordingly.
> I can create an HTTP resolution mechanism for DOI's by doing:
> since the info URI contains the "natural" DOI identifier, wrapping
> it in a URI scheme has no value when I could have used the DOI
> identifier directly, as in the first HTTP resolution example.
In this case, you're right -- because the parameter name "doi" tells
you what vocabulary the identifier is drawn from, much as the prefix
of an XML element name tells you what namespace it's drawn from. But
in general, when you can't rely on having that extra bit of data
floating around alongside the actual identifier (as in the OpenURL
rft_id example) it's nice to have identifiers that are
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "If only there were some EASY, COWARDLY way out of this" --
Bob the Angry Flower, www.angryflower.com