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

From: Juha Hakala <[email-masked]>
Date: Thu, 23 Dec 2010 11:48:49 +0200

Hello all,

What follows is a partial commentary of the latest version of 
RFC2141bis, concentrating on those aspects of the document which are 
relevant for the project PersID (www.persid.org). PersID is an "emerging 
international effort to establish a general, distributed, stable URN 
resolution service" (see chapter 1.3 of the I-D) and therefore PersID 
members like The National Library of Finland are well positioned to 
provide comments to both RFC2141bis and RFC3046bis.

The project may provide its own feedback later. The views expressed 
below have not been endorsed by the initiative.

Properties of URNs

Listing the past requirements for URNs from RFC 1738 is a good idea, but 
since that RFC was written, things have developed a little bit, and RFC 
2141bis could provide some reservations and additional requirements. For 
instance:

Human transcribability: while I agree that humans should be able to 
understand URNs, the URN system is at mercy of identifier systems which 
have URN namespaces. Since URN can not influence existing and future 
identifiers in this respect, it is pointless to mention this aim. ISTC 
(International Standard Text Code) will be very hard for the humans to 
remember, also when it used as URN.

Service friendliness: It should be possible to use URNs to transmit 
resolution service related parameters in such a way that these 
parameters can be separated from the actual identifier both by human and 
machine users of the system.

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.

Query and fragment

 From the PersID point of view, both <query> and <fragment> are vitally 
important. We support the idea of reserving <query> for the transfer of 
service parameters as a part of the resolution process. There is also a 
need to use <fragment> in the NBN namespace, and we believe that there 
are other namespaces which will benefit from this feature as well.

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.

Namespace identifier syntax

In order to avoid confusion, the NID "urn" must not be used. For the 
same reason, NIDs "url" and "urc" could also be permanently reserved.

Either RFC2141bis or RFC3406bis should recommend that if a standard 
identifier has a well known acronym such as ISBN or ISSN, then this 
acronym should be used as the NID for this identifier. Moreover, known 
identifier acronyms should not be assigned as NIDs to other identifiers.

Either RFC2141bis or RFC3406bis could recommend that NIDs, if possible, 
should be human readable and understandable. Intentionally confusing 
NIDs such as ones based on already existing NIDs (e.g. ISBN2) should be 
forbidden or at least strongly discouraged.

NSS syntax

AFAIK & and ~ can be allowed. But the I-D should make it clear that the 
rules applied in a namespace can be either more restrictive than the NSS 
syntax allows, or more liberal, depending on the identifier system the 
namespace belongs to. In the latter case such strings must be translated 
into canonical NSS format, as already made clear in the I-D. In the 
former case no action is required beyond specifying in the namespace 
registration the characters used in the identifier system.

Season's greetings,

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, 23 Dec 2010 11:15:12 +0100

On 23.12.2010 10:48, Juha Hakala wrote:
> ...
> ...

Be careful with that.

Fragments are defined in Section 3.5 of RFC 3986, and specifically it says:

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

In particular, funny things may happen if you hardwire fragment 
semantics now, and then make something resolvable later on.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 23 Dec 2010 13:07:05 +0200

Hello all,

