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

Sorry, I must be missing something substantial.  Why would you want to record dataset changes upon access instead of only on g-box modification?

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 14:57:46 UTC