Subject: Re: [urn] Comments to the draft-ietf-urnbis-rfc2141bis-urn-00.txt

From: Juha Hakala <[email-masked]>
Date: Wed, 05 Jan 2011 12:10:26 +0200

Hello Mykyta,

See comments below.

Mykyta Yevstifeyev wrote:
> Jula,
> 
> Some responds to your comments:

>>>> Persistence (additional considerations): URN is typically related to 
>>>> a single manifestation of a resource (work). URN will have a longer 
>>>> life time than any such manifestation, which means that over long 
>>>> period of time resolution is only possible if URNs of successive 
>>>> manifestations of a resource are linked to one another, allowing the 
>>>> user to access a more modern version of the resource. The technical 
>>>> implementation of linking these URNs to one another is namespace / 
>>>> implementation specific and discussed in e.g. namespace registration 
>>>> documents.
>>
>>> I think this issue is in the scope of implementators who will develop 
>>> the URN resolution mechanisms.
>>
>> Yes and no. From the point of view of the URN system, I think this 
>> means that it should be possible to request a list of URNs related to 
>> the URN at hand. Thus, if I know one manifestation, I would be able to 
>> find all other manifestations as well, and the description of the work 
>> itself. This service and its inbuilt URN-URN linking would also make 
>> systems resilient in the sense that if the resolution service can not 
>> locate the manifestation the URN refers to, it could still deliver 
>> another, more modern manifestation.
> But in the way you describe it, it seems to be that different URNs can 
> refer to the same resource. But URNs are *unique* and it won't be OK, I 
> think, if more than 1 URN refers to the same resource.

Our different understanding of the term "resource" causes some 
confusion. Because it is important to understand how (bibliographic) 
identifiers work, let me elaborate this point a bit.

In libraries the current thinking is that the top level thing is work, 
such as Hamlet (the novel). There may be related work, such as Hamlet 
(the movie). There may also be different expressions of the Hamlet (the 
novel), such as translations to Finnish, Russian etc. Each expression 
will in turn have one or more manifestations, such as (in the case of 
Hamlet (the novel) hard-cover and paperback book, and electronic 
versions in e.g. plain text, Word 2003, PDF/A and EPUB.

Identifier communities have in theory clear guidelines on how to deal 
with these manifestations. For instance, every manifestation of a book 
should get its own ISBN. (As an aside, there is a pressure within the 
ISBN community to cut corners in this respect, which I think is a bad 
idea.) AFAIK whenever two manifestations of the same work no longer have 
the same intellectual content, it becomes vitally important that they do 
not have the same identifier. And when digital resources are migrated to 
new file formats, changes in look and feel and eventually also in the 
actual content are almost inevitable. Over time these changes will 
probably get more pronounced.

So my view is that each manifestation of a work should have one but only 
one identifier. When a new manifestation is produced via migration, it 
should get a new identifier, because migration may have changed the look 
and feel and/or the content of the resource. So eventually there will be 
a set of identifiers, consisting of one identifier referring to each 
manifestation of the work, and probably also one  belonging to the work 
itself (and its expressions, if any).

All manifestations of the same work should be linked to one another and 
to the metadata record describing the work itself using a persistent 
identifier, since a user should be made aware of the fact that there are 
other variants of the work. As long term preservation of digital 
resources will usually be based on migration strategy, there will 
eventually be a large number of different manifestations available for 
each properly preserved work. We have no control over which 
manifestation the permanent link has been made to. If the linked 
manifestation is outdated, a user following the link may not be able to 
use the document with the applications he/she has available; in such a 
case it is important to know that there are more modern versions 
available. On the other hand, the user may be a digital archeologist who 
wants to find the oldest manifestation so as to avoid all the changes 
migrations have caused to the look and feel and the intellectual content.

Short lifetime of digital manifestations is a headache for persistent 
linking, when "persistent" means at least several decades and often 
centuries. One solution would be to make the permanent link to work / 
expression; that is, to metadata record which is never changed apart 
from new links added whenever there are new manifestations available.

>>>>
>>>> Query and fragment
>>>>
>>>> The I-D proposes two different approaches for supporting <fragment>: 
>>>> individual assignment of fragments on document-to-document basis, 
>>>> and/or creation of a specific set of fragment identifiers which are 
>>>> generally applicable to all resources encompassed by a given URN 
>>>> namespace. Within a namespace only one of these approaches would be 
>>>> acceptable. While it is likely that both methods can be applied, we 
>>>> are not sure if these options are mutually exclusive within one 
>>>> namespace.
>>
>>> If we use fragments, I think it should apply to the whole NS. 
>>> Generally URN NSs specify resources of one type and structure so 
>>> one-type fragments for whole NS is a possibility.
>>
>> While I agree that most namespaces are homogeneous (ISSN namespace 
>> deals with serials, ISBN with books) there are some that are broad. 
>> NBN (National bibliography number) encompasses anything that the 
>> national libraries hold in their collections, which means all kinds of 
>> published cultural heritage, and even some non-published materials).

