Subject: [urn] URNs and URI <fragment>

From: Juha Hakala <[email-masked]>
Date: Thu, 04 Aug 2011 09:11:10 +0300

Hello all,

I am revising the URN namespace registrations for ISBN and NBN (RFC 
3187bis and 3188bis). One of the issues that must be dealt with is the 
use of URI <fragment>.

On the basis of the discussion we had in the URNWG meeting during IETF 
80, I have assumed that <fragment> feature can be used, but only if RFC 
3986 requirements are taken into account. This must be made clear in 
RFC2141bis, and specified further in namespace registrations. There will 
be URN namespaces where <fragment> must not be used because the 
identifier system does not allow it.

ISBN and NBN (national bibliography number) are in different camps as 
regards URI fragments; the former does not allow them, but the latter 
does. Below are the relevant sections from the new Internet drafts. They 
are complementary in the sense that NBN can be used to identify 
component parts of a book (if they do not have ISBNs of their own). 
Armed with both specifications, national libraries and other users can 
assign identifiers to books and their logical / physical components, to 
the level of specificity desired.

This is what the revised RFC 3187bis says at the moment:

Books are finite objects, which may consist of component parts such as 
chapters or short stories / novellas. Such component parts may in some 
circumstances be given their own ISBNs. If they are not identified, ISBN 
standard does not allow augmentation of the ISBN of the book with URI 
fragments for identification of the component parts. Technically it is 
possible to add URI fragments to ISBN, but the resulting identifier will 
not be an ISBN; it could be a national bibliography number (URN:NBN) or 
an internal, completely non-standard identifier.

This is the corresponding section from RFC3188bis:

Bibliographic objects are finite, and may consist of component parts. If 
the object is a book, these component parts may be articles, chapters,
short stories / novellas, images and so on. When a bibliographic object 
such as a book is published in electronic form, it may be possible to 
access its component parts directly. If so, a reliable access key is 
needed. NBNs may be assigned to these component parts, depending the 
local NBN assignment policy. In some circumstances (if the stipulations 
of RFC 3986 and RFC2141bis are met), URI fragments can be applied in the 
NBN string.

However, since logical components of a book may not represented as URI 
fragments (and vice versa), component parts will normally be identified 
by using a local method not based on URI Generic syntax. This RFC will 
not specify the NBN method for generating fragment identifiers, since 
some organizations may use any available mechanism for other purposes. 
However, several viable methods can be suggested. For instance, the book 
as a whole may have an ISBN, and the NBNs for the component parts can be
based on the ISBN. Likewise there may be a base-NBN for the resource 
itself, and extended versions for the logical components. The most 
common approach may be the simplest: assign a separate NBN for each
component part.

------------

My aim is that the new versions of 3187bis and 3188bis will be published 
in August.

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Aug 2011 09:24:55 +0200

On 2011-08-04 08:11, Juha Hakala wrote:
> ...

Clarifying: the RFC 3986 requirement is:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 04 Aug 2011 11:43:06 +0300

04.08.2011 10:24, Julian Reschke wrote:
> representations that might result from a retrieval action on the 
> primary resource. The fragment's format and resolution is therefore 
> dependent on the media type [RFC2046] of a potentially retrieved 
> representation, even though such a retrieval is only performed if the 
> URI is dereferenced. If no such representation exists, then the 
> semantics of the fragment are considered unknown and are effectively 
> unconstrained. Fragment identifier semantics are independent of the 
> URI scheme and thus cannot be redefined by scheme specifications." -- 

... Correspondingly, it is only possible to use the fragment identifier 
when the URI/IRI is clear about the media type of the resource it refers 
to.  This may be determined from the URI itself or if it is mandatory 
that the particular type of a resource identifier must be resolved to 
the resource of a particular type.  URN with ISBN may refer to the text 
of a book in .txt, .html, .doc, .pdf, .ps, format or worse; URN with 
ISBN may refer to the page with book's annotation in any of the above 
format; or something else.  It is impossible to know for sure that "this 
URN is resolved to <bla-bla-bla> format", and, correspondingly, use 
fragment identifiers.  Here I agree with Juha.

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.

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.

(BTW: Fragment IDs, per RFC 3986, are allowed to be present in any URI, 
including URN; however, they cannot be effectively handled in the latter 
case.  I think RFC 2141bis should be clear that this part of an URI, if 
present, should be ignored).

(BTW2: Is new revision of 2141bis going to be published soon?)

Mykyta Yevstifeyev

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

---

From: Juha Hakala <[email-masked]>
Date: Thu, 04 Aug 2011 13:55:54 +0300

Privyet Mykyta; Hello all,

Some comments below.

>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

I have added a reference to media type and RFC 2046 into the draft.
> fragment identifiers.  Here I agree with Juha.

I disagree with Mykyta (but hopefully not with myself :-)).

The reason why URN:ISBN namespace does not allow fragments has to do 
with ISBN syntax. This is OK:

