PropertyReificationVocabulary

From W3C Wiki

Property Reification RDF Vocabulary

This is a strawman draft for an extension to RDFS that allows to express mapping between RDF properties and RDF classes that reify the property.

A vocabulary that implements some of the ideas on this page.

Introduction

A significant weakness of RDF is its lack of an elegant method of expressing more information about relations between resources.

In response to this, vocabulary designers sometimes add classes which are equivalent to the original property, but can express additional information. This is a form of reification on the vocabulary level, instead of using the RDF Reification mechanism. Unfortunately, currently RDFS and OWL provide no means of mapping between the two equivalent forms. The same problem occurs in even more dramatic form when we try to express mappings between different vocabularies, especially when they are of different “granularity”, or level of detail.

Such equivalences occur frequently on the Semantic Web: Relationships between people are sometimes expressed as simple triples, sometimes as resources connected to both people. Authorship is sometimes expressed with a simple triple that connects the author's name to the document, and sometimes the name is attached to an intermediate resource that represents the author.

The vocabulary proposed here extends RDFS to allow expressing such mapping, thus allowing reasoners to infer one form from the other.

Motivating example

This statement says that a web page is tagged with a particular tag ("semweb"), using Richard Newman's Tag Ontology:

<mypage.html> tag:taggedWithTag ns:semweb .

The Tag Ontology provides another, more verbose method of expressing the same:

[]  a tag:Tagging;
    tag:taggedResource <mypage.html>;
    tag:associatedTag ns:semweb;
    .

The second form is more verbose, but has an advantage: Additional statements can be made about the Tagging, e.g. when was it made and by whom. Unfortunately, RDFS and OWL provide no way of expressing that both forms are equivalent. A Tag Ontology processor needs custom code to be able to deal with both forms. The vocabulary proposed here allows to make the equivalence explicit, thereby allowing reasoners to automatically convert between the two forms.

Vocabulary draft

prv:PropertyReification a rdfs:Class ;
    rdfs:comment "Property reification class."@en .

prv:shortcut a rdf:Property ;
    rdfs:comment "Property to be reified to class."@en ;
    rdfs:domain prv:PropertyReification ;
    rdfs:range rdf:Property .

prv:subjectProperty a rdf:Property ;
    rdfs:comment "Subjects of statements that use the reified property."@en ;
    rdfs:domain prv:PropertyReification ;
    rdfs:range rdf:Property .

prv:objectProperty a rdf:Property ;
    rdfs:comment "Objects of statements that use the reified property."@en ;
    rdfs:domain prv:PropertyReification ;
    rdfs:range rdf:Property .


prv:reifiedProperty a rdf:Property ;
    rdfs:comment "Property reified to class."@en ;
    rdfs:range rdf:Property .

Implementation

The implementation requires RDFS entailments to apply.

Core

N3 rules:

[prv1]
{
    ?pr prv:shortcut ?sc ;
        prv:subjectProperty ?sp ;
        prv:objectProperty ?op .

    ?r reifiedProperty ?sc ;
        ?sp ?s ;
        ?op ?o .
} => {
    ?s ?sc ?o .
} .

[prv2]
{
    ?pr prv:shortcut ?sc ;
        prv:subjectProperty ?sp ;
        prv:objectProperty ?op .

    ?s ?sc ?o .
} => {
    ?r reifiedProperty ?sc ;
        ?sp ?s ;
        ?op ?o .
} .

RDF reification integration

While RDF reification doesn't assert the original triple, it can be useful for visualization or other tools which understand it.

# Axioms
prv:reifiedProperty rdfs:subPropertyOf rdf:predicate .

# Rules
[rdfr1]
{
    ?pr prv:subjectProperty ?sp .
} => {
    ?sp rdfs:subPropertyOf rdf:subject .
} .
[rdfr2]
{
    ?pr prv:objectProperty ?op .
} => {
    ?op rdfs:subPropertyOf rdf:object .
} .

Shortcut Property Extension

To aid particular modeling style, this extension might prove useful (advocated by Zazi).

prv:shortcutProperty a rdf:Property ;
    rdfs:comment "Relates to the property of the reification class, which relates to the predicate of the shortcut relation. In simple terms, custom prv:reifiedProperty."@en ;
    rdfs:domain prv:PropertyReification ;
    rdfs:range rdf:Property .

# Rules
[spext]
{
    ?pr prv:shortcut ?sc ;
        prv:shortcutProperty ?scp .

    ?r prv:reifiedProperty ?sc .
} => {
    ?r ?scp ?sc .
} .

[spext2]
{
    ?pr prv:shortcutProperty ?scp .
} =>   {
    ?scp rdfs:subPropertyOf prv:reifiedProperty .
} .

Alternatives

Notation3 rules can be used to make the connection, and have been implemented since 2000.

RDF Reification does not assert the original triple, therefore one cannot infer the statement form from the reified form.

RIF rules can express the required mappings, but are quite complex and not yet supported in most tools. We advocate a simpler mechanism tailored to the specific problem.

Named Graphs can be used to assert metadata about a set of statements, and work well for larger sets of statements that share common metadata, but are cumbersome if the metadata differs a lot between statements. In the extreme case, it requires one graph per statements. It also goes beyond the standard RDF data model. See Jeni Tennison's blog post which advocates the use of Named Graphs for this purpose.

Issues

Example

Using the tag ontology: http://www.holygoat.co.uk/projects/tags/

The mapping according to current draft:

[] a prv:PropertyReification ;
    prv:shortcut tag:taggedWithTag ;
    prv:subjectProperty tag:taggedResource ;
    prv:objectProperty tag:associatedTag .

tag:isTagOf owl:inverseOf tag:taggedWithTag .
tag:tag owl:inverseOf tag:taggedResource .

