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

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 6 Nov 2013 15:32:58 +0000

All (trimming the recipient list),

Bengt wrote: 

> The text in draft-ietf-urnbis-rfc2141bis-urn-06 section 4.3 (Query Component
> and Fragment Identifier Component) already gives some directions on where
> guidelines can be found (refers the question to, for example RFC 2483bis, as I
> understand it).
> Is the concern that this is not enough and that the text should be more
> explicit about it?

My concern is that if we don't have any cases where the query is sent directly to the resource identified by the URN, we should either
1) leave queries out of URNs, or
2) explain very carefully to the readers of the specification what is the difference between queries in URNs (i. e. queries sent to the resource identified by the URN) and queries sent to resolvers. And then we need a way to differentiate between the two, should we have cases where a URN with a query is sent to a resolver and we use another query to send information to the resolver.

Best,

Lars

***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
[email-masked]

---

From: Juha Hakala <[email-masked]>
Date: Fri, 08 Nov 2013 12:24:28 +0200

Hello,

I am not sure if it is a good idea to indicate ("hard-code") in a query 
whether the query should be processed by the URN resolver or the 
resource. It might be best to leave the decision to the resolver, since 
they should know what the best option is.

Let us assume that the human end user wants descriptive metadata about 
the identified resource, in order to make sure that what he will get 
exactly what he wants.

The URN resolver must know at least one resource which is capable of 
supplying the requested service. This service might be for instance a 
bibliographic database which supports SRU query. The resolver must know 
the search protocol, and it must be capable of transforming the URN + 
query into appropriate SRU search request.

Following a software update in the bibliographic database, it might 
become possible to pass the URN + query as such to the database. Then 
there would be no need to anything to the query in the resolver and the 
URN can be passed as such to the resource.

The URN resolver might know of  1-n resources which may provide the 
requested service. These resources may differ from another in that some 
may prefer the URN as such, while others may support other approaches, 
such as receiving SRU search requests.

Letting the user to specify where the query is to be processed might 
also be counterproductive if the user makes the wrong choice; that is, 
demanding for instance that the resolver passes the URN + query to 
resource which cannot deal with URNs (but does support 1-n interfaces 
that would do).

To make things clear to the implementers, RFC 2483bis  could explain 
that normally URN resolvers will decide whether to pass queries on as 
such or to turn them into something else before passing the request on 
to the resource. The end users should not even need to know where their 
requests are processed; all they care about is that they get what they 
are asking for.

Best regards,

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, 08 Nov 2013 10:25:32 -0500

--On Friday, 08 November, 2013 12:24 +0200 Juha Hakala
<[email-masked]> wrote:

> Hello,
> 
> I am not sure if it is a good idea to indicate ("hard-code")
> in a query whether the query should be processed by the URN
> resolver or the resource. It might be best to leave the
> decision to the resolver, since they should know what the best
> option is.

Let me suggest putting that question aside for the moment and
concentrating on what the actual requirement might be.

> Let us assume that the human end user wants descriptive
> metadata about the identified resource, in order to make sure
> that what he will get exactly what he wants.

After some discussion in Vancouver but with the understanding
that the confusion that follows is strictly mine, when I read
the above and the rest of the note, I'd like to ask some
fundamental questions about whether we can understand each other
and our terminology sufficiently to carry on a discussion.  And
I'd like to do that without getting too much tied up in the
history of URNs and URIs.

I apologize for the length of this.  In some respects, I'm
trying to re-derive the theory of URNs.  If I've succeeded (I
doubt that I have), a version of the contents of this note might
belong in an informational document somewhere.

Can we agree about the following?

URNs, just about by definition and without the details, are
supposed to provide names for objects, either directly or by
incorporating and using other identifiers for the objects.
ISBN, ISSN, and DOI URNs are examples of the latter.   We don't
have URNs for classification system values (e.g., Dewey or LC
identifiers) because those are more like locators than about
names of objects.  Or perhaps they are something else -- I think
that one thing that has gotten several of us confused is that we
have divided the resource-reference world into "locators" and
"identifiers" and that there really are other categories (as the
original URI model anticipated).

