# Re: Reification and Provenance modelling

From: Bob Ferris <zazi@smiy.org>
Date: Tue, 20 Sep 2011 12:08:45 +0200
Message-ID: <4E78662D.9080003@smiy.org>

```Hi Richard,

On 9/17/2011 5:27 PM, Richard Cyganiak wrote:
> Hi Bo,
>
> Thanks for the response. More questions inline.
>
> On 15 Sep 2011, at 17:46, Bob Ferris wrote:
>> The proposal in the RDF Datasets proposal document [1] lacks the ability to elegantly deal with one-triple-graphs.
>
> I don't follow. As far as I can tell, [1] works equally well regardless of the number of triples in the graph.

Just imagine a triple store full of single-triple graphs. Querying this
triple store might really getting complex, or? I guess, nobody really
wants to isolate single triples in separate graphs, or?

> In what way is the handling of single-triple graphs inferior to the handling of multi-triple graphs in this proposal?

Well, I think that I didn't claim this, I would rather claim that both
cases are important and should be elegantly covered by the final solution.

>
>> Single statements should make use of statement identifier instead.
>
> Why?

It keeps us a away from isolating single triples into separate graphs.

>
>> The simple graph literals proposal [4] looks a bit more elegant, however, these graphs have still no identifier (from my POV).
>
> Why is this a problem? Note that you can make statements about them.

To make statements about them somewhere else we usually need an
identifier to refer to them, or?

>
>> All these proposals cannot deal with the "Slicing datasets according to multiple dimensions" [5].
>
> I don't think that's true. The same triple can exist in multiple graphs. Nothing stops a triple store from providing different views on the same set of triples.

Yes, of course. However, in the existing proposals we would simply
duplicate the data and from my POV this is not the intention of the
described use case, i.e., in the multi graphs use case (see also [1] for
an alternative description of it) one and the same triple (e.g.
identified via a statement identifier) should be utilisable across the
border of graphs.

>
>> The goal should be to develop a representation that do not require much additions to the existing triple-based model, i.e., (from my POV) adding an optional fourth element that represents a statement identifier.
>
> [1] and [4] don't change the triple-based model *at all*. ([1] adds a formalism for handling multiple RDF graphs. [4] adds a new kind of RDF term within the triple-based model.)
>
> In terms of the magnitude of the change, both of these are less invasive than [3].

proposals (at least from my POV), i.e., my proposal covers the formalism
for handling multiple RDF graphs as well. It makes used of the TriG
Vocabulary and a ':contains' property.
It's all about the semantics you would add for the interpretation of graphs.

>
>> To preserve the triple-based nature of RDF we should develop a graph vocabulary that describes a graph, e.g., which statements are included etc.
>>
>> This modelling has the following advantages (at least):
>> - graphs can be indexed separately in triple stores
>
> This is possible, and easier, in [1]. (And probably in [4], but I won't argue that case here.)

Well, I don't see this really, because, one the side, it's about
representing this graph structure externally (syntactically) and, on the
other side, it's about the internal storage mechanism. Since my graph
representation proposal really describes what a graph contains via
utilising the statement identifier of the containing triples this is
somehow different and can be separate in another way as it can be done
with the other proposals.

>
>> - statements can be utilised in multiple graphs
>
> This is possible in [1].

Via importing single-triple graphs into other graphs? (This looks
somehow artificial to me, sorry).

>
>> - provenance for statements and graphs can be handled in a unified way.
>
> This is possible in [1] if one thinks of a statement as a single-triple graph.

Yeah, I know. However, I believe that there is a strong antipathy for
single-triple graphs.

Cheers,

Bo

>> [1] http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal