Subject: Re: [urn] Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt

From: "Svensson, Lars" <[email-masked]>
Date: Thu, 29 Aug 2013 14:32:43 +0000

Juha, all,

On Thursday, 29. August 2013 08:07, Juha wrote
> On 28.8.2013 17:12, Svensson, Lars wrote:
> > I probably misunderstand how the resolution service and the urn work
> > together, but this is my understanding:

> The problem we are facing is that currently the URN resolution services are
> too simple. Just mapping URNs to single or multiple URLs is not enough,
> because the user requirements are more complex, and we have an
> increasingly rich technical infrastructure which can supply various things for
> users.
> 
> I doubt if anybody understands all the specifics, but at least we have some
> examples of how things might work out.

OK, I look forward to seeing more examples coming up.

> > 1) I have a resolution service at http://resolver.example.com/.
> > 2) To that service I pass the URN
> urn:example:something?here=is&a=query#withFragment.
> > 3) In order to tell the service that I want the default URL for the URN I tell
> the service s=I2L (service = URI to URL). I encode that in a query.
> >
> > The urn already has a query that has no meaning for the resolver. In
> > order to make the resolver ignore that query (and the fragment), I
> > need to percent-encode the characters '?', '&',  '=' and '#' when
> > passing them on to the resolver. Then I can add the query targeted at
> > the resolver, which gives me
> >
> >
> http://resolver.example.com/urn:example:something%3Fhere%3Dis%26a%
> 3Dqu
> > ery%23withFragment?s=I2L
> >
> > Then I get a resource back and can apply the query on that resource and
> > the fragment to the answer to that query. Do I understand that correctly?

> It seems to me that you make things a lot more complicated than they need
> to be.

That is entirely possible...

> Let us assume that a user wants bibliographic information about a resource in
> Dublin Core format. The user does not know where to get it, but the user
> interface she is using gives an opportunity to request metadata about the
> resource, instead of the thing itself.
> 
> If the identifier of the resource (which happens to be an e-book) is ISBN 978-
> 952-60-5254-0, we get HTTP URI
> 
> http://urn.fi/URN:ISBN:978-952-60-5254-0
> 
> which, since there is no query, the resolution service will map into the
> default value of URL
> 
> https://aaltodoc.aalto.fi/handle/123456789/10927
> 
> from where the user can access to document.
> 
> However, if the user wants metadata about the resource, the HTTP URI
> above would be something like
> 
> http://urn.fi/URN:ISBN:978-952-60-5254-0?I2C&recordSchema=dc
> 
> Please note that there is no point to combine query and fragment unless you
> want the resource itself.
> 
> At this point, the URN resolver must know a bibliographic database which is
> capable of fulfilling this request and how to interact with that system.

Yes, and IMHO the internals of the resolver should be opaque to the specification of the service.
[...]
> This SRU search should return the metadata record the user wants, in the
> form her user interface can deal with.

When resolving over http we should use that protocol's standard ways of specifying formats, i. e. using a combination of Accept header and profiles to state that I want DC in XML (or DC in MARC, or RDA in MARCXML).

> In practice, when we specify I2C-
> related parameters for query, it is necessary to take the existing search
> protocols such as Z39.50, SRU and Opensearch into account.

Yes, and I guess that the resolver's parameter set will be a subset of the other protocols' capabilities.
 
> Migrating the URN + query into a form the interface in the target system will
> understand is not rocket science if these target systems support standard
> APIs. Of course, when technology changes the URN resolver must be
> updated; if for instance the Finnish national bibliography changes location,
> goes from Voyager to some other library system or starts to support SRU 1.2
> it is necessary to tweak the I2C-related parameters in the resolver. Or, when
> the national library's digital archive goes live, we need to add that as a new
> target system into the resolver and specify the services that system will be
> able to supply, such as providing the most original version of the resource.
> 
> >
> >> Alfred Hoenes and myself have started the query specification in
> >> rfc2141bis- urn-03.  Our idea was to use the service names from RFC
> >> 2483, and to complement them with service related parameters; for
> >> instance, having just I2C (URI to URC) is not sufficient in the
> >> situation where there are multiple metadata formats.
> > A side note: is URC formally defined anywhere?
> As far as I know, it is neither used nor properly defined. IMO at present
> Dublin Core has the role that URC was supposed to fulfill.
> However, from I2C point of view the key thing is that no single metadata
> format will ever meet everybody's needs. Some people will be happy with
> simple bibliographic record in DC, some others may want the full record in
> MARC or ONIX, and still others technical metadata in MIX or preservation
> metadata in PREMIS.
> >>>> Yes, and the question (to me) still is if the query attached to the urn is
> to be applied to the resource identified by that urn or if it is supposed to pass
> information on to a (http-based) resolution service.
> My take on this is that the query will pass information to the resolution
> service, but the resolution service will use that information to facilitate
> retrieval of something that applies to the identified resource.
> 
> Unlike query, fragment will be applied to the resource by the web browser
> or other tool the end user is utilizing. I would rather avoid the complications
> which may arise if we use the query for passing resolution related
> information both to the resolver and to the user interface application.

