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

On 01/02/12 03:27, Sandro Hawke wrote:
> On Fri, 2012-01-27 at 09:13 +0000, 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.
>

Do you agree that log:semantics is a time varying predicate?

> That test case is UC2.   I sketched out UC2 with TriG/REST in the
> original "three designs" email [1].
> Basically you do some kind of
> rolling-snapshots, making a new URI for each state of :g that you care
> about.
>
> In TriG/REST, I'd write your situation as:
>
> {
>    <uuid:bae394df-ff39-43db-9f8f-73266b3a772f>  a rdf:FrozenResource.
>    <uuid:9247b06f-b1f4-4bb4-bb69-422cf34dbc36>  a rdf:FrozenResource.
>    [ a rdf:Snapshot;
>      rdf:atTime T1;
>      rdf:snapshotOf :g;
>      rdf:copiedTo<uuid:bae394df-ff39-43db-9f8f-73266b3a772f>
>    ].
>    [ a rdf:Snapshot;
>      rdf:atTime T2;
>      rdf:snapshotOf :g;
>      rdf:copiedTo<uuid:9247b06f-b1f4-4bb4-bb69-422cf34dbc36>
>    ].
> }
> <uuid:bae394df-ff39-43db-9f8f-73266b3a772f>  { :s :p :o }.
> <uuid:9247b06f-b1f4-4bb4-bb69-422cf34dbc36>  { :s :p :z }.
>
> Make sense?

Yes:
http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0148.html

and also the time-event modelling discussion at F2F2.

 Andy



>
>       -- Sandro
>
>
> [1] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Jan/0021.html
> [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Oct/0152.html
>
>
>
>
>

Received on Wednesday, 1 February 2012 10:53:01 UTC