Re: [urn] New urns-are-not-uris draft

[Juha Hakala <[e-mail]>]

Hello,

On 6.7.2014 19:43, John C Klensin wrote:
>
> --On Sunday, 06 July, 2014 02:14 +0000 Larry Masinter
> <[e-mail]> wrote:
>
>
>> ===============
>> It isn't true that ISBN numbers never change. They change
>> rarely, perhaps. A primary use  of ISBN was as bookstore stock
>> and pricing unique key. So if a book is printed with multiple
>> color covers, they might use the same ISBN number. New
>> printing, perhaps a minor printing flaw fixed, ditto. The
>> permanence and meaning of this kind of identification for
>> documents will change even further.
> Based on reading the standard (have you done that?) and a few
> discussions with the registration agency, I think your
> interpretation above is wrong or at least misleading.  But that
> is not an area where I claim expertise so I'll let others debate
> it with you if they are so inclined.  A few of your comments
> below been elided.  I hope others with more in-depth expertise
> will respond to them, especially if they believe the topics have
> not been adequately covered already.

I was a member in the working group which wrote the current version of 
the standard.

ISBN Manual 
(https://www.isbn-international.org/sites/default/files/ISBN%20Manual%202012%20-corr.pdf) 
and the standard itself provide detailed guidelines on how to apply 
ISBNs. Every well managed identifier system should have published 
guidelines document.

An ISBN which has been assigned to a book will never change. The ISBN of 
Food composition data interchange handbook published by United Nations 
University in 1992 is and will always be 92-808-0774-9. This ISBN will 
never be reused (assigned to another book) and this version of the 
handbook will never get another ISBN.

Chapter 5 of the ISBN manual (Application of ISBN) says that if there 
are no changes to the content and physical form (or if just some 
misprints are fixed), the same ISBN can still be used for reprint. But 
if there are substantial changes to the intellectual content, new ISBN 
is required. ISBNs are usually accompanied with detailed metadata which 
describes the difference between two editions (e.g. 2nd, revised ed.).

Had the Food composition data interchange handbook been published in 
different formats (hardback, paperback, PDF and so forth) each one of 
them would have received its own ISBN.

ISBN community, like other communities using traditional identifiers, 
does not need URNs to extend the scope of the existing identifier system 
or to change its current identifier assignment policy. URNs are needed 
mainly in order to make the existing identifier systems actionable in 
the Internet. Theoretical discussion in this list on the principles of 
naming / identification has therefore not been particularly helpful.

Whether the current principles for assigning ISBNs are correct from IETF 
point of view (whatever that means), or the fact that it is possible to 
misuse ISBNs (some publishers especially in the U.S.A. would like to 
give the same ISBN to all digital versions of a book) is, IMO, not 
something that needs to be discussed in URNBIS / IETF. IETF does not 
have a mandate to change the policy of ISBN assignment. And there are 
other URN namespaces out there which are more problematic than URN:ISBN 
from management point of view.

>
> In particular, your excerpts from what is now Section 3 are
> about text for which Juha provided that starting point and that
> has been, IMO, extensively discussed on-list.  If he tells me
> that I misinterpreted his intent, I will be happy to revise as
> needed (also, of course, if Andrew tells me the WG consensus is
> different).

No, John has interpreted my intent correctly.

>   But, unless you are ready to engage with his
> position, and, IMO, do so with equal experience and authority,
> repetition of the same assertions this just leads us in circles.
>
>> Not every blog post gets
>> its own identifier, with many information tools, 'location' is
>> meaningless. You may think this is a minor point or these are
>> corner cases, but I think they're central. The well-ordered
>> world wished for isn't there.
> I think that may be true but is certainly irrelevant.  See
> above... and Juha's repeated comments about managed processes.

The world as a whole is not well-ordered, but there are parts of it 
which are reasonably well managed and orderly. And it is in these well 
managed parts of the world where URNs and other persistent identifiers 
are most urgently needed. If there is no requirement to preserve a 
document for long term (beyond the life time of technologies such as 
HTTP) then even protocol dependent and un-managed "identifiers" may be 
sufficient.

A blog post in the web is not persistent, but a blog post harvested into 
the national library's web archive will be preserved for long term, and 
is likely to receive a persistent identifier as well.

Juha
>
>> The document consistently attributes to "all URIs" properties
>> that are only true of a few URI schemes. There are plenty of
>> name-like URLs that are not URNs, tag:, data:, uuid: and many
>> others.
> The "all URIs" problem is a consequence of the language of 3986
> (on which I note your name appears) and not the present document.
>
>> Comments linked to the text:
>>
>> # 1. Introduction
>> The names of categories of identifiers "name-type" and
>> "location-based" are design concept ideas and not properties
>> of the identifiers themselves.
>>
>> # "Impractical to constrain URNs to syntax and high-level
>> # semantics of URLs"
>> What constraints there are can changed  without seceding URNs
>> from the URI union. As far as I can tell, the only syntactic
>> changes wanted is to allow "#" for fragments and "/" for
>> hierarchy. If this is necessary it might require an update.
> Other changes may be needed - see the document at -01 and the
> correspondence on the list.  More important, my opinion (perhaps
> wrong) and that of Barry and Pete (unless I've misunderstood) is
> that there is insufficient energy in the IETF to undertake a
> 3986bis, or even a substantive and detailed update, and more it
> to completion in a reasonable amount of time.  The separation
> model is just a pragmatic way to work around that problem
> without holding the work of the URN WG up for an additional
> extended period -- and allowing the odds of a fork in the
> standard by another body that doesn't need to debate these
> niceties of definition to rise considerably.
>
>> # "Generalization ... has failed ..."
>> I don't see any use cases where splitting URNs from URIs
>> reduces failure. If there are  failures, they are intrinsic.
> The failure is to come up with a syntax and set of semantics for
> URNs that meet the perceived needs of the important parts of the
> URN community without violating the constraints of 3986.  I
> thought that was clear; if not, I apologize and will make
> another pass through the draft.
>
>> # "... are simply different creatures ..."
>> The boundary between locator and name is completely blurred
>> and there are endless examples where the pun is a fundamental
>> feature: that the same URI functions as a name in some
>> contexts and a location in others.  XML namespaces are a clear
>> instance where both http and urn URIs are used uniformly.
> See prior comments (above and on the list) about the perceived
> needs of legitimate and experienced communities.   You, of
> course, get to disagree, but that doesn't seem to affect their
> perceptions.  And, again, the IETF gets to either adapt or risk
> (I believe "guarantee", but could be wrong) an externally-forked
> standard.  This is not an instance where the IETF gets to say
> "no, you shouldn't do that, or believe that, so don't" and
> expect an established community with centuries of experience to
> pay any attention.
>
>> ...
> best,
>     john
>
> _______________________________________________
> urn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. [phone]
  Mobile [phone]