Subject: Re: [urn] DOIs as an example of name/locator confusion, was URNs are not URIs

From: [email-masked] (Henry S. Thompson)
Date: Sun, 01 Jun 2014 22:48:45 +0100

John Levine writes:

>> Let's take the e-book example (I'm using a DOI, because
>> I happen to remember where to find the resolver for them, but the
>> point would be the same for any URN->http:URI resolver today):  The
>> following _both_ identify the main body of an editorial in the journal
>> _Nature_ of 28 May 2014:
>
>>  doi:10.1038/509534a#article
>>  http://dx.doi.org/10.1038/509534a#article

Sorry, the both _identify_ the same thing because the 

> Actually, they don't.  The DOI maps to a bunch of bibliographic info
> which you get if you fetch that URL and ask for JSON or bibtex.  (See
> JSON below.)

Fetch?  You're right, of course, that I should have tried the official
resolution mechanism to see what I got, which I didn't.  How should I
have done so?

> As a hack, albeit the one that people use 99% of the time, if the
> publisher provides a URL, the DOI web server responds with a redirect
> to the publisher's URL if you ask for html

I didn't ask for anything -- I did a bare-naked

GET http://dx.doi.org/10.1038/509534a HTTP/1.1
Host: dx.doi.org

and followed the redirects.

> thereby in practice turning DOIs which are supposed to be names into
> locators.  In your example, the #article is a fragment in the
> redirected page at www.nature.com, nothing to do with the DOI.

Hmm.  The name/locator duality is something I'll come back to in
another post, but I see one interesting thing now which I had missed
before -- the first redirect (from dx.doi.org) is a 303 ("See Other"),
which, as you say, confirms that the result is _not_, in the meaning
of the Act, a representation of what is identified by the URI.

More later.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: "John R Levine" <[email-masked]>
Date: 1 Jun 2014 19:32:28 -0400

>> JSON below.) ...

> resolution mechanism to see what I got, which I didn't.  How should I

As far as I can tell you can't, since nobody implements the protocol 
defined by the handle system on which DOIs are based.

> and followed the redirects.

Yes, that's the hack.  If your GET asks for HTML, which is of course the 
default, it returns the redirect, and any fragment name is applied to 
whatever the publisher returns as the redirected page.  If you ask for 
JSON, you get the bibliographic stuff:

$ GET -H 'Accept: application/json' http://dx.doi.org/10.1038/509534a
{"subtitle":[],"subject":["General"],"issued":{"date-parts":[[2014,5,28]]},"score":1.0,"prefix":"http:\/\/id.crossref.org\/prefix\/10.1038","container-title":"Nature","reference-count":0,"page":"534-534","deposited":{"date-parts":[[2014,5,28]],"timestamp":1401235200000},"issue":"7502","title":"Welcome, 
Scientific Data!","type":"journal-article","DOI":"10.1038\/509534a","ISSN":["0028-0836","1476-4687"],"URL":"http:\/\/dx.doi.org\/10.1038\/509534a","source":"CrossRef","publisher":"Nature 
Publishing Group","indexed":{"date-parts":[[2014,5,31]],"timestamp":1401579700372},"volume":"509"}

It's not surprising if you find this confusing -- I had to poke around for 
a long time before I could figure out what was actually going on.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 02 Jun 2014 08:38:04 +0100

> ...

Oops, sent with an unfinished line included, please ignore, see
corrected version in next email!

ht

---

From: [email-masked] (Henry S. Thompson)
Date: Mon, 02 Jun 2014 08:41:39 +0100

>>  http://dx.doi.org/10.1038/509534a#article

I shouldn't have said that they identify _anything:_ an ordinary user
can't tell wrt to either of them, as we can't get any evidence on
that point because the doi: has no resolver, and although the http:
does, its response disclaims its utility for this purpose -- see below.

More later.

ht

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 05 Jun 2014 21:15:15 +0100

[Responding only to the change of subject, not the substance :-]

3986 [0] distinguishes between a resource (what a URI *identifies*)
and representations ( what you can *retrieve* ).  In most cases,
although not absolutely necessarily, these are distinct.

I think it's useful to distinguish at least four possible empirical
properties of (what we currently call) a URI and its scheme (and
sub-scheme in the case of a URN):

 1) No public generic action is defined for instances of its scheme
    and/or sub-scheme, either in principle (i.e. by the
    scheme/sub-scheme definition/registration) or in practice (e.g. by
    a widely available app or browser plugin).  We say that such a URI
    (scheme/sub-scheme) is *not actionable*;

 2) Such an action _is_ defined for at least some instances of its
    scheme and/or sub-scheme, and it is one such instance. We say it
    is *actionable*;

 3) Not only is it actionable, but one available action ('retrieval',
    see above), if successful, is defined to yield a representation of
    the resource it identifies.  We say that such a URI is
    *retrieval-enabled*;

 4) Its scheme/sub-scheme is actionable, but at least some of the
    in-principle available actions fail (for non-contingent reasons).
    We say that it *does not support* those actions.

