Subject: [urn] Talking about fragments in URNs

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Jun 2016 11:05:30 -0400

As I'm trying to catch up on the many long messages in the various
discussions, I'm seeing issues that seem related to how we're talking
about some of this stuff, and that appears to be getting in the way of
understanding and coming to agreement.  So let me babble for a moment:

As we're talking about naming things -- URNs are names -- we mix in
issues of locating them, finding them, and other such terminology that
gets in the way.  In reading a conversation between Juha and Julian, I
was struck by things of this sort (from that thread):

>> urn:isbn:<isbn>#chapter1
>> urn:isbn:<isbn>#chapter1para1
>> urn:isbn:<isbn>#chapter1para1line1
>> urn:isbn:<isbn>#chapter1para1line1word1
>> urn:isbn:<isbn>#chapter1para1line1word1letter1
>>
>> According to the rfc2141bis, all these URNs are equivalent (they identify
>> the same book, and only that), but they indicate different locations within
>> the first chapter of the identified book. Anyone could create these URNs
>> once the national library has established the base URN. This is not a
>> mandate problem since fragments have no role in identification.
>
> Wow, they are *equivalent*, but indicate *different* locations? That's IMHO
> a very very surprising definition of equivalence. It probably would be good
> to use a more specific term.

Setting aside, for the moment, whether fragments make sense within the
ISBN namespace, I think it's important for us to understand what's
being named (or identified, if you prefer) by

   urn:isbn:<isbn>

...and by

   urn:isbn:<isbn>#chapter1

...and I suggest that (1) they're not identifying the same thing, but
(2) what they're identifying is related, and (3) none of this has
anything to do with locating the entity that's been named, nor how
that might happen.

The first is identifying, say, a book.  Specifically, a given edition
of a book, from a specific publisher.

The second is identifying the first chapter of that editing of that
book from that publisher.

Yes?

When Juha says they're "equivalent", he means that they refer to the
same book, but he doesn't mean that the URNs are truly equivalent.
When Julian says "wow, equivalent?", he questions where the
equivalence stops.  We're being imprecise, and it's getting in our
way.

And I think that's happening because we, naturally, keep thinking in
terms of going and finding the thing that's named, rather than staying
with the idea that these are abstract names.

Will it help, maybe, if we're clear that when we talk about URNs,
we're talking purely about names for things, and that anything related
to how to use that name to actually *find* the things is a separate
question?  And then try hard to keep our language in terms of the
names only?

Barry

---

From: Sean Leonard <[email-masked]>
Date: Fri, 3 Jun 2016 12:40:53 -0700

> question?  And then try hard to keep our language in terms of the

+1000

We (well, you and I) are in agreement.

We can start with agreeing to call "URN equivalence" something more 
precise. See my posts around 5/3/2016:

http://mailarchive.ietf.org/arch/msg/urn/936s5wvwAsXB8ih3fP-EhBjBSKw

"Name the Same Thing"

Best regards,

Sean

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Jun 2016 18:14:46 -0600

> http://mailarchive.ietf.org/arch/msg/urn/936s5wvwAsXB8ih3fP-EhBjBSKw

Juha has previously mentioned examples of two URNs from different 
namespaces (ISBNs and ISSNs) that name the same thing, i.e., the same 
publication. Irrespective of how one would find that publication based 
on the different namespaces (e.g., separate lookup services for ISBN and 
ISSN), he believes that the two URNs name the same thing. However, as 
far as I can see such a concept of naming the same thing cannot be 
captured in a form that can be processed by a machine; relatedly, it is 
not at all what we mean by URN equivalence, which is closer to what I 
think Barry means when he talks about "abstract names". Because I don't 
see any possible engineering solution to this problem, I would prefer 
that we not try to solve it.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jun 2016 20:47:07 -0400

--On Tuesday, June 28, 2016 18:14 -0600 Peter Saint-Andre
<[email-masked]> wrote:

>...

