Re: Back to HTTP semantics

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?

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.

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

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

Received on Thursday, 11 June 2009 21:52:37 UTC