Re: hold up

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.

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

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

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

Best,

Nathan

Received on Saturday, 26 February 2011 21:41:30 UTC