Re: URI lifecycle (Was: Owning URIs)

Hi John,

Re: "The URI Lifecycle in Semantic Web Architecture":
http://dbooth.org/2009/lifecycle/

On Tue, 2009-05-19 at 10:46 -0700, John Graybeal wrote:
> *Very* interesting paper, for the content and for the links.   
> Addresses many a topic I've been trying to sort out.
> 
> If I may ask for a clarification on a few key points at the beginning:
> 
> 1) At what point does 'minting' occur?  (a) When I think of the URI,  
> (b) when I first write it down as a string in some file, (c) when I  
> 'serve' it in some formal way, (d) when I make a statement that  
> references it, or (e) ...? You define it as 'establishing the  
> association between the URI and the resource it denotes', but how does  
> the process of establishing that association occur, exactly? It all  
> seems a little imprecise with respect to real-world resources.

The simplest answer is that the URI is minted when the URI owner
publishes its URI declaration, since it is the URI declaration that
establishes the association between the URI and the resource it denotes.

> 
> 2) Am I correct in thinking the URI owner is just the person who has  
> the authority to create a URI (and optionally provide an initial set  
> of statements about it)? In the SW, the idea of someone having the  
> "authority" to link their URI to the actual resource -- Earth's moon  
> for example -- is confusing, since many people will mint URIs meant to  
> refer to the Earth's moon; I think they all have that authority, in  
> some sense. (AWWW focused more on the actual URI and information  
> resources, where there is an implicit association, often through  
> deferencing.)

In simple terms, the URI owner is the owner of the domain from which the
URI is allocated, or the owner's delegate.  For example, if John owns
domain foo.example.com then John is the owner of all URIs allocated
within that domain, such as http://foo.example.com/bar/whiz/bang .
However, John could delegate minting authority to all or part of his URI
space.  For example, John could delegate minting authority for all URIs
matching http://foo.example.com/lucinda/* to Lucinda.  

The notion of URI ownership is defined in the AWWW section 2.2.2.1:
http://www.w3.org/TR/webarch/#uri-ownership

> 
> 3) Can you define a "core assertion"?  If I can improve my assertions  
> to clarify that I meant the Earth moon we all know about, as opposed  
> to some other 'Earth moon', is that not allowed per R1? How do we know  
> when an improvement makes the original concept more useful, as opposed  
> to erroneous for some users? (Note your suggestion later that "it's OK  
> when expectations are properly set", a la SKOS.)

The core assertions are merely those that are provided in the URI
declaration and serve to define the association between the URI and a
resource.  They do so by constraining the permissible "interpretations"
for that URI.  (An "interpretation" in RDF semantics lingo maps URIs to
resources.)  In the end the question of whether a change in a URI
declaration will be helpful or harmful to your users is a judgement
call.  In theory, any change to the core assertions has the potential of
invalidating some user's code.  However, in practice some changes are
far less likely to cause problems than others, because they don't affect
the set of permissible interpretations -- at least not in a way that
matters.  For example, in the moon example at
http://dbooth.org/2007/uri-decl/#example
changing the rdfs:seeAlso assertion is unlikely to break users' code
because it doesn't really constrain the resource identity of the URI
http://dbooth.org/2007/moon/ .  

One can think of the core assertions as constraining the set of
permissible interpretations for that URI.  There will always be some
ambiguity about what resource the URI denotes -- this is inescapable --
but the core assertions clearly delineate that ambiguity.  This is
further explained in a companion paper, "Denotation as a Two-Step
Mapping in Semantic Web Architecture":
http://dbooth.org/2009/denotation/

> 
> The paper is a nice encapsulation of many of the idiosyncrasies of the  
> current state of the social practice. Thanks

You're welcome.  And thanks very much for your comments!


-- 
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 Wednesday, 20 May 2009 16:40:38 UTC