Re: Time-varying g-boxes : a dataset pattern

On Tue, 2011-10-11 at 10:57 -0400, David Wood wrote:
> Sorry, I must be missing something substantial.  Why would you want to record dataset changes upon access instead of only on g-box modification?

I think it's kind of brilliant.   Really, I think, you'd want to record
changes on each access if the data was changed since the previous record
of change.  That way if the data changes frequently but is accessed
infrequently, or if it changes infrequently but is accessed frequently
-- either way -- you only need to record changes (relatively)
infrequently.

    -- Sandro

> Regards,
> Dave
> 
> 
> On Oct 11, 2011, at 8:47, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
> 
> > This is a quick sketch of how an application that requires quite
> > detailed information about a g-box might go about it to illustrate the
> > idea of dataset patterns.
> > 
> > I'm sorry this is a bit rushed and a bit late.
> > 
> >    Andy
> > 
> > ==== Time-varying g-boxes
> > 
> > This is a Dataset Usage Pattern for recording the state of a resource
> > [AWWW], where accessing the resource using HTTP GET results in receiving
> > an RDF graph.  The state of the resource is expected to change over
> > time. The application wishes to have a record of the state of the
> > resources at various times (it does not wish to just have a copy of the
> > latest observed state).
> > 
> > Each time a resource is accessed a new graph is added to the dataset as
> > named graph.  The URI in the (URI, Graph) pair for the named graph is a
> > unique identifier created as part of the process of accessing the
> > resource.  The identifier is a URI and is never reused. The identifier
> > is not the URL of the resource.
> > 
> > Multiple resources can be tracked in the same dataset.
> > 
> > Typically the identifier is a non-dereferencable URI such as a "tag:" or
> > a "urn:uuid:".  URIs in these scheme can be allocated cheaply and
> > locally but guaranteed to be globally unique.
> > 
> > A description of the action that resulted in the triples is recorded.
> > In the example below it is stored in the default graph of the dataset,
> > using the default graph as a manifest for the named graphs in the rest
> > of the dataset.
> > 
> > == Example 1
> > 
> > The resource <http://faraway/place> is read and returns a graph of one
> > triple "<s> <p> <o>".  The dataset management process allocates URI
> > <tag:store,2010:1234> for the g-snap and <tag:store,2010:9876> for the
> > interaction.
> > 
> > ["allocates...for" is intentionally weak wording to not require
> > normative meaning to the dataset named graph pair as that would obstruct
> > other dataset usage patterns.]
> > 
> > The dataset is modified as follows by adding:
> > 
> > # Record the gSnap:
> > <tag:store,2010:1234> { <s> <p> <o> }
> > 
> > # Record the information about the operation performed
> > { <tag:process,2010:9876> :valueObserved <tag:store,2010:1234> ;
> >      :actionTimestamp "2011-10-10T17:35:56Z"^^xsd:dateTime ;
> >      :gBoxLocation <http://faraway/place> }
> > 
> > 
> > == Example 2
> > 
> > Later, the process reads the resource again, using a condition GET and
> > is told the resource has not changed.  The dataset management process
> > generates a URI for the process step <tag:store,2010:ABCD> and links to
> > the previous named graph because the graph value is the same.
> > 
> > { <tag:process,2010:ABCD> :valueObserved <tag:store,2010:1234> ;
> >      :actionTimestamp "2011-10-11T09:35:56Z"^^xsd:dateTime ;
> >      :gBoxLocation <http://faraway/place> }
> > 
> > 
> > == Discussion:
> > 
> > The modelling is merely illustrative.
> > 
> > In the examples, the action description triples go into the default
> > graph.  There is no necessary requirement for this.  They could be
> > stored in a designated system graph.  They could be stored in a separate
> > graph, not in the dataset or even in an associated dataset description
> > with details such as a VoID details of the remote location.
> > 
> > What the dataset is providing is the ability to query access the
> > different observed g-snaps of the g-box.
> > 
> > 
> 
>

Received on Tuesday, 11 October 2011 16:18:45 UTC