Re: old threads

On Thu, 2010-05-27 at 10:59 -0400, Jonathan Rees wrote:
> I have never understood what you mean by "binding" 

A binding is the association between a name and the thing that it
denotes.  The act of binding is the act of establishing such an
association, like in a programming language:
http://en.wikipedia.org/wiki/Name_binding

The reason for using the term "binding" (as an action) is that allows us
to talk about the lifecycle of the association between a name and the
thing that it denotes: the creation and destruction of that association.

We don't have to use that term, but we do need the ability talk about
the lifecycle somehow.

> but rather than
> argue with it let me ask:
> 
> - what axioms apply to the relation 'x is bound to y'?

"u is bound to t" == hasUri(t, u) == t log:uri u == "u denotes t"

> - how would an agent come to believe a statement of the form 'x is bound to y'?

There are several ways.  Some are:

 - The agent dereferences URI u and receives a 200 response, which
implies that u is bound to some w:InformationResource.  

 - The agent dereferences URI u and receives a 303 redirect to a page
with 200 response, and that page contains a URI declaration for u,
specifying a set of assertions that constrain the identity of the
resource to which u is bound.

 - The agent's owner loaded some RDF into the agent, and that RDF told
the agent that URI u is bound to some resource.

> - what operational consequences follow from 'x is bound to y' being true?

You can talk about y using the symbol x: x is a name for y.

> 
> On Wed, May 26, 2010 at 10:17 PM, David Booth <david@dbooth.org> wrote:
> > On Wed, 2010-05-26 at 14:01 -0400, Jonathan Rees wrote:
> >> Since the draft gets into the old old question about what is an
> >> "information resource" I think it will be worthwhile to review old
> >> threads, to save Pat, Tim, Dan B&C, et al. the trouble of repeating
> >> themselves... e.g.
> >> http://lists.w3.org/Archives/Public/www-tag/2007Nov/0041.html... of
> >> course the discussion goes back to 2002 or beyond; found some TAG
> >> discussion from 2004 which I'm skimming.  Of course the RDF graph
> >> question was discussed in 2007, as was the class/property question.
> >>
> >> Here's another example, from Tim,
> >> http://lists.w3.org/Archives/Public/www-tag/2004Sep/0033.html
> >
> > Those threads won't help.
> 
> My purpose is to keep a communication channel open with the parties
> that care about these issues, not proclaim without justification
> things they don't believe. (On the other hand *proving* things they
> don't believe from things that they do believe, or are willing to
> believe, is good thing.)

Yes, always good to keep the communication channel open.  

> 
> > The problem is rooted in the inescapable fact
> > that there is, and will always be, ambiguity in the identity of a
> > resource:
> 
> I don't know what the identity of a resource is. Can you tell me:
> - how would one come to believe that x is the identity of y,
> - what axioms hold for this function,
> - what are the operational consequences of believing that x is the
> identity of y?

I'm not suggesting we define a "hasIdentity" relation.  I'm talking
about when a URI consumer
http://dbooth.org/2009/lifecycle/#consumer
receives some RDF and wants to know what resource a particular URI was
intended to denote in that RDF: the URI consumer wants to know the
"identity" of the resource.  In the semantic web world, "identity" boils
down to a set of assertions that constrain the permissible
interpretations of that URI:
http://dbooth.org/2009/denotation/#uri-interp

> 
> > http://www.ibiblio.org/hhalpin/homepage/publications/indefenseofambiguity.html
> 
> I know this paper and take it as a defense of the approach I'm trying
> to take (axiomatic method, relativity of belief, emphasis on
> consequences rather than platonism). Basically it tells me to stay
> away from model theory and denotation in favor of just considering
> what's true or consequential. 

Well, we certainly may have taken different lessons from it, but the key
lesson that I took was that "reference is inherently ambiguous": "It is
impossible to achieve unambiguous universal reference of names by using
descriptions" (and descriptions are what we have, in the semantic web
world).

> By sticking to proofs, theories, and
> consequences you can put the whole ambiguity question out of scope.

I don't see how, given that reference is inherently ambiguous, and this
is captured explicitly in the RDF semantics by the fact that a graph may
have many interpretations.  But if you see a way to side-step that, then
that would be great.

> Not that it's uninteresting, just that we don't have anything
> particularly insightful to say about it.

On the contrary, we can say a *lot* about it.  In particular, if you buy
the notion of URI declarations -- basically that each URI should have an
established set of assertions that constrains its interpretations --
then this ambiguity of reference can be precisely bounded.  That's
*important*, because it means that the meaning of a particular URI is
not merely subjective and determined at whim, it is bounded.

> 
> In any case AWWW is quite clear that there are things that are not
> "information resources". 

Yes, IMO the AWWW erred in this regard.  We won't get very far if we
assume that the AWWW is correct in every aspect when we examine it with
a microscope, and that's just what we're doing when we're trying the
nail down the precise semantics of these things in semantic web
architecture.  And in the AWWW's defense, there is nothing wrong with
saying that some things *shouldn't* be considered "information
resources".  Indeed, that is *good* advice that helps prevent ambiguity,
a/k/a "URI collision".  So IMO it wasn't a very large error to say that
some things are *not* "information resources", but when we examine the
semantics to the extent that we are doing, it shows up as significant.

