[urn] Standardization of URN R component semantics

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

Hello,

here in the National Library of Finland we have added an experimental R-component implementation to our URN resolver application. Instead of the default service, redirect to the identified resource (https://urn.fi/urn:isbn:9514005058) it is now possible to request also a list of all Web locations of the resource  (https://urn.fi/urn:isbn:9514005058?+s=I2Ls)

The value of and the functionality provided by the R-component I2Ls is based on RFC 2483. We are not aware of any previous implementations of URN R-component, but we decided to use RFC 2483 service specifications when possible to maximize backwards compatibility.

RFC 8141 says in the end of clause 2.3.1 that

r-components SHOULD NOT be used for URNs before their semantics have been standardized.
In order to proceed with our R-component implementation it is necessary to agree how such standardization can be done as efficiently as possible, and with minimum bureaucracy.

Revising RFC 2483 would be a mistake, because it must be easy to add in the future both new R-components and additional parameters to existing components. A more flexible solution would be a new Registered R-components section to the IANA register of URN namespaces (https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml) Requests for new R-components and parameters could then be processed by the same group of experts which reviews the namespace registration requests. I believe we are more than capable of doing this. Compared with the review of URN namespaces review of R-component related requests should be easy.

The initial set of services and service parameters could be something like this:

I2L (URN to URL)
I2Ls (URN to URLs)
I2AL (URN to Web archive URL)
I2ALs (URN to Web archive URLs)
I2R (URN to Resource, default value)
I2Rs (URN to Resources)
I2C (URN to metadata)
I2N (URN to PID, retrieval of another persistent identifiers of the same resource)
I2Ns (URN to PIDs)

I2AL and I2ALs are not included in RFC 2483. We foresee a need for them due to our cooperation with the ISSN International Centre. Web archives provide access to past volumes and issues of serials, and therefore using archived copies of these resources is of special interest. A web site may contain just new material, but the Internet Archive covers 28 years, and may have more than 500.000 copies of a single site (see e.g. https://web.archive.org/web/20230000000000*/nytimes.com)

Some R-components, such as I2C, will often be accompanied by parameters. We suggest that they should be separated by "&p=" from service requests, which in turn will begin with "s=". For instance, in order to receive metadata about the resource in Dublin Core format, an R component ?+s=I2C&p=DC might be used.

Parameter values for metadata formats may include for instance the following options:

BF (BIBFRAME)
DC (Dublin Core)
MARC (MARC 21)
UMARC (Unimarc)
IMARC (Intermarc)
OBS (Onix for Books)
OPL (ONIX for Publication Licenses)
ODRL (Open Digital Rights Language)
XrML (XrML)
MIX (NISO Metadata for Images in XML)
TextMD (TextMD)
VideoMD (VideoMD)
AudioMD (AudioMD)
PREMIS (PREMIS)

It is important to allow the users to request both descriptive and administrative metadata about identified resources.

RFC 2483 provides additional information about error conditions and security considerations. I am not sure to which extent it is necessary to provide such information as a part of the registration. Perhaps a better place to specify this kind of information is an API (siehe z. B. https://wiki.dnb.de/display/URNSERVDOK/URN-Service+API)

All the best,

Juha

Juha Hakala
Senior advisor

National Library of Finland
Library Network Services
Po Box 15 (Unioninkatu 36)
00014 University of Helsinki
Finland
[e-mail]<mailto:[e-mail]>

nationallibrary.fi<mailto:nationallibrary.fi>
facebook.com/Kansalliskirjasto<http://www.facebook.com/Kansalliskirjasto>