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

On Wed, 2012-02-01 at 10:52 +0000, 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?

Yes.

I think your point in this thread was originally about the name
"TriG/REST" and I'll concede that such a name doesn't clearly convey the
time-dependence issue.   I'm happy with calling it "TriG/state" or
"TriG/graphState".

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

Right, yes -- I was a bit confused writing the above example because I
was sure you understood the concept just fine, I'd just forgotten that
specific email, sorry.

   -- Sandro

>  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 12:33:50 UTC