Re: Semantics of 301 [was Re: More comments on draft report]

How about if we use "denotes" in the model theory sense and
"associated with" for some phenomenon in our domain of discourse. If
we use two distinct words then my objection about meta-modeling mostly
goes away.

My view is that we don't really care about what URIs denote to the
agents we're studying; that's not observable. We just want to know
what statements the agents make using the URIs. That is, the machine
we're specifying takes a series of HTTP exchanges as input, and
produces an RDF graph as output. You look at the graph and consider
its provenance, and decide whether you're willing to believe it, and
if you are, then it will inform your own private model (denotations).
If it's inconsistent, or if it makes statements you disagree with or
that could be dangerous, then don't believe it.

Maybe if you could show what RDF graph you would curate in the case of
domain name sale or a 301 that changes different(U,V) from false to
true that would help. (I don't understand how you would ever deduce
that occurrences of a URI in two exchanges could be converted into the
same URI in the graph.) But I would prefer to just say this
complication of extracting meaningful information from a situation
that is on the surface inconsistent is out of scope. The problem is
hard enough already.

Jonathan

On Mon, Feb 15, 2010 at 10:36 PM, David Booth <david@dbooth.org> wrote:
> On our last call, Jonathan and I briefly discussed the semantics of an
> HTTP 301 code (Moved Permanently).  I offered the view a 301 means that
> the binding between a URI and the resource that it denotes has changed:
> a new URI

it might be an old URI

> is now bound to the resource.

What happened to the resource it was bound to before?  Anyhow the
agent authorizing the 301 may not even have any authority over the
(binding of the) target URI! How could the 301 have any effect at all
on the target?

