Subject: Re: [urn] Tuning the "URNs are not URIs" spec

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 25 Jun 2014 14:24:36 +0000

All,

> >>     Instead, the question is whether the IETF is willing to
> >>     evolve and adapt the URN definition to accommodate those
> >>     perceived needs or whether if prefers to have that work
> >>     done elsewhere, either by adoption in the broader
> >>     community and marketplace of a different approach or,
> >>     potentially, even a competing URN standard.
> > As far as I can tell, the key question is "Is the syntax of RFC 2141
> > ("URN syntax") inadequate for the needs of important groups of users?"
> Urnbis charter requires (among other things) the WG to make
> 
> > an update of the formal syntax specification in the light of the
> > URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
> > (RFC 5234)
> 
> In practice, two major changes are needed: revised URN syntax should
> allow the use of fragment and query.
> 
> The use of URI fragment to indicate locations within identified
> resources enables creation of URN-based citations instead of URL-based
> ones. But in order to avoid breaking the assignment rules of traditional
> standard identifiers, RFC2141bis must make it clear that the fragment is
> not part of the namespace specific string (that is, from URN point of
> view, it does not identify anything).

Isn't this a question if we look at the fragment from a generic URI point of view or specifically as a URN? As an example (looking at http:):

>From a generic URI point of view the strings http://example.org/ and http://example.org:80/ are different resources. The http specification says that for comparison resources the port is to be ignored if it is 80, so under http semantics those are equivalent (identify the same resources). Since comparison should always be about avoiding false positives, that is OK. Could it be an option to state in the URN syntax, that when comparing for equivalence, the fragment identifier can be ignored?

That said, I don't know if the commitment from the urn:nbn community to ensure that fragment identifiers will always work is enough to have them added to the generic URN syntax.

> > If that actually is so, it is a fairly concrete fact, it shouldn't be
> > very difficult to make the case in a convincing way.  And once the
> > case is made, it would be a sound reason to move ahead with
> > significant changes to the status quo.
> 
> The problem is that what looks convincing to e.g. library community -
> and we are not the only significant group out here which is using
> persistent identifiers - may not convince other groups which have
> different requirements and applications. If there is no need to preserve
> millions of documents for hundreds of years, even cool URIs may look
> like a sufficient solution.

So it seems that there are different requirements for different URN namespaces. One further reason to keep identification (common area) and resolution/services separate.

Best,

Lars

---

From: Juha Hakala <[email-masked]>
Date: Thu, 26 Jun 2014 08:59:56 +0300

Hello,

>>>>  From a generic URI point of view the strings http://example.org/ and http://example.org:80/ are different resources. The http specification says that for comparison resources the port is to be…

Two URNs should be considered to be equivalent if they identify the same 
thing. Therefore the latest version of RFC2141bis says that

> If a query component, fragment identifier component, or both have
>     been appended to the assigned URN, they MUST be ignored for purposes
>     of determining equivalence.

...because neither fragment nor query are part of the NSS.

> That said, I don't know if the commitment from the urn:nbn community to ensure that fragment identifiers will always work is enough to have them added to the generic URN syntax.

 From the URN point of view fragments have nothing to do with 
identification. National libraries and our allies assign urn:nbns to 
resources, but typically it will be the users of these resources who 
will add fragments to the urns when they cite identified resources.

It is unfortunate that URI generic syntax talks about fragment 
identifiers. We should not do the same mistake, since it is very unclear 
what fragments could actually identify and how such fragment-driven 
identification process would be managed properly. A lay person may not 
see any problems here, but in this respect my point of view is one of a 
professional who has been closely involved with development and use of 
ISO identifier standards for about 20 years.

Generally speaking, fragments can be added to URNs which identify just a 
single manifestation of a resource and the mime type of the resource 
allows fragment usage. There are plenty of namespaces and mime types 
which meet these requirement. The requirement for being able to use 
fragment does not really come only from the urn:nbn community. Adding 
fragment to the URN syntax has more to do with the needs of the people 
who will cite resources which have already been identified with URNs 
which then provide access to these resources. IMO people will add 
fragments to URNs no matter what the URN syntax says. But if the URN 
syntax says nothing about fragments, then URI syntax applies, which 
means that everyone who cites a resource identifies something (location 
or segment or something else) within that resource by the act of citing, 
which sounds absurd (and unmanageable) to me.

  Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678