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

Re: sketch of an exposition

From: Jonathan Rees <jar@creativecommons.org>
Date: Wed, 19 May 2010 15:44:31 -0400
Message-ID: <AANLkTincI2w36auuhpmjwMO0-bp60Wx2IzWrl_0XMze8@mail.gmail.com>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: AWWSW TF <public-awwsw@w3.org>
Thanks for your comments.  Responses inline below

On Tue, May 18, 2010 at 10:28 AM, Alan Ruttenberg
<alanruttenberg@gmail.com> wrote:
> On Mon, May 17, 2010 at 5:40 PM, Jonathan Rees <jar@creativecommons.org> wrote:
>> Apologies up front:
>>  - sorry it's rough and unformatted.  I'm trying out expository ideas
>> and terminology & wanted to get this out to you all for critique
>>  - topic not covered: metadata subjects (DC, FRBR, etc.); redirections
>>  - tell me which statements you disagree with! we thrive on
>> statements that are interesting enough that one can argue over them.
>>  - idle question: does every IR have a REST-representation?
>>
>> -Jonathan
>>
>> -------------------
>>
>> Axiomatic method = don't take anything for granted - if some result
>> can't be proved from axioms already stated, do not assume that it is
>> true.
>>
>> Assume a universe of discourse, which I'll call Thing.
>>
>> In formal treatments one needs a way to refer to (or name or
>> designate) things.  For this purpose we may use URIs, although other
>> notations may be useful too.
>>
>> Reference is not objective; when a URI refers to a Thing it's
>> because someone has chosen to have it do so.
>
> These are two issus.
> 1) How a name comes into being, how it is maintained
> 2) Whether we can objectively say what it refers to, once it exists
>
> I don't think they come as a package.

No of course they don't, but how reference comes about is not relevant
at this point in the presentation. I merely want to touch on what
happens, not how what happens comes about.  I will change the wording
to make it clearer perhaps, something like:

"Reference is not objective; when a URI refers to a Thing it's because
someone uses that URI to refer to that Thing. That is, reference is a
three-place relation between an agent, a URI, and a Thing. Usually the
agent is understood - it's the one 'using' the URI in an utterance or
message.

Then the question is how one would falsify a statement of the form
"agent A uses U to refer to T". I don't know - only A has access to
this information, and they might lie...

>> Reference does not imply any special knowledge of a Thing.  I can
>> talk about a thing without knowing exactly which thing I'm talking
>> about - for example, I might be communicating partial knowledge
>> (properties) that I received from someone else.  Reference is not
>> "identification".
>
> Good.

Actually, throwing in the word "identification" is unnecessarily
inflammatory; how about if I qualify that as meaning identification in
the dictionary sense and not the webarch sense.

>> We'll suppose that (in any given conversation or context) a URI refers
>> to at most one Thing.  An agent may take a URI to refer to no Thing at
>> all, or refer to a Thing by multiple URIs, or not take any URI to
>> refer to some Thing.
>>
>> If a URI U refers to some thing T then <U> is another name for T.
>
> You don't need the above line - introduces a new name T for no reason.

Good. I'll see if I can flush the use of <...> entirely, or at least
explain it differently. "If U is a URI then we'll write <U> to
designate the referent of U."

>> Some Things will be what we call 'REST-representations'.
>>
>>   For now think of them as being similar to HTTP 'entities' - they
>>   consist of content and a few headers such as media type.
>>   But we'll figure out the details later.
>>
>>   We don't assume that these REST-representations are 'on the wire'
>>   or associated with particular events or messages.
>>   We reserve the right to refer to them using URIs, but generally
>>   this will be unnecessary.
>>
>> Posit a relationship, which I'll call 'W', between some Things and
>> some 'REST-representations' e.g. W(T,R).
>>
>>   The intent is for W to capture what gets written variously
>>     R is "an entity corresponding to" T (RFC 2616 10.2.1)
>>     T "corresponds to" R (RFC 2616 10.3.1)
>>     R is a representation of the state of T (Fielding and Taylor)
>>     R "encodes information about state" of T (AWWW glossary)
>>     R "is a representation of" T (AWWW 2.4)
>
> The intent is, therefore, to make W incoherent. Unless you mean the
> intent is to decide on a coherent definition for W, ideally as
> strongly connected to what has been previously written and practiced.

I mean for W to stand for whatever meaning one would and/or should get
from a GET/200 exchange. And what that meaning is, is an unknown to be
solved for. Let's figure it out. If you think a GET/200 exchange is
without consequence (logical or otherwise), then W is indeed
meaningless (to you). I'm not sure what you mean by "incoherent"
though or how "incoherent" differs from "meaningless" or
"inconsistent".

I can believe that the meaning of W is *contingent* on other knowledge
(such as the type of the thing), if that's what you mean. I don't see
any problem with that.

It would be great if W could be proven meaningless or inconsistent -
then we wouldn't have to bother with this project at all!

>>   We permit the same REST-representation to be W-related to multiple
>>   Things, i.e. W(T,R) and W(T',R) is consistent with T != T'.
>
> Assumes the identify condition for a representation is *only* equality
> of its bytes + mime types + whatever other details are determined
> later.

That is true in all of the primary treatments of which I'm aware. (Not
satisfied by the theory always raised by certain TAG members that
REST-representations are event-like or "on the wire", but I don't give
that theory much standing as it doesn't seem to be written down
anywhere.) I can make the assumption more explicit.