http://urn.fi/URN:ISBN:978-952-10-7060-0

but I am not allowed to add anything to the namespace specific string 
even if the media type in which this book is published would allow that. 
Of course, adding <query> would be OK since it would not be part of the 
identifier.

The URN:ISBN string itself does not imply any media type directly, but 
ISBN assignment rules make it clear that if the media type changes, a 
new ISBN must be assigned. The ISBN above belongs to a PDF version to a 
dissertation; if it is migrated to EPUB 3, a new ISBN is required.
> 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.

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.

> have very limited scope and resolve to the resource of the type which is 

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.
> (BTW2: Is new revision of 2141bis going to be published soon?)

Alfred Hoenes indicated before his summer vacation that he plans to 
concentrate on URNBIS work during the first half of August.

Best regards,

Juha

-- 

  Juha Hakala

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Aug 2011 13:17:55 +0200

> Of course, adding <query> would be OK since it would not be part of the

I don't believe an URI scheme (and thereby an URN namespace) can make 
this restriction.

> dissertation; if it is migrated to EPUB 3, a new ISBN is required.

If the ISBN above is guaranteed to identify a PDF document then I don't 
see why using a PDF anchor shouldn't work.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Thu, 04 Aug 2011 14:46:54 +0300

Hello,

> I don't believe an URI scheme (and thereby an URN namespace) can make 

ISBN can and must. If you add e.g. a fragment identifier to the end of 
the URN:ISBN string, the resulting identifier is not an ISBN anymore. Of 
course the new identifier can still be a valid URI and it may belong to 
some other URN namespace such as NBN.

> see why using a PDF anchor shouldn't work.

An ISBN given to a PDF version of a book must not apply to any other 
version of that book, or to some other book.

Having said this, there are cases in some countries (which I do not wish 
to name here) where publishers insist upon giving the same ISBN to all 
e-versions of a book. In such a case, ISBN does not provide even a 
reliable starting point for creating an identifier for a fragment in one 
of these formats. Any standard is only as strong as the weakest link; in 
this case it is a subset of users who abuse the standard (and may come 
to regret it later on).

Juha

-- 

  Juha Hakala

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Aug 2011 13:57:40 +0200

> some other URN namespace such as NBN.

A URN:ISBN URI is not an ISBN in the first place, so I think the above 
doesn't make any sense (sorry :-).

Best regards, Julian

---

From: [email-masked]
Date: Thu, 04 Aug 2011 17:15:34 +0300

Hello Julian,

> On 2011-08-04 13:46, Juha Hakala wrote:
X
> A URN:ISBN URI is not an ISBN in the first place, so I think the  
> above doesn't make any sense (sorry :-).
>
According to RFC 3187 (the namespace registration of the ISBN  
namespace), all the URN namespace specific strings in the ISBN  
namespace must be ISBNs. So every URN:ISBN URI must contain a valid  
ISBN.

If I construct something like

URN:ISBN:978-951-0

to identify the largest publisher in Finland the string is a valid URI  
but it is not a valid URN because it breaks the rules of the ISBN  
namespace. But I might do something like

URN:ISBNFINPUB:978-951-0

and nobody would object (provided that I am not breaking the  
regulations of the ISBNFINPUB namespace which must be registered  
before I can build a URN above).

All the best,

Juha

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Aug 2011 16:48:13 +0200

On 2011-08-04 16:15, [email-masked] wrote:
> namespace), all the URN namespace specific strings in the ISBN namespace
> must be ISBNs. So every URN:ISBN URI must contain a valid ISBN.
>...

Yes. But that doesn't make the URI a ISBN.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 05 Aug 2011 06:59:34 +0300

> Privyet Mykyta; Hello all,

Well, Ave, Juha,

> Some comments below.

See my responses ibidem :-)

>>> representation, even though such a retrieval is only performed if 
>>> the URI is dereferenced. If no such representation exists, then the 
>>> URI scheme and thus cannot be redefined by scheme specifications." 
>>> -- <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>
>
>> ... Correspondingly, it is only possible to use the fragment 
>> identifier when the URI/IRI is clear about the media type of the 
>> resource it refers to.  This may be determined from the URI itself or 
>> if it is mandatory that the particular type of a resource identifier 
>> must be resolved to the resource of a particular type.  URN with ISBN 
>> may refer to the text of a book in .txt, .html, .doc, .pdf, .ps, 
>> format or worse; URN with ISBN may refer to the page with book's 
>> annotation in any of the above format; or something else.  It is 
>> impossible to know for sure that "this URN is resolved to 
>> <bla-bla-bla> format", and, correspondingly, use fragment 
>> identifiers.  Here I agree with Juha.
>
> even if the media type in which this book is published would allow 
> that. Of course, adding <query> would be OK since it would not be part 
> of the identifier.

Neither would the fragment ID, though.