> But in this way, fragments should not be allowed at all, as assigning 
> fragments to all (or not all) elements in the namespace (when there 
> could thousands of them) does not seem very great perspective to me.

We both agree that this kind of random usage of <fragment> would not be 
sensible.

When the namespace belongs to a well-specified standard such as ISBN, 
the namespace registration could / should specify whether fragments are 
allowed at all, and if they are, how. With more vague namespaces such as 
for instance NBN it is harder to specify how fragments will be used, 
since we know neither the syntax of the identifier nor the resources 
NBNs will be applied to. If RFC2141bis allows the usage of fragments, 
NBN namespace registration should specify at least in broad terms some 
principles for the usage of fragments within that particular namespace.

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: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 08 Jan 2011 18:09:29 +0200

Juha,

Please find some comments below.

05.01.2011 12:10, Juha Hakala wrote:
>>>>> Persistence (additional considerations): URN is typically related 
>>>>> to a single manifestation of a resource (work). URN will have a 
>>>>> longer life time than any such manifestation, which means that 
>>>>> over long period of time resolution is only possible if URNs of 
>>>>> successive manifestations of a resource are linked to one another, 
>>>>> allowing the user to access a more modern version of the resource. 
>>>>> The technical implementation of linking these URNs to one another 
>>>>> is namespace / implementation specific and discussed in e.g. 
>>>>> namespace registration documents.
>>>
>>>> I think this issue is in the scope of implementators who will 
>>>> develop the URN resolution mechanisms.
>>>
>>> means that it should be possible to request a list of URNs related 
>>> to the URN at hand. Thus, if I know one manifestation, I would be 
>>> able to find all other manifestations as well, and the description 
>>> of the work itself. This service and its inbuilt URN-URN linking 
>>> would also make systems resilient in the sense that if the 
>>> resolution service can not locate the manifestation the URN refers 
>>> to, it could still deliver another, more modern manifestation.
>> But in the way you describe it, it seems to be that different URNs 
>> can refer to the same resource. But URNs are *unique* and it won't be 
>> OK, I think, if more than 1 URN refers to the same resource.
>
> (the movie). There may also be different expressions of the Hamlet 
> (the novel), such as translations to Finnish, Russian etc. Each 
> expression will in turn have one or more manifestations, such as (in 
> the case of Hamlet (the novel) hard-cover and paperback book, and 
> electronic versions in e.g. plain text, Word 2003, PDF/A and EPUB.
>
> idea.) AFAIK whenever two manifestations of the same work no longer 
> have the same intellectual content, it becomes vitally important that 
> they do not have the same identifier. And when digital resources are 
> migrated to new file formats, changes in look and feel and eventually 
> also in the actual content are almost inevitable. Over time these 
> changes will probably get more pronounced.
>
> So my view is that each manifestation of a work should have one but 
> only one identifier. When a new manifestation is produced via 
> migration, it should get a new identifier, because migration may have 
> changed the look and feel and/or the content of the resource. So 
> eventually there will be a set of identifiers, consisting of one 
> identifier referring to each manifestation of the work, and probably 
> also one  belonging to the work itself (and its expressions, if any).
I agree with you here. But if you say that we need the identifier for 
each version (or you say 'manifestation') of resource, why do we need 
the generic one?
>
> All manifestations of the same work should be linked to one another 
> and to the metadata record describing the work itself using a 
> persistent identifier, since a user should be made aware of the fact 
> that there are other variants of the work. As long term preservation 
> of digital resources will usually be based on migration strategy, 
> there will eventually be a large number of different manifestations 
> available for each properly preserved work. We have no control over 
> which manifestation the permanent link has been made to. If the linked 
> manifestation is outdated, a user following the link may not be able 
> to use the document with the applications he/she has available; in 
> such a case it is important to know that there are more modern 
> versions available. On the other hand, the user may be a digital 
> archeologist who wants to find the oldest manifestation so as to avoid 
> all the changes migrations have caused to the look and feel and the 
> intellectual content.
Here I agree with you too.
> from new links added whenever there are new manifestations available.
But the question is who will record metadata? Different URN resolution 
services will have different metadata databases. Who or what will 
synchronize them?
>
>>>>>
>>>>> Query and fragment
>>>>>
>>>>> The I-D proposes two different approaches for supporting 
>>>>> <fragment>: individual assignment of fragments on 
>>>>> document-to-document basis, and/or creation of a specific set of 
>>>>> fragment identifiers which are generally applicable to all 
>>>>> resources encompassed by a given URN namespace. Within a namespace 
>>>>> only one of these approaches would be acceptable. While it is 
>>>>> likely that both methods can be applied, we are not sure if these 
>>>>> options are mutually exclusive within one namespace.
>>>
>>> national libraries hold in their collections, which means all kinds 
>>> of published cultural heritage, and even some non-published materials).
>
> We both agree that this kind of random usage of <fragment> would not 
> be sensible.
>
> the namespace registration could / should specify whether fragments 
> are allowed at all, and if they are, how. With more vague namespaces 
> such as for instance NBN it is harder to specify how fragments will be 
> used, since we know neither the syntax of the identifier nor the 
> resources NBNs will be applied to. If RFC2141bis allows the usage of 
> fragments, NBN namespace registration should specify at least in broad 
> terms some principles for the usage of fragments within that 
> particular namespace.
In this case we should define smth like this: "The URN specification MAY 
define the usage of <fragmets>. In this way it SHALL either specify 
their generic syntax or define procedures for assignment fragments to 
segregate resources."

