Re: [urn] Talking about fragments in URNs

[Sean Leonard <[e-mail]>]

On 6/29/2016 12:56 AM, Hakala, Juha E wrote:
> Hello Sean; all,
>
> some comments below.
>
>> -----Original Message-----
>> From: urn [mailto:[e-mail]] On Behalf Of Sean Leonard
>> Sent: 29. kesäkuuta 2016 9:54
>> To: [e-mail]
>> Subject: Re: [urn] Talking about fragments in URNs
>>
>> On 6/28/2016 10:39 PM, Hakala, Juha E wrote:
>>> Hello,
>>>
>>> there are at least four different aspects of equivalence or "naming the
>> same thing".
>>> [...]
>> 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.
> 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.
>
>> 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 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.
>   
>> 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).
> 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.

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.

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

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