The notion of naming an information-containing object is
obviously centuries old.  Books and even some scrolls and
tablets have had titles (sometimes formal, sometimes not) nearly
forever.  Modern names (perhaps more properly "identifiers")
have developed to clear up "same thing" ambiguities and
controversies by binding the identifier not only to an object
but to an axiomatic set of conventions about "sameness" and/or a
per-object registration procedure.

Now, where the original URN definition may have been inadequate
is that it sort of assumed that named objects were atomic.  A
URN that identifies the content of a web page, independent of
where the pages is located, is fine.  But, when the named
objects get large and complicated one needs to recognize that
subsidiary identifiers of document structure are needs.  Again,
this is nothing new:
     RFC 2026, Section 4.1
     The Art of Computer Programming, Chapter 2

are examples of resource identifiers that we use all the time,
but that the original URN model doesn't handle well unless we
assign names to chapters or sections as well as to the whole
work, and that causes other problems.

Are we all together this far?   If we are not, I think we have
either terminology or conceptual problems so basic that I need
someone to explain them to me.

Now, using a functional notation that is deliberately different
from the URN/URI form, we can say 

* name(Art of Computer Programming)
	But get what is, at the level of precise object or
	resource identifiers, an ambiguous or multiple answer
	because there are edition and volume issues when that
	function is evaluated.  Those edition issues (at least)
	raise issues with what we have called stability, but, in
	this case, they are a lot more about uniqueness.
	Whether that is a problem of not depends on why we would
	want to use the function.
	
ISBN(Art of Computer Programming, Volume 1, 1968)
	The hypothetical function yields "ISBN 0-201-03801-3",
	and is unambiguous and stable.

ISBN(Art of Computer Programming, Volume 1, 1968, Chapter 2)
	This function evaluation probably fails, not because
	there is anything wrong with the object-reference but
	because ISBNs just don't do that.  On the other hand,
	since functions that return ISBNs aren't ISBNs, one
	could define an ISBN-returning function, ISBNvar, s.t.,

ISBNvar(Art of Computer Programming, Volume 1, 1968, Chapter 2)
	Might then return "ISBN 0-201-03801-3; Chapter 2".  That
	is _not_ an ISBN; it is something that an ISBN
	dereferencer/ processor that returns parts of books
	might be able to do something with.   But that
	dereferencer isn't the "name" of the chapter, it is a
	function that works on it.   So

	ISBNvar is a function that is applied to an object and
	that yields a particular type of identifier (an
	identifier that cannot be stated as part of an RFC
	2141-3406-3187 URN).

If one had a book-retriever function s.t., 

book-retriever(adequately-unique-book-id)
	Handed back the book, that would be really useful.  It
	doesn't make much difference to that conceptual
	definition whether 

exec(book-retriever(adequately-unique-book-id))
	is performed by a human or a machine, the point is that
	one applies a function to a book identifier and gets the
	book back.  And, again, this basic function is centuries
	old.  The function is also not a candidate for a URN
	[namespace] because it doesn't name something, it
	retrieves a named object.

For completeness and assuming the ability to deal with nested
functions,

book-retriever("ISBN 0-201-03801-3")     and
book-retriever(ISBN(Art of Computer Programming, Volume 1, 1968))

are equivalent.  If one defined "book-retriever" appropriately, 

book-retriever(ISBNvar(Art of Computer Programming, Volume 1,
1968, Chapter 2))

	would be fine too -- the book-retriever function just
	over-retrieves a bit and no one thinks about it.

But now let's assume that the library is modern, does
print-on-demand, and has sorted out all the copyright and other
issues.  The new function, book-facsimile-retriever, returns
different things when applied to ISBNvar when that is applied to
strings with and without chapter identifiers for all of the
obvious economic and resource reasons.

Ok so far?

