Das einfache Subjekt-Prädikat-Objekt Datenmodell von RDF verführt dazu, Beziehungen und Verben als einfache Prädikate oder Eigenschaften zu behandeln. Doch dieser Ansatz wird der Komplexität der Realität oft nicht gerecht.
Ein einfaches Beispiel
Betrachten wir das Sammeln von Daten über Arbeitsverhältnisse oder Projektauftragnehmer. Ein erster Ansatz könnte wie folgt aussehen:
@prefix : <http://example.org/data/example#> .
@prefix demo: <http://example.org/models/demo/> .
@prefix gist: <https://ontologies.semanticarts.com/o/gistCore> .
@prefix schema: <https://schema.org/> .
:_Meier schema:worksFor ~:_Firma .Nun möchten wir hinzufügen, dass Herr Maier als Teamleiter arbeitet:
:_Meier schema:worksFor ~:_Firma …
:_Meier schema:ocupationalCategory :_Teamleiter .Doch was, wenn Herr Maier freiberuflich tätig ist und gleichzeitig für zwei Firmen arbeitet?
:_Meier schema:worksFor ~:_FirmaA .
:_Meier schema:worksFor ~:_FirmaB .
:_Meier schema:ocupationalCategory :_Teamleiter .
:_Meier schema:ocupationalCategory :_Projektleiter .In welcher Firma ist er nun Teamleiter, in welcher Projektleiter? Oder wie formulieren wir, dass Herr Maier seit 2012 für :_FirmaA arbeitet?
RDF-Star wird ja gerne als Lösung für die Darstellung zeitlicher Gültigkeit gesehen:
<<:_meier schema:worksFor :_Firma >>
gist:actualStartDateTime "2012-09-01T00:00:00" .
<<:_meier schema:worksFor :_Firma2 >>
gist:actualStartDateTime "2012-09-01T00:00:00" .
<<:_meier schema:position :_Teamleiter >>
gist:actualStartDateTime "2012-09-01T00:00:00" .
<<:_meier schema:position :_Projektmanager >>
gist:actualStartDateTime "2012-09-01T00:00:00" .
Doch wie man sieht, kann RDF-Star die Zusammenhänge dieser Fakten nicht ausreichend darstellen.
Ein altes Problem, eine bekannte Lösung
Das Problem der formalen Darstellung von Verben und Adjektiven ist nicht neu.
Eine oft genutzte Lösung wurde zuerst von Donald Davidson in The Logical Form of Action Sentences (1967) beschrieben, und von Terence Parsons in Events in the Semantics of English (1990) vereinfacht. Dabei wird jedes Verb, also auch jede Handlung, als "Ding" betrachtet, im Grunde als Ereignis (event).
Im RDF-Jargon bedeutet das, dass aus :_Meier schema:worksFor :_FirmaA ein demo:Contract mit zusätzlichen Attributen wird.
So können alle relevanten Informationen an das so entstehende freiberufliche Arbeitsverhältnis angehängt werden:
:_MeiersArbeitsverhältnis_A a demo:Contract ;
demo:auftraggeber :_FirmaA ;
demo:auftragnehmer :_Meier ;
demo:position :_Teamleiter ;
gist:actualStartDateTime "ZeitpunktA"^^xsd:dateTime .
:_MeiersArbeitsverhältnis_B a demo:Contract ;
demo:auftraggeber :_FirmaB ;
demo:auftragnehmer :_Meier ;
demo:position :_Projektmanager ;
gist:actualStartDateTime "ZeitpunktA"^^xsd:dateTime .Und weil wir gerade dabei sind, fügen wir noch Informationen über seine Abteilung und den zugrundeliegenden Vertrag hinzu:
:_MeiersArbeitsverhältnis_A a demo:Contract ;
demo:auftraggeber :_FirmaA ;
demo:auftragnehmer :_Meier ;
demo:position :_Teamleiter ;
demo:abteilung :_AbteilungA ;
demo:vertrag :_VertragA ;
gist:actualStartDateTime "ZeitpunktA"^^xsd:dateTime .
:_MeiersArbeitsverhältnis_B a demo:Contract ;
demo:auftraggeber :_FirmaB ;
demo:auftragnehmer :_Meier ;
demo:position :_Projektmanager ;
demo:abteilung :_AbteilungB ;
demo:vertrag :_VertragB ;
gist:actualStartDateTime "ZeitpunktA"^^xsd:dateTime .Damit haben wir deutlich mehr Informationen erfasst. Und sobald mehr Informationen zu einem solchen Arbeits-- und Vertragsverhältnis erfasst werden, desto mehr schwindet der Unterschied in den benötigten Tripeln, also in der Last auf den Triplestore.
Darstellungskomplexität
Bei der einfachen Aussage ist der Unterschied ein zu drei Tripeln:
:_Meier schema:worksFor :_FirmaA .
# vs
:_MaiersArbeitsverhältnis_a a demo:Contract ;
demo:auftraggeber :_FirmaA ;
demo:auftragnehmer :_Meier .Und würden wir hier RDF-Star einsetzen, um den Zeitrahmen auszudrücken, brauchen wir für jeden Triple ein zusätzliches RDF-Star Statement und damit sind wir dann bei 8 zu 8 Tripeln und haben noch nicht einmal ausgedrückt, dass wir hier *ein* Vertragsverhältnis beschreiben.
Natürlich könnten wir jetzt noch einmal 4 RDF-Star-Statements hinzufügen, die auf den zugehörigen Vertrag verweisen, um diese Triple zusammenfassen zu können, aber damit wären wir schon bei 12 zu 8 Tripeln.
Damit zeigt sich bei der konkreten Modellierung von Ereignissen ein deutlicher Vorteil für die Darstellung eines Verbs oder einer Property als "Ding", als Entität, als eigene
URL.
"Reifizieren" ist im RDF-Kontext ein schlechter Ausdruck hierfür
Diese Technik wird gerne "Reifizieren" genannt: aus einer Eigenschaft ein "Ding" machen.
In RDF gibt es allerdings eine semantische Form die "Reification" genannt wird, mit der man einen Triple referenzieren kann. RDF-Star fing ein wenig als syntactic sugar für die Reification in RDF an, eine einfachere Syntax um eine Aussage über einen Triple zu machen.
Darum wird im Kontext von RDF "reifizieren" oft als dieses eher selten benutzte Vokabular interpretiert, was zu Missverständnissen führt.
Darum vermeide ich das Wort in diesem Zusammenhang und spreche nur von Ereignissemantik bzw. event semantics.
Abfragekomplexität
Abfragen über solch komplexeren Datenmodelle sind ebenfalls komplexer. Das ist ein Grund, warum in vielen Ontologien einfache Eigenschaften definiert werden, obwohl vielleicht eine Entität sinnvoller gewesen wäre.
Suchen wir z.B. die Firmen, in denen Herr Maier gearbeitet hat in einem einfachen Modell:
select ?firma where {
:_Maier schema:worksFor ?firma
}Wunderbar, oder? So leicht können Wissensgraphen sein...
Nun aber mit der gleichen Beziehung als Ereignis ausgedrückt:
select ?firma where {
?contract a demo:Contract ;
demo:auftragnehmer :_Maier ;
demo:auftraggeber ?firma
}Deutlich aufwändiger zu schreiben, und auch der Triplestore muss hier zwei vollständige Triple und eine potentielles Set von Tripeln suchen und dann einen Join von den drei Tripeln machen um zu antworten - deutlich aufwändiger!
Hier fehlt jetzt noch ein kleiner Benchmark, ich hoffe den in nächster Zeit zu ergänzen.
Detaillierter geht immer
Natürlich können wir auch die Eigenschaften unsres demo:Contract wiederum als Dinge ansehen: vielleicht ändert sich die Position von Herrn Maier während der Laufzeit eines Vertrages. Dann reicht unsere demo:position nicht mehr, und wir müssen eine demo:Position einführen, mit dem demo:contract und einer Positionsbeschreibung Eigenschaften.
Das kann fast beliebig komplex werden. Und jeden Triplestore (und jeden Kopf) überfordern.
Vorgeschlagenes Vorgehen
Prüfen Sie jede Eigenschaft, ob sie ein Event darstellen könnte. Nur so kommen Sie zu vollständigen Modellen. Überlegen Sie dann, ob diese Informationen wirklich nötig sind, und testen Sie die verschiedenen Modelle auf ihre Auswirkungen auf den Triplestore. Entscheidungen sollten auf Performancemessungen basieren.
Testen mit synthetischen oder Livedaten, aber vor allem mit einer Menge an Daten, die der angestrebten Menge zumindest nahe kommt, maximal eine Größenordnung davon entfernt.
Mit diesen Informationen entscheiden sie dann von Fall zu Fall, welche Eigenschaft wie modelliert wird: als OWL property oder als OWL node bzw. Individuum, und bekommen so ein Modell, das einfach genug ist, aber nicht zu einfach...