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

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 26 Jun 2014 10:27:39 +0000

Juha,

> On 25.6.2014 17:24, Svensson, Lars wrote:
> > All,
> >
> >>>>
> >>>>
> >>>>  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?
> 
> Two URNs should be considered to be equivalent if they identify the same
> thing.

Yes, and this depends on your definition of "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.

In my eyes, that is not a strong enough argument since that is obvious from the syntax urn:nid:nss?query#fragment. We need an explicit statement that says that "for identification purposes, the URN ends after the last character of the NSS. This implies that while a generic URI parser would consider the two URIs urn:example:foo and urn:example:foo?bar#baz two different URIs and thus -- without further knowledge -- identifying two different resources, a URN parser would treat them as equivalent." (Or something along those lines, which I cannot find in 2141bis). I also suggest that rfc 2141bis adds some examples with queries and fragments to §6.1.

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

This makes the users/patrons responsible for using the correct fragment identifier syntax for the media type in use, which requires good tool support. Perhaps we need some use cases to illustrate how this would work.

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

Yes, terminology can be a PITA, but that's nothing we can change (modulo updating 3986).

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

If we don't add fragments to the URN syntax, a URN with an added fragment simply will not be a valid URN...

Best,

Lars