If I have this right, at least some of our discussion isn't
actually about URNs or even URN defererencing.  We have a clear
issue as to whether URN namespace and syntax that would allow an
equivalent of ISBNvar to be expressed (my own impression from
the above and discussions on the list is a pretty clear "yes").
But choices of functions that can be applied to a given URN
(e.g., between "book-retriever" and "book-facsimile-retriever"
above) is not a URN problem.  That choice also implies that we'd
best be careful when we think about systems for finding
functions that can be applied to a particular URN namespace to
retrieve or otherwise process objects because there can be
several such functions that are appropriate under different
circumstances (as well as zero for some namespaces).

I'm reasonably sure about all of the above.   Of course, I could
be completely wrong.  If I am, can we have the discussion in the
above terms rather than getting tied up with what is or is not a
URN and how they are organized, compared, etc.   Those are
important questions, but I think we need to be sure we are all
talking about the same thing before we try to answer them.

In particular, I think different people are using "URN resolver"
in a number of different ways and that is contributing to our
confusion (and some of us being bewildered by what others appear
to be saying).

That brings me back to Juha's note because, at least if the
above reasoning is correct, retrieval of metadata about a named
object is no more part of the name, or functions that act on an
object to name it, than book-retrieval is.   In other words, a
function like:

metadata-retriever(name, attributes)
	Makes perfectly good sense, even if "name" actually
	makes the function
	
metadata-retriever(ISBNvar(Art of Computer Programming, Volume
1, 1968, Chapter 2), "page-count", "publisher", ...)
	Which would return some number and "Addison-Wesley".

In the same context, one might have:

metadata-search((ISBNvar), "page-count", "publisher")
	or, if someone could design the relevant abstractions
	(not our problem, fortunately)
ISBNvar(metadata-search("page-count", "publisher"))

	Which would return a number of names in whatever format
	ISBNvar returned.
	
Coming back to Juha's note and stressing that I'm not
disagreeing, I'm just trying to be sure that we are all talking
about the same thing.

> The URN resolver must know at least one resource which is
> capable of supplying the requested service. This service might
> be for instance a bibliographic database which supports SRU
> query. The resolver must know the search protocol, and it must
> be capable of transforming the URN + query into appropriate
> SRU search request.

This, along with the closely-related notion of just typing a URN
into a web browser where a URL might otherwise go, is what I
keep having trouble getting my head around.  A [generic] "URL
resolver" works because a URL doesn't specify a location at all.
Instead, it specifies a method and data for that method.  As
such, a "URL resolver" isn't a resolver, it is what some
computer science disciplines would call a "method dispatcher".
If I'm right, a "URN resolver" is a function (or member of a set
of functions) that might reasonably be applied to a name with a
namespace-specific domain.  That might make a database or
registry of functions that work on the names in a particular
namespace an interesting thing to have (or not), but that one
can't have a universal URN resolver because its inputs would
have to be not just the name but a method-like statement about
what one wanted to do with that name or the associated object,
if any... and those are not the same thing.
> 
> Following a software update in the bibliographic database, it
> might become possible to pass the URN + query as such to the
> database. Then there would be no need to anything to the query
> in the resolver and the URN can be passed as such to the
> resource.

