More comments on draft report

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 04:31:01 UTC