Re: [urn] Transition of 2141bis and 3406bis

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/21/13 12:05 AM, Juha Hakala wrote:
> Hello Peter; all,
> 
> See the answers below.
> 
> On 21.2.2013 7:13, Peter Saint-Andre wrote:
>> Could you explain a bit more clearly the intended usage of query 
>> components in URNs? As far as I have been able to determine, no
>> one has proposed to include query components in URNs themselves
>> (e.g., "urn:isbn:978-951-1-25645-8?param=value"), only in URIs
>> (mostly HTTP URIs) that encapsulate such a URN for resolution
>> purposes and then append a query component to the end of the URI
>> (say, 
>> "http://resolver.example.com/urn:isbn:978-951-1-25645-8?param=value").
>>
>> 
Does the Finnish ISO TC 46 shadow committee plan to proceed along the
>> URI path, or do they plan to include query components in URNs
>> themselves?
> The plan is to continue the work started in URNBIS by Alfred Hoenes
> and others. That is, query components will not be a part of the
> URN (namespace specific string). They will always be added only
> after the URN has been assigned (by the publisher or somebody
> else), by e.g. the user requesting a resolution service, such as
> URI to URL as specified in RFC 2483.
> 
> Typical use cases include a user who wants metadata about a book
> before e.g. purchasing or borrowing it; a user who wants to see the
> copyright statement of a video; a user who wants to see all the
> available variant versions (e.g. PDF, EPUB 3, OOXML and so on) of
> the article she wants to read; a user who wants to check with the
> help of preservation metadata what kind of differences there are in
> the look and feel between the oldest and subsequent versions of a
> still image. Since long term preservation of digital resources will
> be primarily based on migration, in due time there will be n
> versions available for each resource that has been available long
> enough (please remember that the time scale the national libraries
> are talking about is centuries, not decades). In this complex
> environment the digital archivists in national libraries, national
> archives etc. will need persistent identifiers and services 
> provided by URN resolution.  Being able to use query to ask for
> these services looks like a preferred way to move on.
> 
> There are several reasons why query components cannot be part of
> the URN. From the formal point of view, most standard identifier
> systems do not allow adding anything to namespace specific string.
> From practical point of view, services depend on the technical
> infrastructure and will change over time. For instance, the list of
> services in RFC 2483 is insufficient and some of the services
> (especially URI to URC and URI to URCs) need service parameters; in
> the case of the above mentioned services, a user must be able to
> specify his metadata format preference. There is no way to specify
> a priori all the different query elements that can be attached to a
> URN.
> 
> There are many ways in which service requests can be passed to the
> URN resolution service which will process them. IMHO the most
> convenient one is the query, now that RFC 3986 allows it. When the
> first set of URN RFCs was developed, this was not an option and
> workaround was developed; alas, DDDS as specified in RFC3401 etc.
> has never really become popular.  In order to prevent proliferation
> of local query specifications, it is necessary to create a (global
> / public) registry which specifies the services and their
> parameters. Such registry would also provide a simple means for
> adding new services and service parameters; trying to nail them
> down in an RFC (as in RFC 2483) would only lead to constant need
> for updating that RFC when new kind of services emerge in the
> Internet / Web.
> 
> So our plan is - if query is not incorporated in the official IETF
> URN syntax - to extend the IETF specification, and lay basis for a
> Finnish registry for URN resolution services. Of course we would
> prefer to have query (and fragment) included in the official IETF
> URN syntax. IMHO, f the aim is to align URNs with RFC 3986,
> incorporating both query and fragment usage into the URN syntax
> should be the URNBIS aim as well.

Juha, I am confused. First you say that "There are several reasons why
query components cannot be part of the URN." Then you say that service
parameters will be passed to URN resolution services using query
components. Do you propose that service parameters will be passed by
appending them to the URN but not as part of the URN itself? Do you
have examples of what that would look like? My impression from your
earlier messages was that the parameters would be passed in the query
component of a URI, such as:

http://resolver.example.com/urn:isbn:some-number?param=value

But in that case the query component is not part of the URN, it is
part of the URI. And if that's what you are proposing, then URNs still
don't have query components. If I'm missing something here, please do
tell.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJt1DAAoJEOoGpJErxa2p1CkP/2EJmD/6Dfn57fMnn/BPrqiX
2liceW+k9e9VZlhj4RRVxMk1wenDQDxq91mJL2j5OpPYF85A8g6J+gxXiEOCzFSi
MyM+uCNpfwqESdxIpqPZf9WVttWKuG+j/SHG7QypOhy3WXGCrDE/7ndoPxv5nV5Z
tdMvcw6wdQe1EFRIyPuq55EnkaFDz47l1y0Jgi596EIUczvb49DaOjCPdY2QvNBs
5NDTGGMKcBUmtqbYWzZrY7EqVwnTcIRs/2x/nLrdPIBtQDZQdst22rvjHLD26byS
IeLRkS3Rz5fNfzeEE8/Js4aYEB4UgfVdE54vJ0x4PszZoGsUGw0djHFnwSTFgo3S
QFJgbtGdrLOWKmcnrNicWn8svawAxT6YkzgmnPueHsk1pGlO5+AGd7g7MPmuDu/2
pGnlShfgiDrUFtqLJpNmQ3IPSUrR/qN+DldNGs0tMqtY6frQV0CHUNPAW4DsSsel
hiWa2OsgpA0MBueWnIzmRHGu67jgk4fPFSnp9bP7uh1hkJoWwdey0Ra8MtXCUkVv
EIKdbvo67tEdEeaTMmHtBuNAlhuqKJyyJ0xurY6+cEIq3RXWZpPmNOjFwp+s50HO
6/LEgQjc+/5AwlJZhWuKaZ0cIdO5/0CeUjHlS4MsbvzRu/5Ps5s6ApfajD91ODyp
xsSvLK6+uumWKvdBK1pa
=lmbZ
-----END PGP SIGNATURE-----