If you say that I make things too complicated, this -- to me -- sounds like a too big simplification. If we allow query (and fragment) in urns, generic resolvers need a way to handle that and they need to know how to differ between queries to be handled by the user agent and queries to be handled by the resolver.

Assume that a (future) eBook format allows me access certain information in the book by executing a query (e. g. searching for a specific word) and that a (future) eBook reader can handle that. Then URN:ISBN:978-952-60-5254-0?search=someword tells my eBook reader to open the identified resource and highlight all instances of "someword".

Lars

---

From: Juha Hakala <[email-masked]>
Date: Fri, 30 Aug 2013 15:58:33 +0300

Hello,

> OK, I look forward to seeing more examples coming up.

You have to wait for a while, I plan to provide query examples in 
rfc2483bis, and that document will only be written once rfc3406bis is 
(more or less) complete.
> Yes, and IMHO the internals of the resolver should be opaque to the specification of the service.
+ 1. For each service, there should be a list of targets (bibliographic 
databases, digital preservation systems, institutional repositories and 
so forth) and for each target it is necessary to specify 1-n interfaces. 
Then, if the interface protocol is for instance SRU, the resolver must 
know how to create SRU queries for the remote system.
> When resolving over http we should use that protocol's standard ways of specifying formats, i. e. using a combination of Accept header and profiles to state that I want DC in XML (or DC in MARC, or…
This is to be discussed. In SRU protocol, there is a way to specify the 
metadata format (recordSchema keyword) and if we use the same mechanism 
in query, conversion to SRU is very simple and we have a good model for 
how to specify format in query. We may also invent our own way for query 
format specification, or rely on some other protocol, or use the 
approach you recommend. I am not sure which approach would be the best, 
but using the SRU model might well be the easiest.
> Yes, and I guess that the resolver's parameter set will be a subset of the other protocols' capabilities.
Correct, and the person setting up the resolver must know which features 
are supported and which ones aren't.
> Assume that a (future) eBook format allows me access certain information in the book by executing a query (e. g. searching for a specific word) and that a (future) eBook reader can handle that. The…
If we have a valid case for using query to provide guidance to the 
browser or other user agent, or if we think that such cases may arise in 
the future, we may add a parameter into the query which indicates that 
the service request and parameters related to it (if any) should be met 
by the user agent and that the URN resolver may just ignore the query.

For instance, something like

URN:ISBN:978-952-60-5254-0?agent=user&search=someword

would do, assuming that the user agent knows what to do with it. But my 
gut feeling is that there is a lot to do to define just the URN 
resolution services and their parameters. If we start listing also user 
agent resolution service functionality, we'll have plenty of additional 
stuff to deal with. An easy way to solve this is to reserve agent=user 
for user agent related services (default being agent=resolver) and leave 
the specification of these services to the future implementers.

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: John C Klensin <[email-masked]>
Date: Fri, 30 Aug 2013 09:45:44 -0400

--On Friday, August 30, 2013 15:58 +0300 Juha Hakala
<[email-masked]> wrote:

> If we have a valid case for using query to provide guidance to
> the browser or other user agent, or if we think that such
> cases may arise in the future, we may add a parameter into the
> query which indicates that the service request and parameters
> related to it (if any) should be met by the user agent and
> that the URN resolver may just ignore the query.
> 
> would do, assuming that the user agent knows what to do with
> it. But my gut feeling is that there is a lot to do to define
> just the URN resolution services and their parameters. If we
> start listing also user agent resolution service
> functionality, we'll have plenty of additional stuff to deal
> with. An easy way to solve this is to reserve agent=user for
> user agent related services (default being agent=resolver) and
> leave the specification of these services to the future
> implementers.

This seems to me to be a good idea.  It preserves the ability to
expand things in the future in directions we can only vaguely
anticipate today (and that some of us find controversial at
best) without committing ourselves to those extensions in the
future or requiring that the details be sorted out now.

Would it be appropriate to incorporate text into 2141bis and/or
3406bis that explicitly reserves "agent" as a query keyword and
specifies "agent=resolver" as the default case?

    john