Examples:

 1) 'tel:' -- No actions defined [1]
 2) 'mailto:' -- 'construct' and 'send' actions defined, at least
                  implicitly, but no notion of retrieval [2]
 3) 'ftp:' -- Retrieval is spelled out in the spec [3]
 4) PUTting to 'http://www.w3.org/' -- the PUT action is not supported

(4) implies that (2) and (3) are applicable in slightly different ways
to URI schemes/URN sub-schemes and to individual URIs (not (1),
because if a URI's scheme/sub-scheme is not actionable, it can't be
either):

 2) Even if a URI's scheme/sub-scheme _is_ actionable, a particular
    URI may not support any of the actions defined therein;

 3) Even if a URI's scheme/sub-scheme _is_ retrieval-enabled, a
    particular URI may not support the defined retrieval action;
                                        for that URI 

In many cases, the available actions for an actionable URI are defined
in the definition/registration of its scheme/sub-scheme by reference
to a particular protocol.  

For 'mailto:' this is SMTP [1], for 'ftp:' it's FTP, for http: it's
HTTP (although, interestingly, HTTP is not restricted to actions on
'http:' (and 'https:') URIs).

So where in this space does a name/locator distinction emerge?
Nowhere, as far as I can tell:

  "In practice, the line between 'locator' and 'name' has been
   difficult to draw: locators can be used as names, and names can be
   used as locators." [4]

All URIs are by definition names, not just because they are called
identifiers, but because the nature of what can be identified, and of
identification, is carefully spelled out [5].  Some URIs
(retrieval-enabled ones) are _also_ more-or-less useful as locators.

Examples:

 tel: URIs name "the canonical address-of-record or identifier for a
 termination point within a specific network" [1], but isn't actionable;

 mailto: URIs name mailable entities, is an actionable scheme, but is not
 retrieval-enabled, and doesn't obviously 'locate' anything;

 ftp: URIs name network resources by locating them.  It's
 retrieval-enabled.  It is probably the closest we still have to
 something that deserves to be called a locator in the
 ordinary-language sense of the word, i.e. an address.

 http: URIs name both network and non-network resources.  In its early
 days, most http: URIs were (intended to be) retrieval-enabled.  This
 is no longer true.  XML namespace names [6] are explicitly _not_
 required to be retrieval-enabled, and many of them are not.  For
 principled reasons, many http: URIs used in Semantic Web documents
 are not retrieval-enabled (although they _are_ actionable_).

 doi: URIs likewise name both network and non-networked resources.
 The original intention as stated [7] was for them to "[identify]
 entities of significance to the content industry" and to "reference a
 set of service descriptions".  At the very least they were intended
 to be actionable, and in practice they now are, perhaps not quite as
 originally intended.  Whether they are retrieval-enabled is less
 clear to me.

 urn:ietf:rfc URIs name IETF RFCs, and services exist which act as
 retrieval proxies, see for example
     http://wm-urn.org/urn:ietf:rfc:2119
 A plugin could be constructed to reproduce the simple
 transformation from urn:ietf:rfc:nnnn to
     http://tools.ietf.org/html/rfc2119
 but I don't _think_ the IETF has any published commitment to that
 mapping, or nor is it obvious what the status of this statement [8]
 is:

  The canonical URI is of the form:
  http://www.rfc-editor.org/rfc/rfcXXXX.txt.

The point, now perhaps overly belaboured, is that in practice there is
a _huge_ range of variation within a complex multi-dimensional space
as regards actionability, retrievability and comprehensiblity (that
is, can you find out what a URI identifies if all you have is the URI,
and if so, how).  Suggesting that there is a straightforward
"name/locator" distinction ignores the richness of the actual
phenomenena.

So, back to my core question: what are the requirements?  Saying "we
need names, not locators" is not a requirement until you tell me what
the operational distinction is that you are covertly appealing to.  If
you find the above terminology/taxonomy helpful in answering my
question, so much the better.

ht

[1] http://tools.ietf.org/html/rfc3966
]2] http://tools.ietf.org/html/rfc6068
[3] http://tools.ietf.org/html/rfc1738
[4] http://tools.ietf.org/html/bcp35
[5] http://tools.ietf.org/html/rfc3986#section-1.1
[6] http://www.w3.org/TR/REC-xml-names/
[7] http://tools.ietf.org/html/draft-paskin-doi-uri-04
[8] http://www.rfc-editor.org/pubprocess.html
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]