Re: Datasets and contextual/temporal semantics

On Sat, 2011-10-15 at 00:05 +0100, Dan Brickley wrote:
> 
> 
> On Friday, 14 October 2011, Jeremy Carroll <jeremy@topquadrant.com>
> wrote:
> > On 10/14/2011 12:42 PM, Sandro Hawke wrote:
> >>
> >> 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,
> >
> > I agree with the sentiment that if dates and times of events are
> important then they should be explicitly modeled. My point about these
> HTTP header mechanisms is that it is basically obligatory on the web
> to participate in these cache control mechanisms and a lot of the
> anxiety about out-of-date data seems to me to be anxiety about our
> implementations that *do not check* to see whether our local copy of
> someone's foaf page is or is not up-to-date with the master copy on
> that person's web site, and is being misplaced as anxiety about the
> underlying specification in RDF Recommendations of a native time
> model.
> 
> 
> 
> Slight aside --- but HTML has the http-equiv construct, eg
> http://www.w3.org/TR/html5/semantics.html#pragma-directives
> 
> While this was no good regarding Http-range14 since even serving up
> such an HTML doc via HTTP 200 means it's too late by time we've got
> the doc to use http-equiv HTML meta to issue different http headers.
> However, maybe here we could use in-HTML metadata to express header
> info, for the cases where real http headers can't be changed?

It seems to me reasonable to allow consumers to learn context
information from various sources.   So the lastUpdateTime, etc, could be
learned from the content, from http-equiv headers (if the RDF is inside
HTML), from http headers, or from nearby data.  

I'd suggest the RDF lastUpdateTime gets priority if specified; if not,
then fall back to HTTP Last-Modified if specified; if it's not specified
either, fall back to HTTP Date.    Something like that.

    -- Sandro

Received on Saturday, 15 October 2011 01:15:51 UTC