W3C home > Mailing lists > Public > public-awwsw@w3.org > February 2011

Re: hold up

From: Jonathan Rees <jar@creativecommons.org>
Date: Sun, 27 Feb 2011 13:33:42 -0500
Message-ID: <AANLkTik2RRe2mv7z-Uq_32AHuzj-ph+06ZLq-UgkWhPp@mail.gmail.com>
To: nathan@webr3.org
Cc: AWWSW TF <public-awwsw@w3.org>
On Sat, Feb 26, 2011 at 4:40 PM, Nathan <nathan@webr3.org> wrote:
> Jonathan Rees wrote:
>>
>> On Sat, Feb 26, 2011 at 11:26 AM, Nathan <nathan@webr3.org> wrote:
>>>
>>> Jonathan Rees wrote:
>>>>
>>>> On Sat, Feb 26, 2011 at 4:26 AM, Nathan <nathan@webr3.org> wrote:
>>>>>
>>>>> I've just been reading huge chunks of archived messages again, and
>>>>> there's a
>>>>> consistent phrase coming out that's just flat out wrong.
>>>>>
>>>>>  "a representation of the resource"
>>>>>
>>>>> that's not what HTTP and the specs say, a representation is a
>>>>> representation
>>>>> of the current or intended state of a resource. not a representation of
>>>>> the
>>>>> resource.
>>>>
>>>> While I agree that the first is unjustified, I'm not convinced that
>>>> the second has any support in the specs, other than fleeting mention
>>>> in AWWW.
>>>
>>> this seems pretty clear to me:
>>>
>>>  A "representation" is information in a format that can be readily
>>>  communicated from one party to another.  A resource representation is
>>>  information that reflects the state of that resource, as observed at
>>>  some point in the past (e.g., in a response to GET) or to be desired
>>>  at some point in the future (e.g., in a PUT request).
>>>
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-12#section-4
>>
>> I wasn't counting HTTPbis as a 'spec' because it hasn't gone to last
>> call (or equivalent) yet... but you're right, Roy is pushing this new
>> terminology (borrowed from AWWW perhaps), and I'm not exactly happy
>> about it, but I'm not sure what harm it will result.
>
> afaict none, considering HTTP is just a transfer protocol, and I have to
> confess I'm of the opposite opinion and see it as being very important, we
> need to be able to GET a document, edit it and PUT the new version back,
> that state transfer is important, critical even.

Ah yes, that would be very nice.  I remember that the 2116 definition
of PUT says nothing about what the server is supposed to do, and maybe
talking about 'change' or 'state' is the only way to explain its
obligations.

You have to be careful, as there is no way an observer can distinguish
a PUT that changes the state of the server from a PUT that changes the
state of the resource. For instance, acceptance of a PUT for Moby Dick
may merely indicate acceptance that the representation is an
acceptable one for Moby Dick, not necessarily any change on the part
of Moby Dick itself - and this may be just fine.  Also, success of a
PUT need not be reflected in the result of future GET requests. The
decision of which among many representations to return is the server's
and it may just decide not to deliver the one you PUT in response to a
GET.

PUT is part of the REST model and makes more sense there, so I'd be
willing to say REST should probably be brought into play if you want
some kind of contract around PUT.

>>> but even regardless of that, if you GET a 200 OK then the URI must refer
>>> to
>>> a resource,
>>
>> I could argue against this... what it refers to depends on who is
>> writing and reading the reference...
>
> you could be reading to much in to this, if you GET <u> and receive a 200 OK
> then you know that what <u> refers to, exists. As in, you've established it
> exists, as opposed to a 404 where you simply don't know.

OK. At least you know the server is willing to be held to that,
assuming the server is respecting the specification. That doesn't mean
it's true, though.

> see http://webr3.org/http-combinations.txt "The possible states of a
> resource are:..." section

Good.

Nit: With a successful PUT, the state of the resource would only
change if what is PUT is not currently authorized.