> Jonathan resisted, asserting
> that we don't need to use "meta" modeling to capture these semantics.  I
> don't consider this to be meta modeling, but merely capturing more of
> the semantics of the whole URI lifecycle.  And the idea of explicitly
> modeling the binding of a URI to a resource seems very natural to me.
>
> For example, suppose a URI domain name is sold, such that a URI U that
> was previously associated with one document X is later bound to a
> completely different (and unrelated) document Y.  Surely the most
> natural way to think about that situation is that at one time the URI is
> bound to X and at another time that same URI is bound to Y, rather than
> insisting that the URI has only one binding to a resource that somehow
> encompasses both X and Y.  Finally, if one accepts this idea, then a 301
> response would seem like a logical way to indicate that a resource now
> has a new URI binding.
>
> What do others think of this situation?
>
> If there is interest, we could also discuss this on tomorrow's call.
>
> David
>
> On Tue, 2010-02-02 at 08:58 -0500, David Booth wrote:
>> I've been thinking further about the "speaksFor" relation and how it
>> fits with the semantics of RFC2616.  I don't have this entirely worked
>> out, but here are my thoughts so far.
>>
>> When you are given a URI, normally you are not merely given the URI, you
>> are given the URI for a particular *resource* that you want.  ("Here is
>> the URI for that document on trains that you wanted.")  The URI is
>> accepted under the belief that the server responding to a GET request on
>> that URI is authorized to "speak for" that resource.  To express this,
>> we might introduce a ht:speaksFor predicate, such that "?u
>> ht:speaksFor ?r" means "the server that is authorized (by the HTTP spec)
>> to respond to requests for URI ?u is authorized to speak for
>> resource ?r", which means that it is authorized to: (a) delegate to
>> another server; (b) provide authoritative metadata about ?r; and (c)
>> serve awww:representations.
>>
>> Thus, prior to the GET request, the client has something like this in
>> mind:
>>
>>   # Let ?r be the resource on trains that I want.
>>   ?r dc:primaryTopic "Trains" .
>>   "http://example/uriA" ht:speaksFor ?r .
>>
>> Now if the client does a GET request on that URI and receives a 200
>> response with entity ?e at time ?t, then the client is able to assert a
>> ht:Correspondence,
>> pretty much as described in
>> http://www.w3.org/2001/tag/awwsw/http-semantics-report.html
>> although I've added a ht:uri property and dropped the ht:holdsUntil
>> property:
>>
>>   [] a ht:Correspondence ;
>>       ht:fromResource ?r ;
>>       ht:uri "http://example/uriA" ;
>>       ht:contentEntity ?e ;
>>       ht:heldAt ?t .
>>
>> However, suppose the client instead gets a 301 (Moved Permanently)
>> response with new Location "http://example/uriB".  This result could be
>> expressed as:
>>
>>   "http://example/uriB" ht:speaksFor ?r .
>>
>> This new fact motivates the client to do a GET on http://example/uriB in
>> search of the desired resource ?r.  If this GET yields a 200 response at
>> time ?t, then the client may assert a correspondence between the
>> *original* desired resource ?r, the received entity ?e and the new URI
>> http://example/uriB as follows:
>>
>>   [] a ht:Correspondence ;
>>       ht:fromResource ?r ;
>>       ht:uri "http://example/uriB" ;
>>       ht:contentEntity ?e ;
>>       ht:heldAt ?t .
>>
>> Finally, an approach like this could also capture the semantics of 303.
>> Suppose we create another predicate "?u ht:speaksAbout ?" that means
>> "the server that is authorized to respond to requests on URI ?u is
>> authorized to provide authoritative metadata about resource ?r".  And
>> suppose we create a predicate "?u
>> ht:hasNoAvailableRepresentationsFor ?r" that means "the server
>> authorized to respond to requests on URI ?u has no awww:representations
>> of ?r available".  Then if a GET on "http://example/uriA" yields a 303
>> with Location "http://example/uriC", the client could conclude:
>>
>>   "http://example/uriA" ht:hasNoAvailableRepresentationsFor ?r .
>>   "http://example/uriC" ht:speaksAbout ?r .
>>
>> David Booth
>>
>>
>> On Mon, 2010-02-01 at 23:30 -0500, David Booth wrote:
>> > I've done a bit of work on my action items, but as I got into it I
>> > decided that I needed to refactor my n3 code, and I haven't finished
>> > doing that, so I'm afraid I do not yet have any n3 to show.
>> >
>> > However, I also read through our draft report
>> > http://www.w3.org/2001/tag/awwsw/http-semantics-report.html
>> > and noted the following comments.  Some of these are concrete
>> > suggestions for changes, others are merely food for thought.
>> >
>> > 1. In "Spacetime worm":
>> > s/"to" the entity R/"to" the resource R/
>> >
>> > 2. In "Spacetime worm":
>> > 'A correspondence is of only a single content entity ("of" is
>> > functional)'
>> > But surely the same content entity can be returned at different times?
>> > It seems to me that the functional nature should be *from* resource R
>> > and time T *to* entity E.  That would better match how people
>> > operationally use HTTP.
>> > Accordingly, I suggest renaming:
>> > s/ht:ofContentEntity/ht:toContentEntity/
>> > s/ht:toResource/ht:fromResource/
>> >
>> > 3. In "Correspondences":
>> > The ht:heldAt description says: "This relation might be inferred, for
>> > example, from the Date: or Last-Modified: header of a 200 response to a
>> > GET."  What about the time when the HTTP request was issued, regardless
>> > of what the headers say?   However, this gets into the question of
>> > whether the times in the headers are correct.
>> > I think we should make the simplifying assumption that times specified
>> > in the headers are correct, so the semantics can be interpreted as
>> > saying "*if* header times are correct, then . . . ".
>> >
>> > 4. In "Coincidences":
>> > I think it would be more helpful to call this "delegation" instead of
>> > "coincidence".  I agree that "it is a server that delegates to another
>> > server", but this is a technical detail that is immaterial to the
>> > ontology, because servers do not appear in the ontology.  So although I
>> > do think it is useful to point out this technicality, it would be easier
>> > to read if we used the term "delegation" instead of "coincidence".
>> >
>> > 5. s/may be derive from/may be derived from/
>> >
>> > 6. s/aren't rules out/aren't ruled out/
>> >
>> > 7. s/ContentEntity/Entity/g
>> > just to be shorter.
>> >
>> > 8. Regarding 301 Moved Permanently,
>> > www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
>> > it seems to me that this code is talking explicitly about the binding of
>> > a URI to a resource.  It implies that the old URI is not longer bound to
>> > the desired resource (because it has "moved permanently"), but the URI
>> > given in the Location header is bound to it.  Therefore, if we are going
>> > to accurately capture the meaning of this status code, we need to
>> > explicitly model URI-resource bindings in the RDF, rather than using
>> > URIs as though they directly (and permanently) denote resources, like
>> > variables.  This means that the Correspondence class should be used
>> > something like:
>> >
>> > [ a ht:Correspondence ]
>> >   ht:resource [ log:uri "http://example/old-uri" ] .
>> >
>> > 9. Regarding time, I think a simpler way to deal with time would be
>> > to assume that time is discrete, with a minimum universal "tick"
>> > duration.  Time theoreticians may know better whether this would cause
>> > any special problems, but if not, then it would allow us model
>> > ht:Correspondences using a single ht:heldAt property instead of having
>> > both a ht:heldAt property and a ht:holdsUntil property.
>> >
>> > 10. Regarding the Last-Modified header and 301 (Moved Permanently),
>> > suppose a document at http://example/uriA is modified at 3pm.  At 5pm,
>> > the document is "moved permanently" to http://example/uriB , though the
>> > content is not changed.  A GET request on http://example/uriB is made at
>> > 7pm.  Should the Last-Modified header say 3pm or 5pm?  My answer: 5pm,
>> > as 3pm would be misleading to the client.  Why?  Suppose
>> > http://example/uriB is used for a different purpose until 5pm.  For
>> > example, a GET on http://example/uriB might return representations for a
>> > completely different resource at 4pm, which the client may have cached.
>> > When the client does a HEAD on http://example/uriB at 6pm, if the
>> > Last-Modified header says 3pm, the client would erroneously conclude
>> > that the cached value of the 4pm GET was still good.  This implies that
>> > we should think of a ht:Correspondence as not merely between a resource
>> > and an entity (at a particular time), but between a resource, a
>> > particular *URI* and an entity (at a particular time).
>> >
>> >
>> >
>> >
>>
>>
>
>
> --
> David Booth, Ph.D.
> Cleveland Clinic (contractor)
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of Cleveland Clinic.
>
>
>

Received on Wednesday, 17 February 2010 18:30:21 UTC