Subject: [urn] URN R-component specification

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 1 Mar 2019 07:27:38 +0000

Hello,

ISSN International Centre and the National Library of Finland are working together in order to enhance the library's URN resolver in such a way that it will meet the requirements of resolving URNs from the urn:issn namespace. This, in turn, is not possible without using the R-component. The IETF URN WG did not specify its internal syntax, but it is necessary to do that now so that the project can move on.

A summary of our thoughts on this (your comments are most welcome):

R-component must be compliant with URI syntax. In this respect it will differ from other widely used PID systems. I don't know if the on-going revision of Handle system will change the situation for Handle and DOI, because no drafts of the revised Handle specification are available.

R-component must specify services and service related parameters. In order to facilitate simple processing of R-components, there should be at most one service request per R-component, but there can be 0-n parameters related to it.

As in URI queries, both the service and its parameters will be composed of field-value pairs. The field name and value will be separated by the equals sign, and the series of pairs are separated by the ampersand.

Field name for services will be s. Field name for parameters will be p.

Initial set for service values will be derived from RFC 2483. Since the set of services specified in it is not enough for our project, some additional values will be specified; we expect that a registry of services and their names and service parameters will be established later by an appropriate body which may or may not be IETF / IANA. IESG or some other appropriate body should discuss this. AFAIK service registry does have a close relation to the registry of namespaces; when namespaces are registered, the registrants should also list the resolution services supported (if any).

Possibility of sharing this proposed registry with other PID systems should be investigated, even though both ARK and Handle/DOI need a syntax revision to be able to use the URN R-component or syntactically similar construct.

We expect that service parameter values will be specified in this project only for metadata request, to enable specification of metadata schema/ format and whether the record requested  is full or "mini". The latter is free in the ISSN database, the former is not.

Parallel to the R-component specification we are drafting the data model for the updated URN resolver. The current one is simple 1:1 mapping between URN and (functional) URL, but the future resolver must enable one to many -mappings, and it must be also aware to the sufficient degree on how the URLs relate to the identified resource.

Examples

Request for the (current) homepage of the identified periodical

urn:issn:<issn-number>?+s=I2L

Request for a past homepage of the identified periodical (new service, for requesting just "dead" URIs, which can still used for locating the resource from Web archives)

urn:issn:<issn-number>?+s=I2Lp

Request for all  homepage URLs of the identified periodical

urn:issn:<issn-number>?+s=I2Ls

Request for metadata about the identified serial in JSON schema

urn:issn:<issn-number>?+s=I2C&p=JSON

Request for full metadata record about the identified serial in MARC format

urn:issn:<issn-number>?+s=I2C&p=MARC&p=full

Although it is possible to add R-components manually, we expect that user interfaces will take care of this, on the request of end users.

Since R-components do not have a role in identification, they do not need to persist, and they can be changed "on the fly" if need be.

Best regards,

Juha

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 01 Mar 2019 23:39:28 -0500

> Field name for services will be s. Field name for parameters will be p.

In this conceptualization, all parameter values (values of the "p"
field) are drawn from the same value space, which generally limits them
to being "keywords".

> Initial set for service values will be derived from RFC 2483. Since
> the set of services specified in it is not enough for our project,
> some additional values will be specified; we expect that a registry of
> services and their names and service parameters will be established
> later by an appropriate body which may or may not be IETF / IANA. IESG
> or some other appropriate body should discuss this. AFAIK service
> registry does have a close relation to the registry of namespaces;
> when namespaces are registered, the registrants should also list the
> resolution services supported (if any).

Your examples essentially scope the service values to the urn:issn
namespace, which suggests that although they may be shared other PID
systems for serials, they aren't likely to be generally applicable
across all URN namespaces.  So they should be looked at as part of the
urn:issn registration, rather than as part of a global space of
"services for URNs".

> Since R-components do not have a role in identification, they do not
> need to persist, and they can be changed "on the fly" if need be.

That is, they may be changed in an incompatible way in the future.

Dale

---

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 4 Mar 2019 07:10:16 +0000

Hello Dale, 

thank you for your comments; some responses below. 

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: lauantai 2. maaliskuuta 2019 6.39
To: Hakala, Juha E <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Pietarila, Emma S S <[email-masked]>; [email-masked]; Keskitalo, Esa-Pekka <[email-masked]>; Hyvönen, Nina <[email-masked]>
Subject: Re: URN R-component specification

In this conceptualization, all parameter values (values of the "p"
field) are drawn from the same value space, which generally limits them to being "keywords".

Juha: OK. I suppose this is not a problem to what we intend to do. 

> resolution services supported (if any).

Your examples essentially scope the service values to the urn:issn namespace, which suggests that although they may be shared other PID systems for serials, they aren't likely to be generally applicable across all URN namespaces.  So they should be looked at as part of the urn:issn registration, rather than as part of a global space of "services for URNs".

Juha: although my examples are from the urn:issn namespace, the services themselves are IMO generic. Most of the services are taken from RFC 2483, which has no relation to the urn:issn namespace at all. There are many other urn namespaces - for instance urn:isbn and urn:nbn - which may support provision of metadata about the identified resource in various formats. And most namespaces which provide some kind of resolution services will support urn - url and urn - urls mappings.  

The only urn:issn specific service the ISSN database will support is a request for extended metadata based on the so called Linking ISSN. Such metadata covers all manifestations of a serial and has no exact equivalent in other bibliographic databases, at least in library sector. Request for such metadata may be implemented as a namespace specific service or with a namespace specific parameter attached to the I2C service R-component. 

Many urn namespaces may have these internal services. But even they should be registered centrally, as eventually another namespace may emerge with a similar need.

Juha: note "if need be". I was thinking about some hypothetical major changes to the URI syntax having an impact on the R-component specification. I find such changes very unlikely since they would be a problem to a very large number of applications and "cool" URIs out there. 

At this point it is important to get a confirmation from technical experts that our specification is compliant with both RFC 3986 and RFC 8141. If not, we shall of course do whatever is needed to fix it.  

Dale