W3C home > Mailing lists > Public > public-awwsw@w3.org > June 2009

Re: Back to HTTP semantics

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 12 Jun 2009 13:00:11 -0500
Cc: AWWSW TF <public-awwsw@w3.org>
Message-Id: <449B1BB8-2FBA-44A2-898B-6D45272CDB72@ihmc.us>
To: Jonathan Rees <jar@creativecommons.org>
Just a headsup that my contributions will be spotty for a while for  
distracting personal reasons. Not that Im bored or anything, etc...


On Jun 11, 2009, at 4:52 PM, Jonathan Rees wrote:

> On Wed, Jun 10, 2009 at 6:46 PM, Pat Hayes<phayes@ihmc.us> wrote:
>> Well, but don't give up entirely. We can say very weak things in  
>> RDF, and
>> they might turn out to be useful, if only in a mild way. It might  
>> be worth
>> just writing this down and waiting until later to sort out what it  
>> might
>> mean. We have two things, I gather: an entity and a resource, and a
>> corresponds_to property relating the former to the latter. OK,  
>> thats a
>> start. (Pity about "entity', but those are the lexical breaks...)
> "representation" isn't any better. HTTPbis plans to replace "entity"
> with "representation", so I guess I should go with the flow.
>> And we
>> know that corresponds_to is functional, right?
> No, I thought the same entity can correspond_to multiple resources,
> just as two people can have the same weight. They're syntactic units,
> not events, so can be repeated in multiple contexts. What did you have
> in mind?

OK, I guess Im behind the curve here. I thought that entities/ 
representations were indeed individuated at the event/token level  
rather than the syntactic level. OK, if thats wrong then we don't get  
any kind of functionality constraint, true.
> Since correspondence varies with time, I'm wondering what would be
> most useful for curation and modeling purposes: a corresponds_to that
> means that at some time, past, present, or future, the entity
> corresponded/corresponds/will correspond to the resource (this would
> be as in Tim's model); or if the choice of time is contextual or
> indeterminate. Or if there should be two different relationships for
> the two cases. Or a class of events specifying the resource, the
> entity, and one or more parameters, such as time. I think the latter
> is like something Stuart suggested a while back. That might help in a
> treatment of caching.

Apologies for ignorance, but are HTTP responses timestamped in any  
way? Can one tell by looking that something has been cached for a long  
time since it was created? Because if not, I don't see how this can  
help much.

>>> The response
>>> does say quite a bit about the *entity* in the response (the
>>> wa-representation), and we could attempt to capture that. And it is
>>> certainly useful to record the uninterpreted fact of a particular  
>>> HTTP
>>> interaction, such as when it happened and what the request and
>>> response were, in case that can be used in testing or in evidence or
>>> hypothesis generation, but this is more the job of HTTP-in-RDF  
>>> than of
>>> AWWSW. But lacking further assumptions or information, the
>>> wa-representations say almost nothing about the resource. If the URI
>>> owner has even thought about what the URI names (unlikely), they  
>>> might
>>> adhere to just about any ontological or pragmatic stance, and  
>>> still be
>>> within the broad confines of RFC 2616.
>> True.
>>> So to the question, what is the responder saying about a resource?  
>>> my
>>> answer is, lacking other information or assumptions beyond RFC 2616,
>>> nothing.
>> Well, that it is corresponded_to by an entity. That is *something*.  
>> We know
>> for example that there must be many things for which this is not  
>> true,
>> because there aren't enough entities to go round.
> And it would be hard to argue that an entity that carried the text  
> of Anna
> Karenina corresponded_to a resource that was Moby-Dick-on-the-web, or
> that an entity coming from the Citibank home page corresponded_to
> the Bank of America home page. Maybe this is worth a shot. Alan will  
> hate it...
>>> We are therefore finished with this particular part of the
>>> exercise.
>>> Re #2:
> ...
>>> It is important to distinguish between two cases: One where the URI
>>> owner is providing the metadata, in which case it can be considered
>>> constraining or "authoritative", and another where someone else is
>>> providing the metadata based on what is observed in HTTP  
>>> responses, in
>>> which case it might be merely speculative.
>> I know Im in the minority here, but I really think this isn't a  
>> significant
>> distinction, nor indeed should it be. Ownership of the URI has almost
>> nothing to do with what it refers to. That is determined by how it is
>> *used*, and its inherent in the Web that the publisher has  
>> absolutely no
>> control over that once the URI is published.
> Yes, I should have remembered who I was talking to. Ownership only
> matters in TAG court. If I rephrase this then I think I may be able to
> dispense with that hypothesis. The scenario is: A publishes at URI U
> an HTML document describing a person (in prose). B observes content
> 200-gotten at U and publishes RDF that says (perhaps indirectly via a
> domain or range restriction) that U names a document. A later
> publishes RDF that says U names a person. A and B agree that no
> document is a person. Contradiction. I think you are saying: Let the
> marketplace decide - either A and B will live in different worlds, or
> one of them will have to choose to back down. Yes? Fine, but a little
> bit of advance advice (such as httpRange-14 convincing A to not say U
> names a person) can go a long way towards preventing such competition
> - same idea as agreeing on which side of the road to drive on.

OK, I in turn should have remembered that I was talking on the TAG  
line, where we propose rules for good behavior rather than act as Web  
anthropologists. Agreed,   giving the author prior authority makes  
very good sense.

> I''m not an httpRange-14 fanatic, but this seems to me a halfway
> plausible argument in its favor. (I don't see any others.) (The
> alternative of saying the squatter wins because they got there first -
> the distributed first-come first-served principle used in the Linnaean
> system - is also plausible, but the price taxonomists pay for it is
> quite high.) (Another good alternative is for B to stay away from
> RDFing with U until A makes its intentions clear - safe but contrary
> to the encourage-folk-metadata goal.)
>>> For example, if I wrote the above
>>> RDF, and was happy, and then the owner of
>>> http://www.hindawi.com/86874642.html came along later and said
>>>  <http://www.hindawi.com/86874642.html> rdf:type foaf:Person.
>>> I'd be in a bit of a pickle.
>> Well, but you would be in the same pickle even if they had used the  
>> approved
>> HTTP redirection, right? (Or is the point that in that case you  
>> wouldn't
>> have drawn the first conclusion? But why not, if as you say the  
>> owners don't
>> know squat about RDF or indeed care?)
> I guess I would have treated the 303 redirection as a "keep out" sign,
> not because that makes sense but because Tim told me to and I like
> drive-on-the-right (or -left) rules.

What puzzles me is that according to range-14, the 303 isn't a 'keep  
out', its an explicit declaration that I'm **not** going to constrain  
the meaning, so its seems more like an invitation. Oh, unless the  
point is that the authority of the author always applies, and so the  
use of 303 means "I know this has a meaning, and you can't infer it  
from my http behavior, so don't say anything about that unless I tell  
you you can."  Hmmm, I guess that makes sense in a Web-Gricean kind of  
a way.


> And yes, I assume that in the
> future everyone will care about RDF. They just don't do so now. Don't
> squat, because they'll come 'round.
>> In other words, I don't see how this problem, if it is one, relates  
>> to
>> http-range-14.
> OK. I think gratuitous inconsistency is a problem. (Non-gratuitous
> inconsistency is to be celebrated.) But its relation to httpRange-14
> is almost as obscure as httpRange-14 itself.
> Jonathan

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 Friday, 12 June 2009 18:00:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:07 UTC