Diagram describing the mapping

See Also

Contributors

JiriProchazka, RichardCyganiak, Bob Ferris

Comments and Discussion

ODDlinker

Chris Bizer: Another use case for this might be representing meta-information about RDF links between different Linked Data sources. Oktie has already worked into this direction with his ODDlinker tool that is used to interlink LinkedMDB movies with other data sources. He has designed a vocabulary to represent information about links such as the confidence score or the algorithm (linkage run) that was used to discover the link. We are going to use the same vocabulary for representing the output of a link discovery tool that will be released soon.

Example:

http://data.linkedmdb.org/resource/interlink/1036
   rdfs:label  "1036 (Interlink)" ;  
   oddlinker:link_source  <http://data.linkedmdb.org/resource/film/2014> ; 
   oddlinker:link_target  <http://dbpedia.org/resource/The_Shining_%28film%29> ;
   oddlinker:link_type  owl:sameAs ;
   oddlinker:linkage_run  <http://data.linkedmdb.org/resource/linkage_run/1> ;
   oddlinker:linkage_score  "0.567848166224181" ;  
   movie:linkid  "1036"^^xsd:int ;  
   rdf:type  oddlinker:interlink .


Temporal metadata

It might be interesting to also add some standard properties that can be used on a reified instance to denote its temporal scope, e.g. from when until when the instance is valid. This would provide a fairly natural and unobstrusive method of reconstructing past states of an RDF graph. —RichardCyganiak

  • A good use-case for this is mapping MusicBrainz data to RDF using the Music Ontology. MusicBrainz relates objects with simple database relations as well as what they call Advanced Relationships. The latter always have a temporal scope stated through a "from" and a "until" date (and may also have some other attributes). The Music Ontology for most relationships relies on simple properties like mo:producer. So expressing Advanced Relationships using those loses information. My idea so far was to reify all of these properties in the Music Ontology as sub-classes of the Event Ontology as it has already been done with some of them (mo:Performance). Having an established vocabulary for this that reasoners can work with would certainly help. -- SimonReinhardt DateTime(2009-02-20T01:09:26Z)
  • I suggest not to standardize such properties, because it is out of scope of this ontology and very subjective. People want to describe relations in many ways, we cannot predict all of them. Some are more abstract (duration like you point out, trustworthiness, authorship, time of creation...) bordering with resource description like in POWDER, some less abstract (strength, location...). But this is irrelevant to the mapping itself - it is about using the reified instance. So if any of these standard properties are to be released, I suggest to separate them from the core ontology, perhaps as different ontology. -JiriProchazka

Wrong way?

"I don't think the solution of creating classes for things like membership works either because then you can't re-use widely deployed vocabularies - and in the end, wouldn't you end up creating classes for everything?" was said by Simon Reinhardt in comment to http://www.jenitennison.com/blog/node/101 - this whole blogpost is relevant to this and worth reading. What Simon said might be true, I would like some more elegant way, provided by RDF natively, but I don't see any better alternatives, and this would work if the inferencing works. -JiriProchazka

That was when I hadn't had looked into this proposal. ;-) My point was that you might need this sort of reification everywhere and it is not practical to republish every popular vocabulary in a reified way. Mostly because it is too much work and because you wouldn't use existing URIs so data integration is harder. But if this vocabulary here and the reasoning rules for it were widely supported in applications and libraries then it might be a good alternative to named graphs. -- SimonReinhardt DateTime(2009-03-03T16:41:43Z)

Possible Use Case - Change logs

{
    dc:modified
        a r:reifiedProperty ;
        r:reificationClass ex:Change ;
        r:subjectProperty ex:changed ;
        r:objectProperty dc:date .

    dc:contributor
        a r:reifiedProperty ;
        r:reificationClass ex:Change ;
        r:subjectProperty ex:changed ;
        r:objectProperty event:agent .

    :change1
        a ex:Change ;
        ex:changed <document.txt> ;
        dc:date "2008-01-01" ;
        event:agent "Joe Bloggs" .
}
=>
{
    <document.txt>
        dc:modified "2008-01-01" ;
        dc:contributor "Joe Bloggs" .
}


The above use case shows that a commonly used predicate like "dc:modified" might be reified into, for example, this "ex:" vocabulary, but other people might want to reifiy it into other vocabs.

An alternative: property chains

tag:taggedWithTag a owl:ObjectProperty ;
	owl:propertyChainAxiom (tag:tag tag:associatedTag) .


An OWL 2 reasoner will now infer the shortcut (a triple using tag:taggedWithTag) from this longer path. -- SimonReinhardt DateTime(2009-06-17T14:55:15Z)

Should perhaps mention: using this you can only infer the regular form from the reified form, not the other way round. Also you can only reify object properties because property chains don't work with datatype properties. But still property chains are a nice mechanism for providing shortcuts of more verbose (reified) models.

Another alternative

The approaches above seem to be RecordDescription ones. But reification of properties could also be done via OnTheFlyProperties:


:something :tagReification :tag .

:tagReification a ex:Reification ;
	rdfs:subPropertyOf tag:taggedWithTag ;
	dcterms:date "..." .


This is valid in OWL 2 because of punning: A reasoner would regard :tagReification as two different things, first as a property and then as an individual of the class ex:Reification. That class would act as a marker to basically express that this sub-property is an on-the-fly one and everything attached to it is information about the relation between the two things it is used between rather than information about the property itself. A validator could check that this property really only gets used once.

Note that a property in RDF can only be a URI, not a blank node. So while the following is valid in N3 it doesn't work in RDF:


:something [ a ex:Reification ; rdfs:subPropertyOf tag:taggedWithTag ; dcterms:date "..." ] :tag .


-- SimonReinhardt DateTime(2009-10-30T13:24:00Z)

Please add!