Re: [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Graham Klyne <[e-mail]>]

Hi John,

I've just taken a look at 
http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00, and have some 
comments.

I find myself asking what is gained by removing URNs from the scope of what we 
call URIs?

At heart, the argument seems to be that not all locators are good names, and not 
all names are useful locators.  I can't disagree with that.  But that's not the 
same as saying all locators are not good names, or, conversely, all names are 
not useful locators.

An example that comes to mind is the use of DOIs for academic research outputs, 
and in particular for research data sets (e.g. Datacite [6]).  DOIs are 
conceived as names, and have the appropriate management processes around them 
applicable to names.  But I have observed that in recent times, the preferred 
form for presenting DOIs to the Web has increasingly been in the form 
"http://dx.doi.org/..." or similar (see also: [1]).  I think this exemplifies 
something that MAY be used as both identifier and name.

One of the goals and strengths of URIs in the web has been that they encompass 
other systems of identification [2].  A key notion is that for some thing to be 
"on the web" it should have an assigned URI (or several).  URNs regarded as a 
form of URI allow things that are named by other means, such as ISBN, DOI, etc., 
to be "on the web".  http://tools.ietf.org/html/rfc2141 (appendix A) alludes to 
this by noting "The URN syntax has been defined so that URNs can be used in 
places where URLs are expected" (terminology that predates RFC3986) - so there 
is some recognized value here in being able to use names as URIs.

For the Web, blurring the distinction between names and locators enables an 
incremental deployment of "follow your nose" information discovery, which in 
turn enables information discovery at a scale far beyond that which can be 
encompassed by any single managed namespace.  Particularly when we consider a 
web of agents (and things), where we can create names that are also machine 
actionable without prior bilateral or multilateral agreement (beyond the 
existing ones that underpin the web itself).  Ed Summers (who, among other 
things, put the LoC subject headings on the web [4]) offers this example [3]:
[[
One of the benefits of linking data in this way is the “follow your nose” 
effect. When a person in their browser or an automated agent runs across the 
creator in the above triple they are able to dereference the URL and retrieve 
more information about this creator. For example when a software agent 
dereferences a URL for NISO.
[...]
This ability for humans and automated crawlers to follow their noses in this way 
makes for a powerfully simple data discovery heuristic. The philosophy is quite 
different from other data discovery methods, such as the typical web2.0 APIs of 
Flickr, Amazon, YouTube, Facebook, Google, etc., which all differ in their 
implementation details and require you to digest their API documentation before 
you can do anything useful. Contrast this with the Web of Data which uses the 
ubiquitous technologies of URIs and HTTP plus the secret sauce of the RDF triple.
]]

At the level of technical implementation, the distinction between names and 
locators is, if not artificial, not as hard-and-fast as a fixed distinction 
(such as requiring that URNs are not URIs) would suggest.  You point out that a 
key feature of names is that their meanings persist.  Tim Berners-Lee has 
pointed out [5] that naming is a social and contractual issue, and that 
persistence is really a quality of service matter rather than something 
fundamentally apart from location.  In summary, the qualities you require of a 
name *could* be applied to many forms of URI, especially http: URIs, subjected 
to appropriate policies and management practices.

In conclusion, I am not seeing any practical way in which declaring URNs to be 
not-URIs actually helps to achieve the goals of URNs.  I don't see any specific 
constraints imposed by RFC3986 that are inimical to being names.  I'm not seeing 
any legal aspect of a URN (per http://tools.ietf.org/html/rfc2141) that isn't 
also allowed in a generic URI.  (I think there are other reasons why URNs have 
not enjoyed widespread uptake, such as unnecessarily restrictive syntax, and in 
some cases an over-strict interpretation of persistence.)

As they stand, having URNs as part of the URI "family" means that we have an 
assured way of using names that do satisfy the stated properties in a way that 
their referents may be first-class members of the class of entities that the 
Web, in all its richness, can describe.

...

Nits: the RFC3986 link in the body text at 
http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00#section-3 is 
incorrectly linked.

#g
--

[1] http://www.doi.org/doi_handbook/2_Numbering.html#2.6

[2] http://www.w3.org/DesignIssues/Axioms.html#uri

[3] http://inkdroid.org/journal/2008/01/04/following-your-nose-to-the-web-of-data/

[4] http://id.loc.gov/authorities/subjects.html  (nee lcsh.info)

[5] http://www.w3.org/DesignIssues/NameMyth.html

[6] https://www.datacite.org



On 14/04/2014 14:11, John C Klensin wrote:
> Hi.
>
> It seems wise to call the attention of this broader group to
> something that is going on in URNBIS (and more generally).
> This message is a personal opinion.  It summarizes some
> discussions in and around that WG but is not an attempt to
> report on any sort of consensus.
>
> RFC 3986 on Generic URI Syntax was an attempt to create a
> general syntax (and, despite its title, partial semantics) for
> an extremely general set of resource identifiers, using
> experience with and developments from URLs as a starting point.
> The general URI concept was intended to including URLs, URNs,
> and possible future types.  That approach worked for URNs as
> long as they preserved the very narrow definitions and syntax of
> RFC 2141 but without taking advantage of any of the provisions
> for extensibility ("future use") in that specification.
>
> In the nearly 20 years since RFC 2141 was published, experience
> with URNs in various communities has demonstrated the need, with
> some URN types (NIDs), to be able to specify operations or
> retrieval of metadata as well as objects and for partial
> retrieval or other operations on either metadata of the objects
> themselves.  At the same time, there have been forceful
> discussions in information science, library, museum, and
> publisher communities about the fundamental differences between
> locators and names (which much of that community calls
> "identifiers", excluding locators from that category) and the
> disadvantages of mixing the two concepts.  That might be mostly
> a theoretical issue except that the URNBIS WG has found it
> impossible to define the functionality it needs while remaining
> within the syntax and semantic constraints of RFC 3986 (at least
> without creating obvious and very ugly kludges).
>
> The WG is now considering
> draft-ietf-urnbis-urns-are-not-uris-00, which proposes to
> separate URNs from RFC 3986, presumably leaving the latter with
> URLs and name-like things that are not URNs.   It may be worth
> noting that there is now work in W3C and WHATWG on a new URL
> definition.  The intent of that work includes eventually
> superceding 3986 (and 3987), at least for URLs, so there are
> multiple forces working to dismember RFC 3986.  However, the
> URNBIS draft is intended to narrowly focus on the needs of URNs,
> rather than trying to boil the URI ocean.
>
> Those who are interested in this topic should probably take a
> look at the draft and the discussions during the last week or so
> on the URN mailing list
> (http://www.ietf.org/mail-archive/web/urn/).   That list has
> been fairly low-volume, so looking at those messages should not
> be burdensome.  Discussion should also occur on that list unless
> there are very broad issues that belong here.
>
> thanks,
>     john
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>