- From: Simon Cox <simon.cox@jrc.ec.europa.eu>
- Date: Wed, 2 Sep 2009 19:03:07 +0200
- To: "'C. M. Sperberg-McQueen'" <cmsmcq@blackmesatech.com>, "'Henry S. Thompson'" <ht@inf.ed.ac.uk>
- Cc: "'Tsao, Scott'" <scott.tsao@boeing.com>, "'G. Ken Holman'" <gkholman@CraneSoftwrights.com>, <xmlschema-dev@w3.org>
I agree with Michael. The fact that there is no general URN resolution service (besides reading the relevant RFCs) is highly inconvenient and pragmatically it is a killer. But the fact that URN assignment is onerous (much much much more onerous than URL creation) is not necessarily a bad thing. Some resources really are more valuable than others, and having a high threshold in the identifier assignment process reinforces this. I think I understand the Thompson/TAG argument that the same discipline *could* be applied to http URIs, but in general it is not ... which leaves us in this maybe/maybe not situation. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@jrc.ec.europa.eu http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of C. M. Sperberg-McQueen Sent: Wednesday, 2 September 2009 18:53 To: Henry S. Thompson Cc: C. M. Sperberg-McQueen; Tsao, Scott; G. Ken Holman; xmlschema-dev@w3.org Subject: Re: Best Practices for Establishing Namespace Name On 2 Sep 2009, at 09:40 , Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > C. M. Sperberg-McQueen writes: > >> The record would not be complete without someone observing that it >> also has the disadvantage that if the domain name registration for >> [your committee] ever lapses, there is no guarantee that the new >> owner will refrain from assigning a new meaning to http://[your >> committee]/namespaces/xxx > > For sure. > > But be careful using this as an argument in favour of using URNs or > some other URI scheme -- If you don't care about dereferencing, it > doesn't matter that http://[your committee]/namespaces/xxx doesn't > dereference today, and might dereference misleadingly in some > relatively unlikely future. If you _do_ care, then the mechanisms put > in place to support dereferencing of e.g. URNs will almost certainly > be vulnerable to the same human-originating failure modes. The meaning of some identifiers is given in a way that guarantees permanence of the meaning assigned. If URLs mean things by virtue of the actions and/or intentions of their owners (which is what I understand the TAG's story to be), then when the owner changes, the meaning is necessarily subject to change. The difference at issue is not whether, when you dereference something, you get something 'misleading' or not. The issue is whether the prescribed methods for determinining the denotation of an identifier guarantee stability of denotation over time or not. On the account offered in your email, the system of using URLs as long-lived identifiers seems to depend on (a) the proposition that a URL has a given meaning just when the owner of the relevant domain assigns it that meaning, and (b) the proposition that a URL has a given meaning whenever we feel like interpreting that way, regardless of the actions of the owner of the relevant domain. The TAG may have no trouble reconciling those two propositions; I confess that to me, they just look like a contradiction at the heart of the TAG's edifice. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Wednesday, 2 September 2009 17:04:40 UTC