Subject: [urn] Usage of f-, q- and r-components

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 27 Jul 2015 07:57:41 +0000

Hello, 

Keith said: 

> 3. For the sake of interoperability between clients, interpretation of 
> q-component, r-component, and f-component by client software needs to 
> be consistent across all URNs that can resolve to URLs. The current 
> text explicitly permits variant uses of these components, without 
> setting any restrictions on such usage.

John responded: 

I think we have a real conundrum here and I don't know how to resolve it.  I also think you are contradicting yourself.  That perception (correct or not) is a symptom of the problem.  On the one hand, we want and need to allow significant flexibility to namespace-definers, especially those who are trying to overlay URNs on existing, standardized, and extensively-deployed namespaces.  

---

As a namespace-definer who is trying to overlay URNs on a few existing, standardized and widely used namespaces my take on this is that the problem may not be as severe as John seems to think. It helps - I think - to discuss this issue in more practical terms, instead of trying to solve it theoretically. 

F-components look exactly like URI fragments and will be treated like them. Web browsers should never send them to URN resolvers, and if they do, resolvers should ignore the f-component. It will only be applied to the identified and retrieved document. 

Things get more challenging with q-component. Let's have a practical example: a user wants bibliographic metadata in Dublin Core format of the book which has ISBN 978-3-598-24287-8.     

