Subject: Re: [urn] URNs and URI <fragment>

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 9 Sep 2011 14:54:16 +0200

All,

I'm arriving late to this party, so I don't really know where to chime
in, but I opt for adding my comments to the thread in reverse order of
posting.

Juha wrote:

> I think some level of initial confusion is natural when we have two
> communities (IETF and people who work with bibliographic identifiers)
> with differing ideas and terminology as regards what a fragment is and
> how they can and should be identified.
> 
> But such initial diversity should not prevent us from finding a
> solution
> which will be acceptable for both communities and beneficial for the
> URN
> users.

Yes!

[...]

> However, there are URN namespaces in which the possibility of using
> RFC3986-based URI fragments exists, on the basis of the identifier
> syntax & assignment policy. And such functionality may be useful,
which
> is why Alfred Hoenes and myself decided to propose fragment usage in
> RFC2141bis and namespace registrations (when applicable).

+1, I see no reason to rule it out completely at the top level, if we
see possibilities for fragment identifiers further down in the chain.

> One namespace which can be "fragmented" is NBN (National bibliography
> number) specified in RFC 3188. Given the diversity of NBN systems used
> by different national libraries, there is no way to nail down a
non-RFC
> 3986 -based generic means for specifying fragments in the NBN
namespace
> (such as saying that "." is the delimiter between the two parts of the
> identifier). In such case, using URI fragment may come handy. For
> instance, one URN implementation project has analyzed the
possibilities
> for using URI fragments to identify elements of research data within a
> database.

If we decide to accept fragment identifiers in NBNs, the specification
MUST mandate that you can only use fragment identifiers if you also can
ensure that the media type of the returned representation
("manifestation" in FRBR-speak) will never change OR if you can ensure
that the use of the fragment identifier will be forward-compatible will
_all_ future representations. If we don't mandate this, it means that
future curators of digital objects will be responsible for mapping
fragment identifiers from older document versions to the new versions in
case you at some point in the future decide to migrate PDF 4.2 to PDF
648.16, where the meaning of the fragment might have changed. We mustn't
forget that one of the central use cases for urn:nbn in libraries is as
identifiers for digital long term preservation and that the decisions we
make to-day will be relevant for future generations.

> If a URN contains a fragment in the RFC 3986 sense of the word, then
> resolving or dereferencing that identifier should provide (among other
> things) direct access to the fragment. This functionality should be
> similar to how URLs with fragments work, except for permanence.

If I have a URN with a fragment, e. g. urn:nbn:aq:987-65432-1#chapter98,
and make this URN "actionable" by prefixing it with a resolver-URI --
http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98 -- is the
fragment identifier then a part of the URN or of the http-URI? (And:
does it really matter?)

> Preserving access to a particular file (such as a document in PDF
> format) for long term (centuries) is of course very hard or
impossible;
> objects will usually be migrated. But most bibliographical identifiers
> are tied to particular manifestations. When a book in PDF format is
> migrated to, say, OOXML, the new manifestation will get another
> identifier / URN. The new manifestation may no longer have the same
> internal structure and therefore it is possible that the URI fragments
> cannot be used in the same manner.

See above: this really means that we potentially create a lot of work
for future digital curators.

> There is a more general problem of how to provide persistent links to
> resources when any digital manifestation of a resource is doomed to
> become non-accessible eventually. Library community has not developed
a
> general answer to this, but one possibility is to encourage creation
of
> URN links primarily to the description of the work.

"Work" in what sense? I assume you don't refer to FRBR Work here, but
that you mean "description of the [FRBR] expression".

> In this case,
> dereferencing would provide a metadata record (with links to the
> existing manifestations of the work), or perhaps all or at least some
> manifestations of the resource at one go. What I do not know is how
URI
> generic syntax is applicable to this or to the flexibility provided
> with
> URN resolution services in general in its current form.
> 
> IMHO those namespaces which do not identify objects in the
> manifestation
> level cannot use URI syntax -based physical fragments.

Then that must be clearly specified in those namespaces.

[...]

All the best,

Lars

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 9 Sep 2011 15:13:13 +0200

Juha, all,

Juha wrote:
> 
> Leslie Daigle wrote:
> 
> > The URN WG meeting I was at during IETF80 seemed reasonably clear
> that
> > the options were:
> >
> > 1/ Define how fragments make sense for *ALL* URNs (i.e., not just
the
> > namespaces of which one is aware) and update the URN specifications
> > accordingly.
> >
> > -- OR --
> >
> > 2/ Include, in the NSS syntax for a given URN namespace, a means of
> > identifying what that Namespace means by 'fragment'.
> >
> >
> > I haven't seen any discussion on this list to accomplish "1/".  (I
> also
> > don't believe it's possible, but that's just a personal technical
> opinion).
> 
> I am pretty certain that 1/ cannot be achieved, not least because this
> has not been the approach chosen by the WG. No generic specification
> can
> be exhaustive, given the diversity of the identifier systems /
> namespaces / media types. Also, we cannot take into account in the
> abstract level the logical fragments of publications, as namespaces
> tend
> to see and deal with them differently.
> 
> However, generic principles (for instance, the requirement that the
> identifier must only apply to a single manifestation of a resource,
and
> the identified media type in that manifestation must support
fragments)
> can be given in RFC 2141bis. RFC2141bis should also stipulate that
> namespaces can have their internal fragment specifications which will
> be
> understood by resolvers that deal with that particular namespace.

