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

On 01-02-2012 11:52, Andy Seaborne wrote:
>
>
> 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.

The file scenario in the Provenance Data Model WD appears to be another 
use case to which this design / usage pattern applies. It might be 
useful to work this out in detail:

   http://www.w3.org/TR/prov-dm/#file-scenario

I suggest to do this as joined work with the Prov WG.

Guus

>
> 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, 8 February 2012 21:32:20 UTC