>>   We permit one Thing to be W-related to more than one
>>   REST-representation, i.e. W(T,R) and W(T,R') is consistent with
>>   R != R'.
>
>>   If you don't accept web architecture as expressed in RFC 2616 in
>>   its rudiments, you should stop reading here.
>>
>> Let us stipulate that a GET/200 HTTP exchange expresses a
>> W-relationship between a Thing and a REST-representation.  That is:
>>  1. If a URI U refers to a Thing <U>, and
>>  2. an HTTP request GET U results in a 200 response carrying
>>     REST-representation R, then
>>  3. we will interpret the exchange as communicating W(<U>, R).
>>
>>   WHETHER WE CHOOSE TO BELIEVE W(<U>, R) IS ANOTHER STORY.
>>   (Consider a buggy or malicious proxy.  HTTPbis starts to address
>>   believability by trying to specify a notion of 'authority'.)
>>   ISSUES OF TRUST AND AUTHORITY WILL BE TREATED SEPARATELY (if we get
>>   around to it).
>
> Good.
>
>>   We might fudge this by speaking of "credible" HTTP exchanges without
>>   saying exactly what that means (as indeed one cannot say).
>>
>> The implication goes in only one direction: a credible GET U/200 R
>> exchange implies W(<U>, R), but the absence of such an exchange does
>> not imply that W(<U>, R) is not the case.
>
> Barely needs to be said. Add statement of open world assumption
> earlier in discourse.

My experience is that for every statement of the form P implies Q in a
presentation of this sort, there will be some ... person ... in the
audience who lays into you because they think you're saying Q implies
P, which of course would imply you're an idiot. So I try to preempt
that kind of confusion as best I can. In this case, it would be
*consistent* at this point to say that W(<U>, R) *if and only if* a
GET/200 historically occurred, so I'm expecting confusion.

I would say "axiomatic method" instead of "open world assumption" but
I guess they're similar.

>> In fact there may be other ways to communicate or infer W(<U>, R) -
>> by consulting a cache, for example.
>>
>> A consequence (or precondition) of this stipulation is that for each
>> URI U for which there is a GET/200 exchange, there exists a Thing <U>
>> that U refers to.  Roughly speaking, all web URIs refer to
>> *something*.
>
> Might have to be careful here. I have in mind URIs that are
> intermediate on a redirection. I haven't thought this through, but
> this seems stronger than it needs to be.

ok, I'll flush "web URI" and stick to the strict consequence.

Where should I put this thing?  Dan has pioneered use of google docs
for TAG work, maybe I should follow his lead.

-Jonathan

>>   This is the way in which the web is "grandfathered" into the semantic web.
>>
>>   Although it's not falsifiable, this seems to be the idea that IH
>>   denies (there are no resources).
>>
>> This is a powerful constraint.  Since servers are "authoritative",
>> they can produce whatever 200 responses they like for a URI that they
>> control, and not violate protocol.  That is, for an *arbitrary* set of
>> REST-representations concoctable by a server, we've committed to
>> allowing the existence of a Thing that has those REST-representations.
>>
>> Note on what is NOT provable at this point
>>
>>   We haven't created a way to falsify any W-statement.  That is,
>>   there is no way to infer the W(T,R) does not hold.  Therefore this
>>   theory is satisfiable by having a single Thing T, that all URIs
>>   refer to, having the property that W(T,R) for all
>>   REST-representations R.
>>
>> Note on time
>>
>>   Although W is time-sensitive, we'll ignore time as it is not
>>   helpful to account for it right now.  later we'll redo the
>>   treatment to take time into account.
>>
>>   So W is OK as a binary relation for now.  Later it might be
>>   W(X,R,t).
>>
>> Note on RDF
>>
>>   RDF is just a vector for FOL, and FOL is a lot easier to read and
>>   think about, so better to start with FOL and then render it in RDF
>>   (and perhaps other notations) later on.
>>
>> No number of GET/200 exchanges can tell you what a resource is.
>> There are several reasons for this.
>>  1. The absence of a GET/200 giving W(T,R) does not mean that W(T,R)
>>     isn't true.
>>  2. Two Things T,T' could have W(T,R) but not W(T',R) for some
>>     REST-representation R not hitherto obtained by a GET/200 exchange.
>>  3. T and T' could agree on the truth or falsehood of *every*
>>     W-statement and *still* be different
>>
>> Information distinguishing such Things, if it were available, would
>> have to come through a different channel (e.g. RDF).
>>
>> httpRange-14
>> ------------
>>
>> Let IR be a proper subclass of Thing containing the domain of W,
>> i.e. suppose W(T,R) implies that T is in IR.
>>
>> Properties of IR:
>>   Grandfathering: "web resources" (those for which we get 200s) are in IR
>>     - this is a consequence of the above stipulation.
>>   TimBL: "generic resources" are in IR (genont)
>>   TimBL: literary works are in IR  (Pat Hayes disagrees)
>>
>>   TimBL: dogs and people are disjoint with IR
>>     (by extension: anything physical)
>>   TimBL: strings and numbers are disjoint with IR
>>     (by extension: anything mathematical)
>>   TimBL: REST-representation is disjoint with IR
>>     (JAR doesn't see the point)
>>   Pat: RDF graphs are not in IR
>>
>>   TimBL: members of IR are not determined by their W-relations
>>     i.e. one might have W(T,R) = W(T',R) for all REST-representations
>>     R, yet T != T'   [time sheet example]
>>
>> We have three theories of IR in the works now: Dan's speaks-for
>> theory, Alan's what-is-on-the-web theory, and JAR's property-transfer
>> theory.
>
Received on Wednesday, 19 May 2010 19:45:04 UTC

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