>> "Name the Same Thing"
> 
> Juha has previously mentioned examples of two URNs from
> different namespaces (ISBNs and ISSNs) that name the same
> thing, i.e., the same publication. Irrespective of how one
> would find that publication based on the different namespaces
> (e.g., separate lookup services for ISBN and ISSN), he
> believes that the two URNs name the same thing. However, as
> far as I can see such a concept of naming the same thing
> cannot be captured in a form that can be processed by a
> machine; relatedly, it is not at all what we mean by URN
> equivalence, which is closer to what I think Barry means when
> he talks about "abstract names". Because I don't see any
> possible engineering solution to this problem, I would prefer

This is a different type of "equivalence", associated with the
principle that two identifiers (URI or otherwise) can be
considered equivalent if they both result in retrieval (or
equivalent) of an object (or "representation") and the objects
("representations") obtained are "the same".  Note that the
first definition of "equivalence" in RFC 3986 (see the first
sentences of Section 6.1, whether it is "of practical use" or
not).

I hope that the new (and I hope consistent) use of "URN
equivalence" in 2141bis gets us around any issues that "same
object equivalence" or "3986 equivalence" might cause.

best,
    john

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 29 Jun 2016 05:39:44 +0000

Hello,

there are at least four different aspects of equivalence or "naming the same thing". 

1. The simplest case is the one that can be determined just by parsing two identifier strings and determine on the basis of equivalence rules if these identifiers are equivalent. In the case of URN, such equivalence rules may exist on both the namespace level and on the URN syntax level. 

For instance, there are two versions of ISBN, ISBN-10 and ISBN-13. ISBN-10s can be migrated into ISBN-13s. For someone who does not know how that is done, the relation between the source and target ISBN:s may not be obvious. For instance, these ISBNs are equivalent (they identify the same book):

ISBN 0-393-04002-X
ISBN 978-0-393-04002-9

Note that neither the hyphens nor "ISBN" (which is only required when ISBNs are expressed in human readable form) are not taken into account when equivalence is determined. X in ISBN-10 is case insensitive (but should always be shown as capital X). 

When we apply URN syntax equivalence rules on this, we can say that for instance these URNs are equivalent. 

urn:isbn:0-393-04002-X
URN:ISBN:978-0-393-04002-9 

2. Second case is partial of complete semantic equivalence with respect to what has been identified within a single URN namespace. This depends on the identifier assignment rules applied in URN namespaces, and the URN system / syntax cannot change these rules which in some cases have been in production for decades.  

For instance, ISBN standard says that 

"Different product forms of a publication where these are made separately available shall be assigned separate ISBNs."

This means that the same work, when published in different forms, shall have different ISBNs. So if we consider intellectual content identified only, we may say that the ISBNs given to for instance printed and audio versions of Nick Bostrom's book Superintelligence are semantically equivalent. One might even argue that the German and Chinese translations of the book to some extent equivalent to the original as well. However, this is not what the ISBN community does.  

ISBN standard also says that:

"An ISBN should be assigned to the complete set of volumes where a publication comprises more than one
volume. If individual volumes of the set are also available separately, then each volume shall be assigned its
own unique ISBN. The title page verso of the individual volume shall state the ISBN for the respective volume
and should also state the ISBN for the set."

So there can be partial equivalence between ISBNs in the sense that one ISBN identifies all parts of a PDF version of The Lord of the Rings, whereas other ISBN applies just to the second part. 

This kind of equivalence can never be determined just by parsing either the namespace specific string or the entire URN. But many applications such as library systems contain resource related metadata with which this kind of semantic equivalence can be determined. Smart algorithms have been developed by libraries to extract work descriptions from existing manifestation metadata. These algorithms can be said to analyze semantic equivalence between ISBNs since they bring together all versions (and translations) of works such as the Bostrom's book mentioned above. So there is an engineering solution, but it is not and it will never be based on the identifier only. If we want to mention this issue in the URN syntax document, we can say that a URN namespace may apply namespace specific algorithms and external metadata to determine whether two URNs from than namespace are semantically equivalent and the nature of such equivalence (partial or complete).  

