Subject: [urn] Queries and service requests (was: Re: urn:ietf:rfc)

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Jul 2014 18:04:49 +0900

Hello Juha,

On 2014/06/26 17:21, Juha Hakala wrote:

> Using URI query for passing ServiceRequests looks like an attractive
> option with minimal technical overhead. Whether this kind of use of
> query would be confusing, and whether using some other mechanism would
> make things more clear I can't tell, before seeing more detailed
> proposal on how to proceed.

Very good point. I would indeed also like to see more specific 
proposals. Are there any around?

> Like Lars, I wonder if the intention is to
> drop just the word query, or the syntax as well.

Who's intention are you speaking about? According to John, it's people 
like you who know what they need, so what would be your preference?

Regards,   Martin.

---

From: Juha Hakala <[email-masked]>
Date: Tue, 08 Jul 2014 08:46:30 +0300

Hello Martin,

> proposals. Are there any around?

The only specific proposal I have seen so far was the one Alfred Hoenes 
and myself included in RFC2141bis which was later replaced by one 
written by Peter which was less specific about how to use query.

Any meaningful ServiceRequest spec must allow definition of both 
services and parameters related to them. For instance, it must be 
possible to retrieve metadata about the identified resource. RFC 2483 
provides two services for this purpose, I2C (URI to URC) and I2CS (URI 
to URCs). Using these mnemonics and letter s to indicate service, we get 
query ?s=I2C.

Unfortunately this is not enough, because RFC 2483 assumes that the 
metadata is in Uniform Resource Characteristics format, which IETF 
failed to develop. So there is a need to add a parameter for preferred 
metadata format. Assuming that letter p indicates parameter and DC is a 
parameter value for Dublin Core, we get ?s=I2C&p=DC. It might be useful 
to enable something like ?s=I2C&p=MARC21&p=F to indicate that the user 
wants a complete MARC 21 record.

There are many other metadata formats which need to be specified. Page

http://www.jiscdigitalmedia.ac.uk/guide/metadata-standards-and-interoperability

gives a simplified idea of the situation.

Services and service parameters must of course reflect the properties of 
systems which will respond to the requests, and protocols used in the 
system to system communication. If a user wants just metadata about the 
resource, SRU protocol (http://www.loc.gov/standards/sru/sru-2-0.html) 
can be used, and whoever specifies parameters for I2C service should be 
aware of what SRU servers can do. When a user demands all versions of 
the resource from a digital archive, SRU is not appropriate, but for 
instance MEDONA 
(http://www.archivesdefrance.culture.gouv.fr/seda/documentation/SEDA_description_standard_v1_0.pdf) 
can be used. And - just to give you another example - if there is a need 
to synchronize an identified resource between two systems, ResourceSync 
protocol (http://www.niso.org/workrooms/resourcesync/) is available for 
this purpose.

ResourceSync is a brand new American national standard. MEDONA is a 
French standard which was published in February 2014, but its ISO 
standardization process of begun last May. It is likely that both of 
these protocols will be widely supported in digital archives and open 
repositories, so people who design the relevant ServiceRequests (in this 
case I2R and I2Rs, URI to resource(s), and synchronize the resource, 
which RFC 2483 knows nothing about)  must take into account the 
properties of these two and other protocols (if any) which will be 
applied when these services are provided.

In order to manage this complexity efficiently, there is a need for a(n 
IANA) registry where communities using URNs and possibly other 
persistent identifiers can register the URN/ATK/Handle resolution 
services and service parameters they support. Carving these things in 
stone just by extending RFC 2483 won't do, because even such extended 
specification will be outdated soon by new technologies such as 
ResourceSync.

It is unfortunate that there is currently no widely implemented/approved 
means of making resolution related ServiceRequests. Because of this, 
different PID systems are busy re-inventing the wheel by specifying 
their own services and means (query based) to request them. For 
instance, if you add "?" into ARK 
(https://datatracker.ietf.org/doc/draft-kunze-ark/), you'll get simple 
metadata about the identified resource. And adding "??" enables the 
users to fetch the preservation commitment of the organization which is 
holding the identified digital document (this is of course one kind of 
metadata as well).

If URNBIS cannot reach an agreement on how to use query (or an 
attractive alternative method) for passing ServiceRequests to PID 
resolvers, then the result is not just one fork, but many. Most likely 
one of them will apply to URNs. What is required is that

- RFC2141bis allows the use of query in the URN syntax, and
- RFC2483bis provides the necessary background for the (IANA) service 
registry to be established, and
- the registry itself is created, using the services specified in RFC 
2483 as the starting point, but refining them with parameters as needed

IMO the service registry would not be need to be too different from the 
registry maintained for the namespace registrations. The two registries 
could be interconnected; namespace registration may - assuming that URNs 
in that namespace can be resolved - provide a list of resolution 
services and service parameters supported. But I am not sure how useful 
that is, because any such list will be outdated very soon, and keeping 
it up to date would be a burden.

> like you who know what they need, so what would be your preference?

My preference is to use URI query, because "things should be made as 
simple as possible, but not simpler", and other persistent identifier 
systems are using query already. But I am open to other suggestions, 
especially if there are obvious technical benefits that even I can 
understand.

All the best,

Juha

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678

---

From: Larry Masinter <[email-masked]>
Date: Tue, 8 Jul 2014 13:32:41 +0000

* If both URLs in WhatWG and URNs abandon 3986, what  is the scope of 3986 left with?
   URNs that don't identify documents, and URLs unsuitable for fetch?
   Of course 3986 should be updated, including integrating the i18n requirements.

* naming and locating and fetching representations may be different
   enough activities to say they're different activities, but the same
  string is used for both. 
  
* URNs are used to name things that aren't documents, but these
   specs with fragments and retrieval methods and query components
   are pretty irrelevant for non-document applications. rfc3553 
   for example.

* I wasn't joking, look at XRI. In the end, I think they came to the sensible
   conclusion that resource identification could use a data structure, if only
   to make the equivalence algorithm more sensible. Yes, they also defined
   a way of packing the data structure into an "xri:" URI, but that's just
  packaging. You might as well use data:application/xri+xml,...... (or
  data:application/xri+json,.... if you want to be modern.)

Larry
--
http://larry.masinter.net