I personally don't think it's possible to mandate that a URN MUST only
apply to a single manifestation of a resource, particularly since this
might impact all or at least some of the currently 44 registered urn
namespaces [1]

[...]
> >    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  So,
an
> > updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be
> achievable....?
> 
> Sorry, it is not. Please observe that RFC 3187 makes it pretty clear
> that in the ISBN namespace namespace specific string must be an ISBN
> and
> nothing else. So in URN:ISBN:<foo> = URN:ISBN:<ISBN-string>. ISBN with
> a
> fragment identifier or anything else added to it is not an ISBN
anymore
> and does not belong to the ISBN namespace. For this kind of identifier
> construct, another namespace such as NBN can be used, if local NBN
> assignment policy approves this.

If I understand the discussion correctly, the question is if in
urn:isbn:1-234-56789-X#foo the #foo is part of the ISBN or not. If it's
part of the ISBN, the urn would be invalid since ISBNs cannot have
fragments. IMO a fragment (in the sense of RFC 3986) refers to the URI
as a whole and not to the NSS of a URN. I guess that there are people on
this list who can shed some light on this.
> 
> So URN:NBN:<foo><fragment> is certainly achievable, and there may be /
> will be other namespaces out there where <foo><fragment> is also
> acceptable.
> 
> Concerning the NBN namespace, given the broad scope of allowed / used
> syntaxes, URI fragment is the only way in which fragments can be
> generally expressed in the identifier syntax. New namespaces may
> specify
> their own fragment architectures for those cases when RFC3986 & 2046
> requirements are not fulfilled, but retrospectively such changes may
be
> impossible or at least complicated to implement. Such namespace
> specific
> arrangements should be referred to in RFC2141bis in the abstract, but
> they can only be specified in the namespace level.

Considering that RFC 3986 still mandates that the semantics of fragments
are specific to media types, I don't think it's possible to make
regulations on their meaning on the scheme-level except for very special
cases. 2141bis can say that fragments are generally allowed in URNs and
leave it to individual schemes to make their own arrangements, where my
guess is that most schemes will not be able to allow them, except where
the specification mandates that once you've created a URN with a
fragment, the resolution service MUST continue to return resources with
a media type compatible with that fragment.

[...]

Lars

