Universally constraining interpretations [was Re: summary so far.]

On Wed, 2011-03-02 at 12:53 +0000, Nathan wrote:
> yay, definitely getting there! follow up at the bottom to keep it in 
> context:
> 
> Nathan wrote:
> > Jonathan Rees wrote:
> >>> So, <u> does not refer to an HTTP/REST resource, that is, even if you 
> >>> could
> >>> see the entire set of representations ever given to every person, you 
> >>> still
> >>> often cannot deduce to what the URI refers, what it names.
> >>
> >> umm. doesn't compute. Oh, I see, you're saying the mapping from URI to
> >> IR isn't functional. Agree completely - someone has got to (or has the
> >> privilege to) decide which of those IRs the URI is to refer to, even
> >> assuming that they're using the URI to name an IR at that URI. THis is
> >> why my 'is bound to' relation is not functional.
> > 
> > interesting thing here.. next paragraph
> > 
> >>> Here is some evidence to back up this claim:
> >>>  http://lists.w3.org/Archives/Public/public-awwsw/2011Mar/0006.html
> >>>
> >>> In the case pointed to above, you must see how the URIs are /used/
> >>> (consistently over time) to establish what they refer to; and not 
> >>> what the
> >>> information resource reflects (consistently over time).
> >>
> >> Yes, meaning of a URI is how it's used by agents
> > 
> > now this is interesting, and I'm unsure exactly how to say it, but if we 
> > work from HTTP Resource upwards to URI, such that we consider an HTTP 
> > Resource as being a distinct object for which all URIs used to refer to 
> > it are bound to that HTTP Resource (the URIs are a property of the HTTP 
> > Resource), then we come to the wrong conclusions, and things break.
> > 
> > In the quoted example above, it would mean that all four URIs are bound 
> > to the "HTTP Resource", they all refer to the "same thing", which is 
> > clearly inconsistent and just wrong in every way.
> > 
> > Even though there is only one "HTTP Resource", there are four distinct 
> > "Resources".
> > 
> > Each of the four URIs could be bound to one, or four, or two billion 
> > different "HTTP Resources" and you wouldn't know.
> > 
> > Which means that.. they're unquantifiable.
> > 
> > Every single bit of information which could possibly be used to 
> > determine exactly how many HTTP Resources there are, is therefore 
> > hidden, and has to be, otherwise the whole thing falls apart. This is a 
> > product of the uniform interface and the compound identifier with it's 
> > late binding of the various differently scoped names of which a URI 
> > comprises.
> > 
> > Jonathan: Kudos, you said this a while back and I didn't fully grasp 
> > what you meant, but you were right, you cannot prove in any way that 
> > there is more than one HTTP/REST resource (technically by looking 
> > through the uniform interface).
> > 
> > This falsifies all kinds of things, and I have to draw some conclusions.
> > 
> > "meaning of a URI is how it's used by agents" - check, yes.
> > 
> > (I'll have to iteratively explain the next bit)
> > 
> > each URI is optionally bound to a set of representations over time, each 
> > representation is anonymous (only existentially quantified) by default 
> > (*) and late bound to the URI as a product of the dereferencing process, 
> > thus if one representation has been bound to a specific URI then that 
> > URI belongs to the class of things for which representations have been 
> > bound. I'll that class of things RB for now (has a [R]epresentation 
> > [B]ound).
> > 
> > * given two identical representations, you cannot tell what they are 
> > representations of, if they are representations of the same thing, or 
> > two different things.
> > 
> > Okay, I used representation above to mean content+meta, nothing more, 
> > nothing less, and doesn't mean that it's a "representation" of anything. 
> > I've purposefully not used the term information resource, because at 
> > this moment in time I can't bring myself to say any more than there are 
> > URIs, some URIs have had content+meta's bound to them, and thus we could 
> > make a proper subclass which is the class of all URIs for which a 
> > content+meta has been bound.
> 
> for all URI <u> in class RB, <u> is bound to a set SR of representations 
> {Ri,i=1...n}, to a Thing.
> for all URI <u> in class RB, there exists a set SA of agents 
> {Ai,i=1...n} for which <u> is a name for SR or T.
> 
> hashes [
>    for some <u> in class RB there exists a class of sub-URIs of the form 
> <u#f>.
>    for all <u#f> in <u>, <u#f> is bound to SR.
>    if there exists 1...n <u#f> in <u>, then <u> refers to SR and T == SR.
>    for all a in SA, <u> refers to SR and T == SR.
> ] (
>   - easy
>   - doesn't cover the cases where you can't use <u#f>
>   - it's still true that:
>      for some a in SA, <u> refers to T
>      for some a in SA, <u> refers to SR
>      for some <u> in class RB, T != SR.
>      for some <u> in class RB, T == SR.
> )
> 
> slashes [
>    for some a in SA, <u> refers to T
>    for some a in SA, <u> refers to SR
>    for some <u> in class RB, T != SR.
>    for some <u> in class RB, T == SR.
>    if T == SR then for all a in SA, <u> refers to SR and T == SR.
>    if T != SR and no a in SA uses <u> for SR, then <u> refers to T.
>    if T != SR and some a in SA uses <u> for SR, then T == SR && T != SR.
> ] (
>   - the problem
> )
> 
> if any of the following conditions is true, then there no problem:
> 
>    if T == SR
>    for all a in SA, <u> refers to T
>    for all a in SA, <u> refers to SR
> 
> the only "fix" is to make ( for all <u> in RB, T == SR ) universally 
> true (<u> == IR), or make it universally false ( can't use <u> as a 
> name). there's no way to enforce either.