23.12.2010 11:48, Juha Hakala wrote:
> relevant for the project PersID (www.persid.org). PersID is an 
> "emerging international effort to establish a general, distributed, 
> stable URN resolution service" (see chapter 1.3 of the I-D) and 
> therefore PersID members like The National Library of Finland are well 
> positioned to provide comments to both RFC2141bis and RFC3046bis.
>
> Listing the past requirements for URNs from RFC 1738 is a good idea, 
> but since that RFC was written, things have developed a little bit, 
> and RFC 2141bis could provide some reservations and additional 
> requirements. For instance:
>
> understand URNs, the URN system is at mercy of identifier systems 
> which have URN namespaces. Since URN can not influence existing and 
> future identifiers in this respect, it is pointless to mention this 
> aim. ISTC (International Standard Text Code) will be very hard for the 
> humans to remember, also when it used as URN.
And the same is with ISBN and ISSN numbers, I think. So is there the 
need for such NIDs if they do not conform the 'Human transcribability' 
rule? Or there is no need for such rule?
> parameters can be separated from the actual identifier both by human 
> and machine users of the system.
>
> 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.
> important. We support the idea of reserving <query> for the transfer 
> of service parameters as a part of the resolution process. There is 
> also a need to use <fragment> in the NBN namespace, and we believe 
> that there are other namespaces which will benefit from this feature 
> as well.
>
> 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.
> same reason, NIDs "url" and "urc" could also be permanently reserved.
As for this, I also propose to reserve the 'example' NID as well as 
'iri' one. So that we could have the following NIDs reserved: 'urn', 
'url'. 'urc', 'uri', 'iri', and 'example'. That would be OK, IMO. 
Nevertheless, I think we should provide clear registration template for 
such NIDs, like it is made for 'example' URI scheme.
> identifier acronyms should not be assigned as NIDs to other identifiers.
Such assignments will be exactly discarded by IESG and there is no need 
to mention such points in the guidelines for registration.
>
> Either RFC2141bis or RFC3406bis could recommend that NIDs, if 
> possible, should be human readable and understandable. Intentionally 
> confusing NIDs such as ones based on already existing NIDs (e.g. 
> ISBN2) should be forbidden or at least strongly discouraged.
The same as above.
>
> NSS syntax
>
> AFAIK & and ~ can be allowed. But the I-D should make it clear that 
> the rules applied in a namespace can be either more restrictive than 
> the NSS syntax allows, or more liberal, depending on the identifier 
> system the namespace belongs to. In the latter case such strings must 
> be translated into canonical NSS format, as already made clear in the 
> I-D. In the former case no action is required beyond specifying in the 
> namespace registration the characters used in the identifier system.
>
> Season's greetings,
>
> Juha
Best regards,
Mykyta Yevstifeyev

---

From: Juha Hakala <[email-masked]>
Date: Thu, 23 Dec 2010 14:13:43 +0200

Hello Mykyta,

Thank you for this. There are a few comments below.

> rule? Or there is no need for such rule?

There is no need for such rule. We cannot assign URN namespaces only to 
those identifiers which are human transcribable (whatever that means; I 
might argue that at least librarians can understand ISBNs), or prefer 
such identifiers over those that are not, such as ISSN.

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

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

> 'url'. 'urc', 'uri', 'iri', and 'example'. That would be OK, IMO. 

OK.

> such NIDs, like it is made for 'example' URI scheme.

Can you tell a little bit more about this?

> to mention such points in the guidelines for registration.

I agree that is more or less certain that IESG would do this (provided 
that they are aware of a conflict, but if we make the RFC more 
informative, some people might not even attempt to "intrude".

The problem with NIDs is that once they have been assigned, they can 
never be re-assigned. Domain names are for sale, and many names (such as 
nokia.com) that were initially reserved by "wrong" organisations, have 
been passed to their rightful owners. With NIDs no such corrective moves 
are possible, at least not after the first URNs have been assigned. If 
and when the URBN system becomes popular, NID assigment becomes a 
critical point and we need to be careful of what we say about it in the 
RFCs.

> The same as above.

Yes :-).

Best regards,

Juha

-- 

  Juha Hakala

---

From: Juha Hakala <[email-masked]>
Date: Thu, 23 Dec 2010 14:48:49 +0200

Hello Julian,

Please find comments below.

> semantics now, and then make something resolvable later on.

It is difficult to discuss the usage of fragments in an abstract manner. 
  There are definitely "wrong" ways in which to use them, and quite 
likely also some that make sense.

In my library, there has been discussions of how to provide identifiers 
to digitised serials. In our case, each serial issue is stored in its 
own METS container. Currently we give separate URN:NBNs to the issue 
(full text of which is included in METS/ALTO), and each article in the 
issue (if they have been made explicit in the encoding), and each image 
in these articles. The users will be able to provide persistent links to 
all these resources (the issue, the articles in it, and all the images) 
using URN:NBNs.

In this particular case, I believe that the semantics of fragments is 
fairly well defined and understood & persistent.

Currently we assign each resource a different NBN; in the future 
(RFC2141bis and RFC3188bis allowing) we might have just one NBN (for the 
issue) and fragment identifiers to the articles and images embedded in 
the issue. Whether we go this way or that is not a matter of life and 
death; we can continue the present practice of which requires plenty of 
NBNs since NBNs are free, and we will never run out of them. But there 
may be other URN implementers out there to whom the use of fragments is 
essential.

