W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Time-varying g-boxes : a dataset pattern

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 11 Oct 2011 13:47:56 +0100
Message-ID: <4E943AFC.1030803@epimorphics.com>
To: RDF-WG <public-rdf-wg@w3.org>
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 12:48:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:45 GMT