No, that is not the only fix.  That is a fix that can be used *within* a
particular RDF graph.  But I do not believe that it is correct to make
that hold in any sort of universal sense.  I think that would be falling
victim to what I call Myth #2 "RDF semantics are global":
http://dbooth.org/2010/ambiguity/paper.html#myth2

If <u> is globally unconstrained -- if it has no URI declaration that
universally constrains its interpretations -- then <u> can perfectly
well refer to T in one graph and SR in another graph, while in both
graphs T != SR.

The key is to ask: how are the interpretations of <u> *universally*
constrained?  Those universal constraints are the purpose of a URI
declaration
http://dbooth.org/2007/uri-decl/
For the case of IRs, these constraints are what the IR axioms draft in
http://www.w3.org/2001/tag/awwsw/ir-axioms/20110225
refers to as "(c) an appropriate RDF axiom set derived from the above
axioms".  The IR axioms draft only covers the case of IRs; the above
paper on URI declaration focuses on the case of non-IRs.  

I've been a bit sloppy here in my language, since as I've said before I
do not think there needs to be a universal distinction between IRs and
non-IRs, but I hope you'll get what I mean.  

To clarify, here are some potential rules to decide what axioms /
assertions / URI declaration to use:

 - If the URI has no fragID, and an HTTP GET yields a 200 response code,
then that URI has an (initial) implicit URI declaration consisting of
"(c) an appropriate RDF axiom set derived from the above axioms".

 - Furthermore, if the content type from the previous step is RDF, then
the assertions in that RDF should be merged with any assertions obtained
in the previous step.  (Ian Davis, in his toucan proposal for ditching
303
http://lists.w3.org/Archives/Public/public-lod/2010Nov/0013.html 
was essentially proposing that the assertions from the previous step be
*overridden* rather than being merged.)

 - If the URI has a fragID and its base (i.e., the part without the
fragID) deferences to RDF, or if the URI has no fragID but it
dereferences through a 303 to RDF, then its URI declaration consists of
that RDF.

The inference rules that I drafted a while back at
http://www.w3.org/wiki/AwwswDboothsRules
were an attempt to codify rules like these.  Hopefully, once we have
worked out the rigor that Jonathan's been pushing we can come back to
this and end up with a more refined and universally agreeable set.



-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Friday, 4 March 2011 20:25:52 UTC