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

[Mark Nottingham <[e-mail]>]

I have to say that I'm sympathetic to the proposed outcomes, albeit for different reasons, perhaps.

We have two communities using a shared artefact (URIs) with vastly differing use cases and viewpoints about them. Managing this situation has already proven extremely difficult for the IETF, and it seems to me to be very pragmatic to cease forcing them to co-exist, constantly bickering about angels dancing on pins. 

While people don't want to consider it in-scope for this discussion, I also think that doing so will make the situation with WHATWG and W3C more manageable.

Cheers,


On 16 Apr 2014, at 3:47 am, John C Klensin <[e-mail]> wrote:

> Hi.
> 
> Just wanted to tell folks that I'm on a very poor connection (if
> on at all) for the next couple of days and probably won't be
> able to give careful answers until Thursday and probably should
> not try.  But one very quick observation in response to part of
> Larry's note...
> 
> --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter
> <[e-mail]> wrote:
> 
>> The only thing that makes something a name 'persistsent' is
>> the existence of a name resolution service or method which
>> persists. The syntax or namespace is irrelevant.  'persistent'
>> isn't binary, it's just "how long". Everything has a life-time.
>> 
>> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
> 
> I think the above largely misses the point and that, in a sense,
> your blog posting illustrates the point although not in the way
> you probably intend.   "Persistent identifier" entered the IETF
> vocabulary a long time ago but may not be very look terminology.
> 
> Some objects -- like stone statues if one doesn't care whether
> they remain intact and standing-- have very long life
> expectancies.  Others, like people, have shorter ones.  But URIs
> (with or within including URNs) aren't objects, they are object
> reference that, like most good references, involve some degree
> of abstraction.  Now, "Ozymandias" is a very long-persistent
> reference.  It isn't the object.  It is a somewhat ambiguous
> reference because it can refer to the statue, the poem, your
> blog posting, and probably several other things, but has a long
> duration, perhaps one that is long enough to survive the objects
> it references (just like titles of long-lost books).   But, as a
> reference, it is that persistent because it is not bound to a
> retrieval mechanism that has its own persistence properties. 
> 
> Whatever its other properties,
> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
> is lousy as a persistent identifier.  It depends on the
> availability of "http" (or something called that) as a retrieval
> mechanism.  It depends on there being a DNS, on there being a
> TLD named "com" an SLD named "blogspot", and both of them having
> certain properties of which HTTP can take advantage.
> "Ozymandias", and even the potential URN
> urn:poems:Shelley/Ozymandias are more persistent because they
> represent a higher level of abstraction and are not tied to
> either a location or a retrieval/access method.  Use of a
> hypothetical ISPN (International Standard Poem Identifier) in
> the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or
> might not be more persistent: it would be an exact identifier of
> something and makes equivalence comparison more feasible and
> less ambiguous, but it is probably tied to a database to
> actually identify an object and such databases may be more or
> less available and persistent than access methods and/or the DNS
> (which is, after all, just another database).
> 
> Regardless of what one calls them, I suggest that
> access-method-dependent identifiers (http:...,
> NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?"
> represents one or more carefully-chosen delimiters that may not
> have RFC 3986 semantics), ...) are different kinds of creatures
> than either the objects to which they refer or names of those
> objects that are not, in the sense of the above, method or
> location-model dependent.
> 
> More soon.
> 
>    john
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/