Re: superimposing the Fielding and TBL architectures

Sorry for the missing context, let me fill in gaps (I think I've said
all this in previous emails and documents, but I don't expect you to
keep track of all that)

On Tue, Sep 27, 2011 at 2:04 PM, Pat Hayes <phayes@ihmc.us> wrote:
> OK, a few points.
>
> 1. This diagram suggests that the two resources must be different, but they could be the same thing (I believe...).

Not intended.  Might be different, might be same.

> 2. The diagram glosses over what I think is (and always has been) the key issue, which is that TBL-representation has no single meaning: sometimes it means 'denotes' and sometimes it means 3986-representation, although...

Hmm, no, TimBL uses 'is a representation of' quite consistently,
meaning 'is a wa:Representation that specializes' - the domain is
'generic resources' as laid out in his generic resources note and
elaborated in my 'information resources and web metadata note'.
Specializations inherit properties (*) of what they specialize. Maybe
you find 'generic resource' ontologically incoherent, and I respect
that, but I think it's inferentially sound. If there's a better way to
explain statements like <http://example/doc> dc:title "The Fish" where
the retrieval results show variability other than in title then I
would like to hear it.

(*) not all properties, just almost all of them, see the note.

> 3. ... nobody has ever, AFAIK, given a clear unambiguous account of what 3986-representation actually means.

Agreed. And there never will be one. It says
   "A "representation" is a
   sequence of octets, along with representation metadata describing
   those octets, that constitutes a record of the state of the resource
   at the time when the representation is generated."
The text says what it says. It will never change. We are never going
to get any more information than this.

I find Roy's writings and 3986 (which derives from them) to be less
than coherent, so I am willing to allow that every wa:Representation
is a 3986-representation of every resource (whatever a resource is) -
I have no way to argue against any such proposition.

> 4. When TBL-representation means denotation, TBL-identifies is meaningless, so the diagram kind of breaks at that point.

Not sure what you mean by this. "is a TBL-representation of" is a
relation between wa:Representations and wa:GenericResources; sometimes
I call it "specializes". No denotation in sight. TBL-identifies is
like "denotes" or "names" (subject to TimBL's architecture) which
would hold between a URI and something.

> 5. What is the wa:Representation a representation of? And in what sense of 'representation'?

Term of art.  A wa:Representation is content + certain metadata (media
type, maybe language), such that it can be made part of an HTTP
request or response. Not necessarily a representation of anything.
We've gone through the exercise of attempting to rename this term
several times, with no success.

> On Sep 27, 2011, at 11:01 AM, Jonathan Rees wrote:
>
>> Mulling over designs for httpRange-14(a) opt-in, I made a picture
>> (attached), just for fun, that superimposes the Fielding/3986
>> architecture with the TimBL architecture.
>>
>> What stands out is the common ground: There is general agreement on
>> what constitutes a correct retrieval operation using a URI.
>
> Sure, but not on the status of what is actually retrieved, or how it relates to the 'identified' resource.

Agreed. For http:, the retrieval is correct, according to spec, if it
is 'authorized' by the domain owner. (This is underscored and
amplified by HTTPbis.) For urn:, the retrieval is correct if it agrees
with the 'retrieval' section of the appropriate URN namespace id
registration. For other schemes there are similar considerations that
are independent of "identification" which for the most part is
completely untestable.

>> The
>> agreement derives from the RFCs and from server and client behavior.
>> This is invariant as we modulate theories of what the resource is and
>> what "is a representation of" means.
>>
>> In the Fielding architecture the resource is unconstrained. I can give
>> you a bunch of different resources, and then when you challenge me to
>> prove that there is a resource with those Fielding-representations, I
>> can cook up any story I like, post hoc, and you'd have no way to prove
>> me wrong.
>
> I dont think so. The representation in that loop must be something that can be a retrieval result

sorry, I took that as implicit.  Every retrieval result is a
3986-representation (of something) and every 3986-representation
is a wa:Representation (not *of* anything; wa:Representation is a
type, not a relationship).

I have not found any substantial disagreement about what
'representation' means as a type. I say wa:Representation to emphasize
the type-nature.

> and must also record the current state of the resource. So the 3986-resource must be something that has states which can be recorded in a representation which can be retrieved over a network. That rules out, for example, distant galaxies (too big), sodium atoms (too small) and fictional or abstract entities (no state). In practice it also rules out things like the weather in Oaxcala, actually. Maybe you can refer to this state and describe it, but you can't *record* it.

That is a completely rational interpretation of 3986 and the word
"record", and I would like to agree with you, but I don't think it
will be convincing to those who want to weasel out of it. Here are
some arguments people will make:
- the record can be a partial or an imperfect record, so an image of a
galaxy is a perfectly good a 3986-representation of the galaxy
- we can (sophistically) argue that everything has at least one state,
i.e. stateless things have themselves as their own state
- the interpretation of the record and what constitutes "state" follow
the Humpty Dumpty rule (the server is "authoritative" for its the "is
a 3986-representation of" relationship)

I think the weaseling, while unprincipled, is fair since REST (on
which 3986 is based) was only a post hoc software architecture story
intended to explain proxies and caches and encourage practices that
enable their use. It could not possibly have been intended as
ontology.

Rather than try to make sense of 3986 and Roy's world, I prefer to
cede the ground, treat it as opaque, and let others make whatever
sense they like of it. That's why I want to want to build a consensus
to either (a) let go of some of the freedom accorded by 3986 and 2616
(i.e. adopt an amended httpRange-14(a) rule), or (b) establish an
opt-in protocol that would allow one to reliably relate retrievals to
the thing named by the URI, when one wants to.

Jonathan

>
> Pat
>
>>
>> In Tim's architecture the resource is determined, modulo usually we
>> probably don't care about, by what the correct retrieval results would
>> be. Once those results are determined, there's no choice as to what
>> the resource is. Contrariwise, if the server side commits to what the
>> resource is, we can hold them to it by checking any
>> TBL-representations that they deliver.
>>
>> httpRange-14(a) opt-in would be a statement or protocol element that
>> says that the URI Fielding-identifies the generic resource (i.e. the
>> same thing that it TBL-identifies).
>>
>> Nothing much new here, pretty much what Pat has said in different
>> words (although I put less stock in "access" and more in social
>> agreement over what would constitute correct access were it to occur).
>> Just noodling.
>>
>> Jonathan
>> <gr.png>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>

Received on Tuesday, 27 September 2011 21:21:29 UTC