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

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 2 Sep 2015 07:25:27 +0000

Juha, Keith,

On Tuesday, July 28, 2015 6:04 AM, Keith Moore wrote:
 
> On 07/27/2015 03:57 AM, Hakala, Juha E wrote:
> > 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.

+1

> > 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&maximu
> mRecords=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.
> 
> >
> > 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
> 
> 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

Yes, that's  my view, too. Although I'd drop the "protocol" and "maximimumRecords" part and keep it to 

urn:isbn:978-3-598-24287-7??request=I2C&recordSchema=dc

since it's up to the URN resolver to decide how it will communicate with the bibliographic information system (perhaps even using Z39.50).

> and the client might need to translate this to a URL like the following
> one to request the needed information:
> 
> http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&
> query=9783598242878&maximumRecords=1&recordSchema=dc
> 
> 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.

Right.

> (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.

Yes, that's why I think that the r-component should not say anything at all about which protocol to use...

> 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.)

Right, but that should be kept to a minimum.

> > 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.

This is where we differ: In my opinion the resolver needs to know what "I2C" means, whom to ask for the URC and how to build the request. The reason is that if the client already mandates what protocol to use we're in for serious problems when in future there is no bibiliographic lookup service that supports SRU (or Z39.50) because everyone has moved on to BLOAT (Bibliographic Lookup Online Access Terminal) or whatever protocol is en vogue at that time. If URNs with r-components are intended to be persistent, they must only say _what_ is to be done, but not _how_.

> > 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

OK, so we arrived at the same solution here. That's good!

> > 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.
> 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.

+1

[snip google example]

> 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.

Yes.

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur und Bestanderhaltung
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49-69-1525-1752
Telefax: +49-69-1525-1799
mailto:[email-masked] 
http://www.dnb.de

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Sep 2015 13:53:01 -0400

On 09/02/2015 03:25 AM, Svensson, Lars wrote:
> This is where we differ: In my opinion the resolver needs to know what "I2C" means, whom to ask for the URC and how to build the request. The reason is that if the client already mandates what protocol to use we're in for serious problems when in future there is no bibiliographic lookup service that supports SRU (or Z39.50) because everyone has moved on to BLOAT (Bibliographic Lookup Online Access Terminal) or whatever protocol is en vogue at that time. If URNs with r-components are intended to be persistent, they must only say_what_  is to be done, but not_how_.

I think we should make clear that only the "assigned portion" of a URN 
can be expected to be persistent.   If an f-component, q-component, 
and/or r-component is included with the URN, the entire URN can no 
longer expected to be persistent, but the "assigned portion" is still 
expected to be persistent.

Similarly, just because a URN appears with an f-component, q-component, 
or r-component doesn't mean that applications processing that URN are 
expected to use all of those components in every situation.   This may 
vary due to both the context in which a URN appears and also according 
to the user interface.   For instance:

  * A URN appears in the HREF parameter of an A element in an HTML
    document.   If the user "clicks" on that link, the expectation is
    that the document referred to by the URN should be loaded and
    presented to the user, who can then interact with that resource if
    it supports interaction.
      o If the r-component of that URN doesn't specify any particular
        operation, the client should probably try to present the
        document referred to by the URN to the user, and whether that
        happens by the client issuing a I2L request to the resolution
        service and selecting from among the links returned, or by the
        client issuing an I2R request to the resolution service, this is
        an implementation detail.  The client would also supply any
        q-component to the resource, and process the returned content
        according to any f-component supplied with the URN.
      o If the client were to learn that the resource requires some sort
        of authentication or purchase, the client might instead present
        a dialog which permits the user to authenticate and/or authorize
        such a purchase, before trying to present the actual resource.  
        This is reasonable behavior for the client in this case because
        the expectation is that the user can interact with the client
        and the resource.
      o However if the r-component of the URN explicitly specifies the
        I2C operation, the citation of the resource (perhaps further
        selected by additional parts of the r-component) should be
        presented to the user.
      o Even if the URN supplies an r-component that specifies default
        behavior for "clicking" on the link, the client might permit the
        user to "right click" on the link and explicitly request a
        citation, links, related resources, revision history, etc.   In
        that case the client would ignore any {f,q,r}-components
        supplied with the URN.
  * A URN appears in the SRC parameter of an IMG element in an HTML
    document.   In this case, the client will attempt to obtain the
    resource content (which it assumes to be an image) and automatically
    display it.   Any r-component that specifies other than I2R should
    probably be ignored, but an f-component or q-component would be used
    if supplied.   The client could still permit "right click" on the
    image and allow the user to obtain citations etc. from the assigned
    portion of the URN.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 3 Sep 2015 17:32:29 -0600

> expected to be persistent.

Agreed.

Peter

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 4 Sep 2015 06:07:23 +0000

Hello,

people who manage URN namespaces will only be responsible of namespace specific strings. When somebody / something adds a component to a URN, there should not be an expectation that the component will persist in the same way as the URN proper. 

There is one exception: f-components will be fairly persistent iff they are used in namespaces where the URN applies to a single manifestation of the identified resource only. An example is ISBN namespace, an ISBN assigned for a book in PDF format is not supposed to re-assigned to any other manifestation of the book.  Alas, mistakes do happen, and therefore even in urn:isbn namespace f-components are not to be fully trusted, although they are still more reliable than fragments added to URLs. Note that if the same ISBN is given to two manifestations of a book, the URN:ISBN remains actionable, although there is a possibility that the user will get an unexpected version of the book.    

