Subject: Re: [urn] q-components, r-components, and resource transmission: Section 3.3

From: Keith Moore <[email-masked]>
Date: Sun, 1 Nov 2015 23:25:31 -0500

On 10/27/2015 07:20 AM, Hakala, Juha E wrote:
> Hello,
>
> Usually it will be enough to have just r- or q-component in the URN string. That is, normally resolution related parameters are passed either to the URN resolver or to the target system, but not to both of them at the same time.

I agree with this statement, or at least I suspect the interaction 
between r- and q-component is not well-understood at this time. For 
instance, if the r-component selects between several alternative 
representations of a resource, the interpretation of the q-component (or 
f-component) could vary from one representation to another.

> If a user wants for instance metadata about the identified resource, the request can be made either with an r-component or with a q-component. In the former case the r-component specifies the requested resolution service, and it is up to the resolver to turn that into a URI that will be accepted by the target system. In the latter case, q-component must contain a string the target will be able to deal with without conversion by the URN resolver. So for a hypothetical ISTC (International Standard Text Code) A02-2009-000004BE-A there could be URN (provided that namespace ISTC has been registered):
>
> URN:ISTC:A02-2009-000004BE-A
>
> We can then add an r-component indicating that the user wants Dublin Core metadata about this work
>
> URN:ISTC:A02-2009-000004BE-A??s=I2C&p=DC
>
> A URN resolver might map this URN into e.g.
>
> http://lx2.loc.gov:210/lcdb?version=1.1&operation=searchRetrieve&query=A02-2009-000004BE-A&recordSchema=dc
>
> which is an SRU (http://www.loc.gov/standards/sru/index.html ) search to be sent to the SRU server in the Library of Congress (the search does not work since ISTC in the example is not real). Whenever protocol version or the address of the target system changes, the URN resolver URN to SRU mapping must be updated accordingly. But r-component will remain the same, and is therefore more persistent than the q-component.

This is an interesting example, and I hope an atypical one. Ideally the 
URN resolver would itself perform the search and return either the 
resource content itself (if its static), one or more URLs of the actual 
resource, or (when applicable) URNs of specific 
instances/versions/manifestations of the resource named by the original 
URN.

The reason I hope this example is atypical is that the URL returned by 
the resolution service is of a search engine rather than the resource 
itself, and the URL contains a query, which is not a good result if the 
resource itself accepts queries.   My understanding is that ISTC is only 
for purely text and not interactive resources, so maybe it's not 
actually a problem for this specific example.   But that's a subtle 
distinction.

But I don't think this is an incorrect example.   The URN resolution 
service shouldn't be expected to know the details of the URLs it 
returns.   If an authoritative source associates a URL containing a 
query with a URN in the resolution service, the resolution service 
shouldn't reject it.

> If the target system does not support a standard search protocol, proprietary search can be "hard-coded" into a q-component. But a simple use case such as "find metadata about the identified resource" should not require use of both components in the same time, no matter how the target system behaves.

Agreed.   If the use case is "find metadata" then normally only the 
r-component would be specified.   The q-component is intended for 
interaction with the named resource itself, so is not really applicable 
to a "find metadata" use case.

But I think we need to consider several use cases side-by-side.

>
> However, a user who knows the work identifier may want to retrieve a specific manifestation of the work - for instance, a PDF version - without knowing its identifier (in the worst case, the book may not have an identifier at all). Getting from works to manifestations may require slightly more complex communication between the URN resolver and the target system, and the use of both r and q components may be necessary.
>
> The URN to start the process could be something like
>
> URN:ISTC:A02-2009-000004BE-A??s=I2CS?s=I2R&p=PDF

This seems like a very strange example, and probably not a valid one.   
The user doesn't know (or shouldn't rely on knowing) that the above URN 
will resolve to a URL that refers to a specific kind of search engine -- 
unless, perhaps, he knows that the named resource actually is a search 
engine  (which is not the case in the above example - the resource is a 
text document).   And the q-component is intended for interaction with 
the actual resource named by the assigned-portion of the URN, not for 
interaction with a search engine that will return the resource.   So if 
the user wants to request a PDF manifestation of the work, that request 
needs to be made via the r-component.

And this leads me to a somewhat awkward conclusion, which is that 
r-components aren't just for use by the resolution service.  Clients 
need to know something about them also.    I can think of a couple of 
examples off the top of my head:

- the URN specifies an r-component that requests resource content (I2R), 
but the resolution service only supports the ability to return resource 
locations (URLs).   The client needs to know how to interpret the 
r-component enough to understand the type of request, and implement it 
by getting URLs from the resolution service and getting the resource 
content from one of those URLs.

- the URN specifies and r-component that specifies a particular kind of 
resource manifestation (e.g. PDF).   The resolution service might not 
provide sufficient detail to let the client know which of the URLs it 
returns (for example) will return a PDF manifestation.  The client might 
then need to contact multiple URLs and use (for example) HTTP 
content-negotiation to insist on a PDF manifestation of the content, 
until it finds such a manifestation.   So the client needs to be able to 
understand that the URN is requesting a particular kind of resource 
manifestation.  (of course this scenario can work out in other ways 
also:  The resolution service might be able to limit its result to PDF 
manifestations, or the client might be able to tell from the results 
returned by the resolution service which of those URLs can provide PDF 
manifestations)

Which leads me to some other conclusions:

- either r-component facets must be a managed name space, or there needs 
to be a way to distinguish namespace-independent facet names from other 
facet names
- at least some r-component facets must be standardized and independent 
of URN namespace.
- it's dangerous to publish 2141bis until such standards exist

> In these examples and also generally, neither r- nor q-component have a role in identification (which is what we have agreed on ages ago). It would be very confusing to say that the ISTC identifies anything else than the work itself. And although q- and r-components could be presented in any order, IMO it is more logical to express the r-component first. Some actions by the URN resolver (based on the r-component) may be required before the target system can carry on using the guidelines provided in the q-component.

I agree with these statements.  Though I want to reread the text in 
2141bis about interaction between r- and q-components and make sure that 
it's unambigious as to which has precedence in the event that a 
resolution service returns a URL with a query.   Does the q-component 
from the URN replace that query, or is the q-component discarded, or is 
this perhaps an error that should result in a failure to access the 
resource?   I'm not even sure what the right answer is, but it needs to 
be the same for all cases.

Keith