Re: Three solution designs to the first three Graphs use cases

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.

 Andy

Received on Friday, 27 January 2012 09:13:49 UTC