W3C home > Mailing lists > Public > public-awwsw@w3.org > May 2010

Re: old threads

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 27 May 2010 10:59:52 -0400
Message-ID: <AANLkTimDsS1AE0b2dIPWz6dc4WO5pW8Ru0I2BsUKeiRX@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: AWWSW TF <public-awwsw@w3.org>
I have never understood what you mean by "binding" but rather than
argue with it let me ask:

- what axioms apply to the relation 'x is bound to y'?
- how would an agent come to believe a statement of the form 'x is bound to y'?
- what operational consequences follow from 'x is bound to y' being true?

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

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

> 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. By sticking to proofs, theories, and
consequences you can put the whole ambiguity question out of scope.
Not that it's uninteresting, just that we don't have anything
particularly insightful to say about it.

In any case AWWW is quite clear that there are things that are not
"information resources". If it doesn't matter whether there exist
things not in this class, then there is no need at all for

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

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

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

> 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?  Other than the circular pseudo-situation of
enabling 200 responses? That would help a lot.


> 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.
Received on Thursday, 27 May 2010 15:00:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC