Generic "Graph" Use Cases

Richard Cyganiak wrote:
> On 6 Mar 2011, at 19:23, Nathan wrote:
>> Andy Seaborne wrote:
>>> RDF datasets don't address the assertions about graphs UC very well.
>>> They can - with careful graph naming (naming the g-snap, not the g-box), the default graph can contain assertions about the properties of a graph, just like graph literals can be used for RDF datasets.  It's just there is "some assemble required".
>> There's a very critical detail here, the need to talk about a g-box, and the need to talk about a g-snap
> 
> Just to be sure we're on the same page in this discussion, can you give an example for “talking about a g-box” and one for “talking about a g-snap”, in particular one where the distinction matters?

All the graph use-cases which we are collecting can be broken down in to 
a core set of generic uses cases relating to the generic concepts we have.

The generic concepts (apologies, I need to use different terms here to 
disambiguate them)

anonymous-snap:
   a distinct set of triples

anonymous-box:
   a container of triples who's value changes over time

named-snap:
   a distinct set of triples, associated with a name.

named-box:
   a container of triples who's value changes over time, associated with 
a name.

named-box-snap:
   a distinct set of triples which represents the value (or state) of a 
named-box at a certain time (previous state, current state etc)

I've included anonymous-box here just to give a full list, typically 
this would correlate to something like a Graph Class instance which you 
can add and remove triples from, but that isn't associated with any name.

anonymous-snap can be correlated to quoted-graphs in N3, they're useful 
when you want to make statements about a distinct set of triples, create 
rules, rdf diff and patch, or apply your own provenance and annotation 
data to a set of triples.
   { ... } :created "2011-03-01"; :by "john" .

named-snap is another approach to some of the anonymous-snap use-cases, 
where rather than having a graph quoted in the subject/object position, 
you instead give it a (temporary) name, then talk about the name (nb: 
the name is a property of the serialization, and not some uri for a 
named-box)
   G1: { ... }
   G2: { :G1 :created "2011-03-01"; :by "john" . }

named-box correlates to a named-with-a-uri graph in a quad store or the 
URI of an rdf-providing information resource on the web, any statements 
made about a named-box relate to the box over time, not to it's current 
state
   <u> a :Graph/:Document ; :about :monkeys .
   <x> rdfs:seeAlso <doc> .

named-box-snap correlates to the memento or web archive side of things, 
grabbing the state of a named graph or information resource at a certain 
time, and talking about it.
   see: http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC/Changes_over_time
   or example 3 here: http://www4.wiwiss.fu-berlin.de/bizer/TriG/#example

On the last one, named-box-snap, there are only really two approaches to 
this, one is to talk about a set of triples and say where they came from 
and when (the first linked to example) - or - to capture the current 
state and transfer that (trig example 3).

personal viewpoint ahead!
Essentially, a large proportion of the use-cases (if not 100%) can be 
handled with either anonymous-snap or named-snap, the difference between 
the two is that with anonymous-snap it's all within the RDF data model, 
where-as with the named-snap approach (example 1 of trig) the names are 
properties of the serialization, and it requires out of band knowledge 
about the document in order to know what the :Gn's are for / how to 
piece them together etc.

To expand on this last comment, if you take examples 1 and 3 from the 
trig documentation, and replace :G1,:G2,:G3 in the first example for 
their full URIs, then what do you have here? is it a capture of the 
current state of three named-box's, or is it three named-snap's to be 
considered for provenance information? This is what I mean by out of 
band knowledge.

With a trig-like syntax, we could specify that graph names can be bnode 
identifiers or uris, when it's a uri the contained graph is a 
named-box-snap (where the uri identifies the named-box), and when it's a 
bnode identifier then it's a named-snap.

There is a very fun question though, if we did move to a trig like 
syntax, and one wanted to take a snapshot of a trig doc and talk about 
it, how would you do it? wrap things up in a nother set of curly braces 
and assign another name? or?

Will leave it there

Best,

Nathan

Received on Sunday, 6 March 2011 21:55:29 UTC