Re: [urn] URN R-component specification

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

Hello Dale, 

thank you for your comments; some responses below. 

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

"Hakala, Juha E" <[e-mail]> writes:
> 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".

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

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

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.

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

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