Re: Time-varying facts in RDF

On Wed, 2012-02-01 at 10:55 +0000, Andy Seaborne wrote:
> 
> On 01/02/12 00:09, Sandro Hawke wrote:
> > 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.
> 
> It also requires that data with unknown predicates isn't merged (what if 
> that predicate is, in fact, time varying?, what is that assertion is 
> added to the definition after the merge? Oops).

Yes, it is a very painful situation.   The problem is that we're in that
situation now, with foaf:age-style data out there.  Ignoring the problem
(or not addressing it in this Working Group) doesn't make it go away.

> I think we should avoid (strongly) context sensitive semantics in the 
> core of RDF for this WG.

I'm not sure if what I'm suggesting affects the core or not.   Pat has
said the core currently forbids content-sensitive RDF, but I think that
may be only implicit, and clearly it's not done in a way that people
have heard and understood.  (Not to pick on DanBri, but he was in both
prior RDF Working Groups, as an active participant and editor, and he
still went ahead and put "age" in FOAF.)

I'm really just brainstorming about ideas for how we might approach this
problem.   Declaring the context sensitivity of predicates is the only
solution I've heard that takes into account the fact that people are
doing this now.   Other than saying "Don't Do That!" to something people
clearly want to do, ... what other approaches can people think of?

    -- Sandro

>  Andy
> 
> >
> >      -- 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 12:42:25 UTC