W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Re: Datasets and contextual/temporal semantics

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
Message-ID: <1318621338.4884.52.camel@waldron>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:45 GMT