> new ISBN must be assigned. The ISBN above belongs to a PDF version to 
> a dissertation; if it is migrated to EPUB 3, a new ISBN is required.

But you should consider that ISBN may also be assigned to printed 
version, which may also be transformed to the electronic form.  In this 
case, even being the same book, the format will be different, and mostly 
likely different from one used to produced printed copy.  Then such 
scanned copies may be entered in the URN resolution system, and the URN 
with ISBN will be resolved to one of such copies.

I also don't actually think that when some person transforms the text of 
the book in the format he/she likes, he/she will request the new ISBN.  
ISBN identify contents, unlike fragment identifiers, which concertize 
contents in terms of media type.

>> contents.  The same publication with the unique NBN number may exist 
>> in electronic form in different formats.  Just the same as above.
>
> work (in one file format). Manifestations in different file formats 
> will get a different URN:NBNs. The reason for this is that file format 
> We've had similar practices for printed stuff: hard back and paper 
> back versions of a book have different ISBNs.

One of the assumptions of URN namespaces is global uniqueness.  From RFC 
1737:

>     o  Global uniqueness: The same URN will never be assigned to two
>        different resources.

and therefore I don't understand URNs for NBNs with such identifier 
possible to be assigned twice or more to the same resource.  If the work 
doesn't change, the URN must be stable.

>
> 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 
> 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.
>

NBN namespace, with what you've said, break the aforementioned 
assumption for URNs; different manifestations of a similar work 
shouldn't have different URNs, I'll repeat.  So I suppose the case with 
NBNs isn't generally applicable to the URNs.  (It also breaks the 
"persistence" principle, which means that one URN will identify the 
resource forever.  With NBNs, which may change depending on the version 
of the resource and its format, it isn't possible to persistently refer 
to the "newest version".)

>
>> 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.
>

And I'll ask the same question - how do you determine the format a 
particular URN may theoretically be resolved to?

>> (BTW: Fragment IDs, per RFC 3986, are allowed to be present in any 
>> URI, including URN; however, they cannot be effectively handled in 
>> the latter case.  I think RFC 2141bis should be clear that this part 
>> of an URI, if present, should be ignored).
>>

Thanks for info.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 05 Aug 2011 07:04:04 +0300

04.08.2011 14:46, Juha Hakala wrote:
>>> that.
> the URN:ISBN string, the resulting identifier is not an ISBN anymore. 
> Of course the new identifier can still be a valid URI and it may 
> belong to some other URN namespace such as NBN.

 From RFC 3187 it's clear that URN with no queries or fragments is 
"urn:isbn:<isbn-number>" and that's all.  Please consider that fragment 
ID won't override the ISBN number, if appended.  However, I'm opposed to 
fragment IDs here.

>> If the ISBN above is guaranteed to identify a PDF document then I 
>> don't see why using a PDF anchor shouldn't work.
>
> Having said this, there are cases in some countries (which I do not 
> wish to name here) where publishers insist upon giving the same ISBN 
> to all e-versions of a book. In such a case, ISBN does not provide 
> even a reliable starting point for creating an identifier for a 
> fragment in one of these formats. Any standard is only as strong as 
> the weakest link; in this case it is a subset of users who abuse the 
> standard (and may come to regret it later on).

This also seems not to match RFC 1737, "global uniqueness".

Mykyta

---

From: Juha Hakala <[email-masked]>
Date: Fri, 05 Aug 2011 08:48:06 +0300

Hello Mykyta; all,

This debate has much to do with how identifiers - and in this case 
particularly ISBN and NBN - are and will be applied in practice, and how 
that relates to URN usage in namespaces. If the aim is to build reliable 
and persistent URN resolution services, we need identifier communities 
with well defined professional practices. The trick is to apply these 
practices in the Internet in a fruitful manner, taking into account the 
requirements of the new environment. If all goes well, both the 
identifier and the IETF communities may learn something in this process.

Since Mykyta brought up many important points about identifiers and 
identification I discuss them at length.

> Neither would the fragment ID, though.

That assumption is not correct. According to the RFC2141bis, fragment ID 
- if we allow its use in the URN syntax - will be part of the 
identifier. An identifier which consists of and ISBN and a fragment no 
longer identifies the book as a whole but a component part of it. 
Whereas ISBN with <query> still identifies the book as a whole; the role 
of the <query> is to specify the resolution service the user wants.
> with ISBN will be resolved to one of such copies.

It should not, at least not automatically. When a book with (or without 
ISBN) is scanned and published in the Web (many national libraries are 
busy with this kind of activity), the resulting digital book shall not 
get an ISBN at all (according to the well established rules of the 
community). So we will end up with URN:ISBN for the printed version and 
URN:NBNs for digitized versions. If the publisher has created "official" 
digital versions, then those will have URN:ISBNs as well.

