- From: David Booth <david@dbooth.org>
- Date: Mon, 15 Feb 2010 22:36:45 -0500
- To: AWWSW TF <public-awwsw@w3.org>
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