Re: revised sketch

Hi Jonathan,

Again, nice work.  My comments are below.

On Mon, 2010-05-24 at 16:58 -0400, Jonathan Rees wrote:
> For those of you attending tomorrow's call (if there are any) I'd be
> grateful if you could take a look at this, even if only a little...
> 
> http://www.w3.org/2001/tag/awwsw/web-semantics-20100524.txt

1. How about adding line numbers or section numbers, so that we can
refer to portions more easily?

2. Regarding this: "Whether we choose to "believe" a statement
W(<U>,R) . . . ."  It isn't clear whether you are talking about: (a)
believing that the relation W(<U>,R) itself holds, or (b) believing any
assertions that may be contained in R.

3. "the current HTML editor, who has said that resources don't exist".
How about naming him?  Or deleting this mention?  It otherwise forces
the reader to guess or search.

4. If you're going to have a "Note on time", then you REALLY should have
a "Note on requests", because w:Representations *also* depend on
requests.

5. "FOL is a lot easier to read and think about".  This is a matter of
personal preference.  Personally, I am more used to thinking in RDF than
FOL.  How about re-phrasing this to "FOL is easy to read and think
about"?

6. "The TAG's httpRange-14 decision throws doubt on location/designation
practice by advising against the use of http: URIs to name certain
kinds of things".  Whoa!  No it doesn't.  
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039
It simply says that if there's a 2xx response then the resource "*is* an
information resource".  But as I've explained, the resource can also be
something else at the same time.  

7. "There is so much controversy over the use of http: URIs".  I think
this is stated too pessimistically.  How about: "There is enough
confusion over the use of http: URIs"?

8. "The 303 issue is a red herring since even if # URIs are used you
have to decide whether you need a # URI at all."  Actually, I think 303
makes the issue *clearer* than with # URIs, because # URIs introduce the
(red herring) issue that the meaning of the fragID depends on the
content type returned.

9. "It would be nice if we could provide a defense of the practice (of
using URIs involved in GET/200 exchanges to refer to members of class
WR)".  Class WR hasn't been introduced yet.  You define it later in the text.

10. "That WR is a *proper* subclass of Thing is, I believe, implied by
the httpRange-14 resolution - otherwise why would one raise the
question?"  No, it isn't by the httpRange-14 resolution -- not directly,
at least.  You only get that it is a *proper* subclass if you *also*
assume that the class of "information resources" (or WR) is disjoint
with some other class, and that assumption should not be made.  The AWWW
describes "information resource" as though it is, but as I've explained
before in
http://lists.w3.org/Archives/Public/public-awwsw/2010May/0016.html 
http://dbooth.org/2007/splitting/#httpRange-14
it is a mistake to do so, because it is not necessary to the
architecture.

Bear in mind that it is useful to know "X is a member of class WR" even
if class WR is not disjoint with any other class.  This is the
difference between something being provably true (X a WR) versus not
provably false, and it is a key difference between open and closed world
reasoning.

11. Regarding "Axioms proposed for WR", if you delete all of
disjointness axioms everything works fine.   :)

12. "Dan C's speaks-for theory".  I like it, but it seems orthogonal to
the issue of base issue of what is WR.  I think the "speaks-for" theory
can be layered on top of whatever else we come up with.

13. Regarding Redirects, I think we need to explore ways to explain them
in terms of changes to variable bindings.  For example, a permanent
redirect seems to me that it is saying that the resource that had been
bound to URI U1 is no longer bound to URI U1, and URU U2 is now bound to
that resource.  In other words, before the redirect <U1> denoted T, but
after the redirect, <U2> denotes T.

We should also explore other ways to explain redirects.



-- 
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 Tuesday, 25 May 2010 02:21:11 UTC