Re: [urn] fragment identifiers

Hello,

Peter Saint-Andre wrote:
> On 3/10/11 7:12 AM, Julian Reschke wrote:
>> On 10.03.2011 15:04, Juha Hakala wrote:

>>> ...
>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5>:
>>
>> "The semantics of a fragment identifier are defined by the set of
>> representations that might result from a retrieval action on the primary
>> resource. The fragment's format and resolution is therefore dependent on
>> the media type [RFC2046] of a potentially retrieved representation, even
>> though such a retrieval is only performed if the URI is dereferenced. If
>> no such representation exists, then the semantics of the fragment are
>> considered unknown and are effectively unconstrained. Fragment
>> identifier semantics are independent of the URI scheme and thus cannot
>> be redefined by scheme specifications."
>>
>> I think this is pretty clear -- if you *can* have representations,
>> you're constrained by the media types that are used as representations.
>> There's no way avoiding that if you want to stay aligned with the URI spec.
> 
> Another way to put it is that you can have representations or free-form
> semantics, but not both (because along with representations come the
> constraints of media types, according to RFC 3986).

I see now where the problem lies. But it is necessary to consider the 
additional complexity that URN resolution brings in.

Depending on the namespace, the relation between an identifier and a 
representation can be complex. For instance, a manifestation of an 
e-book with a single identifier can consist of multiple files (each 
representing a chapter), each file having its own URL. Or, an identifier 
may be assigned to a resource which is just a component part within a 
larger structured resource (for instance, a metadata record within JPEG 
2000 file).

What are the options RFC 3986 allows in such a case? It is OK if the URN 
resolves to list of URLs (those of the files from which the resource 
consists of). But it seems that adding <fragment> to the e-book NBN to 
enable retrieval of individual chapters (files) is against the spirit of 
RFC 3986. Resolving a URN with no <fragment> into a component part of a 
resource such as embedded metadata within an XML file may or may not be 
a philosophical problem (technical implementation is possible).

Anyway, it seems that there is a mismatch between the requirements of 
the RFC 3986and the way in which some identifier systems are (will be) 
used as URNs, because RFC 3986 does not take into account the 
functionality embedded into URN resolution services.

After URN has been resolved to one or more URLs, there is no longer a 
conflict with the stipulations of RFC 3986; these URLs must be aligned 
with the data types of the files retrieved. Such alignment may also 
exist between a URN and the thing it resolves to, but to require that 
this should always be the case may put some counterproductive 
constraints on the usage of standard identifiers as URNs.

Best regards,

Juha


> 
> Peter
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

Received on Friday, 11 March 2011 06:53:17 UTC