Re: [urn] resolver profiles: a generative POWER-UP for r-component

[Sean Leonard <[e-mail]>]

Hello,

Thank you for this response. I think we are making progress.

On 10/5/2015 3:53 AM, Hakala, Juha E wrote:
> Hello,
>
> some comments below.
>
>> -----Original Message-----
>> From: urn [mailto:[e-mail]] On Behalf Of Sean Leonard
>> Sent: 25. syyskuuta 2015 15:24
>> To: [e-mail]
>> Subject: [urn] resolver profiles: a generative POWER-UP for r-component
>>
>> URNies:
>>
>> What URNs really need is a way to ensure that the resolution process
>> delivers more consistent and predictable results.
> All PIDs must be made "smarter". If resolution only links identifier (name) to 1-n locations, it is possible to argue that this is an extra step that can / should be avoided. But if resolution can facilitate persistent access to all kinds of information about the identified resource, it is hard to achieve similar results with e.g. HTTP (which is itself not persistent).
>
> It has not been easy to improve URN syntax so that smart resolution is possible. One problem is URI syntax, which has left us with a limited tool set (? for query and # for fragment). Using ?? for r-component is in these circumstances the best thing we can do. Alas, other PID systems may not be able to do even this.

The invention of the r-component is (in my view) a major step forward. 
Making the r-component mean something, i.e., enabling and channeling the 
resolution process, is the next step forward.

>
>> Since the introduction of the r-component, URNs are now able to address
>> (speak to) the resolver directly to control aspects of the resolution process.
>> Yet the specifics are woefully absent in draft-ietf-urnbis-rfc2141bis-urn-13.
> The intention is to proceed in two steps: first to establish r-component, and then to establish mechanism with which the r-component syntax and semantics are maintained.  Since the technical infrastructure within which resolution happens changes all the time, it is not possible to create a fixed list of resolution services and service parameters. But we can have for instance IANA registry for shared services (and their parameters) and some other arrangements for namespace specific services (if any).

Yes, that is the idea.

>> Consider our favorite urn:isbn. Given an ISBN, what can we do with it?
>> What do we want to get for it? And how can we make the f-component
>> meaningful, if the urn: URI string is not going to give us back some kind of
>> predictable media type/type of resource?
> And also: what do / can we do now, and what is possible 50 or 100 years from now? We do not have any idea of what library systems / digital archives will be capable of in the distant future, but we do now that books will still have the same ISBNs by then. Of course, all manifestations valid now will be rendered useless for most users in 2115; only those with specialized tools can still render the original documents. All others will use migrated modern versions of the works.

Yes we should design for the future as well.

>
>> Answer: the namespace registration can include profiles, and these profiles
>> better specify what happens when resolution occurs. In our ISBN case,
>> profiles can include:
>> showbook
>> librarycatalog
>> pricing
>> buybook
>> covershot
>> bibliographicinfo
>> referencedworks
>> ...and a potentially infinite range of other resolution things to do.
> Indeed; I could easily add a lot of stuff into this list ;-).
>   
>> The absence of a profile string does not imply a "default" action. If you
>> specify urn:isbn:0385537670, you are left with just the identifier.
>> The implementation (context) can figure out whatever it wants to do.
> This is the current status and definitely not one that we should be happy with. It is important to give the user a choice between different options. IMO the role of metadata will be essential: how much will this resource cost? is there a Finnish translation? what can I do with this resource once I have downloaded it? what tools shall I need to render it? who owns the rights for this work? And so on.

Yes.

>
>> To the extent that the resolver profile needs or accepts additional data, this
>> data can follow the profile string.
>>
>> Examples include:
>>
>> urn:isbn:0385537670?productphoto:dpi=600
>> urn:isbn:0385537670?pricing:au;used
> Although these information needs are definitely valid it is not necessary to nail the syntax yet.
>
>> urn:oid:1.3.6.1.5.5?info
>> urn:ietf:rfc:3986?getspec:ct=text/html#section-2.1
>>
>> The syntax is:
>>
>>
>>         namestring    = assigned-name
>>                         [ "?" r-component ]
>>                         [ "#" f-component ]
>>         assigned-name = "urn" ":" NID ":" NSS
>>         NID           = (alphanum) 0*30(ldh) (alphanum)
>>         ldh           = alphanum / "-"
>>         NSS           = word
>>         r-component   = profile [":" query]
>>         profile       = NID
>>         ; query is from RFC 3986
>>         word          = pchar *(pchar / "/")
>>         f-component   = fragment
>>
>> Unlike the NSS, which needs to be well-defined, durable, immutable, etc.,
>> profiles are intended to be very lightweight and capricious. To the extent
>> that a namespace uses profiles at all, registration of profiles would be either
>> First-Come, First-Served, or Specification Required. The namespace
>> registration can impose restrictions on profiles (including disallowing profiles
>> altogether), but anyone should be permitted to invent a new profile,
>> document it, and register it. [This is a generative proposition--see David G.
>> Post, The Theory of Generativity,
>> <http://ir.lawnet.fordham.edu/flr/vol78/iss6/2/>.]
> Whatever rule a URN namespace applies for naming, only applies to NSS.
Yes.

> The components can be added by anybody any time.

Yes, that is part of the "generative principle": we are designing 
systems that will generate innovation by making the registration process 
as free and open as possible to disruptive new technologies.

> I suppose that they will often be machine generated. A GUI which enables the user to retrieve metadata about the resource will modify the actual component accordingly when protocols and metadata formats change. Users do not need to know anything about these changes. And we standard makers only need to provide new services and parameters when requested.
>
> As regards the syntax of r-component, IMO it is useful to provide some generic services. Backwards compatibility with RFC 2483 requires that. But we also know that RFC 2483 had too simple view on services; for instance, there can be many different metadata formats, and asking each one of them via different service would not make sense.

I do not consider RFC 2483 backwards compatibility a design goal (for 
one thing, it includes URCs, which don't really exist now), but it's 
good to know. I have now been made aware of the text/uri-list media type.

>
>> Resolver profiles are namespace-specific, so "info" for the oid: URN would
>> have totally different semantics from "info" for the nato: URN or
>> service: URN.
>>
>> The profile functions as a contract on how specific resolvers should behave,
>> including how the resolver should interpret the query parameters
>> (string) and translate the information into resources (or into URLs that can be
>> dereferenced into resources).
> I am afraid that making resolver profiles solely namespace-specific might create problems. But it is certain that different namespaces will support different services. For instance, ISBN and ISNI (International Standard Name Identifier) will not have much common from service point of view. But same people will be using both, provided that ISNI acquires a URN namespace.

Yes, that is the tension between universal resolver profiles and ones 
that are namespace-specific: identifiers (or, more specifically, 
identified objects) may not have much in common with each other's 
applicable services. Delineating by namespace is one way to group 
services, but it is not the only way. I will follow-up with a dedicated 
post on this topic.

Best regards,

Sean