I'm confused about this too, partially because, as someone who
used to work in databases, I'm used to phrases like "pass
[something] to the database" being the worst kind of handwaving.
I think the above use may be too, but I'm not sure what is
actually intended.  I know what it means to apply a function to
a database because I then know how to determine whether that
function and its arguments are actually well-specified.  f(name,
query) over a particular database (or f((database), name, query)
don't bother me at all, but I hope you see where this is going.

>...
> Letting the user to specify where the query is to be processed
> might also be counterproductive if the user makes the wrong
> choice; that is, demanding for instance that the resolver
> passes the URN + query to resource which cannot deal with URNs
> (but does support 1-n interfaces that would do).

See the "chapter" and "book-retriever" discussions above.

> To make things clear to the implementers, RFC 2483bis  could
> explain that normally URN resolvers will decide whether to
> pass queries on as such or to turn them into something else
> before passing the request on to the resource. The end users
> should not even need to know where their requests are
> processed; all they care about is that they get what they are
> asking for.

I think the latter is very important, but the "URN resolver"
postulated above seems to require a component of magic.

best regards,
   john

---

From: Juha Hakala <[email-masked]>
Date: Wed, 13 Nov 2013 15:55:44 +0200

Hello John; all,

  A lot of comments below.

> concentrating on what the actual requirement might be.

OK.
> history of URNs and URIs.

Without relying too much on any theory, my response below is based on 
actual implementation requirements, especially in the library community 
but also in museums and archives.

> ISBN, ISSN, and DOI URNs are examples of the latter.

OK.

> We don't
> names of objects.
I agree that we don't have URNs for classification system values yet, 
but the National Library of Finland intends to assign URN:NBNs to 
concepts in the trilingual Finnish national ontology system. For now, 
cool URIs are used as identifiers (for instance, the URI for term damage 
is http://www.yso.fi/onto/koko/p35352), but we do not think that this is 
a satisfactory solution in the long run.

Assigning persistent identifiers for data element values is seen as an 
essential part in creating linked data. And for libraries a subject 
heading like "damage" is not a locator but an object that can be used in 
various ways in information retrieval.

It would not be possible to use e.g. ISBNs to identify subject headings, 
but that is not a problem with e.g. NBNs. Given that we have very 
liberal namespaces such as UUID or NBN, almost anything can be 
identified by URNs.
> Or perhaps they are something else -- I think
Yes; some identifiers / namespaces have strict rules for specifying when 
the two resources are the same and when they are different. And we may 
have several, interrelated identifiers, and underlying model of how they 
relate to one another. One of these is the libraries' practice of 
separating works, manifestations and items (each of which can have an 
identifier). One work such as Hamlet may have a lot of different 
manifestations, and there may be a lot of copies (items) of each 
manifestation. Applying these models in practice requires complex rules.
> work, and that causes other problems.
Yes, we routinely refer to / cite parts of documents, but citing does 
not imply that we want to identify them.

In the current URN documentation we allow the use of URI fragment to 
indicate locations such as section 4.1 of RFC 2026. But this is only 
possible if RFC 2026 as a whole has a URN, encoding of the RFC allows us 
to mark the beginning of chapter 4.1 and if HTTP is used. So quite often 
we need to provide additional information such as page number to 
pinpoint the information we are referring to.

In the URN context, fragment only indicates a location within the 
identified document; it does not identify anything. If that were the 
case, then URN:ISBN + fragment could be used to identify basically 
anything within a book (as long as that is technically possible), and 
the ISBN community would find it very difficult to accept such an 
uncontrolled extension of the scope and user community of the standard.

The fact that fragments cannot be used to identify component parts of 
documents is not a problem, since different identifier systems can apply 
namespace specific means for identification of logical fragments. So, if 
chapter 2 of The Art of Computer Programming is for sale as a separate 
file, a URN:ISBN can be given to it, and that URN will resolve to 
Chapter 2 only. Or, a library can digitize a book and give a URN:NBN to 
each page image (and the entire book).

Other PID systems have paid no attention whatsoever to fragment 
identification. In practice, projects using Handles have extended the 
scope of the PID by developing some innovative solutions for fragment 
identification, some of them completely against the stipulations of RFC 
3986. This is one reason why URNbis should develop a standard solution 
for how to use fragment (and query). My gut feeling is that if we cannot 
agree on what to do, we may see a lot more innovative solutions for 
fragment identification in URNs, Handles, DOIs and so on.

> 	want to use the function.
In the future, libraries will start the process from identification of 
the immaterial work. Art of Computer Programming, written by Donald 
Knuth, is a popular work with 151 different manifestations (not counting 
the multivolume versions).

The identifier applied for textual works will be ISTC, and URN:ISTC will 
resolve to a description of the work and links to expressions 
(translations) and manifestations (physical embodiments) of which
> 	and is unambiguous and stable.
is just one. Each manifestation should have its own ISBN.
> 	could define an ISBN-returning function, ISBNvar, s.t.,
Correct. But ISBN + fragment could take the user to the beginning of 
Chapter 2, and if we have digitized the book, we may have URN:NBNs both 
in chapter and in page level.
> 	function that works on it.
We might get ISBN + fragment as a response for this. We might also be 
able to check if a book which has been identified with ISBN has 
component parts which have been identified with URN:NBN. Different URN 
namespaces can be applied to complement one another.

In practice, we do not see cases like this yet. If publishers sell 
chapters separately, they assign ISBNs (or DOIs) to each of them.
> 	identifier that cannot be stated as part of an RFC
Yes, but we might use 3188 (NBN) to extend the scope of 3187 (ISBN).
> 	retrieves a named object.
What we can add to this now is that if a person wants to find a 
manifestation of a book (such as 1968 edition of The Art of Computer 
Programming) and that version is not available, we can easily find out 
if one of the 150 other editions (such as the 3rd edition from 2011) is 
available.
> obvious economic and resource reasons.
I think so. But we should not try to do too many things with URN syntax; 
a lot of functionality can be left to the namespaces. And it is 
important to know what current / future identification practices are 
within the potential URN user communities; otherwise we may develop 
features which will not be useful or will replicate things people prefer 
to leave to the namespace level.
> above) is not a URN problem.
Yes - bibliographic information systems will be aware of relations 
between books and their digital or facsimile surrogates. So if somebody 
wants to read a Finnish dissertation printed in 17th century, the user 
will be informed that the original book is only available witihin the 
library, but digital copy is free. Interlinking of bibliographic records 
describing these versions of the book will be based on identifiers, but 
URNs themselves do not need to be aware of all these versions; the 
required links are embedded in bibliographic metadata.

> That choice also implies that we'd
Right; and because there is no pre-defined and stable set of functions 
(services) it must be easy to specify additional URN resolution services 
whenever they are needed.
> confusion (and some of us being bewildered by what others appear
Some (most?) of us have URN resolvers in production. And there are plans 
of how to enrich them with new functionality, so that we can supply for 
instance metadata as a surrogate to the resource itself.
> disagreeing, I'm just trying to be sure that we are all talking
My impression is that we are all talking about an elephant, but perhaps 
concentrating on different body parts ;-). Libraries have been using 
URNs for a long time, and our URN-related requirements stem on the one 
hand from our collections and systems, and on the other hand from the 
legacy identifier systems libraries use. Like any other user community, 
we want a URN that can be adapted to meet our needs. It would be very 
difficult for us to change our key routines (such as assigning ISBNs to 
books) to accommodate a PID system.
> computer science disciplines would call a "method dispatcher".
URNs are no different in that respect. Currently most URN resolvers are 
very simple, and HTTP URI with embedded URN is mapped into the URL which 
shows the current location of the resource in the Internet.

What we are looking forward to is a resolver which can support a wider 
set of resolution services, so that if a user wants metadata about the 
resource instead of the resource itself, then the URN resolver must a 
search request according to the SRU protocol, or, in John's terminology, 
method (SRU) and data (search request encoded as URL).
> namespace-specific domain.
Yes.
> That might make a database or
We are not striving for anything universal, just a network of 
interconnected resolvers, each one of which is aware of how to deal with 
certain kinds of resolution requests. A user could produce something like

http://urn.fi/urn:isbn:<isbn-number>?s=URC

and our national URN resolver would know how to deal with that.
> [something] to the database" being the worst kind of handwaving.
Sorry for being too vague with this. What I meant was that a URI like

http://urn.fi/urn:isbn:<isbn-number>?s=URC

can be passed to the appropriate port in a bibliographic database. The 
application would have to know how to parse the request.

Bibliographic databases are currently able to deal with SRU search 
requests, which look like this:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=<isbn-number> 
<http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur>

It is not hard for the URN resolvers to map HTTP URIs such as the one 
above into SRU queries. The resolver only needs to know the address of 
the relevant SRU server, and the mapping of the URN NID into an SRU 
query term. And if the resolver can do this, the bibliographic 
information system can do such mapping as well.

> don't bother me at all, but I hope you see where this is going.
Yes, I do.
> postulated above seems to require a component of magic.
I hope not; there is nothing magical in our information systems although 
they sometimes produce unpredictable results :-).

Juha

-- 

  Juha Hakala
  Senior advisor