Subject: Re: [urn] Names and derived identifiers

From: Juha Hakala <[email-masked]>
Date: Wed, 01 Oct 2014 15:05:18 +0300

Hello Dale; John,

Comments to the three examples:

>> Example 1: Adding a "fragment" part to a URN
>>
>> Let us assume that <urn:oid:1.3.6.1.4.1.14490.21.137> is the
>> name of an HTML document.  (I have administrative authority
>> over that part of the OID tree, so I can make it so!)  And let
>> us suppose that one of the <a> tags in the document has a
>> "name" attribute with value "section1". Then (given how
>> "fragment" is used in HTML URLs), it would be reasonable to
>> define that <urn:oid:1.3.6.1.4.1.14490.21.137#section1>
>> references that location within that (abstract) HTML document.

+ 1.
> But 3986 explicitly binds fragments to media type, so, unless
> either every OID or your particular OID has a media type, that
> discussion leads to a very odd place.  In addition, as
> previously discussed on-list and reflected in Appendix B.3 of
> the current draft, there is a case to be made that the fragment
> to which you refer is really a property of the HTML document and
> not the OID or URN.  As such, the syntax you are looking for
> might be more like
>
> <http://retrieval.mechanism.domain/?urn:oid:1.3.6.1.4.1.14490.21.137#section1>
> I don't believe that, but the distinction is very fine indeed
> and one that the WG may need to address.

Fragments can be added to URNs if the identifier assignment rules in the 
namespace in question (or in a subset of that namespace) require that 
identifiers are applied to one manifestation of the resource only. ISBN 
meets that requirement (unless someone is misusing the system, but we do 
not need to consider that option here).

In the URN context, the philosophically most acceptable solution is to 
say that the fragment indicates a location within a resource that is 
identified with the URN. A user can add a fragment any time after that 
URN has been assigned, provided that the media type (file format) of the 
identified resource allows that.
>
>> Example 2: Footnoting a page
>>
>> Sitting in front of me is a copy of the book edition with ISBN
>> 978-1-59403-698-9.  That book edition has the URN
>> <urn:isbn:978-1-59403-698-9>.
>>
>> Suppose we define an extension to the syntax to allow
>> reference to a specific page of a book denoted by an ISBN:
>> <urn:isbn:978-1-59403-698-9^p=67>.  (Here, I deliberately use
>> the character "^" for the extension; "^" is not valid in URIs,
>> and so I cannot be thought to be advocating any particular
>> syntax.)  This construction would be useful for scholarly
>> citations.
> Of course, your doing that as part of the URN requires that you
> have an agreement with the particular publisher that all
> instances of objects that they associate with the ISBN have the
> same pagination properties.  I don't believe that is a
> requirement of the ISBN standard.  Whether it is or not, I know
> (as Juha has also pointed out), publisher assignments of ISBNs
> are sometimes more flexible.

Just an aside: with new electronic formats such as HTML 5 and CSS 3, 
page numbers are getting meaningless. For referencing purposes it will 
be better to use logical components of resources such as chapters and 
paragraphs.

>
>> Example 3: Retrieving bibliographic information
>>
>> Suppose there is a standard for providing the metadata
>> (bibliographic data) about a resource.  This has been called
>> "URC" (Uniform Resource Characteristics) in RFC 2169.  Then we
>> could standardize that
>> <urn:oid:1.3.6.1.4.1.14490.21.312^metadata> is the identifier
>> of the metadata regarding <urn:oid:1.3.6.1.4.1.14490.21.312>.
>> (Of course, this does not address how we obtain the metadata,
>> it only defines a standard identifier with which to refer to
>> it.)
> I'll let you and Juha (and others who are interested) debate
> whether that form is an identifier or a service request.  I hope
> that, in the process, you will explain to the rest of us how the
> distinction moves the work of the WG forward.

Libraries etc. do not use the same identifier system for resources and 
metadata records which describe those resources. Such solution would be 
cumbersome to maintain. One cannot safely assume that there is 1:1 
relation between resources and metadata records about these resources. 
Of course, metadata records do contain the identifier / identifiers of 
resources / works.

