Re: URI lifecycle (Was: Owning URIs)

Hi Pat,

On Fri, 2009-05-22 at 12:47 -0500, Pat Hayes wrote:
> On May 20, 2009, at 12:01 AM, David Booth wrote:
> 
> > Hi Hugh,
> >
> > Re:
> >>> "The URI Lifecycle in Semantic Web Architecture":
> >>> http://dbooth.org/2009/lifecycle/
[ . . . ]
> > It is clear that semantic
> > drift is a natural part of natural language: a word that meant one  
> > thing
> > years ago may mean something quite different now.
> 
> And the same is happening with URIs. My favorite example is dc:author,  
> which when coined was intended to refer to the relation of authorship  
> between people and things like books, things that would be found in a  
> library catalog. But by now, thanks to FOAF, the overwhelmingly  
> largest usage of dc:author is to state the relationship between a  
> person and their FOAF home page. This is a real social meaning shift,  
> and it happened without anyone really noticing and without anything  
> breaking or failing to work. If the original DC specs had posted a  
> detailed 'authoritative' ontology, the change would still have  
> happened and it would still have worked, but there would have been  
> interminable debates about whether a home page was really a "work" (or  
> whatever the term that was used), suggestions that FOAF use a  
> different URI, etc., etc.,, all to absolutely no purpose. Just look at  
> the interminable and utterly pointless debate now raging about exactly  
> what an 'information resource' *really is*, none of which has any  
> bearing whatsoever on how the actual Web works, even though the latter  
> is actually constructed almost entirely out of the former.
> 
> >  As humans we can
> > usually deal with this semantic drift by knowing the context in  
> > which a
> > word is used, though it can cause real life misunderstandings  
> > sometimes.
> >
> > However, I think our use of URIs in RDF is different from our use of
> > words in natural language, in two important ways:
> >
> > - RDF is designed for machine processing -- not just human
> > communication -- and machines are not so good at understanding context
> > and resolving ambiguity; and
> >
> > - with URI declarations there is a simple, feasible, low-cost  
> > mechanism
> > available that can be used to anchor the semantics of a URI.
> 
> But that begs the question of whether you want them to be anchored. I  
> suggest that we often don't: that letting them 'drift' in meaning to  
> fit their usage is exactly what we want to be happening.

And that's fine too.  The important thing is that expectations be set
accordingly.  I covered this slightly:
http://dbooth.org/2009/lifecycle/#other
[[
Change policy for the core assertions. Some ontologies, such as SKOS
[Miles 2009], have intentionally chosen to permit the definitions of
their terms to be changed without minting new URIs for them. Although
such a policy could be disastrous for some applications, for others it
may be the most cost effective. Although changing the core assertions
may change the set of permissible interpretations for a URI -- thus
changing the URI's resource identity -- such changes are okay if the
change policy has set expectations appropriately.
]]

However, perhaps I should have said more about this.  There are actually
two ways to permit semantic drift when it is desired.  One is to do as
SKOS does and change the definitions over time (having set expectations
appropriately).  The other is to provide an unchanging but intentionally
loose URI declaration.  The extreme of this is a URI declaration with an
empty set of core assertions -- none whatsoever -- which of course would
not really anchor the semantics at all.  Either of these approaches is
fine, and fits within the architecture that I described, but still
permits semantics to be anchored when desired.

> 
> >
> > In short, although semantic web architecture could be designed to  
> > permit
> > unrestricted semantic drift, I think it is a better design -- better
> > serving the semantic web community as a whole -- to adopt an
> > architecture that permits the semantics of each URI to be anchored, by
> > use of a URI declaration.
> 
> And I disagree. 

Are you really saying that you think an architecture that *permits* (but
does not require) the semantics of a URI to be anchored is less
preferable than an architecture that does not even permit the semantics
to be anchored?  In "Why URI Declarations? A comparison of architectural
approaches" http://dbooth.org/2008/irsw/ I've explained in some detail
the advantage that the ability to anchor the semantics provides.  If you
think that analysis is flawed I'd be very interested to know how.

> I think this whole idea is based on the insistence of  
> various authoritative sources upon the naive idea that URIs have to  
> "identify" things. This has never been the case, in fact, even in the  
> pre-Semantic web, and its even less the case now. Its a chimera:  
> forget about it, rather than try to enforce it. What URIs do is fetch  
> chunks of information. Hardly anyone using the normal Web in the  
> normal way gives a damn what "thing" their URIs "identify": they only  
> care about what they are looking at, which is whatever that "thing"  
> sent back to them in the body of the 200 response, and what that means  
> or what it can do. The very design of html is all about *hiding* the  
> URIs from users, not about telling them what it is that URIs identify.

Sure, URIs in the HTTP spec are used to fetch chunks of information, and
that is their most common use in the world.  But I'm talking
specifically about *semantic* web architecture -- not every day web
usage.  And in semantic web architecture RDF obviously uses URIs to
denote resources.  So the question is whether, in *semantic* web
architecture, these two uses should be viewed as having any connection
to each other.  I am arguing that there is value *in general* in being
able to dereference a URI as a convenient and deterministic way to find
out its semantics, even if that isn't wanted or possible in every
case.  



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Monday, 25 May 2009 15:11:53 UTC