>>> which has a state (even if that state is just existence),
>>
>> ... not clear to me ...
>
> as above
>
>>> and
>>> the HTTP Interface is a property of that resource,
>>
>> ... not at all clear to me, and this seems to contradict TimBL's view
>> that Moby Dick the novel is an information resource ...
>
> Moby Dick the book/novel has been digitized/webized and one of it's many
> properties is that a webresentation of it can be accessed via HTTP; one way
> of looking at it is to imagine that every single copy of moby dick has been
> removed from existence, all that is apart from this one
> http://www.princeton.edu/~batke/moby/ does moby dick the novel still exist
> such that all it's vital properties remain? yes.

(Not sure what accessibility has to do with it.  Suppose that the only
copy were aboard the Voyager 2 spacecraft. The novel would still
exist.)

OK, now I see what you mean, and the confusion is about what is and
isn't "a property of a resource."
In RDF you can create relationships that are arbitrarily remote and
they're called 'properties', as in a doorknob being a property of a
cat because the cat lives in a house that has a door that has a
doorknob. One doesn't say this in ordinary language. Something being
on the web, or in a library, is to me much more a property of the web
or library than of the thing. But no matter.

> The same is true for a
> particular photo, a video, the declaration of independence, a book about
> moby dick the novel - and similarly this is a property which a another set
> of things does not have, for example me, you, a toucan and Dan's car.
>
>>> therefore the class of all HTTP resources
>>
>> definition please?
>
> ... this is an informal definition, we can formalize later ...
>
>>> must be the class of all things which exist and have the
>>> HTTP Interface as a property - we can say everything else is hidden by
>>> the
>>> interface, but the aforemention still remains true, does it not?
>>
>> How would you know of a given thing, say seven or the color white or
>> the George Washington Bridge, that it did *not* "have the HTTP
>> Interface as a property"? (Other than by reading and believing what
>> TimBL and I have been saying on the subject?)
>
> the George Washington Bridge is an easy one, and as described above, it
> cannot exist on the web, it cannot be digitized/webized transferred via a
> transfer protocol. As for the number seven, that's one for the philosophers
> to discuss mathematical realism, and the reason why we have literals in RDF
> for such platonic abstractions - my gut is "no" though, a description of
> sure, the number seven, no. As for the color white, much the same as with
> numbers.
>
>> You have to be very careful here because "resources" and
>> "representations" and "state" and all that are at best theories, at
>> worst gibberish, or fetishes. Talking about this stuff ontologically
>> is just begging for trouble. We are not linguists or philosophers, we
>> are engineers, and we need to talk like engineers. When I say that in
>> my opinion a dereferenceable URI ought to refer to the information
>> resource at that URI, I am not talking ontology, I have very
>> operational and consequential behavior in mind. I spent a lot of time
>> scouring the specs for the kind of ontological hints you seem to be
>> looking for, and concluded that they're just not there. That's why I
>> think we need a consensus document - some solution needs to be
>> engineered, and neither the RFCs nor the TAG's resolution gives the
>> community what it needs.
>
> don't worry, I'm of the same school of thought as you, IRs exist, they are a
> distinct class of thing, and I'm just looking to get the vital properties
> that distinguish an IR from something which is not an IR. If one can prove
> that IRs exist, and that dereferencable HTTP URIs cannot refer to anything
> but an IR, in reality not just specs and words and ontologies, then we can
> move forward (and potentially not waste time on a plan B which would
> conflict with reality).

I am not so sure that they "exist" in any properly ontological sense -
so I'm not sure we're of the same school. My 'requirements' report
came about from despair at finding any sensible definition or 'vital
properties'. As far as I'm concerned the axioms are an adequate
explanation, a solution to a problem I've been struggling with for
over three years, so I've stopped looking. But of something 'vital'
would be more appealing, since using RDF purely operationally
(cynically, you might say) as I'm suggesting goes against the spirit
of the semantic web endeavor.

The thing to do would be to formulate a candidate 'vital' definition,
then see if it's a model of the axioms. Any discrepancy will teach us
something about either 'vital properties' or the axioms.

Best
Jonathan

> Best,
>
> Nathan
Received on Sunday, 27 February 2011 18:34:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 27 February 2011 18:34:20 GMT