> If it doesn't matter whether there exist
> things not in this class, then there is no need at all for
> httpRange-14.

Not true.  The httpRange-14 decision provides a rule for knowing that
something *is* (provably, assuming you believe the server's response) an
w:InformationResource.  That is *different* than not knowing anything
about that thing, and that difference is crucial to the difference
between open and closed world reasoning.

> 
> Personally I still think the "information resource" idea as received
> doesn't make much sense, and it's our job to prove or disprove that
> that it doesn't make sense, providing a better alternative if there is
> one. There seems to be some objective that the httpRange-14 rule was
> supposed to achieve, and we ought to try to explain how to meet that
> objective (the rule itself almost certainly didn't).
> 
> > Regardless of how precisely one might attempt to define the boundaries
> > of the set of "information resources", there will *always* be ambiguity
> > at the boundary.  This kind of ambiguity is no different from the
> > ambiguity that will always exist with resource identity.  At some point
> > one must admit that there no universally correct answer about where to
> > draw the line: the correct answer will depend on the *application*.  As
> > explained in
> > http://dbooth.org/2007/splitting/
> > this implies that there is no architectural need to define the class of
> > "information resources" as being disjoint with *anything*.
> 
> How would you evaluate "need"? There is no "need" for *any* of this
> web architecture stuff. 

An architecture is designed to have desirable properties -- to support
objectives.  (Of course, those objectives and properties can be hard to
articulate and debatable, but that's a different issue.)  The features
of the architecture are chosen with those properties and objectives in
mind.  When a feature *doesn't* support a desirable property, it isn't
needed.  That's what I mean when I say there is no architectural need to
define the class of "information resources" as being disjoint with
anything: doing so does not benefit the architecture.

> Resources don't "need" to have
> REST-representations, "dog" doesn't have to mean dog, and so on. It's
> a matter of engineering choice.

Right, the design of the web (i.e., the web architecture) was a matter
of engineering choice.  (And a genius design, I might add.)  The notion
of REST-representations is used to help describe how the web works,
i.e., it plays a role in the architecture of the web.

> 
> I also have never understood what you mean by "architectural" - what
> makes one thing architectural, and another thing not?

I mean it is relevant to the architecture.  Specifically, that it is
relevant to the architecture of the semantic web as a software
architecture
http://en.wikipedia.org/wiki/Software_architecture
of a distributed computing system.  A feature is "architectural" or
"important to the architecture" if it is instrumental in causing the
system as a whole to function as desired.  

> 
> > Hence, by
> > Occam's Razor, and to avoid all of this pointless debate about where the
> > boundary *should* be, the architecture *should* *not* define the class
> > of "information resources" as being disjoint with *anything*.
> 
> I was not trying to classify every possible thing as being in or out
> of the class, nor is that an interesting or even meaningful goal. I
> don't know how you read it that way.
> 
> I will clarify in the note that the important thing is the nature of
> the relation W, and that attempts to explain its domain (the class WR)
> are really just desperate and incomplete attempts to explain what W
> means. As I've said, the goal is that the "boundaries" of WR will fall
> out as a side effect of the meaning (axioms, consequences) of W.

Well in that case you shouldn't *assume* that WR is a *proper* subclass
of T.  Just define it to be a *subclass* of T.

> 
> > This does not mean that the notion of "information resource" is useless.
> > It plays a role in the architecture, in that "information resources" are
> > the things that have "representations" (in the AWWW sense).
> > Furthermore, knowing that a resource *is* an "information resource" may
> > be relevant to a particular application even though the class of
> > "information resource" is not disjoint with anything, as explained in
> > item #10 in
> > http://lists.w3.org/Archives/Public/public-awwsw/2010May/0066.html
> 
> Can you give a single practical example of a situation where knowing
> that something is an information resource makes any difference - has
> any consequences?  

Sure.  If I'm collecting samples of natural language text and I have
10,000 URIs, some of which I *know* denote w:InformationResources and
some of which I don't know, I'd much rather try to GET pages using those
URIs that I *know* denote w:InformationResources, because I'm much more
likely to receive a 200 response.

> Other than the circular pseudo-situation of
> enabling 200 responses? That would help a lot.

No, because that *is* the essential characteristic of an information
resource: it can have w:Representations.  There's nothing magical about
it.

David

> 
> Jonathan
> 
> > However, avoiding ambiguity *is* an architectural concern: a URI owner
> > *should* *not* use the same URI for things that consumers of that URI
> > are likely to wish to distinguish, as doing so leads to URI collision:
> > http://www.w3.org/TR/webarch/#URI-collision
> >
> > --
> > David Booth, Ph.D.
> > Cleveland Clinic (contractor)
> >
> > Opinions expressed herein are those of the author and do not necessarily
> > reflect those of Cleveland Clinic.
> 
> 


-- 
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 Friday, 28 May 2010 03:34:24 UTC