3. It is possible to have URNs from 2-n namespaces to identify the same resource. For instance, a book published in monograph series may have both ISBN and ISSN. This kind of equivalence may also be determined with the help of metadata related to the resource, but the results may be less reliable than in the second case since rules applied in different namespaces may be incompatible. 

There will be a lot of partial equivalences: for instance, a digitized book may have an URN:ISBN, but every image in the book may have its own URN:NBN.  

4. Fourth case of equivalence may exist between identifiers in different persistent identifier systems. For instance, we may have both a DOI and an URN identifying the same book, and therefore based on the same ISBN. Again, it is not obvious to a machine (or to most humans) that e.g. these identifiers are identifying the same resource: 

ISBN 1-2345-9999-X
DOI 10.978.12345/99990 
URN:ISBN:978-1-2345-9999-0

The difference between these identifiers is functional: plain vanilla ISBN-10 is not actionable in the Internet; the DOI and URN may be, but at least initially in a different way. DOI would probably be resolved by the publisher or other party which has rights to disseminate the book; URN would be resolved by the national library. After a while, when the copyright has expired (that is, 70 years after the death of the author) there may no longer be any commercial interests and both persistent identifiers may resolve to a copy of the resource in the national library's deposit collection. 

IMO there is no need to discuss the implications of this kind of equivalence in the URN syntax document. We may mention it in passing, though, by saying for instance that persistent identifier systems are not mutually exclusive; a resource may have 1-n PIDs which may support different resolution services. 

Best regards, 