It is very important that via URN resolution services we can keep track 
on all the manifestations of a book. It is also important to give the 
users the possibility to choose between them, because there is no way of 
knowing in advance which manifestation will fit the needs of the user 
best. He might not know that himself, without some orientation. Some 
people may prefer a modern version, which after many successive 
migrations may be quite different from the original. And some may want 
the original version, even though that means digital archaeology is 
needed to actually read the document.

Interlinking between manifestations can be achieved via well planned 
usage of metadata. All records describing any manifestation of the book 
should contain links to all the other versions. In the future our 
catalogues will contain descriptions of immaterials work such as 
Shakespeare's Hamlet, and these descriptions will contain links to the 
manifestation level records which in turn will contain the actual URN 
links.

This may sound a little bit complicated, but when the aim is to provide 
access to digital resources for centuries, simple solutions will not work.

As an aside, the current resolution services document (RFC 2483) does 
not specify a service for finding all related manifestations of the 
resource. In the late 90s this was not deemed necessary; now even Amazon 
provides it. This indicates at least to me that we can not specify a 
fixed list of resolution services, since the services that are valid at 
any given time depend on the technical infrastructure. It follows that 
it is a bad idea to carve the URN resolution services in stone (specify 
them in a standards track RFC). Instead we need a flexible mechanism 
such as IANA registry where new services can be a registered easily. I 
will start writing a private contribution I-D today to provide a basis 
for this.
> contents in terms of media type.

ISBN does not identify intellectual content (ISTC does; see 
http://www.istc-international.org/html/). ISBN identifies a particular 
manifestation of the content, such as a paperback or a PDF version of a 
book.

If somebody digitizes as book, it is not possible to acquire an ISBN for 
the resulting book. Another identifier, such as URN:NBN, must be used 
instead.  When digitized books are catalogued, it is a common practice 
to tell that there is a printed version and provide its identifier (ISBN 
or NBN).

> doesn't change, the URN must be stable.

As I said above, ISBN identifies manifestations. PDF version of the book 
gets one ISBN, EPUB 3 version get another one, and so on. See

http://www.isbn-international.org/pages/media/101118%20Guidelines%20for%20the%20assignment%20of%20ISBNs%20to%20ebooks.pdf

for details. The raison d'etre for ISBN assignment is derived from book 
trade; anything that is for sale as a separate item must have an ISBN, 
so that the particular manifestation can be told apart from other 
manifestations.

Each time a URN namespace is established, the identifier community 
brings in its own traditions. In some cases the community is not well 
formed; for example I have no idea of what best practices URN:IRI 
community as a whole would have for assigning identifiers. AFAIK well 
defined namespaces such as URN:ISBN will have the best chances of 
actually preserving the resources and resolution services in looong term.

There is a namespace where your view is correct: in the URN:ISTC 
namespace URN will never change as long as the work remains the same. 
When Hamlet is translated to Finnish the translation will of course get 
a new ISTC, but there will be a link to the English original (and to 
translations in other languages, such as Russian and Ukrainian).
> to the "newest version".)

To conclude, there will be namespaces where the identifier identifies 
works (such as ISTC, ISWC, ISAN) and namespaces where manifestations are 
in focus (ISBN, NBN). From the URN point of view, both approaches must 
be correct in the URN system accommodates these namespaces. Of course I 
am assuming here that IETF would approve ISTC namespace registration 
request if the ISTC community produces one.

> particular URN may theoretically be resolved to?

The answer to this will depend on the namespace.

With ISBN, there is always a single manifestation of the book that 
should be retrieved (if the user wants a book). For digital content, 
this approach works for a few decades at most. After a couple of 
centuries it gets a little difficult to carry on like this :-). Please 
note that the time scale for the national libraries really is centuries. 
We may have slightly different notion of persistence than e.g. most web 
developers.

The solution is to provide links between manifestations of the work. 
This will allow the user to pick the one he prefers.

In the URN:ISTC namespace, there is no single manifestation the 
identifier should resolve to. It is up to the user to decide what to do. 
Having started from the English original from Hamlet he may end up 
requesting a digital version of the great Russian Hamlet movie from the 
50s.

Best regards,

Juha

-- 

  Juha Hakala

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 05 Aug 2011 17:02:32 -0400

Hi,

 > identifier system does not allow it.

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).

For "2/", you would be in a position to update the ISBN URN NSS syntax. 
    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....?

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 06 Aug 2011 07:21:30 +0300

Hi Juha, all,

Having read your explanations, a number of issues were clarified.  First 
of all, you said that ISBN actually focuses of manifestation of a book, 
not its contents; so does NBN number.  I personally don't agree with it, 
as ISBN, IMO, should be meant to identify book's contents uniquely and 
independently of the format they are represented in, but I have nothing 
to do with here.  Please see further comments below.

