Re: old threads

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.
>
>

Received on Friday, 28 May 2010 14:00:22 UTC