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

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 is now bound to the resource.  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 Tuesday, 16 February 2010 03:37:13 UTC