05.08.2011 8:48, Juha Hakala wrote:
> particularly ISBN and NBN - are and will be applied in practice, and 
> how that relates to URN usage in namespaces. If the aim is to build 
> reliable and persistent URN resolution services, we need identifier 
> communities with well defined professional practices. The trick is to 
> apply these practices in the Internet in a fruitful manner, taking 
> into account the requirements of the new environment. If all goes 
> well, both the identifier and the IETF communities may learn something 
> in this process.
>
>>> but I am not allowed to add anything to the namespace specific 
>>> string even if the media type in which this book is published would 
>>> allow that. Of course, adding <query> would be OK since it would not 
>>> be part of the identifier.
>>
> That assumption is not correct. According to the RFC2141bis, fragment 
> ID - if we allow its use in the URN syntax - will be part of the 
> Whereas ISBN with <query> still identifies the book as a whole; the 
> role of the <query> is to specify the resolution service the user wants.

Strictly at syntactical level, RFC 2141 <NID> and <NSS> form RFC 3986 
<path-rootless>. <fragment> and its preceding "#" is put after <query> 
and its "?", if any, and some sort of path.  So <fragment> cannot be 
considered to be a part of the"path" in the URI.

>>
>>>
>>> The URN:ISBN string itself does not imply any media type directly, 
>>> but ISBN assignment rules make it clear that if the media type 
>>> changes, a new ISBN must be assigned. The ISBN above belongs to a 
>>> PDF version to a dissertation; if it is migrated to EPUB 3, a new 
>>> ISBN is required.
>>
>> version, which may also be transformed to the electronic form.  In 
>> this case, even being the same book, the format will be different, 
>> and mostly likely different from one used to produced printed copy.  
>> Then such scanned copies may be entered in the URN resolution system, 
>> and the URN with ISBN will be resolved to one of such copies.
>
> It should not, at least not automatically. When a book with (or 
> without ISBN) is scanned and published in the Web (many national 
> libraries are busy with this kind of activity), the resulting digital 
> book shall not get an ISBN at all (according to the well established 
> rules of the community). So we will end up with URN:ISBN for the 
> printed version and URN:NBNs for digitized versions. If the publisher 
> has created "official" digital versions, then those will have 
> URN:ISBNs as well.

OK, but why eg. Google Books provide search of e-books with ISBNs of 
their printed versions?

>
> It is very important that via URN resolution services we can keep 
> track on all the manifestations of a book. It is also important to 
> give the users the possibility to choose between them, because there 
> is no way of knowing in advance which manifestation will fit the needs 
> of the user best. He might not know that himself, without some 
> orientation. Some people may prefer a modern version, which after many 
> successive migrations may be quite different from the original. And 
> some may want the original version, even though that means digital 
> archaeology is needed to actually read the document.
>
> usage of metadata. All records describing any manifestation of the 
> book should contain links to all the other versions. In the future our 
> This may sound a little bit complicated, but when the aim is to 
> provide access to digital resources for centuries, simple solutions 
> will not work.

Well, if a "manifestation" implies making some changes to the original 
work, I'll doubt it is the same work; so here another identifier is 
necessary.  If "manifestation" means different format of the same work, 
eg. printed, electronic in different formats, etc., I don't think here 
the new identifier is necessary, but if assigning it (I mean ISBNs and 
NBNs) is community-accepted, I have nothing to say.  I consider tracking 
relationships between such resources to be necessary in both cases.

> resource. In the late 90s this was not deemed necessary; now even 
> Amazon provides it. This indicates at least to me that we can not 
> specify a fixed list of resolution services, since the services that 
> are valid at any given time depend on the technical infrastructure. It 
> follows that it is a bad idea to carve the URN resolution services in 
> stone (specify them in a standards track RFC). Instead we need a 
> flexible mechanism such as IANA registry where new services can be a 
> registered easily. I will start writing a private contribution I-D 
> today to provide a basis for this.

I'm looking forward to work on this draft.  Juha, please note that RFC 
3404, DDDS application for resolving URIs and URNs intended to use 
assigned resolution service names, but failed to create corresponding 
registry.  In your draft, it's possible to mention that new registry for 
resolution services may also be useful in this DDDS application.

>>
>> I also don't actually think that when some person transforms the text 
>> of the book in the format he/she likes, he/she will request the new 
>> ISBN.  ISBN identify contents, unlike fragment identifiers, which 
>> concertize contents in terms of media type.
>
> manifestation of the content, such as a paperback or a PDF version of 
> a book.

Even though I don't agree with it, as I've already said, but have 
nothing to say here :-).

