Re: old threads

I'll try.  But can you be more specific about which parts you don't
understand, of what I wrote below?  Otherwise I don't know what things I
should be trying to further explain.  For example, did you not
understand the explanation I gave of what I meant by "binding"?  

David

On Fri, 2010-05-28 at 09:59 -0400, Jonathan Rees wrote:
> Sorry, I've heard you say all these things many times and I *still*
> don't get it; you're just asserting, not teaching. Maybe if you gave
> some practical use cases where there's a real problem to be solved
> (and making no appeal to non-operational words like "binding" or
> "identity") that would help.
> 
> Jonathan
> 
> On Thu, May 27, 2010 at 11:33 PM, David Booth <david@dbooth.org> wrote:
> > 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.
> >
> >
> 
> 
> 


-- 
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 16:08:43 UTC