W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2011

Re: Reification and Provenance modelling

From: Bob Ferris <zazi@elbklang.net>
Date: Fri, 08 Apr 2011 13:28:22 +0200
Message-ID: <4D9EF156.7020307@elbklang.net>
To: public-rdf-comment@w3.org
Hi,

since the reification issue is a discussed topic in the RDF WG mailing 
list [1] at the moment, it might be worth to have a look/consider my 
proposal/thoughts in this context, or?

Cheers,


Bob


[1] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Apr/0164.html

On 1/31/2011 10:52 AM, Bob Ferris wrote:
> Hi Ivan,
>
> thanks a lot for being up to consider my thoughts. I just wanted to send
> my "proposal" to the RDF WG somehow, so that it can lately be considered
> (before it will maybe to late).
> I'm not being in a rush ;)
>
> Cheers,
>
>
> Bob
>
>
> Am 31.01.2011 10:37, schrieb Ivan Herman:
>> Bob,
>>
>> this is not a technical but rather a more administrative response...
>>
>> The RDF WG is, currently, only gathering. What this means in practice
>> is that people are signing up to the group and the real work will
>> begin mid-February. In the meantime, I have archived this mail so that
>> it could be put 'back' into the collective psyche of the group when
>> the time comes...
>>
>> Thanks
>>
>> Ivan
>> On Jan 28, 2011, at 20:18 , Bob Ferris wrote:
>>
>>> 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
>>>
>>
>>
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Friday, 8 April 2011 11:28:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:52 UTC