>
>
> If somebody digitizes as book, it is not possible to acquire an ISBN 
> for the resulting book. Another identifier, such as URN:NBN, must be 
> used instead.  When digitized books are catalogued, it is a common 
> practice to tell that there is a printed version and provide its 
> identifier (ISBN or NBN).
>
>> One of the assumptions of URN namespaces is global uniqueness.  From 
>> RFC 1737:
>>
>> possible to be assigned twice or more to the same resource.  If the 
>> work doesn't change, the URN must be stable.
>
> As I said above, ISBN identifies manifestations. PDF version of the 
> book gets one ISBN, EPUB 3 version get another one, and so on. See
>
> for details. The raison d'etre for ISBN assignment is derived from 
> book trade; anything that is for sale as a separate item must have an 
> ISBN, so that the particular manifestation can be told apart from 
> other manifestations.
>
> When Hamlet is translated to Finnish the translation will of course 
> get a new ISTC, but there will be a link to the English original (and 
> to translations in other languages, such as Russian and Ukrainian).
>>
>> shouldn't have different URNs, I'll repeat.  So I suppose the case 
>> with NBNs isn't generally applicable to the URNs.  (It also breaks 
>> the "persistence" principle, which means that one URN will identify 
>> the resource forever.  With NBNs, which may change depending on the 
>> version of the resource and its format, it isn't possible to 
>> persistently refer to the "newest version".)
>
> works (such as ISTC, ISWC, ISAN) and namespaces where manifestations 
> are in focus (ISBN, NBN). From the URN point of view, both approaches 
> must be correct in the URN system accommodates these namespaces. Of 
> course I am assuming here that IETF would approve ISTC namespace 
> registration request if the ISTC community produces one.

ISCT namespace would fit the aforementioned requirement of RFC 1737 
better than ISBN; but if it is an already established practice...

> note that the time scale for the national libraries really is 
> centuries. We may have slightly different notion of persistence than 
> e.g. most web developers.
>
> identifier should resolve to. It is up to the user to decide what to 
> do. Having started from the English original from Hamlet he may end up 
> requesting a digital version of the great Russian Hamlet movie from 
> the 50s.

Considered what you've said, it may be possible to specify fragment I-Ds 
to ISBNs.  With respect to NBNs, if one is capable of determining or 
finding up for sure which media type the resource it refers to has, 
fragment IDs can also be possible.

With regard to 2141bis, I think it should allow fragment IDs but mention 
that separate namespaces may define them as allowed or disallowed; for 
those which disallow, fragment ID should be ignored.

Mykyta Yevstifeyev

>>> URN:NBNs must be assigned at the file format level if the intention 
>>> is to use fragments in one or more of these formats.
>>>>
>>>> the latter case.  I think RFC 2141bis should be clear that this 
>>>> part of an URI, if present, should be ignored).
>>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Aug 2011 10:28:14 -0600

<hat type='individual'/>

> updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be achievable....?

That is consistent with my understanding of the meeting in Prague. I've
been expecting draft-ietf-urnbis-rfc3187bis-isbn-urn-01 to include text
showing how to include fragment identifiers within URNs in the URN:ISBN
namespace.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andy Newton <[email-masked]>
Date: Mon, 8 Aug 2011 15:06:51 -0400

On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:

> For "2/", you would be in a position to update the ISBN URN NSS syntax.    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....?

Do you mean <fragment> as defined by URIs or an NSS specific syntax that doesn't conflict with the URI specification?

-andy

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 08 Aug 2011 15:46:29 -0400

Hi,

On 8/8/11 3:06 PM, Andy Newton wrote:
>> For "2/", you would be in a position to update the ISBN URN NSS
>> syntax.    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....?
>
> Do you mean<fragment>  as defined by URIs or an NSS specific syntax
> that doesn't conflict with the URI specification?

The latter -- some NSS specific syntax.

Leslie.

--

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 09 Aug 2011 03:54:19 +0200

>identifier system does not allow it.

As I see it, there is a URI layer which sees all URIs. Below it there is
a scheme layer which can see the URI scheme and the scheme-specific part
of the URI. It cannot see the fragment identifier as it is not specific
to individual schemes. So the scheme layer cannot make statements about
fragment identifiers as it is unaware of them. In this sense there can-
not be URN namespaces that say anything about fragment identifiers. This
matches Julian Reschke's interpretation.

Could you explain how you think these terms and concepts fit together?
It seems to me there is confusion here about terminology, but I am not
sure what your mental model here is. There is some nuance about what I
say above, as schemes do get to say how you dereference an identifier,
which in turn affects which representations are available, which affects
how fragment identifiers are interpreted, but that seems out of touch
with how you think about this.

Put differently, as Julian noted, "Fragment identifier semantics are
independent of the URI scheme and thus cannot be redefined by scheme
specifications." How would you reconcile this with your statement above?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Keith Moore <[email-masked]>
Date: Tue, 9 Aug 2011 01:36:12 -0400

> specifications." How would you reconcile this with your statement above?

Clearly, fragment identifier semantics are associated with the content-type(s) of the resource, not the URI scheme.  How can it work any other way?

Keith

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Aug 2011 12:13:08 +0200

> The latter -- some NSS specific syntax.

+1

Just to clarify: this would mean to use something like

   URN:ISBN:978-952-10-7060-0:chapter1

instead of

   URN:ISBN:978-952-10-7060-0#chapter1

...so it's really mainly a different choice of delimiter...

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 09 Aug 2011 09:26:17 -0600

