Subject: [urn] Think about r-components and q-components differently

From: Sean Leonard <[email-masked]>
Date: Wed, 23 Sep 2015 16:22:26 -0700

URNies:

The introduction of r-components and separating out directives to the 
resolver, from directives to the resource*, is a welcome development.

For my part I want to put a big +1 to putting the r-component before the 
q-component. I.e.:

urn:isbn:0385537670??service=showscanned?dpi=600#chapter2

I read all the arguments both ways. My reasoning is this from left to 
right: first, we have URN scheme. Then we have the namespace. Then we 
have the actual identifier. Beyond that, we get into "okay, what do we 
do with this identified resource?" We need to tell the *resolver* to do 
something, to the extent that we want the resolver to do one particular 
thing over a default act (whatever that act could be). The resolver may 
(or may not) give us a location by URL--so from there, we then 
dereference the URL to retrieve the representation of the resource, at 
which point we want to qualify the nature of the resource that we want 
back (i.e., the q-component, which gets translated into the query 
component). Finally, we have some resource in memory, so we want to 
identify a particular part of that resource, which is what f-component 
gives us.

URN protocol [urn] -> namespace [nid] -> persistent identifier [nss] --v

parse/view/act upon [f]  <-   locate/deref  [q]   <-  resolve [r]

Very nice diagram; 6 components.

To the extent that we ask the resolver to do something with the URN 
(resolve it) FIRST, before using the q-part, it's worth considering that 
the resolver should get a crack at interpreting the q-component part as 
well. Consider an ISBN resolver that resolves the URN above into a URL. 
Well, the resolver might be set to use some scanned book service that 
requires extra parameters for payment information, federated login 
information (OpenAthens, etc.), screen information, etc.:

https://www.readbooksonline.com/scans?isbn=0385537670&dpi=600&payment_transaction=XYZABC#chapter2

In this case, the resolver needs to be able to have the latitude to 
piece together a URL that includes the q-component, but possibly in a 
translated or transposed form. The alternative is that you force the 
URN->URL protocol always to output:
https://www.readbooksonline.com/scans/byisbn0385537670/payment_transactionXYZABC?dpi=600#chapter2

This violates the "hierarchical information" vs. "non-hierarchical 
information" distinction between path and query components, as the isbn 
and payment transaction information are not necessarily hierarchical 
with respect to each other.

Ultimately an HTTP(S) server can deal with this, as it can just be 
configured to redirect that URI to a URI that the site operator deems to 
be "cooler". But other schemes may not be so lucky, and ultimately, it's 
just a kludge.

Sean

* [see following e-mail on "resource"]