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

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.

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?

     -- 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 03:27:19 UTC