<hat type='individual'/>

> ...so it's really mainly a different choice of delimiter...

Agreed. It could be "." or ";" or whatever the community for that
namespace prefers.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andy Newton <[email-masked]>
Date: Tue, 9 Aug 2011 13:04:19 -0400

> Agreed. It could be "." or ";" or whatever the community for that

So we can move forward on this issue, is there any disagreement on this approach?

-andy

---

From: [email-masked]
Date: Tue, 09 Aug 2011 21:18:14 +0300

Hello,

>>>  URN:ISBN:978-952-10-7060-0#chapter1

You cannot use either one of these identifiers in the ISBN namespace.  
But it is possible to specify another namespace where this kind of  
syntax is ok, such as NBN.

> So we can move forward on this issue, is there any disagreement on  

There are namespaces - including ISBN - which do not accept any kind  
of fragments, since using them would be against the syntax of the  
identifier. Namespace registrations must clarify this.

Whenever the namespace does approve fragment use - NBN being an  
example of this - a namespace specific practice for identifying  
(logical) fragments can be outlined in the namespace registration  
request. Even well established standards could consider this kind of  
practice for the future when the standard is revised. Identifying  
component parts is one of the big challenges the identifier systems  
are facing.

As regards NBN, it may not be possible to specify a generic NSS  
specific delimiter because all the characters that could be used for  
this purpose may already be in use within the namespace specific  
strings. Locally (for individual users of the namespace) such  
practices can easily be developed.

So, the possibility for creating NSS specific delimiters for  
identification of logical / physical fragments of resources can and  
IMHO should be mentioned in RFC2141bis.

In addition, I think it would make sense to include the use of  
<ragment> in 2141bis. Physical fragments of a resource can be  
identified with URI <fragment>, iff media type allows this and the  
identifier is attached to a single manifestation of the resource (in  
the media type level). In such a case the URN will follow the  
requirements of 3896 and and 2046. I assume that these cases will be  
relatively rare.

Best regards,

Juha

---

From: "Stella Griffiths \(ISBN\)" <[email-masked]>
Date: Wed, 10 Aug 2011 10:26:43 +0100

Juha is correct about the use of ISBN namespace. That namespace only supports a 13 digit number and not any form of appended fragment indicator. Different ISBNs can be used to identify a) the entire publication in a specific edition or format and b) to identify a particular chapter or fragment of that same publication however.

Stella

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 09 August 2011 19:18
To: Andy Newton
Cc: [email-masked]; Stella Griffiths
Subject: Re: [urn] URNs and URI <fragment>

Hello,

You cannot use either one of these identifiers in the ISBN namespace.  
But it is possible to specify another namespace where this kind of syntax is ok, such as NBN.

> So we can move forward on this issue, is there any disagreement on 

There are namespaces - including ISBN - which do not accept any kind of fragments, since using them would be against the syntax of the identifier. Namespace registrations must clarify this.

Whenever the namespace does approve fragment use - NBN being an example of this - a namespace specific practice for identifying
(logical) fragments can be outlined in the namespace registration request. Even well established standards could consider this kind of practice for the future when the standard is revised. Identifying component parts is one of the big challenges the identifier systems are facing.

As regards NBN, it may not be possible to specify a generic NSS specific delimiter because all the characters that could be used for this purpose may already be in use within the namespace specific strings. Locally (for individual users of the namespace) such practices can easily be developed.

So, the possibility for creating NSS specific delimiters for identification of logical / physical fragments of resources can and IMHO should be mentioned in RFC2141bis.

In addition, I think it would make sense to include the use of <ragment> in 2141bis. Physical fragments of a resource can be identified with URI <fragment>, iff media type allows this and the identifier is attached to a single manifestation of the resource (in the media type level). In such a case the URN will follow the requirements of 3896 and and 2046. I assume that these cases will be relatively rare.

Best regards,

Juha

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Aug 2011 16:20:39 -0400

> The latter -- some NSS specific syntax.

A URN can refer to anything, including a portion of another resource also named by a URN.   However, it's important to ensure that a URN describing a fragment of a resource named by a URN still meets the properties of URNs.  

For instance, if URNs are coined to describe fragments of a resource also named by a URN, and the "outer" resource is subject to change in such a way that the fragments also change, then the URNs coined to describe those fragments may no longer have the same meanings as they did when the URNs were originally associated with those fragments.

The problem is that there are two conflicting desires:  One is to maintain stable bindings between individual URNs and they resources named by them (whether or not those resources are fragments).   The other is to keep the syntactic relationship between the "global" URN and the "fragment" URNs stable, so that the global URN is derivable from the fragment URN, and perhaps, vice versa.   The URN rules require the former; the expectation that there can be a syntactic relationship between a name of a fragment and the name of the resource containing the fragment creates the latter desire.