Juha 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: 29. kesäkuuta 2016 3:47
> To: Peter Saint-Andre <[email-masked]>
> Cc: [email-masked]; Barry Leiba <[email-masked]>
> Subject: Re: [urn] Talking about fragments in URNs
> 
> 
> 
> > on the different namespaces (e.g., separate lookup services for ISBN
> > and ISSN), he believes that the two URNs name the same thing. However,
> > as far as I can see such a concept of naming the same thing cannot be
> > captured in a form that can be processed by a machine; relatedly, it
> > is not at all what we mean by URN equivalence, which is closer to what
> > I think Barry means when he talks about "abstract names". Because I
> > don't see any possible engineering solution to this problem, I would
> > prefer that we not try to solve it.
> 
> This is a different type of "equivalence", associated with the principle that
> two identifiers (URI or otherwise) can be considered equivalent if they both
> result in retrieval (or
> ("representations") obtained are "the same".  Note that the first definition
> of "equivalence" in RFC 3986 (see the first sentences of Section 6.1, whether
> it is "of practical use" or not).
> 
> I hope that the new (and I hope consistent) use of "URN equivalence" in
> 2141bis gets us around any issues that "same object equivalence" or "3986
> equivalence" might cause.
> 
> 
> best,
>     john
> 
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: Sean Leonard <[email-masked]>
Date: Tue, 28 Jun 2016 23:54:25 -0700

On 6/28/2016 10:39 PM, Hakala, Juha E wrote:
> [...]

Thank you, Juha, for that.

Upon reading the responses, I revise my proposal of "Name the Same 
Thing". It appears that "NtST" means or can be implied to mean "semantic 
equivalence", which is not what we are going for.

I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly opposed 
to the term "URN equivalence". The term is confusing and adds little 
value. Even very intelligent people can't tell if the q-, r-, and 
f-components are supposed to be included in the comparison or not.

Honestly, I don't see why we got away from the term used by Section 5 of 
RFC 2141, "lexical equivalence". Folks, that is what we have been 
talking about all along.

Lexical def.:
http://www.dictionary.com/browse/lexical?s=t
1. of or relating to the words or vocabulary of a language, especially 
as distinguished from its grammatical and syntactical aspects.
2. of, relating to, or of the nature of a lexicon.
=> Lexicon def.:
1. a wordbook or dictionary, especially of Greek, Latin, or Hebrew.
[...]
3. inventory or record.

***
That is what we are talking about. A namespace is an "inventory" (or 
"dictionary") of names. Each name is different. But some names can be 
written in a plurality of ways but still be the same name. Tomatoes and 
tomatos are the same fruits (tomato is a fruit, in case you were wondering).

It appears that the term "lexical" got dropped between draft-05 and 
draft-06:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-urnbis-rfc2141bis-urn-06.txt

for reasons unbeknownst to me...but as Peter Saint-Andre and Ryan Moats 
were the editor/author at the time, I would like to ask (respectfully 
and politely), "why?"

Let's bring back "lexical equivalence", and call it a kind of 
scheme-specific comparison (Section 6.2 of RFC 3986).

Another verbal formulation is "two URNs have the same name" (HtSM). This 
formulation is interchangeable with "lexical equivalence", just in a 
different part of speech.

Regards,

Sean

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 29 Jun 2016 07:15:30 +0000

Hello, 

some additional comments about equivalence. 

> >> equivalence stops.  We're being imprecise, and it's getting in our

It is natural for the people with IETF background to see equivalence from technical (RFC 3986) point of view. And it would be easy if we could just parse two URN strings and always make a decision based on that. IMO chapter 3.1 in RFC2142bis provides clear guidelines for doing that. 

But it is important to keep in mind what the last paragraph in 3.1 says: URN namespaces MAY include additional rules for URN equivalence. And it is actually much more complicated than that; it is possible to analyze resource metadata to determine if two URNs from different namespaces or even two PIDs from different PID systems are equivalent in the sense that they identify the same thing. 

We can only be precise if we stick to the procedure in chapter 3.1, illustrated with examples in chapter 3.2. Trying to provide anything like an all-encompassing description of equivalence in the URN context is impossible since each namespace has its own practices which may be difficult to understand to the non-initiated. Such practices have an impact on the URN syntax only when dictating something on the URN side would have a negative impact on existing identifiers. For instance, insisting that fragments do identify something would not go down well in the ISBN community.   

> >> terms of going and finding the thing that's named, rather than
> >> staying with the idea that these are abstract names.
> >> we're talking purely about names for things, and that anything
> >> related to how to use that name to actually *find* the things is a
> >> separate question?  And then try hard to keep our language in terms
> >> of the names only?

The community I represent identifies resources like books using principles which were carved in stone long time ago, and URN is interesting to us primarily because it can make the existing identifiers actionable in the Internet. We do not need to specify resolution services and their technical implementation in RFC 2141bis, but syntax must allow us to do that later on. R- and q-components should satisfy that need.   

> > precise. 

AFAIK the current version of RFC 2141bis gives good guidelines for checking if two URN strings are equivalent in the strict sense of the word. This is all URNbis needs to do (if we also say that namespaces may have their own rules). Determining whether two URNs from the same/different namespaces are equivalent in the broader sense that they identify the same thing is far more difficult and requires deep understanding of the namespace used. This is and should be beyond the scope of RFC 2141bis, as is any guidelines for checking of whether two different PIDs identify the same resource. 

Juha     

See my posts around 5/3/2016:
> publication. Irrespective of how one would find that publication based on the
> different namespaces (e.g., separate lookup services for ISBN and ISSN), he
> believes that the two URNs name the same thing. However, as far as I can
> see such a concept of naming the same thing cannot be captured in a form
> that can be processed by a machine; relatedly, it is not at all what we mean
> by URN equivalence, which is closer to what I think Barry means when he
> talks about "abstract names". Because I don't see any possible engineering
> solution to this problem, I would prefer that we not try to solve it.

---

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 29 Jun 2016 07:56:49 +0000

Hello Sean; all, 

some comments below. 

> From: urn [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: 29. kesäkuuta 2016 9:54
> To: [email-masked]

Yes. People who actually create URNs must pay attention to semantic equivalence and use the namespace specific rules when they do that. But it is beyond the URNBIS scope to try to tell namespaces what they should be doing. 
> 
> I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly opposed to
> the term "URN equivalence". The term is confusing and adds little value.
> Even very intelligent people can't tell if the q-, r-, and f-components are
> supposed to be included in the comparison or not.

They are not, since then many namespaces would not be able to use them. Including f-component in the comparison would mean for instance an extension to the ISBN scope so that it could be used to identify component parts of books, which is not acceptable to the ISBN community. The problem can be bypassed simply by saying that fragment does not identify anything, which is not compliant with what at least some people think RFC 3986 requires. This dilemma has been solved by making URN palatable to the identifier systems.     

> RFC 2141, "lexical equivalence". Folks, that is what we have been talking
> about all along.

Lexical equivalence might be a better term than URN equivalence, since URN equivalence can be understood to be too broad a concept. For instance, some people may think that URNs based on ISBN-10 and ISBN-13 of the same book are equivalent in the RFC2141bis sense of the word since they identify the same resource. However, these URNs are lexically equivalent only if additional namespace specific rules are applied to detect the equivalence. RFC 2141bis guidelines alone would not be sufficient to detect the equivalence.  
 
> 1. of or relating to the words or vocabulary of a language, especially as
> distinguished from its grammatical and syntactical aspects.

OK, but in lexical analysis we would only be interested in one language at the time. We shall not try to determine anything across languages, for instance to determine if tomato and tomaatti mean the same thing.   

> were the editor/author at the time, I would like to ask (respectfully and
> politely), "why?"
> 
> Let's bring back "lexical equivalence", and call it a kind of scheme-specific
> comparison (Section 6.2 of RFC 3986).

OK, but in order to avoid misunderstandings we should say that lexical analysis is not namespace (identifier) specific but applies to all namespaces, and from RFC 3986 point of view it is scheme specific from URN point of view; not from the point of view of identifier schemes. 

We must also keep the last paragraph of 3.1 which says that namespace definitions may include additional rules for URN equivalence. These rules can be lexical or something else. For instance, ISBN standard says that hyphens must are not part of the ISBN and are only used to improve readability (simple lexical rule) but there is also a complex lexical rule concerning generation of ISBN-13 from ISBN-10, and semantic rules concerning identification of resources. 

Juha 

> Another verbal formulation is "two URNs have the same name" (HtSM).
> This formulation is interchangeable with "lexical equivalence", just in a

---

From: Sean Leonard <[email-masked]>
Date: Wed, 29 Jun 2016 08:37:38 -0700

> OK, but in lexical analysis we would only be interested in one language at the time. We shall not try to determine anything across languages, for instance to determine if tomato and tomaatti mean t…

Yes. Basically the comparison has to be computable offline, via the 
application of an algorithm specified in the namespace registration. And 
you can't try to get around this by registering the entire English and 
Italian dictionaries as part of your algorithm and expect people to 
implement it.

> We must also keep the last paragraph of 3.1 which says that namespace definitions may include additional rules for URN equivalence. These rules can be lexical or something else. For instance, ISBN…

Ok.

It sounds like we now have two votes/opinions in favor of "lexical 
equivalence".

In view of the computability property, it would be desirable for 
namespace registrants to provide a string comparison specification that 
can be compiled directly into a variety of implementations. What are 
standard notations for string comparison specifications? For example, 
rather than just saying in prose: "To compare ISBNs for lexical 
equivalence, you eliminate hyphens and then compare in a case-sensitive 
manner", you should say {elim: "-", compare: "C"}, and then 
copy-and-paste this (or compile this) into your implementation.

Regular expressions sort of fall in this category, but not really. A 
regex can test an arbitrary string against itself, but we want to take 
two strings and compare them in a particular way. This is either called 
normalization, or something like "comparison operation". You can write 
regular expression-based patterns to eliminate characters, e.g., 
s/-//gi, but that is not a true comparison spec, that is a pattern 
substitution spec. I am looking for something like LDAP/X.500 Attribute 
syntax matching rules. A quick Google search did not come up with what I 
was looking for.

Juha brought up this ISBN-10 -> ISBN-13 thing. If the registrant of the 
ISBN namespace wants to provide a complex but still purely "lexical" 
algorithm to generate and compare the two, that is computable, I say it 
is fair game. That is up to the namespace registrant.

Sean