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

On Oct 11, 2011, at 12:53, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
> 
> On 11/10/11 17:18, Sandro Hawke wrote:
>> 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
> 
> The g-box is somewhere else across the web - not under the control of the watching application.  All the application can do is look every so often with HTTP.
> 
> There are ways to give the illusion of push changes, or even real push, but it requires the publisher to provide something extra.

Got it. Thanks. 

Regards,
Dave

> 
>    Andy
> 
>>> 
>>> 
>>> 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 17:37:14 UTC