Mykyta Yevstifeyev

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 10 Jan 2011 10:48:56 +0900

Hello Juha, Mykyta,

May I remind you of the basics of fragment identifiers?

The meaning of fragment identifiers, which I would understand to include 
their presence or absence, is determined by the MIME media type of the 
representation returned when resolving an URI. So in general, very, very 
little if anything will be needed in terms of considerations for 
fragment identifiers in URN namespace specs. As for the URN spec itself, 
the most important thing to say is just what's said above.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Juha Hakala <[email-masked]>
Date: Mon, 10 Jan 2011 12:56:53 +0200

Dear Mykyta (and Martin),

See some answers and comments below.

> Please find some comments below.

<snip>

> each version (or you say 'manifestation') of resource, why do we need 

The generic identifier is for the work itself, which library community 
regards to be separate from its physical manifestations. Embodiment of 
the work is a metadata record describing it. There are applications 
which are capable of extracting work level metadata from manifestation 
level records.

As a persistent identifier system URN is in a way in an advantageous 
position compared with for instance DOI and ARK because URN is based on 
existing identifiers (specified as namespaces). Therefore we do not need 
to think the scope of the URN; scope decisions have been made in 
identifier communities. URN does cover books because there is a 
namespace for ISBN, but it does not cover textual works yet since there 
is no namespace for the ISTC (International Standard Text Code).

For the time being none of the ISO work level identifiers (ISWC, ISAN, 
ISTC) have URN namespaces, but IMHO they would qualify. From the point 
of view of the library community tere is a need to identify the work 
itself separately from its manifestations; work level metadata record 
should have a unique access key, and such record is also an ideal place 
for links to all the manifestations related to the work. One might argue 
that if a link has to be really persistent, it should be made to the 
work level metadata record, since such a simple resource we should be 
able to preserve for centuries, and from there there will be links to 
those manifestations that are available at that point of time.

 From the preservation point of view, providing links between works and 
expressions may become useful in the long run (in the national 
libraries, the time scale being centuries, not decades). For instance, 
in a distant future we may no longer have Gone with the wind (the 
movie), but Gone with the wind (the novel) could still give an idea of 
what the movie was about. Or we may not have been able to preserve a 
digital copy of the Finnish translation of the novel, in which case we 
should be able to direct the user to the printed book (another 
manifestation of the resource) or to the original text in English 
(another expression of the work) which may at that point be available in 
the Web.

> services will have different metadata databases. Who or what will 

There is no single answer to this, but for certain kind of resources we 
have candidates. The basic requirement is persistence, not superior 
technical skills.

National libraries are responsible of creating national bibliographies, 
which contain metadata about books, serials, etc published in the 
country in question. This data is routinely shared with other libraries 
and union catalogue hosts. In a few years' time, these (fairly 
persistent) databases will contain work level metadata, linked to the 
manifestation level metadata records.

There are already national libraries applying URNs in their national 
bibliographies and other databases, and the number of libraries using 
them may grow in the future.

There are many URN namespaces which the national libraries are not 
using. These identifier systems may or may not share the "world view" 
the libraries have. URN system as such is flexible and can accommodate 
different approaches. But URN services specified should allow the 
different communities to do the things they need, as long as they are 
not in conflict with URN basics.

> their generic syntax or define procedures for assignment fragments to 

Something like this, yes. We still need to consider how to formulate this.

Martin Duerst said:

> The meaning of fragment identifiers, which I would understand to include their presence or absence, is determined by the MIME media type of the representation returned when resolving an URI. So in general, very, very little if anything will be needed in terms of considerations for fragment identifiers in URN namespace specs. As for the URN spec itself, the most important thing to say is just what's said above. 

I am not sure that this approach is sufficient. When a URN / URI is 
resolved the representation returned may be a complex resource 
consisting of several files in different MIME types, all incorporated 
within a (METS) container. Thus for us a fragment could be a JPEG 2000 
image which is a part of a digitized article which is a part of a serial 
issue which is in its entirety encapsulated in a single METS container.

Best regards,

Juha

-- 

  Juha Hakala

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 24 Jan 2011 05:33:06 +0200

Hello Juha,

Sorry for late answer and find some comments below.

10.01.2011 12:56, Juha Hakala wrote:
>>> migration, it should get a new identifier, because migration may 
>>> have changed the look and feel and/or the content of the resource. 
>>> So eventually there will be a set of identifiers, consisting of one 
> position compared with for instance DOI and ARK because URN is based 
> on existing identifiers (specified as namespaces). Therefore we do not 
> need to think the scope of the URN; scope decisions have been made in 
> namespace for ISBN, but it does not cover textual works yet since 
> there is no namespace for the ISTC (International Standard Text Code).
>
> should have a unique access key, and such record is also an ideal 
> place for links to all the manifestations related to the work. One 
> might argue that if a link has to be really persistent, it should be 
> made to the work level metadata record, since such a simple resource 
> we should be able to preserve for centuries, and from there there will 
> be links to those manifestations that are available at that point of 
> time.
>
> (another expression of the work) which may at that point be available 
> in the Web.
See below.
>
>>> Short lifetime of digital manifestations is a headache for 
>>> persistent linking, when "persistent" means at least several decades 
>>> and often centuries. One solution would be to make the permanent 
>>> link to work / expression; that is, to metadata record which is 
>>> never changed apart from new links added whenever there are new 
>>> manifestations available.
>
>> But the question is who will record metadata? Different URN 
>> resolution services will have different metadata databases. Who or 
>> what will synchronize them?
>
> There is no single answer to this, but for certain kind of resources 
> we have candidates. The basic requirement is persistence, not superior 
> technical skills.
>
> National libraries are responsible of creating national 
> bibliographies, which contain metadata about books, serials, etc 
> published in the country in question. This data is routinely shared 
> with other libraries and union catalogue hosts. In a few years' time, 
> these (fairly persistent) databases will contain work level metadata, 
> linked to the manifestation level metadata records.
>
However if we want to establish the database for URN-referenced 
resources' metalinks, that should be smth. that will have the access to 
all URN-referenced resources and smbd. who should have enough energy to 
perform this type of work.

The national libraries you speak about does not seem to be a candidate 
for synchronizing all the metadata and metalinks of all the resources 
linked to via URNs.  And I can hardly imagine that some organization 
will perform this work in the nearest future.  Therefore, despite this 
idea is quite good and interesting, but not now, IMO.
>
>
>>>>>>> Query and fragment
>
>>> When the namespace belongs to a well-specified standard such as 
>>> ISBN, the namespace registration could / should specify whether 
>>> fragments are allowed at all, and if they are, how. With more vague 
>>> namespaces such as for instance NBN it is harder to specify how 
>>> fragments will be used, since we know neither the syntax of the 
>>> identifier nor the resources NBNs will be applied to. If RFC2141bis 
>>> allows the usage of fragments, NBN namespace registration should 
>>> specify at least in broad terms some principles for the usage of 
>>> fragments within that particular namespace.
>
>> In this case we should define smth like this: "The URN specification 
>> MAY define the usage of <fragmets>. In this way it SHALL either 
>> specify their generic syntax or define procedures for assignment 
>> fragments to segregate resources."
>
If we consider this appropriate, we will have to modify the URN 
Namespaces IDs registry and add the value 'Use of Fragments/Queries' 
(separately).  And if we do in this way, we should investigate what URN 
namespaces already use these parts.

All the best,
Mykyta Yevstifeyev
>> The meaning of fragment identifiers, which I would understand to 
>> include their presence or absence, is determined by the MIME media 
>> type of the representation returned when resolving an URI. So in 
>> general, very, very little if anything will be needed in terms of 
>> considerations for fragment identifiers in URN namespace specs. As 
>> for the URN spec itself, the most important thing to say is just 
>> what's said above. 
>
> image which is a part of a digitized article which is a part of a 
> serial issue which is in its entirety encapsulated in a single METS 
> container.
>
> Best regards,
>
> Juha
>>
>> Mykyta Yevstifeyev
>>>
>>> Juha
>>
>>
>