- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 14 Oct 2011 15:42:18 -0400
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Jeremy Carroll <jeremy@topquadrant.com>, public-rdf-wg@w3.org
On Thu, 2011-10-13 at 22:04 -0500, Pat Hayes wrote: > Jeremy, does all this apply to every format for RDF? Content served via HTTP and HTTPS has a "Date" header, which tells you the time on the server when it was served, but even better it can have a "Last-Modified" header which gives you an earlier time and an "Expires" header (in various forms, relative and absolute) which gives you a later time. TimBL used to argue that those times should be understand as Valid-Since and Valid-Until times [1]. Given how they sit in the caching mechanism, they are perhaps closer to transaction times, but I think Tim's point was that one should try to align those sets of times anyway. Eventually he stopped pushing for this, when people told him that they were (a) too hard to control on their web servers, and (b) they want to be using them to control HTTP caching -- as intended -- not to be making claims about the world. This is why I suggested just putting the times in the data itself, either in the graph itself or in a nearby metadata graph, in my Rolling Snapshots sketch [2] on Tuesday. My thinking is that if people want to write: :Alice foaf:age 26. maybe we can get then to also say: <> eg:lastUpdated "2011-10-01"^^xs:dateTime. And now I'm thinking there could be lastUpdateTime, lastUpdateLocation, lastUpdatedBy, ... and anything else we need for decontextualizing. Maybe "last verify" is closer to the true meaning". It could be creationTime or publicationTime, but when people are editing documents in place, I think we need to make clear this info should be updated not left as-in. At the moment, I can't see any problem with generally putting that metadata in the graph. And if some wants to put it elsewhere, that's fine, as long as that "elsewhere" can be easily found (eg via http Link header), and has a way to refer to the graph snapshot. (referring to the g-box would be dangerous, in terms of getting out of sync.) -- Sandro [1] folks not familiar with those terms, see http://en.wikipedia.org/wiki/Temporal_database [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0152.html > Pat > > On Oct 13, 2011, at 8:59 PM, Jeremy Carroll wrote: > > > On 10/13/2011 4:49 PM, Pat Hayes wrote: > >> Factual data that is time-dependent but not given with time information is bad. > > This is a non-issue. > > > > On the WEB it is not possible to publish any information without also giving some time-information. The HTTP headers have it. > > > > Essentially, we have two graphs of interest - the graph on the server, and the graph on the client. The graph on the client is a cached copy of the graph on the server, and the considerations of: > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13 > > apply > > > > > > > > (I do not know if any semantic web implementers have taken this point of view, but whether or not there is implementation experience, this seems to be to have been standardized long ago). > > > > A Graph that says that Alice is 29, when in fact she is 30, and the updated information is available from the Graph's document URL is a stale cached copy that should be discarded. If a particular implementation does not have the mechanisms to check the HTTP headers to work this out, then that implementation is faulty, and it needn't concern us in this WG, other than we might wish to write a test case. (And we might also wish to fix our code). > > > > Jeremy > > > > > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > >
Received on Friday, 14 October 2011 19:42:30 UTC