W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2012

Re: Time-varying facts in RDF

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 01 Feb 2012 10:55:09 +0000
Message-ID: <4F291A0D.1080907@epimorphics.com>
To: Sandro Hawke <sandro@w3.org>
CC: Pat Hayes <phayes@ihmc.us>, "public-rdf-wg@w3.org WG" <public-rdf-wg@w3.org>


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).

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

	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 10:55:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:03 UTC