Time-varying facts in RDF

On Sun, 2012-01-29 at 11:34 -0800, Pat Hayes wrote:
> On Jan 27, 2012, at 1:13 AM, Andy Seaborne wrote:
> 
> > 
> > 
> > On 27/01/12 03:45, Sandro Hawke wrote:
> >> On Thu, 2012-01-05 at 11:09 +0000, Andy Seaborne wrote:
> >>> - - - - - - - - - -
> >>> 
> >>> I find the name TriG/REST confusing because, for me, identifying the
> >>> dereference action is modelling REST which is the other
> >>> 
> >>> It's more like "TriG/WebCache" -- only one instance of the graph
> >>> containers state is possible.
> >> 
> >> I don't follow your logic.   My thinking in picking the name "TriG/REST"
> >> is that the implied relation is the relation that's kind of at the core
> >> of REST, the relationship between a thing and its 'state'.
> > 
> > The difference is time.
> > 
> > The relationship of URI to value is time-varying in REST.  RDF does not have that natively so using events (or etc) is a way of having a world model with fixed facts that included time-based actions.
> > 
> > >>>  g log:semantics { s p o }.       # TriG "REST" semantics
> > 
> > But that only works for a single point in time - a single run and observation in cwm.  Indeed, rerun the rules and you may well get a different answer (c.f. tax returns).
> > 
> > You can't record that as a fact for a time-varying graph container.  You need an indirection though the act of reading the value.
> > 
> > Test case - how to say :g was { :s :p :o } at time T1 and { :s :p :z } at time T2.
> 
> Right, exactly. This is THE semantic issue here. If we are planning to incorporate any kind of state- or time-sensitive meanings into the RDF semantics, then the whole RDF model needs to be re-thought from the ground up. RIght now, RDF HAS NO NOTION OF STATE OR TIME OR CHANGE IN IT ANYWHERE. (Sorry about the shouting, but it is apparently needed.)  If we are going to put that idea in, the change to RDF will be far more profound and far-reaching than anything we have considered so far. The resulting language will not resemble current RDF at all at the semantic level. It will no longer mesh with OWL or RIF or any of the other formalisms that have been built on it.  Is this kind of a change within our charter?

This issue matters for more than just graph reference, and I think it
might be simpler to talk about it without the graph reference use case
for now.   This is a huge problem with RDF on the Web that I don't think
has been discussed much.

We did talk about it at F2F2.  As I recall:

  * Danbri explained that foaf:age was added because users demanded it,
in spite of his sense that it was bad modeling.

  * Richard said, I think, that this kind of contextualized modeling was
very important to have in RDF, and was commonly seen in real data.

  * You pointed out that the whole vision of RDF as a place where you
just merge graphs breaks if people publish contextualized information
(like foaf:age).  

  * I wondered aloud if we could formalize that.  Like, maybe folks can
indicate that foaf:age is a time-context predicate, so consumers know
they have to use the date-of-publication if they are going to do some
kind of merge.   (Other predicates could be location-sensitive or
speaker sensitive, I suppose.   /me goes off to read
http://en.wikipedia.org/wiki/Indexicality .... )

  * You said you thought there might be a formal approach to that.

I think that's as far as we got.  Sorry if I'm mis-remembered what
anyone said.

To bring it back to log:semantic (aka rdf:graphState, or the implicit
predicate in TriG/REST -- what we see in UC1) -- yes, these are
context-sensitive predicates, just like foaf:age.  They are a huge thorn
in the side of folks (like me!!) who want to just merge graphs, but
maybe we can still make them work by explaining how this
decontextualization is supposed to work.    The only standard I think
that would be needed would be an RDFS way to say which predicates are
time-dependent.

    -- Sandro

> Pat
> 
> 
> 
> > 
> >  Andy
> > 
> > 
> 
> ------------------------------------------------------------
> 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 Wednesday, 1 February 2012 00:09:30 UTC