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

[Juha Hakala <[e-mail]>]

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.
>
> Could you also explain (perhaps in a separate thread) the intended use
> of the fragment identifier, as well as any other discrepancies between
> the shadow committee's approach and 2141bis and 3406bis as they stand
> today?
Will do that.

All the best,

Juha
>
> Many thanks,
>
> 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/
>
> iQIcBAEBAgAGBQJRJazyAAoJEOoGpJErxa2p+9IQAKeLUaovxAC6J1kmYFO6wYOi
> MMM+3ywObqB64iz2AgHVt0hq2fWO+B1GvlDWmEAiQZcQkDHICYkqSawyJrYqKU8O
> ljP7+19VlqbfvzOFuNJvo6FbnrVBTo3bcT0yKqqTt8EpI0qD7DE7yo8D1FfbOj1V
> 27Q5ydkK5tl2dagzkNYlgFj2cNRwluFCZvtSd0RZI/MrOd0IxD5GXZ1g4gOjRi9Q
> ZQkvQ0BliFaxbPGmJjtfIV9e2KotpPfRBjSf8Q+p9ETTt/3VMEHaa+VubMQeYy9N
> df/pJtAZMQAzrl+6zVgY3CR+LTUIX8zdUJ6DMs8wBSKhH3CgUz1rppKB7cAUulsB
> ZXPvl1oTstyYZHrbkicKed5MUA0yw5MZMYkRygcCWZx8wejM5RfXjVRMKHdDiTPO
> kH3s53hpk8+yyvfMkzWI8KIjErzW+ZJfW4Jq4SVgDcn/jLf0pB7Q3bAQCW4nw7J4
> oSTsFyPB+BJYy3cW+CSbbW9DzgmUyUtJcsEs/I9WyWr3ILNFiN+/1dC3pvS1A+N9
> GCGZ7iDm7E2r8uLbiEkmjiEvOP5ngbfmIdfEn/Z4anmytWMFv4+DJ5d+jTuEeHbV
> jyHc40eFGEGfTKMVJHFU8koZ4Lc/tf1figiWvvMmnIVECT3ttJke+kIf4vo8wW/+
> dfZU65edw2k1eBmeKkwA
> =5mpd
> -----END PGP SIGNATURE-----


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel [phone]