Re: [urn] URN fragments

[Juha Hakala <[e-mail]>]

Hi,

On 22.2.2013 5:36, Peter Saint-Andre wrote:
> Hi Juha, this model sounds similar to what you described for the query 
> component: the fragment can be "added to the URN". I'm not sure what 
> that means. When you add a query component or a fragment identifier to 
> the URN, is that now a different URN (which wasn't assigned by the 
> minting organization or in accordance with the minting algorithm)? Or 
> is "a URN with some additional data appended" and therefore not really 
> a URN anymore? Or is actually a URI (such as an HTTP URI) whose path 
> is the URN itself as just a string of characters embedded in the 
> broader URI? 

Despite the addition of fragment and query the URN itself remains the 
same, even though the HTTP URI changes.

"Added to the URN" means that neither query nor fragment are part of the 
URN, or more specifically, its namespace specific string. When something 
is identified, more or less formally, the NSS is and must always be 
sufficient for that, and RFC 2141 does not provide any functionality 
beyond that. Full alignment with RFC 3986 would in this interpretation 
mean that once a resource has been identified with a URN, anybody can 
add a fragment to the URN in order to pinpoint a location within the 
resource (for the browsers to act upon), or a query to demand a service 
from the URN resolver.

Syntactically and semantically this interpretation should match the one 
in RFC 3986. Note that fragments do not identify anything since they are 
not part of the NSS. IMHO, since we must use RFC 3986 as the starting 
point it is not even appropriate to say that in the URN context fragment 
actually identifies something. So Peter's term "fragment identifier" 
above is not proper language :-).

One reason why we should clarify the usage of fragment and query in the 
URN context is that there is a need to explain which fragment + query 
combinations make sense. In principle, it is only possible to use 
fragment when the resource itself is requested. In practice, there may 
be namespaces or service environments in which the situation is or will 
be more complicated than that.

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel [phone]