Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Apr 25, 2014 at 4:41 PM, Dale R. Worley <[e-mail]> wrote:
>> From: Larry Masinter <[e-mail]>
>>
>> "data:" URLs don't have DNS names and aren't URNs.
>
> Ooooh, that's a fascinating example!
>
> One can consider a "data:" URI to be a URL, since it provides a way to
> locate the referenced information (i.e., parse the URI).  Nonetheless,
> it does not contain a DNS name or any other identifier of a network
> resource.
>
> And yet it's also a URN, because it is a persistent identifier of the
> referenced information -- the association of the URI with the
> referenced information never changes!

What you seem to be implying is that the term 'name' be defined by
whether or not it meets the requirements for persistence. That is a
terrible way to approach nomenclature.

The whole URN fiasco has been flawed from the start because names are
not persistent by their very nature. Names are in fact the LEAST
persistent type of identifier.

I remember back in the day when some AI people misread some books on
hermeneutics and started talking about 'ontologies'. Many people
reading this are aware of the AI definition which is essentially a
sort of shared vocabulary of terms. But in philosophy an ontology is a
system of being. We are beyond mere epistemology and into considering
the nature of existence and being.

Yes there are passages in Heidegger that can support the idea that a
being is an intersubjective shared framework of communication. But
relying on Heidegger for definitions is always a mistake: His
significance lies in the novelty of his work rather than the clarity.


Again, there is a very longstanding literature in semiotics. If people
want to use terms like 'name' I suggest that they stick to existing
definitions rather than invent new ones.

At the very least we should agree that the term 'name' has an ordinary
meaning and that meeting or failing to meet some requirements that
might somehow be defined in an RFC is not a proper test of whether
something is a name or not.

The term name already has a definition in the IETF, that is why it is
called the Domain NAME System and not the Domain Locator System.


John did complain about a 'my way or the highway' attitude. Well on
this I am completely right and there is no room for argument: DNS
labels are NAMES sand anyone who wants to argue with that proposition
needs to be given a copy of Heidegger and a loaded pistol.

data URIs are not names, they are data.

If we convert from the semiotics terminology of 'signifier'
'signified' to labels and resources we get:

Type 1: Data :  The label is the resource value

Type 2: Index : The label is a deterministic function of the resource value

Type 3: Name : The relationship between the label and the resource is
determined by convention


Note here that the terms Data and Index are constructed in such a
manner that the resource is static, only a name can bind to a dynamic
resource. It follows that all URLs are names.


The reason that this URN thing takes so long is that people are
insisting on bad terminology which is fundamentally confused.

The term name does not imply persistence. It implies the very
opposite. We could have a useful discussion of persistent versus
ephemeral names. Larry's dated URIs are an example of persistent names
(as are John Mallery's Persistent Document Identifiers from 1994). But
equating name = persistent name is to commit to a fallacy.


In conclusion:

* The taxonomic distinction between URLs and URNs is meaningless. URLs
== URNs for all practical purposes. The people who attempted to make
the original distinction did not know what they were doing and they
still don't.

* No more URN requirements documents. If people want persistent
identifiers then they can write up a draft of requirements for
persistent identifiers. There is no point in having a requirements
document for a term introduced 20 years ago.

* Rather than discussing persistence as a binary quality, we should
treat it like we treat security and ask 'how much'.


-- 
Website: http://hallambaker.com/