Subject: Re: [urn] 2141bis questions - (2) Section 3.3.2 q-component clarification

From: John C Klensin <[email-masked]>
Date: Mon, 02 Feb 2015 15:42:10 -0500

--On Wednesday, January 21, 2015 10:27 -0800 Sean Leonard
<[email-masked]> wrote:

> On 1/21/2015 6:11 AM, John C Klensin wrote:
>> [query stuff]
>> 
>> <co-editor and all other hats off>
>> I'm pushing this for a specific reason, discussed at length on
>> the list some months ago.  If we really need the flexibility
>> that having a number of different communities of URN uses
>> seems to imply, especially if we anticipate communities and
>> uses that haven't been heard from yet, there are really
>> strong arguments for allowing the query string to be a series
>> of name-value pairs.   As I read 3986, nothing prevents
>> establishing that principle on a per-scheme basis. [...]
> 
> Hate to put a wet blanket on all these desiderata, but
> honestly, who really needs or wants to use q-components in
> URNs?

Sean, I'll let them speak for themselves, but there are a lot of
folks who have made the claim that they need q-components over
the last few years.   If one takes the 3986 binding of
f-components to [MIME] media types seriously, as some people
obviously believe we should do despite the "syntax only"
approach, then q-components are the _only_ qualifications or
service requests one can make about a URN that doesn't have an
intrinsic, "there is exactly one way to resolve this" binding to
an object with a media type.   Also note that anything that one
hides with an %-coding inside an NSS necessarily becomes part of
equality comparison.   That, in turn, is why some of us have
tried to make a p-component distinction to constrain what is
actually considered to be the NSS.

> Let's say you can use q-components, but any common structure
> will only be considered when actual use cases and communities
> materialize. Until then, percent-encode the "?" in a NSS.

See above.   And the observation below.

> The thing is that the definition of URN is that the NSS is
> basically an opaque identifier. As I have argued, NSSes have
> "dividers", but not "hierarchy" (e.g.: urn:ietf:rfc:3986 --
> the : in rfc:3986 is just a divider for convenience).
> q-components shouldn't be part of the NSS since they represent
> parameter thingies.

Ok. but it seems to me that argues strongly against the "Until
then, percent-encode the "?" in a NSS" position I thought you
were taking above.

> "Worry about stuff that matters, when it matters."

Sure.  But I note that part of several problems that have faced
this WG all along was a belief when 3986 was done that either
extensions beyond 2141 didn't matter (at least yet) or URNs
themselves didn't matter (perhaps at all).  That resulting in
constraints (at least claimed constraints) on what could be done
in URNs that are a lot of the reason the WG didn't finish its
work a couple of years ago. 

Because people want to process URNs with generic URI parsers and
to build slightly-more-specific generic URN parsers, these
things do matter now unless we are willing to constrain cases
that are easily imagined to not use URNs but require another
type of non-locator scheme (and starting many of these
discussions all over again).

    john

---

From: Juha Hakala <[email-masked]>
Date: Tue, 03 Feb 2015 13:32:38 +0200

Hello,

>> honestly, who really needs or wants to use q-components in

Making resolution smarter with the help of q-components is one of the 
main reasons why e.g. libraries want to revise the URN syntax.

Our users may want to retrieve the identified resource. But they may 
also want to fetch descriptive or administrative metadata about it, or 
to see if there are other manifestations of the same work, or related 
works such as translations.

There are other means of passing resolution related parameters to URN 
resolvers, but q-component is probably the most convenient one. Two 
other persistent identifier systems (DOI and ARK) are already using 
query for this purpose. For instance, with ARK it is possible to 
retrieve metadata about the resource, or find out the preservation 
commitment of the organization holding the resource. The metadata 
required for this is held within the ARK resolver itself. This is an 
option in some URN namespaces, while some others may choose alternative 
methods.

>> materialize. Until then, percent-encode the "?" in a NSS.

Library community and the use cases it has - such as retrieving 
descriptive metadata of the resource from e.g. national bibliography 
using the URN as a parameter in SRU search - should do, I think.

Please note that the library community may use for instance urn:isbn and 
q-component to retrieve metadata about the book, but it would be an 
abomination to use urn:isbn and the q-component to identify the metadata 
record. Such an extention of the ISBN scope would be completely 
unacceptable to the ISBN community, and metadata records already have 
other identifiers, which should be used to create persistent links to 
those records.

> then, percent-encode the "?" in a NSS" position I thought you

Q-component must not be part of the NSS. Queries are ephemeral by 
definition - added to the NSS whenever a user wants something else than 
the default resolution service (assuming that one exist; that does not 
need to be the case). When services and service parameters supported by 
applications change, so do the q-components.

In other words, urn:isbn identifies a certain manifestation of a book. 
But urn:isbn + q-component combo used to retrieve a bibliographic 
records of that book does not (in the URN context) identify the 
retrieved record, and it does not even need to be persistent. In the 
future a different q-component and service may be used to provide a 
comparable service (for instance, the metadata record syntax preferred 
by the user community may have changed). A user does not need to notice 
that anything has changed, since q-components can be added to URNs on 
the fly whenever needed.

Juha

> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678