Die Frage eines Kunden hat mich auf die Idee gebracht, die Einflüsse auf meine Modellierungsstrategien und meine eigenen Einstellungen und Leitlinien einmal zusammenzuschreiben.
Dies sind meine Regeln nach meinen momentanen Erfahrungen, Ende 2023. Sie sind nicht allgemeingültig sondern dokumentieren den Stand meiner Entwicklung.
So wenig Konzepte und Relationen wie möglich
Dies ist für mich einer der Hauptvorteile gegenüber den relationalen Modellen, die ich in der Praxis kennengelernt habe. Viele Spaltennamen in relationalen Tabellen wiederholen Konzepte, die auch in anderen Tabellen vorkommen, mit anderem Namen, und suggerieren damit erst einmal andere Bedeutungen. Das macht es aufwändiger, die Struktur zu lernen und präzise anzuwenden.
Da ich RDF-Modelle von den Prädikaten her entwickele achte ich automatisch darauf, ein Prädikat nur einmal zu repräsentieren. Und die Prädikate entsprechen den Spaltennamen in SQL-Tabellen bzw. Relationen.
Die grundsätzliche Motivation zu dieser Regel liegt im eingeschränkten Gedächtnis von Menschen (oder von mir?): mit je weniger Konzepten und Prädikaten ein Gegenstand modelliert ist, desto einfacher und schneller ist es, solch ein Modell zu verstehen und korrekt anzuwenden.
So viele Klassen und Relationen wie nötig
Eine absehbare Ergänzung :)
RDF bietet so etwas wie Namensräume, mit denen ich die gleich benannten aber unterschiedlichen Konzepte abbilden kann, die in meiner Erfahrung in jedem Projekt auftauchen.
Mein Standard-Beispiel ist der Begriff "Kunde": Geschäftsführung, Buchhaltung, Vertrieb und Support haben im Normalfall andere Definitionen für "Kunde". Am klarsten ist das oft im Gegensatz zwischen Support und Buchhaltung: für den Support ist der "Kunde" jeder, der ein Supportticket aufmacht, während für die Buchhaltung oft derjenige als "Kunde" bezeichnet wird, der die Zahlung anweist.
Das sind offensichtlich ganz verschiedene Konzepte (Personen oder Organisationsteile), und ich habe schon so manchen Streit darüber gehört, was denn nun "wirklich" ein Kunde sei.
In RDF kann ich das beispielsweise lösen, indem ich eigene Ontologien für die verschiedenen Bereiche erstelle, und dann mit Begriffen wie accounting:customer und support:customer arbeite.
Wenn das so auf dem Flipboard steht bekomme ich auch keinen Widerspruch in einem Modellierungsworkshop, und das Modell ist für die Anwesenden einfacher verständlich und zustimmungsfähig.
Performance
Natürlich gibt es dann auch noch die hoffentlich wenigen Konzepte oder Prädikate, die nur für die Performance in einer speziellen Triplestore angelegt werden, oder um die SPARQL-Abfragen lesbarer zu machen.
Diese hängen sehr mit dem Themengebiet und von dem eingesetzten Triplestore oder der genutzten Systemarchitektur zusammen, hier kann es kaum allgemeine Regeln geben, die Entscheidung hier sind situationsabhängig.
Relationen haben den gleichen Stellenwert wie Klassen
Ich habe gerade wieder eine Oberfläche gesehen, die die Klassen in den Vordergrund rückt. Und das kann dazu verleiten, Relationen für spezielle Klassen anzulegen; also :label für die eine, :name für eine andere. Und genau das zu vermeiden ist aus meiner Sicht einer der Vorteile von RDF und OWL, den immer nutzen sollte - die Relationen genau so gründlich und präzise definieren wie die Klassen, damit jeder genau weiß was gemeint ist, wenn :label oder :name benutzt wird. Man könnte nämlich beide Relationen benutzen, und dabei vielleicht und abhängig vom Einsatzfall :label als Relation sehen, die auf eine druckbare Repräsentation zeigt, und :name als einen String mit der Bezeichnung. Und hier ist es wichtig, das ein- für allemal in der Ontologie festzuschreiben, und es nicht für verschiedene Klassen verschieden zu nennen.
Daher fange ich beim Modellieren immer mit gleichberechtigten einfachen Listen von Klassen und Relationen an. Und mein Ziel ist es, beide Listen so präzise und vollständig, aber auch so kurz wie möglich zu halten.
Ereignissemantik
Donald Davidson hat in "The Logical Form of Action Sentences" von 1967 als erster herausgearbeitet, das man Verben als Events oder Ereignisse in formale Logik überträgt, oder anders, dass Handlungen Gegenstände sind, oder in der Sprache von RDF, dass Handlungen Subjekte und nicht Prädikate sind.
In der RDF-Community wird das so selten argumentiert, aber oft angewandt. In der "Organization Ontology" des W3C wird im Abschnitt 2.2 z.B. die "Membership n-ary relationship" eingeführt, ohne Hinweis auf Davidson oder Event Semantic.
Hier wird aus meiner Sicht diese Behandlung der Mitgliedschaft als Node bzw. Subjekt statt als Link bzw. Prädikat als etwas besonderes statt als Normalfall dargestellt, z.B. indem erst die vereinfachte Darstellung als Prädikat org:headOf eingeführt wird, und auch später darauf abgestellt wird, dass die vollständige Darstellung als Subjekt via org:Membership "[...] can be a little less convenient to query and explore [...]".
Und das "Ding" org:Membership reicht auch, um einen Satz wie "Herr Meier hat am x.x.xxxx die Stelle angetreten" auszudrücken, denn an der org:Membership wird Start- und Endzeit angehängt, sie ersetzt also in vielen Fällen alle drei Perspektiven, sowohl "ist Angestellter von" wie auch "ist beigetreten" oder "hat gekündigt", also Statusbeschreibung und die Verben kündigen oder einstellen. Je nach Anwendungsfall braucht es natürlich für die Ereignisse Einstellung und Kündigung eigene Ereignisse, um so etwas wie Gründe etc. festzuhalten.
Meine Sicht ist eher, dass die Darstellung einer Handlung als Ereignis, als Node statt als Link, der Normalfall ist, und jede Darstellung als einfacher Link sehr viele Informationen unter den Tisch fallen lässt. Für mich ist die Darstellung als Link dann wieder eine Anwendung meines ersten Prinzips: so wenig Konzepte wie möglich, oder eine Performance-Entscheidung, die teilweise Abhängig vom eingesetzten Triplestore ist: nur wenn absolut sicher ist, dass man auf absehbare Zeit keine weiteren Informationen braucht, dann kann man statt einer Node einen einfachen Link nehmen; dies sollte aber in jedem Fall einzeln untersucht werden. Meine erste Version einer neuen Ontologie modelliert Verben immer als Ereignisse/Dinge/Nodes.
Da man die einfache Relation auch aus der komplexeren Darstellung als Node z.B. per SPARQL erzeugen kann, kann es eine Möglichkeit sein, beide Darstellungen im Graphen zu halten. Hier muss aber immer definiert werden, was die einfache Definition bedeutet: oft bedeutet sie die aktuelle Situation, als "jetzt gerade" ist X angestellt bei Y.
Dann muss bei jeder Änderung im Angestelltenverhältnis, also in org:Membership, geprüft werden, ob der vereinfachte Link gelöscht werden muss. Also ob das Zeitintervall, das per org:memberDuring an der org:Membership hängt, mit einem time:hasEnd geschlossen wurde und damit die Membership beendet wurde.
Oft wird hier auch von "Reification" gesprochen, was aber im RDF-Umfeld problematisch ist, da RDF eine Syntaxform namens "Reification" hat, die etwas ganz anderes ausdrückt. Darum nutze ich diesen Begriff möglichst nicht, sondern spreche von Ereignissemantik bzw. event semantic.
Ich persönlich lasse all solche Klassen von einer Klasse für "Ereignis" erben. das hilft aus meiner Sicht als Dokumentation für Personen, die nicht bei der Entwicklung dieser Ontologie zugegen waren.
Relationen mit mehr als 2 Teilnehmern
Diese lassen sich nicht direkt in RDF modellieren. Hier muß man über eine Klasse gehen, die die mehrwertige Relation abbildet. Ein beispiel ist :between, welches als :Between modelliert werden muß.
Ähnlich wie bei Verben, die zu Klassen werden, modelliere ich um dies zu Dokumentieren als Subklassen von etwas wie :Relation,
Realität abbilden, keine syntaktischen Merkmale
Das ist mir mal wieder aufgefallen, als ich ein Video von Semantic Arts, Inc über Temporal Relations in ihrer Top-Level Ontologie gist gesehen habe.
Hier nutzt der Vortragende Relationen wie ":isSubjectOfRel" und ":isObjectOfRel", also syntaktische Merkmale für genau solche Modelle wie oben erläutert, also für Handlungen oder Ereignisse wie in seinem Beispiel ":_Ownership_JKL :isSubjectOfRel :_Person_Joe; :isSubjectOfRel :_Vehicle_TeslaXYZ."
Hier wird meiner Ansicht nach eine syntaktische Bezeichnung genutzt, die so schlicht falsch ist. "Joe besitzt einen TeslaXYZ" versus "Der TeslaXYZ wird von Joe besessen" zeigt, abgesehen von der schrägen Formulierung im zweiten Beispiel, warum Subjekt und Objekt hier keine guten Namen für die Relationen sind: beide sind leicht austauschbar.
Conceptual Semantics
Ich sehe hier eher konzeptuelle Relationen als angemessen: :agent oder :actor statt :subject für den Handelnden, falls nötig auch noch :initiator um anzuzeigen, wer eine Handlung eingeleitet hat. und dann durchaus :object als das, auf das sich die Handlung bezieht, denn das z.B. von John Sowa oder SUMO benutzte :patient (das Erleidende) war den meisten Stakeholdern eher unklar oder seltsam. Dann kann es noch viele weitere Atribute geben: :recipient, falls in einer Handlung ein Objekt übergeben oder weitergeleitet wird, :material oder :resource, falls etwas in oder von der Handlung verbraucht wird (wie Sauerstoff beim Atmen) und und und
Ich bin hier sicherlich von frühen Ansätzen beeinflusst, wie Robert Schanks Conceptual Dependency Theory oder John Sowas Conceptual Graphs sowie der Suggested Upper Merged Ontology (SUMO, später mehr dazu).
Conceptual Dependency demonstriert hier sehr schön sowohl was machbar ist und wie weit man eine Vereinfachung im Sinne von "wenige Konzepte für viele Worte" treiben kann als auch wie kontraproduktiv dieser Versuch ist, wenn man es zu weit treibt. Hier ist gute Arbeit geleistet worden, und noch heute erinnere ich mich an Diskussionen über Relationen und grundlegende Handlungen aus diesem Bereich und nutze dies, um möglichst einfache Konzepte und Relationen zu finden oder wie oben gezeigt sie auch direkt wiederzuverwenden.
Die heutige pragmatische Aufgabe, einen großen Enterprise Knowledge Graph zu erstellen, benötigt im Grunde genau das, was Schank damals versucht hat: möglichst wenige, präzise Konzepte, mit denen möglichst viel ausgedrückt werden kann, egal ob von der Sicht der Geschäftsleitung oder von Mitarbeiter in der Produktion, von Zulieferern oder Kunden gesehen.
Ontologien aus denen ich Anregungen entnehme
gist - die "minimalist upper ontology for the enterprise" von Semantic Arts, Inc ist eine wohlüberlegte, relativ kleine, und gut dokumentierte Ontologie mit geschäftlicher Ausrichtung. Es gibt eine Reihe von Videos auf youtube, in denen man die Entwicklung verfolgen kann, und viel über den Aufbau und die Weiterentwicklung einer Ontologie lernen kann.
Eine weitere Quelle für Ideen ist die Suggested Upper Merged Ontology (SUMO)
Nicht auf RDF bezogen, sondern auf das leistungsfähigere SUO-KIF (Knowledge Interchange Format) enthält sie viele nützliche Konzepte, z.B. case relations wie die oben benutzten :agent, :initiator und zusätzliche wie :instrument oder :resource.
SUMO und dessen Konzepte sind das Ergebnis eines langen Abstimmungsprozesses im Rahmen der Standard Upper Ontology Working Group der IEEE. Viele engagierte Experten haben hieran mitgearbeitet, es lohnt sich zu spicken, auch wenn nicht jedes Feature nach RDF übertragbar ist.
Literatur
Ein paar Bücher, die ich jedem im Bereich Knowledge Graphs empfehlen kann:
Michael Uschold: Demystifying OWL for the Enterprise, Basel, 2018
Die beste Einführung in die Web Ontology Language (OWL), die ich kenne.
Panos Alexopoulos: Semantic Modeling for Data, Sebastopol, CA:O'Reilly, 2020
Zeigt Fallen und Dilemma bei der Gestaltung einer Ontologie auf. Lesen!
Adam Pease: Ontology A Practical Guide, Angwin:Articulate Software Press, 2011
Dokumentiert die Anwendung und Modellierung einer Ontologie am Beispiel SUMO.