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