Re: [urn] query component in URNs

[Juha Hakala <[e-mail]>]

Hello,

On 24.2.2013 5:58, Keith Moore wrote:
>
> Why should query semantics for URNs be different than for other URIs?

Query semantics for URN will be richer than for other URIs due to extra 
functionality supported by resolution services. Queries specific to the 
URN will be processed by the appropriate URN resolution service, which 
will not pass them on as such. Instead they will be mapped to the form 
supported by the appropriate target system.

For instance, if the requested service is I2C (URI to URC), the 
resolution service would map the URN into a search statement encoded as 
HTTP URI. The exact syntax of the search will depend on search / 
retrieval protocol used.

Let us assume that a user wants metadata related to a book he's 
interested in. The client he's using would assemble a URN in the format 
URN:ISBN:<ISBN-number> plus a query indicating that the user wants 
resource description in Dublin Core format. Choosing the OPAC of the 
Library of Congress OPAC as the target, the URN resolver would map the 
URN sent by the client system into a HTTP URI like this:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dc.identifier 
<ISBN-number>&maximumRecords=1&recordSchema=dc

For any recent book in English there are literally hundreds of 
relatively complex HTTP URIs (targeting various library OPACs, union 
catalogues etc.) which could produce the same result. But from the 
user's point of view, the syntactically simple URN and complex HTTP URIs 
it can be mapped to are semantically equivalent.

Please note that the HTTP URI above is based on the SRU protocol 
(http://www.loc.gov/standards/sru/), which became an OASIS standard a 
couple of weeks back. Many library systems support (also) other query 
protocols which encode the queries as HTTP URIs (while some protocols, 
like Z39.50, do not). But although reasonably stable, these query URIs 
are not intended to be "cool" (whatever that means) and keeping them 
cool would be a real pain in the neck. However, in URN resolvers it 
should be possible to keep track on changing database addresses, 
protocols & protocol versions, etc. Therefore URN query may provide the 
library community a means of providing persistent links to resources, in 
spite of our ever evolving service infrastructure in which it would be 
very hard or impossible to keep the URIs "cool".

Specifying in the URN-related RFCs a subset of queries which will be 
processed by the URN resolvers should not prevent the usage of other 
kind of queries which the resolution service will just pass on to the 
appropriate target system (as a part of appropriate HTTP URI).

> i.e. Why isn't a query on a URN semantically equivalent to the same 
> query on the underlying resource?
>
> Similarly, why isn't a fragment on a URN semantically equivalent to 
> the same fragment of the underlying resource?

Unless I have missed something, fragment on a URN is semantically 
equivalent to the fragment of the underlying resource. Fragment on a URN 
only specifies a location within the identified resource; it does not 
identify any part of that resource.

Best regards,

Juha

> (granted, fragments are problematic for any kind of resource that can 
> map to different formats with different ways of specifying fragments, 
> but that's no worse for URNs than for any other kind of URI for which 
> content-negotiation comes into play)
>
> I don't think it makes sense to overload URN query and fragment 
> semantics to mean different things than they mean for other URIs.
>
> Keith
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

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