Reification and Provenance modelling

Hi,

since the new RDF WG is still forming, I thought it might be worth to 
bring up two issues re. reification and provenance modelling in here.

1. As I saw one issue on the new agenda is the standardization of the 
meaning of the forth element in quadruples. There might be a tendency 
that this should be used for referring the URI of a "named graph" (a set 
of triples, that means, hopefully more than one).
However, currently I would rather tend to assign the forth element for 
an optional statement identifier, which is explicitly intended to be 
used for addressing provenance information. Provenance information is 
from my point of view 'external context' (cf. [1]) to information 
described in a semantic graph.
The following example is also a response[2] of the question of how to do 
practical Named Graphs implementations[3]:

This design allows triple (statement) identification over the enclosures 
of named semantic graphs and furthermore the treatment of provenance for 
statements and graphs in a same way. Additionally, the handling of n-ary 
relations, as an 'internal context' (cf. [1]) refinement of binary 
relation based descriptions, and its mapping to binary relations 
(property reification, see [4]).
Here is an example, which was original only intended for representing 
the internal structure of a quad store. However this could also be used 
in a serialization format (cf. N-Quads [5], where the forth element is 
also optionally). I reformatted it to an N-Quad like serialization:

<#alice> :friend <#bob> <#s1> . # a simple binary relation

<#ab> rdf:type :HumanRelationship <#s2> ; # a property reification (an 
n-ary relation) related to the first binary relation
<#ab> :participant <#alice> <#s3> ;
<#ab> :participant <#bob> <#s4> ;
<#ab> :relationshipType :friend <#s5> ;
<#ab> :since "2010-12-12"^xsd:date <#s6> .

<#s1> :reified <#ab> <#s7> ; # an inference that results in a 
reification relation (such a property currently does not exist, or?)

<#g1> rdf:type rdfg:Graph <#s8> ; # a graph enclosure (which can also be 
more nicely serialized by the TriG syntax)
<#g1> :contains <#s1> <s#9> ;
<#g1> :contains <#s2> <#s10> ;
<#g1> :contains <#s3> <#s11> ;
<#g1> :contains <#s4> <#s12> ;
<#g1> :contains <#s5> <#s13> ;
<#g1> :contains <#s6> <#s14> ;
<#g1> :contains <#s7> <#s15> .

<#g2> rdf:type rdfg:Graph <#s16> ; # another graph enclosure
<#g2> :contains <#s1> <#s17> .

-> I can easily get all statements of a graph by using the :contains 
relation (indexing)
-> I can easily get semantically related property-oriented context 
descriptions (n-ary relations) by using the :reified relation
-> provenance on the statement and on the graph level can easily be done 
by describing the <#g*> and <#s*> information resources:

- thereby, <#s9> - <s#15> and <s#17> are intended for describing 
provenance information of statement <#s*> in graph <#g*>
- one can maybe also inherit graph based provenance information to 
statement provenance information (and vice versa)

-> one can also decouple a reused statement by changing its statement 
identifier; that means, the triple of the statement are still the same 
but the relation to the original statement might now be another e.g., 
reflected by a provenance statement e.g., <#s20> :original <#s19>
-> statement descriptions can be typed i.e. by rdf:Statement (maybe 
obsolete now, since the new agenda propagates a deprecation of the RDF 
Reification vocabulary)

Can such a storing be efficient for the intended use case (practical 
Named Graph implementation)?

2. As one can see already in the first example the application of 
property reification, the Property Reification Vocabulary [4] is 
intended for describing the definitions of such mappings on the 
vocabulary level. So, a reasoning engine can apply the two rules of the 
Property Reification Vocabulary, the shortcut relation rule[6] and the 
property reification rule[7], to infer that a binary relation particular 
and a reification class particular belonging semantically together.
A property reification definition for the example above, would look like 
the following one:

ex:FriendReification a prv:PropertyReification ;
    prv:shortcut :friend ;
    prv:shortcut_property :relationshipType ;
    prv:reification_class :HumanRelationship ;
    prv:subject_property :participant ;
    prv:object_property :participant .

In this case the :friend relation would also be a symmetric relation.

A mapping (inference) of reification class particular descriptions to 
the RDF Reification vocabulary can be done. However, I'm unsure, whether 
this is really necessary.


Finally, I think we have to differ somehow the modelling of 'internal' 
and 'external context'. The modelling of 'internal context' 
(refinements) would still be on the same level as the usual modelling of 
binary relations. The modelling of 'external context' (i.e. provenance 
and trust) would be shifted on another level.


Any comments, suggestions, questions and critics are very welcome.

Cheers,


Bob


[1] 
http://www.dbis.informatik.uni-frankfurt.de/~tolle/Publications/2004/AISTA04.pdf
[2] 
http://blog.dbtune.org/post/2010/12/21/Named-Graphs-and-implementations#c9094397
[3] http://blog.dbtune.org/post/2010/12/21/Named-Graphs-and-implementations
[4] http://purl.org/ontology/prv/core#
[5] http://sw.deri.org/2008/07/n-quads/
[6] http://smiy.sourceforge.net/prv/rdf/shortcut_relation_rule.n3
[7] http://smiy.sourceforge.net/prv/rdf/property_reification_rule.n3

Received on Friday, 28 January 2011 19:18:46 UTC