[1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 9 Sep 2011 15:23:06 +0200

All,

just one short comment on ISTC:

Juha wrote:

> > With respect to NBNs.  The situation is the same.  The matter of
> > fragment ID is the type, the format of the resource, not its actual
> > contents.  The same publication with the unique NBN number may exist
> in
> > electronic form in different formats.  Just the same as above.
> 
> NBN does not refer to the work, but to a single manifestation of the
> work (in one file format). Manifestations in different file formats
> will
> get a different URN:NBNs. The reason for this is that file format
> changes may have an impact on the look and feel of the resource, and
> once something changes, for librarians it is no longer the same thing.
> We've had similar practices for printed stuff: hard back and paper back
> versions of a book have different ISBNs.

This is not always the case, but is not something libraries can solve.

> There is an interesting problem that all digital manifestations will be
> short-lived. When URN:ISBNs and URN:NBNs are not moved over to more
> modern versions of the document (which will receive other URNs) then
> somehow we must guarantee that the users will be made aware that there
> are later versions available as well.
> 
> Other URN namespaces may be more flexible than the ones we are dealing
> now. We could have for instance urn:mykyta where the rule is that the
> file format does not matter. I don't know how much we can /should do in
> RFCs to co-ordinate those namespaces that deal with digital
> manifestations. Works are of course a different matter altogether,
> since
> they are immaterial and as such persistent.
> 
> Independently of any physical manifestations libraries will also
> describe and identify works, but then we do not use ISBN but ISTC
> (International standard text code) for textual resources. And
> registering a namespace for that identifier (which has just recently
> went into production) remains to be done.

ISTC identifies texts, not works. E. g. the English translation of a German text doesn't get the same ISTC as the German original, and a new translation of the same text would get another ISTC as well, at least according to the ISTC user manual [1, §7.1]
> 
> > So, my position is that defining the fragment ID for use with ISBN
> and
> > NBN URNs makes very little sense; they may only be useful in URNs
> which
> > have very limited scope and resolve to the resource of the type which
> is
> > predefined.

I tend to agree with Mykyta here.
 
> My take on this is that if we have e.g. a book in a file format that
> allows specification of fragments, then it is possible that these
> fragments can be accessed directly using HTTP URIs, and improving
> persistence of these access points to with URNs may make sense.
> 
> In case of multimedia documents (with a multitude of file formats),
> URN:NBNs must be assigned at the file format level if the intention is
> to use fragments in one or more of these formats.

Is it at all possible to mandate this in the specification? (And what do we do if someone doesn't comply?)

All the best,

Lars

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 9 Sep 2011 15:24:31 +0200

Sorry for omitting the link:

[1] http://www.istc-international.org/html/multimedia/pdfs/ISTC_User_Manual_2010v1.2.pdf 

  **** Bitte beachten Sie die neue Internet- und E-Mail-Adresse. ****
  **** Please note my new internet- and email-address. ****

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

> -----Ursprüngliche Nachricht-----
> Von: Svensson, Lars
> Gesendet: Freitag, 9. September 2011 15:23
> An: 'Juha Hakala'; Mykyta Yevstifeyev
> Cc: [email-masked]; Stella Griffiths
> Betreff: AW: Re: [urn] URNs and URI <fragment>
> 
> All,
> 
> ISTC identifies texts, not works. E. g. the English translation of a
> German text doesn't get the same ISTC as the German original, and a new
> translation of the same text would get another ISTC as well, at least
> according to the ISTC user manual [1, §7.1]
> >

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Sep 2011 15:31:22 +0200

On 2011-09-09 15:13, Svensson, Lars wrote:
> ...
> ...

It's not part of the ISBN -- I would have thought that's clear from the 
URI spec.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Sep 2011 15:33:53 +0200

> fragment identifier then a part of the URN or of the http-URI? (And:

The syntax is then defined by HTTP (RFC 2616) and URI (RFC 3986); so the 
identified resource is

   http://resolver.example.com/urn:nbn:aq:987-65432-1

any you apply the fragid "chapter98" to whatever is retrieved from that 
resource.

Best regards, Julian

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 9 Sep 2011 16:29:41 +0200

Julian wrote:

> > as a whole and not to the NSS of a URN. I guess that there are
people
> on

Yes, that is what I thought, but I'm glad someone more knowledgeable
could confirm that. Thanks!

All the best,

Lars

---

From: Jonathan Rees <[email-masked]>
Date: Fri, 9 Sep 2011 11:20:20 -0400

You could have it both ways by specifying a required # fragment id
semantics in the namespace registration, and say that any retrieved
representation has to respect that semantics.  That is, if the
namespace reg says #chapter1 refers to chapter 1, then any retrieved
representation in which #chapter1 meant something different would just
be incorrect, the same as if a representation for the wrong document
were retrieved.

I'm not sure I like this solution, but it does seem to both respect
3986 and allow namespace designers to say how they think fragids
should be used.

Just a thought.

Best
Jonathan

---

From: Juha Hakala <[email-masked]>
Date: Mon, 12 Sep 2011 16:41:49 +0300

Hello,

> It's not part of the ISBN -- I would have thought that's clear from the 

I agree; #foo is not part of the ISBN, and that is clear both from the 
URI spec and the ISBN standard.

The current draft of RFC2141bis states that <fragment> is part of the 
NSS, the reason being that an identifier without a <fragment> identifies 
the entire resource, and an identifier with a <fragment> only the 
relevant part of the resource. For the same reason we have not 
considered <query> to be a part of the NSS.

We need to have a shared understanding of the impact of <fragment> usage 
to the resolution process. We will of course be dependent on HTTP 
functionality, and should not assume that the system design will be 
changed. Otherwise it would be a bad idea to use <fragment> at all.

I have assumed that a URN such as

http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98

would, like Julian says, first retrieve the entire resource, and then 
fragment identifier is applied on it. This is how HTTP works, and the 
Web users are used to this kind of behaviour. If we expect something 
else, then we should develop another solution to achieve it.

In contrast, when domain specific fragment identifiers are used (such as 
urn:nbn:aq:987-65432-1.chapter98) the will be the relevant fragment 
(e.g. the chapter 98) only, unless the domain specific fragment is 
mapped into <fragment> in the resolution process.

As regards this proposal by Kadir:

> As a consequence of those two points I tried to explain above, I suggest to start a new discussion:
> queries in URN(:NBN).
> Instead of
> http://resolver.example.com/urn:nbn:aq:987-65432-1#chapter98
> standardizing
> http://resolver.example.com/urn:nbn:aq:987-65432-1?chapter=98
> so the resolver can get the information, that only a small part of the resource and not the whole is required.

one idea behind the RFC2141bis revision has been to use <query> to 
deliver service parameters. While URN syntax will not say much about the 
services themselves, in the revision of RFC2483 I could already consider 
ways in which to expand resource retrieval service in such a manner that 
only predefined sections of a resource are retrieved. For instance, if a 
resource is a journal issue and the user wants just single article 
(certain pages), this could be specified in a <query> containing a 
retrieval request. Satisfying the request would not be done by an HTTP 
resolver, but a digital asset management application to which the 
resolver passes the request.

Whether this kind of usage of <query> would force us to reconsider the 
view that <query> is never a part of the NSS I haven't really thought 
about yet.

Best regards,

Juha

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678