[urn] URN R-component specification

["Hakala, Juha E" <[e-mail]>]

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