IMO r- and q-components will normally be created on the fly and piggybacked with the rest of the URN whenever there is a need to request something else than the default resolution service (whatever that is). 

Whatever the appropriate request for a certain service is will change over time, so it would be shortsighted to "hardcode" r- and especially q-components. For instance, in current application environment library systems might use Z39.50 and MARC 21 metadata format to fulfill I2C request; a decade from now the protocol may be different (BLOAT sounds like a nice name, although then our systems would be bloated) and the default metadata format is likely to be something else as well. Such technological changes will have major impact on q-components, so they are definitely non-persistent. It is possible to make r-component more immune to technical obsolescence, but even that will be challenging. I2C can and will be reserved for requesting metadata about resource, but there will still be the problem of specifying appropriate metadata format; the one supported now by all integrated library systems may be supported by zero ILMs 50 years from now. Not defining the format at all makes the I2C request persistent, but as a result resolution process becomes somewhat unpredictable since metadata format will be whatever the target system regards as default. 

To sum up, components are not part of the namespace specific string, they will not be managed in the same way as NSS (since basically anyone can add a component to an existing URN any time), and apart from at least some f-components they will not be persistent in the URN sense of the word. And when a component is added, the URN still identifies the same resource as persistently as before, but the additional functionality requested by the component is subject to technological obsolescence.   

Juha    

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre -
> &yet
> Sent: 4. syyskuuta 2015 2:32
> To: Keith Moore <[email-masked]>; [email-masked]
> Subject: Re: [urn] Usage of f-, q- and r-components
> 
> >> This is where we differ: In my opinion the resolver needs to know what
> "I2C" means, whom to ask for the URC and how to build the request. The
> reason is that if the client already mandates what protocol to use we're in for
> serious problems when in future there is no bibiliographic lookup service that
> supports SRU (or Z39.50) because everyone has moved on to BLOAT
> (Bibliographic Lookup Online Access Terminal) or whatever protocol is en
> vogue at that time. If URNs with r-components are intended to be persistent,
> they must only say_what_  is to be done, but not_how_.
> >
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 4 Sep 2015 07:27:40 +0000

On Friday, September 04, 2015 1:32 AM, Peter Saint-Andre - &yet wrote:
> vogue at that time. If URNs with r-components are intended to be
> persistent, they must only say_what_  is to be done, but not_how_.
> >

I agree, too, but still want to emphasise that when we design the interface for communication with the resolver ("r-component") we should avoid specifying protocols or specific query parameters to be passed on to an underlying service. The resolver should know how to resolve the URN possibly using information from the r-component, to specify how that is done is not something the client should do.

Best,

Lars

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Sep 2015 03:51:00 -0400

--On Wednesday, September 02, 2015 07:25 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>...
> This is where we differ: In my opinion the resolver needs to
> know what "I2C" means, whom to ask for the URC and how to
> build the request.
>...

Lars,

Perhaps there is a source of misunderstanding here.  Despite the
early model of URLs, URCs, and URNs, as far as I know, URCs have
never been seen in production use.  They were definitely not
included, even by vague handwaving, in RFC 3986.    

The URC situation is one of several reasons why I have been
resisting strong, normative, references to RFC 1737.  It states,
in a couple of places, that URCs are used for meta-information
but neither it nor, as far as I know, any other document actual
defines URC format and use.  In addition, the first paragraph of
the introduction of RFC 1937 contains the statement:

	"URNs are used for identification, URCs for including
	meta-information, and URLs for locating or finding
	resources."  

In practice, while the statement about URNs is true, a very
large fraction of the debates of the last several years has
ultimately been about the relationship and mapping between URNs
and actual objects and what one can do with that relationship
and mapping, activities that might be describes as "locating or
finding resources".  I may be wrong, but I think that bit of
confusion has been a source of comfort for those making the
claim that URNs are useless and unneeded, even if it is not an
actual source of that position.

Do you have examples of the actual existence of URCs and, if so,
where are they documented?

    john

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 4 Sep 2015 11:12:39 +0000

John,

> where are they documented?

No, I have no such examples. I used the term "URC" only because of that is the reading of "C" in "U2C". What I meant was "whom [i. e. which service] to ask for the metadata".

Sorry for any confusion my message might have caused.

Best,

Lars

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Sep 2015 09:31:13 -0400

--On Friday, September 04, 2015 11:12 +0000 "Svensson, Lars"
<[email-masked]> wrote:

>> Do you have examples of the actual existence of URCs and, if
>> so, where are they documented?
> 
> No, I have no such examples. I used the term "URC" only
> because of that is the reading of "C" in "U2C". What I meant
> was "whom [i. e. which service] to ask for the metadata".
> 

Lars,

Not a problem.   The alphabet soup of many abbreviations and
acronyms sometimes gets intense in this area and, as I
mentioned, there have been suggestions that imply treating RFC
1737 as the authoritative statement about the scope of URNs and
what they are suppose to be about, so I just wanted to be sure I
understood what you meant and were referring to.

Thanks for the clarification.

best,
   john