Of course, if the resource referred to by the "global" URN never changes at all, it's not an issue.   And there may be specific characteristics of a particular namespace that make it easier for that particular case.  But in general, trying to define fragments for URNs is problematic, and the syntax is the least of the issues.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Mon, 22 Aug 2011 15:34:20 +0300

Hello Leslie; all,

> 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.

> For "2/", you would be in a position to update the ISBN URN NSS syntax. 

I have already done this for the new versions of ISBN and NBN namespace 
registrations, which I hope to be able to send to the list fairly soon. 
The XML sources are ready, but I need technical help to convert the 
documents into I-Ds.

As regards RFC2141bis, I can (in case Alfred Hoenes does not have time 
for that) edit the fragment related section of the latest I-D if I get 
the XML source.

> 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.

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.

To sum up,

1. In the RFC 2141bis, there should be some general principles 
concerning the <fragment> use, derived from the requirements contained 
in URI Generic syntax and other principles (such as identification being 
manifestation specific).

2. In addition, namespaces may have their own policies as regards 
identification of fragments. Logical fragments (such as chapters of a 
book published as separate files) shall always be dealt with according 
to the identifier assignment policy (in the ISBN namespace, each chapter 
can get its own ISBN) independently of RFC 3986. Fragments in the URI 
syntax sense is the area where URI Generic syntax will and must be taken 
into account. However some namespaces (such as ISBN) will prevent this 
kind of URNs, due to the requirements of the identifier system.

3. If URI <fragment> is used, identifier must apply to the single 
manifestation of the resource only. This is a normal approach of many 
but not all bibliographic identifiers.

4. If multiple/all manifestations are covered by single identifier, 
fragments must no be used. Moreover, namespace registration request 
should outline the resolution process down to the level of manifestions. 
For instance, with ISTC (identifier for textual works) the primary 
target is the work level metadata, from which a user can get links to 
the manifestations.

Juha

-- 

  Juha Hakala

---

From: Juha Hakala <[email-masked]>
Date: Tue, 23 Aug 2011 13:48:26 +0300

Hello Bjoern; all,

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.

 From the point of view of a bibliographic community, the primary 
interest is what I have called logical fragments; for instance, chapters
of a book or articles in a journal issue. Identifier systems typically 
have their own ways of dealing with these fragments. For instance, in
the ISBN namespace each logical fragments gets its own ISBN, while
Serial Item and Contribution Identifier
(http://en.wikipedia.org/wiki/Serial_Item_and_Contribution_Identifier)
allows automated creation of identifiers to journal issues and articles.
Neither of these identifier systems rely on fragments as specified in 
RFC 3986. But URN resolvers that deal with these identifiers shall be 
able to supply the relevant logical fragment (or whatever related 
service) to the user.

Thus fragment identification will often be dealt with in the namespace 
level, using the standard-based practices of the particular identifier 
community. These practices are not based on RFC 3986, as ISBN and SICI 
indicate. And if this were all there is, there would have been no need 
to say anything about RFC 3986 -based URI fragments in either the URN 
Generic syntax or namespace registrations.

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).

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.

> matches Julian Reschke's interpretation.

This may be due to the terminological issues or my ignorance, but I fail 
to see why we couldn't establish a URN namespace which includes fragment 
identifier in the URI generic syntax sense of the word. URNs are URIs, 
and the generic syntax which applies to the URIs should apply to URNs as 
well, unless there are some clear technical reasons why this cannot be 
the case.

> with how you think about this.

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.

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.

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. 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.

> specifications." How would you reconcile this with your statement above?

I am not sure I understand the above statement correctly. If not, please 
explain in plainer terms. But tentatively I would answer by saying that 
in some URN namespaces such as the NBN the generic specification of the 
fragment identifier semantics can and indeed must be based on the URI 
generic syntax. And although in many URN namespaces identifier & 
fragment semantics will indeed be independent of the URI scheme, it may 
be useful to allow usage of fragments based on URI generic syntax in URN 
strings.

Best regards,

Juha
-- 

  Juha Hakala

---

From: "Emanuele Bellini" <[email-masked]>
Date: Wed, 31 Aug 2011 12:47:03 +0200

Hello Juha, all
Thanks for your work in explaining the identification requirements of the national libraries community. We agree with the possibility to use the fragment in the RFC 3188 NBN namespace, and there is no reason to prevent the use of fragment identifier in the URI generic syntax. 
Indeed, the use of fragment opens a number of issues under the digital preservation point of view. Up to now other solutions such as "emulation" can be adopted avoiding the format migration of the content. This can save the resolution behaviour of the fragment...but it is still an open issue.

Best,

Emanuele Bellini
Fondazione Rinascimento Digitale

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Juha Hakala
Inviato: martedì 23 agosto 2011 12:51
A: Bjoern Hoehrmann
Cc: [email-masked]; Stella Griffiths
Oggetto: Re: [urn] URNs and URI <fragment>

Hello Bjoern; all,

Best regards,

Juha
-- 

  Juha Hakala