Re: More comments on draft report

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, 2 February 2010 13:58:36 UTC