W3C home > Mailing lists > Public > www-tag@w3.org > August 2007

Owner is not ultimate authority [was Re: URI declarations]

From: Jonathan Rees <jar@creativecommons.org>
Date: Fri, 31 Aug 2007 09:04:46 -0400
Message-Id: <16A594EF-4EB5-4C11-963D-DD4E858D1C8B@creativecommons.org>
Cc: "Pat Hayes" <phayes@ihmc.us>, "Chimezie Ogbuji" <chimezie@gmail.com>, <www-tag@w3.org>
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>

On Aug 28, 2007, at 12:34 AM, Booth, David (HP Software - Boston) wrote:

> I'm not sure quite what you [Pat Hayes] mean by "SWeb design", but  
> the idea of a
> single authority for associating a URI with a resource is *central* to
> Web Architecture.  The definition of URI ownership[4] says:
> [[
> URI ownership is a relation between a URI and a social entity, such  
> as a
> person, organization, or specification. URI ownership gives the  
> relevant
> social entity certain rights, including:
>    1. to pass on ownership of some or all owned URIs to another
> owner-delegation; and
>    2. to associate a resource with an owned URI-URI allocation.
> ]]
> A URI declaration is ts all about #2.

While I think your notion of a URI declaration is very valuable, and  
ought to be instituted as a formal way to capture prescriptions for  
how URIs are supposed to be used (as distinct from falsifiable claims  
about the resource), and while you are probably correct about the  
current dogma about URI ownership and authority to define, I think  
that something is being missed.

The value of RDF as I see it is that it is a language whose  
utterances "have meaning", and the terms of a language belong to its  
speakers. If the meaning of a term (URI) can change on the whim of an  
"owner" then we will have communication breakdowns: sender composes  
RDF assuming meaning M1 articulated by URI owner; owner changes  
meaning from M1 to M2; receiver receives sender's RDF and consults  
URI owner on meaning, and gets M2 and therefore the wrong  
interpretation. The receiver needs to know what was meant by the URI  
when the sender composed the RDF, and for that purpose the URI owner  
is not necessarily an "authority" - in fact keeping track of meaning  
M1 may not be in the owner's interest. Ultimately, if the URI owner  
can't be trusted to be consistent, the sender has to be responsible  
in some way for M1, either by providing a copy of the intended  
declaration or by citing an independent source (such as a journal or  
other third party repository) that caches a document defining the  
term to mean M1. (Or by using another term, but that just pushes the  
problem onto the other term.)

Suppose that the term is in wide use with meaning M1, but that the  
receiver believes the owner is the authority and uses M2. Suppose  
that as a result, the receiver injures the sender somehow. Sender  
hauls receiver, owner, and W3C into court. Every party until now has  
behaved with complete integrity. If you were judge, who would you  
hold responsible?

We all know (more or less) how to use the term http://www.w3.org/ 
1999/02/22-rdf-syntax-ns#type . If www.w3.org were to be hijacked or  
go away, or the domain name sold and subsequently acquired by an evil  
party, that URI would still mean what it means now. The cost of  
accommodating the whims of a new definer would be so high and so  
unnatural that we would, as a community of speakers of RDF, decide in  
the interest of stability and economy to discard the simplistic  
notion of URI owner "authority", and switch to systems of citation,  
judgment, and arbitration that are used in the rest of society.

A URI owner may have the "authority" to define a term at the time of  
minting, but once a term is released into the wild and is used by the  
community, the community is really the arbiter of meaning, not the  
URI owner. If the URI owner proves to be trustworthy, that's fine,  
but the privilege of being treated as the "authority" for a term's  
definition (or declaration) should be earned, not assumed.

Received on Friday, 31 August 2007 13:05:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:17 UTC