RE: Some questions about declarations, was: Re: AWWW Mechanism for Interpreting use of RDF Symbols was - Re: ISSUE-58: Scalability of URI Access to Resources

Alan,

Great questions!  Responses below.

> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com] 
> 
> Hi David,
> 
> > 1. URI declaration: http://dbooth.org/2007/uri-decl/
> 
> Some questions about declarations:
> 
> - It looks like declarations are for individuals. Otherwise I am  
> confused about what the declaration for a class would be. "A URI  
> declaration is authoritative only in defining the association 
> between  
> the declared URI and a particular resource". Is the class an  
> information resource? If not, what is it, and how does one 
> create the association?

AFAICT a class is not an information resource.  

The examples I have used (and most thought through) have been for
individuals, but my assumption was that URI declarations should work the
same for classes.  Is there a particular reason why you think they would
not?

> 
> - You write that  "the other hand, statement M3 ("For more  
> information about http://dbooth.org/2007/moon/ , see also http:// 
> dbooth.org/2007/moon/about.html") is safe to include in the URI  
> declaration page, because it is merely a suggestion: it does not  
> affect the satisfiability of p(x).". How are we to determine which  
> statements are of this kind - namely that they do not affect the  
> satisfiability of p(x).

I do not know of an automatable way to do that.  It requires
understanding what the statement means.  (Maybe someone better versed in
logic and computability theory can say whether it is even possible?)  So
I assume it is something that a human would just have to judge.  From a
consumers perspective, if the consumer of the URI declaration is not
sure whether a contained statement would affect the declaration then the
safest assumption would be to assume that it might.

The statements made in the declarations are the ones that should be
invariant.  Anything that might need to change should not be in the
declaration.

