Re: sketch of an exposition

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.

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

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

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

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

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

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

>   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 Tuesday, 18 May 2010 14:29:48 UTC