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

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

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 31 Aug 2007 16:44:20 -0400
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C2031D2BF8@tayexc19.americas.cpqcorp.net>
To: "Jonathan Rees" <jar@creativecommons.org>
Cc: "Pat Hayes" <phayes@ihmc.us>, "Chimezie Ogbuji" <chimezie@gmail.com>, <www-tag@w3.org>

Hi Jonathan,

I totally agree with your analysis of this as a potential problem in
theory.  This possibility of social meaning taking precedence over
declared meaning is precisely why I used weasel words such as "prima
facie evidence" and "under normal circumstances" in talking about URI
Therefore, if the URI owner declares
that <x1> identifies X, then that declaration is prima facie evidence
that the URI does identify X (as a performative speech act), so under
normal circumstances, one should assume that it does.

However, while domains will sometimes get hijacked, and URI owners will
sometimes change URI declarations, I don't think that means that the
whole notion of "authority" needs to be discarded.  Here are some

1. Web Architecture and reality are two different things.  The
architectural right to associate a resource with the URI is not the same
as the legal right to do so.  In most cases they should coincide, but in
some cases -- such as the cases you describe -- they could differ.

An architecture presents an idealized model of how things should work,
and it includes certain rules because they provide certain benefits.
The notion of authority is architecturally important because it is
extremely beneficial to have a simple, well-defined way to find out (or
arbitrate) what resource is associated with a given URI.  

2. The primary penalty for a URI owner changing a URI declaration is
that others will get annoyed and stop using that URI.  (Though if it is
done maliciously or with intent to defraud then I could imagine legal
consequences as well.)  Thus, a URI owner publishing some RDF and
wishing to gain mindshare is likely to have an incentive to provide
stable URI declarations at stable URIs.  Conversely, an RDF consumer
wishing to minimize work is likely to have an incentive to assess the
reliability of the URI owner before relying on his/her URI declarations.

One might think that this would unreasonably tie the hands of a URI
owner who learns more about a particular resource -- a protein, for
example -- and wishes to update his/her published information about it.
But if the URI owner has distinguished between the URI declaration and
other published information about the resource, then it does not tie the
URI owner's hands: the URI declaration can remain unchanged, while other
assertions about the resource do change.  This is precisely why I think
it is important to separate the URI declarration from other assertions
about the resource, as explained in "URI Declaration Versus Use":
http://dbooth.org/2007/uri-decl/ .

3. If you are very concerned about the possibility that a URI owner (or
subsequent owner, if ownership changes) may change the URI declaration,
then we could define conventions for a URI to embed a one-way hash of
its declaration, and encourage people to follow those conventions.
Thus, a URI discoverer who comes across a URI following that convention
may feel quite confident that the URI declaration retrieved via the URI
has not changed, whereas if the URI does not follow that convention then
the discoverer may view the retrieved URI declaration with more
skepticism, and may choose not to use it or may even choose to believe
an alternate URI declaration for it.

For example, such conventions could be defined to use specialized URI
prefixes along the lines described in
http://dbooth.org/2006/urn2http/ , perhaps even combining the one-way
hash feature with other features, such as 303-redirection and/or PURL
forwarding.  Alternatively, specialized URI suffixes, query strings, or
other syntactic markers could be used to delineate a one-way hash.

Additional comments below.

> From: Jonathan Rees [mailto:jar@creativecommons.org] 
> [ . . . ]
> 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?

Actually, it sounds to me like the parties did *not* all behave with
complete integrity, or at least not with complete competence.
Publishing information is not merely giving a gift to the world.  It may
also cause the publisher to incur obligations or liabilities,
particularly if others believe the published information and act on it.
As judge, I might finder sender, receiver or both partially responsible:

 - First of all, if a party is going to depend on a URI declaration to
the extent that an inaccurate declaration would cause significant harm,
then it would be negligent for that party to blindly believe the
declaration without taking reasonable measures to verify that it had not
changed, since we all know (and you point out) that it could. I.e.,
caveat emptor.

 - On the other hand, the URI owner may have acted maliciously or
negligently in changing the URI declaration.  How could the URI owner be
negligent?  If the owner knew, or should have known, that changing the
URI declaration would likely result in significant harm to a consumer of
that URI, then it seems to me that changing it could constitute

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

Well, I don't think we would discard the notion of URI owner "authority"
in general, but we would indeed discard it for this specific URI.  In
particular, I think we would both:

 - Configure our software to retrieve or use the original URI
declaration instead of the current declarartion (perhaps by use of a URI
resolution proxy); and

 - Phase out use of that URI in favor of one with a (hopefully) more
reliable owner (or an embedded MD5 hash).

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

As I explained above, from a purely architectural perspective, the URI
owner *is* the arbiter.  But from a practical perspective, in cases
where there would be significant harm if the URI declaration were wrong,
I would agree with this.  But in cases where inaccurate information
merely constitutes a slight inconvenience, I think the URI owner's
"authority" can be assumed.  

Ultimately the reliability of published URI declarations should be
viewed no differently than the reliability of any other published
information.  If you trust the publisher, then you may place more trust
in the information.  If you are depending on the accuracy of that
information in mixing medicine for your sick child, then you would be
negligent if you did not somehow assess its trustworthiness first.

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
Received on Friday, 31 August 2007 20:44:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:53 UTC