> 
> - The following: "If the URI contains a fragment identifier, 
> then the  
> racine of the URI (i.e., the part before the #) should lead to a  
> suitable URI declaration page" would seem to imply that there should  
> not be more than one hash identifier with the same racine, unless  
> they denote the same resource. Do I have this correct?

No, it is fine for multiple URIs to have the same racine, and all may be
declared by the same document.  

An agent discovering http://example.org#foo may look for a URI
declaration by dereferencing http://example.org to get a document that
contains statements about both http://example.org#foo and
http://example.org#bar .  Until the agent realizes that
http://example.org#bar and http://example.org#bar have the same racine
it may initially take the returned document to be a URI declaration for
http://example.org#foo only.  But if it later wishes to find a URI
declaration for http://example.org#bar it can avoid doing another
network retrieval by realizing that it already obtained the document
from http://example.org and recognizing those statements as also
declaring http://example.org#bar .

There is more of a potential efficiency issue when 303 URIs are used
instead of hash URIs.  Suppose http://example.org/foo and
http://example.org/bar both 303-redirect to a common URI declaration
page, http://example.org/decl.rdf .  When an agent deferences
http://example.org/foo to find its URI declaration, the declaration page
from http://example.org/decl.rdf may also include statements about
http://example.org/bar , but without some way to indicate that those
statements are also supposed to represent a URI declaration for
http://example.org/bar , the agent will have no way to know that they
are.  This is one reason why I think it may eventually be helpful to
have an explicit syntax for indicating URI declarations.

> 
> - In the statement: "Proposed rule R1:  Given a URI u, if either of  
> the follow-your-nose mechanisms described above yields a  
> representation r, then, unless otherwise indicated, the conjunction  
> of assertions made in r represents an implicit URI declaration for  
> u", how are we to know whether the yield is a representation, 
> and how  
> would we indicate that the conjunction of assertions does not  
> represent an implicit URI declaration for u?

I'm not certain that I've understood your question, but see if this
helps.

A "representation" is the payload returned with an HTTP 200 response
code, and its interpretation is defined by its media type.

If you do not want to serve the URI declaration from the
racine/303-redirect target, but instead you wish to serve some other
assertions, my suggestion would be: Don't do that.  Serve those  other
assertions from a different location.

OTOH if you want to serve *both* the URI declaration and other
assertions from that same location, then it would be good to have a
standard syntax for separating the two.  I have not proposed one, in
part because I do not think it is a good idea (because it makes the URI
declaration much more susceptible to accidental change), but if there is
enough demand for it, a convention could be defined.

> 
> - Suppose I have a document, and wish to indicate that there is  
> another version of that document with a different URI. How can I do  
> this using the mechanism you propose? 

Do you mean another version of a URI declaration, i.e., a different
declaration for the same URI?  Such as one written in a different
language but otherwise having the same meaning?  Or do you mean one that
associates the URI with a different resource, for example, if the
declaration was changed?

It may be useful the have ways to indicate alternate declarations for a
URI.  If there is an accepted explicit notation for writing URI
declarations, such as the dbooth:declares predicate described in
http://dbooth.org/2007/uri-decl/#declares then that can be used multiple
times to indicate multiple declarations for the same URI.

Note that this cannot be done without talking about the URI itself (as a
URI declaration does) rather than just talking about the URI's resource.
For example, suppose http://dbooth.org/2007/moon/old-decl contained a
previous version of a URI declaration for http://dbooth.org/2007/moon/
that is different than the current declaration in
http://dbooth.org/2007/moon/decl.html , such that
http://dbooth.org/2007/moon/old-decl defines a different resource.  The
following statements would NOT indicate that
http://dbooth.org/2007/moon/ has two different resource definitions or
URI declarations:

  http://dbooth.org/2007/moon/ rdfs:isDefinedBy
http://dbooth.org/2007/moon/decl.html .
  http://dbooth.org/2007/moon/ rdfs:isDefinedBy
http://dbooth.org/2007/moon/old-decl .

because in those statements, http://dbooth.org/2007/moon/ denotes a
single resource -- the same resource in both statements.  So those
statements would be saying that the same resource is defined in two
different documents, whereas what we want to say is that there are two
different resources being defined by those two different documents.

> Or, where *am* I able to say  
> that the moon is made of green cheese.

Anywhere except in your moon URI declaration.  

For example,
http://dbooth.org/2007/moon/ 303-redirects to
http://dbooth.org/2007/moon/decl.html which contains a URI declaration
for
http://dbooth.org/2007/moon/ , but it also says for more information see
also
http://dbooth.org/2007/moon/about.html , which can contain any other
assertions about the moon, including the assertion that the moon is made
of green cheese.  These assertions are not a part of the URI declaration
for http://dbooth.org/2007/moon/ .

> 
> - Is there any status given to statements that are contained in a  
> document served with a 200 response that is not accessed via the  
> follow-your-nose algorithm? If so, how do I know which ones?

They may have socially defined status, but I do not think they have any
architecturally defined status.  For example, if you run across a
document (not at the follow-your-nose location) containing an explicit
URI declaration, and the document is digitally signed by the URI owner,
then you might choose to believe that URI declaration. 

> 
> - The declaration would necessarily use URIs that are defined by  
> others. Suppose the declaration of one of those uris is changed,  
> either purposefully or inadvertently. Can that change the  
> authoritative association of URI to resource that use these  
> externally defined terms in its declaration? 

Yes.

> If yes, then does that  
> not undermine the authority of the declarer? 
> If not, how is one able  
> to become aware of this unfortunate situation?

I wouldn't quite characterize it as undermining the authority of the
declarer.  The URI declaration is the way the declarer chooses to write
it.  If the meaning of that declaration changes because a dependency
changes, then that is because the declarer chose to give it that
dependency.

However, this does not mean that stable declarations are not possible.
If the declarer just declares http://example.org#moon to be owl:sameAs
http://dbooth.org/2007/moon/ then if the declaration for
http://dbooth.org/2007/moon/ changes then effectively the declaration
for http://example.org#moon also changes.  In other words, it is very
susceptible to changes in its dependencies.  But if it is declared
differently, in more closely grounded terms, then changes in the
declarations of its dependencies may have less (or no) effect.

Finally, if the declarer really wants to ensure that changes in a URI
declaration's dependencies will not silently change the meaning of that
URI declaration, then a one-way hash or message digest could be provided
for each dependent URI -- potentially recursively, depending on one's
level of paranoia.  This can be stated either in terms of the dependency
URIs themselves or in terms of the URIs of the declaration pages of the
dependency URIs.

For example, if http://example.org#moon is declared in
http://example.org to be:

  http://example.org#moon owl:sameAs http://dbooth.org/2007/moon/ .

then it is dependent on the declaration for http://dbooth.org/2007/moon/
(and also owl:sameAs, but we'll ignore that for the moment, as it can be
treated the same way).  To guard against the meaning of
http://dbooth.org/2007/moon/  being silently changed, the declaration
for http://example.org#moon could also include statements like the
following:

  http://dbooth.org/2007/moon/ 
        rdfs:isDefinedBy http://dbooth.org/2007/moon/decl.html .

  http://dbooth.org/2007/moon/decl.html 
        foo:hasSHA1 "8739AB6F54E ... " .

where foo:hasSHA1 indicates a SHA-1 hash of the given document.  This
approach explicitly indicates the URI declaration document used for
http://dbooth.org/2007/moon/ .  Alternatively, the declaration for
http://example.org#moon could say something like:

  http://dbooth.org/2007/moon/ 
        foo:hasDeclarationWithSHA1 "8739AB6F54E ... " .

which does not say where to find the URI declaration for
http://dbooth.org/2007/moon/ .  It just says that the resource
identified by http://dbooth.org/2007/moon/ has some URI declaration
document (somewhere) with an SHA-1 hash of "8739AB6F54E ... ".

I don't know if anyone has already defined widely used predicates
equivalent to foo:hasSHA1 or foo:hasDeclarationWithSHA1 above, but if
this declaration stability issue turns out to be a big enough issue in
practice, then we could certainly define them.

This seems like a relatively low cost approach: only one or two extra
triples for each term.  It also avoids getting into copyright issues
that could arise if dependency declarations were copied.


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.

Received on Thursday, 13 September 2007 19:43:46 UTC