If the request is to be sent directly to the target database, then the syntax and semantics of the q-component will be dictated by the search protocol supported by the database. In this case the request can be sent to e.g. Library of Congress Online Catalog (http://catalog.loc.gov/). For machine to machine interaction, it supports Z39.50 and SRU search protocols. In this case SRU is appropriate, so the URN with q-component will look like this:

urn:isbn:978-3-598-24287-8?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc  

The q-component looks complicated to those who do not know SRU. There is a lot that needs to be told to the bibliographic database which acts as the target system: the service we are asking for, search term, number of records to be retrieved and metadata format to be used. Luckily SRU search requests are machine generated; users should not see them at all. 

A URN resolver receiving this should know one or more SRU servers to which the send the request. When the LoC server location is added as SRU base URL to the q component, the URI becomes: 

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc

The URN resolver may be aware of 1-n SRU servers, which can be fulfil the user's demand. But the resolver does not need to know how to construct SRU search request; that has already been done on the fly by the OPAC or other bibliographic system the customer is using. Standard based queries / resulting q-components may look complicated but it is not hard for applications to create and understand them. It is far more difficult to deal with cases when there is no standard search API and "screen scraping" has to be used to create a search URI.

Generally, q-component needs to be whatever the target system requires it to be. So if URNBIS says don't do <foo> in the q-component, then - if <foo> is something required by e.g. the SRU protocol which will be widely used to deliver one of the most important resolution services, the implementers will do <foo> in any case at least if there is no viable workaround such as using the r-component. 

Due to the existence of various standard APIs it should be easy to use r-component to deliver I2C service. All it takes is that the URN resolver can migrate the r-component into appropriate URI such as SRU search, using default values for service related parameters if the user has not supplied them.  For instance, using "I2C" from RFC 2483 as mnemonic for service "URI to URC" and SRU syntax to require Dublin Core metadata, we get URN

urn:isbn:978-3-598-24287-8??s=I2C&recordSchema=dc

The resolver would need to know how to migrate this into a search URI supported by an appropriate target system. It may be SRU server, OpenSearch server, or something else. For the r-component above, Library of Congress Online Catalog would be fine. But if the user wants preservation metadata about the resource with r-component like this

urn:isbn:978-3-598-24287-8??s=I2C&recordSchema=premis

digital preservation system should be chosen instead of a bibliographic database. As a rule the latter do not contain preservation metadata in any format, and do not support Premis which is the de facto format used for this purpose (see http://www.loc.gov/standards/premis/). A user might also request that the identified resource is deleted from digital archive. Then SRU would not be the right protocol; instead, for instance French standard MEDONA (Modélisation des échanges de données pour l'archivage) should be used.  

In order to make r-component truly useful we need a service registry which can be easily maintained. New services and service parameters are emerging as a result of implementation of digital preservation systems and other new tools needed for management of digital resources. It would be impractical to revise RFC 2483 and its successors each time something new (revised metadata format, novel functionality, etc.) is introduced.  

IMO the usefulness of r-component depends on the availability of standard-based APIs for relevant services. Resolving a URN should not be complex or error prone, and therefore it is important to be able to map the service request and parameters in the r-component accurately into a URI. In a standard based environment such mappings should be relatively simple and stable; in a non-standardized environment it is likely to be neither. Even finding out what services are supported in the target system can be complicated, depending on the quality of the documentation provided.

With q-component it will be easier to use non-standardized functionality supported by digital asset management systems than with r-component. All that is needed is to cut and paste the relevant parts of URIs from the target system to the client application. The downside is that URIs used for e.g. searching non-standard bibliographic databases tend to change. So although the identifier (NSS part of the URN) of a resource is stable, the q-component of the URI may change when the target system is updated.      

Best regards, 

Juha 
--

Juha Hakala

 Senior advisor
 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University

 Gsm: +358 50 3827678
 email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Jul 2015 00:03:54 -0400

> urn:isbn:978-3-598-24287-8?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc

This looks odd to me.  I understand the q-component to be reserved for 
information to be transmitted to the resource and interpreted by that 
resource.   So a q-component wouldn't normally be applicable to a paper 
book.   It looks to me like the parameters listed above would be more 
appropriate for r-component.

> http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc

In contrast with the above example, this does not look odd to me, as 
this is a URL for a request to a resolution service.  There's nothing 
wrong with a resolution server accepting parameters via HTTP query 
string.   But a client using such a service for URN resolution needs to 
know how to map the r-component of the URN for which it is seeking 
information, onto that resolution service's protocol.   If the 
resolution service defined its protocol in a way to make this work, the 
client might simply copy the r-component from the URN directly to the 
query component of the HTTP URL used to query the resolution service, 
perhaps adding the assigned portion of the URN as an additional query 
parameter.

To make this more concrete, the original URN might be:

urn:isbn:978-3-598-24287-8??request=I2C&protocol=SRU&maximumRecords=1&recordSchema=dc

and the client might need to translate this to a URL like the following 
one to request the needed information:

Note that this requires some registry or other means by which 
r-component parameters that are widely used across different URN 
namespaces, need to be interpreted by the client (like "request" and 
"protocol" in the example above) and translated into whatever the 
resolution service needs, are distinguished from those parameters that 
are simply passed through to the resolution protocol.

(Ideally, the URN would not need to specify any protocol-specific 
parameters, as this makes the URN dependent on a specific resolution 
protocol that is likely to change over time.   But I think it will take 
awhile to standardize r-component parameters and there will always be 
some need to specify parameters that are specific to a particular 
namespace or resolution service.)

> With q-component it will be easier to use non-standardized functionality supported by digital asset management systems than with r-component. All that is needed is to cut and paste the relevant par…
Your latter two URN examples are also using the r-component in a way 
that is consistent with my expectations.

I get the impression that you envision using q-component for parameters 
that are specific to a particular resolution service, and r-component 
for resolution parameters that are standardized.   I also understand the 
need to distinguish between the two kinds of parameters, but I've 
assumed that both kinds of parameter would appear in r-component, with a 
registry or some sort of parameter naming convention used to distinguish 
between "generic" parameters that might need to be mapped into 
protocol-specific requests, and "protocol-specific" r-component 
parameters that would be passed directly to the resolution protocol.

And I certainly agree with the need for a registry for r-component 
parameter names, and for standard resolution protocols.

However, I want to reserve q-component to be strictly for parameters to 
be passed to a resource (for example, as "queries") and interpreted by 
that resource.   I believe it's important to retain the capability to 
use URNs to identify network-accessible resources that accept input 
parameters, and to associate those input parameters with the URN.

To use a concrete example, suppose the URN urn:example:g were created to 
name the Google search engine.  That URN urn:example:g might resolve to 
the URL https://www.google.com/search .   Then an attempt to access

urn:example:g?Who%27s%20Afraid%20of%20Virginia%20Woolf%3F

in a URN-aware web browser should eventually result in an HTTP GET 
request for

https://www.google.com/search?Who%27s%20Afraid%20of%20Virginia%20Woolf%3F

I think it's important to reserve q-component for this purpose not only 
so that network-accessible resources that accept "queries" can have 
those queries included in a URN, but also, more generally, that "?" will 
behave in a way that is more-or-less consistent with familiar usage.

Keith