All the best,

Juha

-- 

  Juha Hakala

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 23 Dec 2010 17:26:21 +0200

Jula,

Some responds to your comments:

23.12.2010 14:13, Juha Hakala wrote:
>>> aim. ISTC (International Standard Text Code) will be very hard for 
>>> the humans to remember, also when it used as URN.
>
>> need for such NIDs if they do not conform the 'Human 
>> transcribability' rule? Or there is no need for such rule?
>
> There is no need for such rule. We cannot assign URN namespaces only 
> to those identifiers which are human transcribable (whatever that 
> means; I might argue that at least librarians can understand ISBNs), 
> or prefer such identifiers over those that are not, such as ISSN.
>
>>> 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.
>
> 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.
>> 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.
>> Nevertheless, I think we should provide clear registration template 
>> for such NIDs, like it is made for 'example' URI scheme.
>
What I propose is to make separate (or include in this one) document 
specifying reserved NIDs. For instance,

Namespace ID: urn
Registration Information: [relevant]
Declared registrant of the namespace: [relevant]
Declaration of syntactic structure of NSS part: the 'urn' is reserved 
name for NID and MUST NOT be used in URNs. No syntactic structure is 
specified.
Relevant ancillary documentation: none
Conformance with URN Syntax: the 'urn' is reserved name for NID and MUST 
NOT be used in URNs. As no syntax is specified, no conformance with URN 
syntax is intended.
Rules for Lexical Equivalence of NSS part: none
......
etc.

or smth like this can be written for each (or at least for 'example' 
one) 'reserved' NID so that it will be formally specified and not used 
later.

>>> acronym should be used as the NID for this identifier. Moreover, 
>>> known identifier acronyms should not be assigned as NIDs to other 
>>> identifiers.
>
>> Such assignments will be exactly discarded by IESG and there is no 
>> need to mention such points in the guidelines for registration.
>
> never be re-assigned. Domain names are for sale, and many names (such 
> as nokia.com) that were initially reserved by "wrong" organisations, 
> have been passed to their rightful owners. With NIDs no such 
> corrective moves are possible, at least not after the first URNs have 
> been assigned. If and when the URBN system becomes popular, NID 
> assigment becomes a critical point and we need to be careful of what 
> we say about it in the RFCs.
For that there is IESG. There are good and qualified people there and I 
believe they will prevent really incorrect NID names to be assigned.
>>> system the namespace belongs to. In the latter case such strings 
>>> must be translated into canonical NSS format, as already made clear 
>>> in the I-D. In the former case no action is required beyond 
>>> specifying in the namespace registration the characters used in the 
>>> identifier system.
>>>
>>> Season's greetings,
>>>
>>> Juha
>> Best regards,
>> Mykyta Yevstifeyev
>>
>
All the best,
Mykyta Yevstifeyev

---

From: "Emanuele Bellini" <[email-masked]>
Date: Thu, 23 Dec 2010 18:36:31 +0100

Dear Juha,
On the first impression, we agree with your suggestions about the use of fragment in URN. We think that the definition of the fragment in persistent identifiers opens interesting scenarios in scientific and cultural heritage domains. In fact, the evolution of the content production goes towards the integration of cross media resources in a complex (or compound) digital object. Examples are MPEG21, SCORM, FEDORA and METS containers.
Up to now the best practise in PI assignment is to generate a new identifier for each resource (the same vision was applied in PersID project), but in the close future can be crucial to identify the part of this resource. For instance a PhD thesis can be composed by text, video, sound, images, etc. 
>From this point of view, can be useful to cite or retrieve (with the resolution process) only a single part of these object.

In this case the common definition that a PI has to be assigned to atomic information significant in that domain, has to be partially revised.

Emanuele Bellini

Fondazione Rinascimento Digitale
www.rinascimento-digitale.it
[email-masked]

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Juha Hakala
Inviato: giovedì 23 dicembre 2010 13:51
A: Julian Reschke
Cc: [email-masked]
Oggetto: Re: [urn] fragment identifiers,Re: Comments to the draft-ietf-urnbis-rfc2141bis-urn-00.txt

Hello Julian,

All the best,

Juha

-- 

  Juha Hakala

  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
_______________________________________________
urn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/urn