There are a lot of standards for providing (bibliographic and 
administrative) metadata about resources. IETF tried to develop one 
(URC) but decided not to, which was wise. Building and maintaining a 
metadata format is a major commitment.

It is feasible to create a service request for retrieving metadata about 
the identified resource. But a user must be able to specify the 
preferred metadata format.

So instead of this:

urn:oid:1.3.6.1.4.1.14490.21.312^metadata

you might say something like this:

urn:oid:1.3.6.1.4.1.14490.21.312?s=I2C&p=DC

or even

urn:oid:1.3.6.1.4.1.14490.21.312?s=I2C&p=DC&p=simple

to indicate that you want a (simple) Dublin Core metadata record describing the identified resource. This URN is then passed on to a resolver which migrates it into something that is understood as search request by a relevant target system.

Juha

>
>> ...
>    best,
>       john
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  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: Thu, 2 Oct 2014 01:33:49 +0000

There are two ways of addressing the technical specification of fragment identifiers for URNs, if that is actually desirable and implementations agree to build and test it.

The first and simplest is to declare that URI schemes that don't normally define a retrieval operation for a representation be allowed to define meaning for fragments. This isn't a compatibility issue since if the scheme doesn't define retrieval, there can't be a MIME type.

The second and more subtle is to make up a virtual MIME type, say "application/urn-retrieval-result" and define fragment identifiers for that MIME type.  Make application/urn-retrieval-result contain 'landing page' information.  Then define 'retrieval' for urn: URIs as accessing using whatever method is appropriate for the URN namespace, but which returns a virtual application/urn-retrieval-result.

That way you get 'official' 3986 interpretations. Fragment identifiers are defined by the MIME type, but we add one MIME type to do the work of lifting the fragment.

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Oct 2014 08:34:17 +0200

> The first and simplest is to declare that URI schemes that don't normally define a retrieval operation for a representation be allowed to define meaning for fragments. This isn't a compatibility is…

What happens if a resolving service actually makes that URN resolvable?

Best regards, Julian

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 29 Oct 2014 16:06:44 -0400

> From: Larry Masinter <[email-masked]>
> Date: Thu, 2 Oct 2014 01:33:49 +0000
> 
> There are two ways of addressing the technical specification of
> fragment identifiers for URNs, if that is actually desirable and
> implementations agree to build and test it.
> 
> The first and simplest is to [...]
> 
> The second and more subtle is to make up a virtual MIME type, say
> "application/urn-retrieval-result" and define fragment identifiers
> for that MIME type.  Make application/urn-retrieval-result contain
> 'landing page' information.  Then define 'retrieval' for urn: URIs
> as accessing using whatever method is appropriate for the URN
> namespace, but which returns a virtual
> application/urn-retrieval-result.
> 
> That way you get 'official' 3986 interpretations. Fragment
> identifiers are defined by the MIME type, but we add one MIME type
> to do the work of lifting the fragment.

That concept allows a lot of interesting possibilities.  The
resolution process which is defined to "retrieve" the document with
the special MIME type can be defined on a per-NID basis (or even
finer).  The process doesn't have to fetch a block of octets which
previously exists in any server, the process can assemble the document
by any algorithm it chooses, using whatever data sources it chooses.

And there is no pre-commitment regarding which MIME type(s) the
resolution process will generate for any particular URN -- the MIME
type(s) of the document(s) are an output of the resolution algorithm.
So different NIDs can use different types, and indeed, any one NID can
use several different types, with different URNs resolving to
sets of documents with different sets of types.

(I am assuming here that we follow the rule that I saw in some W3C
document:  If a URI can resolve into multiple manifestations of the
resource, each fragment name that is defined in any manifestation must
be defined in all manifestations with meanings that are "the same"
from the user's point of view.)

This concept allows a remarkable amount of flexibility while staying
within the conceptual structure of the existing RFCs.

Dale