Beim Erstellen eines Modells für eine Graph-Datenbank hilft das Tool Protégé bei Axiomen, Objekt-Eigenschaften, Individuals, Annotationen und Internationalisierung.

Die Grundlagen des „Semantischen Web“ hat die dotnetpro in den beiden zurückliegenden Ausgabe 4/2020 und 5/2020 vorgestellt: Im ersten Teil waren das die Standards RDF und OWL, Klassenhierarchien, Taxonomien, Data- und Object-Eigenschaften mitsamt ihren Einschränkungen und semantischen Metadaten, Individuals, die eigentlichen Objekte in einer semantischen Graph-Datenbank, Reasoner, die für die Konsistenz der Daten sorgen, und die Inferenz, die logische Schlussfolgerungen und damit das maschinelle Lernen ermöglicht [1].

Nach diesen technischen Grundlagen führte der zweite Teil in die praktische Arbeit mit Ontologien ein, also das Erstellen eines semantischen Datenmodells, wobei als Werkzeug die Software Protégé zum Einsatz kam [2]. Gezeigt wurde, wie Sie mit Protégé Klassen, Eigenschaften, Individuals und Annotationen verwalten, wie Sie Schemata und Klassifizierungen umsetzen, wie Sie Restrictions einsetzen und den Reasoner nutzen und wie Sie Modelle importieren und exportieren. Im vorliegenden dritten Teil geht es nun darum, wie diese Modelle mit einer semantischen Graph-Datenbank synchronisiert und dort für das Wissensmanagement verwendet werden. Er schließt ohne Umschweife an den zweiten Teil an.

Protégé: Ein ausgereiftes Ontology Modellierungs Tool

Protégé ist ein sehr ausgereiftes und eines der am häufigsten eingesetzten freien Tools zum Modellieren von Ontologien. Betreut wird es von der Stanford University, und es ist auf deren Website kostenfrei verfügbar [3]. Die Software hat sich daher als Modellierungs-Tool etabliert, dessen generierte Modelle in ihren verschiedenen Formaten von allen W3C-konformen semantischen Datenbanken unterstützt werden.

Für einfache Testzwecke bietet das Programm ein Plug-in für SPARQL-Abfragen. Wie der Name schon andeutet, können damit SPARQL 1.0-konforme select-Abfragen ausgeführt werden. Die SPARQL-1.1-Operationen insert oder delete un- terstützt das Plug-in (noch) nicht.

Protégé positioniert sich somit klar als technisches, UI-orientiertes Modellierungswerkzeug und überlässt sowohl den operativen Betrieb als auch das programmatische Datenmanagement den Datenbank- und App-Herstellern.

Globale Axiome versus Property Constraints

Wichtig zu wissen ist, dass sowohl Range- als auch Domain- Axiome (siehe [2]) global wirken, wenn sie direkt für Eigenschaften definiert werden – mit entsprechenden Auswirkungen für die Ontologie.

Versehen Sie beispielsweise eine spezifische Eigenschaft companyName mit einem Domain-Axiom Company, so sorgt der Reasoner dafür, dass jedes Individual, das companyName verwendet, automatisch zu einem Mitglied der Klasse Company wird – ohne dass dies einer expliziten Klassenzuweisung à la dnp:Company_EbnerVerlag rdf:type dnp:Company bedarf – die gewünschte und hilfreiche Seite der Inferenz.

Wenn Sie hingegen eine generische Eigenschaft name mit einem Domain-Axiom Product versehen, so werden ebenfalls alle Individuals, die diese Eigenschaft verwenden, automatisch zu Mitgliedern der Klasse Product. Folgerichtig würde auch eine Person, welche die Eigenschaft name verwendet, ebenfalls zu einem Product-Objekt, was dann zwar logisch richtig, semantisch aber natürlich unsinnig ist.

Bei generischen Eigenschaften mit allgemeinem Charakter sollte man also besonnen mit Domain-Axiomen umgehen, um spätere Überraschungen durch unerwartete Klassenzuordnungen zu vermeiden. Eine gute Praxis ist, Axiome als Instrument zur automatischen Klassifizierung von Individuals zu verwenden – Range-Axiome zur Klassifizierung der Objekte und Domain-Axiome zur Klassifizierung der Subjekte – und nicht zum Validieren oder als (Typ-)Constraints.

Wollen Sie lokal für eine Klasse spezifizieren, dass eine Eigenschaft auf einen bestimmen Datentyp oder Wertebereich beschränkt sein soll, so definieren Sie dies als Type-/Value-Restriction auf Klassenebene. Da die Nutzung gemeinsam verwendeter Eigenschaften sowohl in Klassen als auch in Individuals in einem Graphen sehr leicht zu ermitteln ist, kann die Konsistenz der Ontologie ebenfalls leicht validiert werden, aber ohne den Effekt der automatischen Klassifizierung. Bei der Spezifikation von Klassen weiter unten wird der Artikel darauf noch genauer eingehen.

Object Properties anlegen

Während Dateneigenschaften konkrete Werte verschiedener Datentypen, sogenannte Literale, für Individuals enthalten referenzieren Objekteigenschaften (Object Properties) andere Individuals. Sie sind die Basis für die Beziehungen zwischen den Individuals in einem Graphen, beispielsweise die Relation zwischen einer Rechnung und dem dazugehörigen Kunden.

In RDF sind alle Entitäten, also auch alle Individuals und Eigenschaften, durch ihre IRIs eindeutig identifiziert. Entsprechend einfach sehen auch die Tripel für die Repräsentation von Relationen aus. Ein Beispiel:

dnp:Invoice_A dnp:hasCustomer dnp:Customer_B

Die Objekteigenschaft hasCustomer verbindet hier die Rech-nung A mit dem Kunden B. Zum Anlegen einer solchen Eigenschaft klicken Sie im Protégé-UI unten auf das Register Object properties. Wie die Dateneigenschaften stammen in OWL alle Objekteigenschaften von owl:topObjectProperty ab. Selektieren Sie owl:topObjectProperty und klicken Sie den Button Add sub property an. Protégé fordert Sie auf, den Namen der Objekteigenschaft einzugeben (Bild 1).

Open

Anlegen einer Object Property „hasCustomer“ (Bild 1)

Wie bei den IRIs für die Klassen setzt Protégé per Vorgabe den IRI der Eigenschaft aus dem Ontologie-IRI, dem Trennzeichen # und dem eingegebenen Bezeichner zusammen. Das ist international eindeutig und in Abfragen gut lesbar.

Klassen – Klassifizierung versus Schemata

Der nächste Schritt nach dem Erstellen von Taxonomie, Daten- und Objekteigenschaften ist die Spezifikation der einzelnen Klassen mit ihren jeweiligen Eigenschaften und Constraints. Zuvor ging es darum, wie in Ontologien Domain- und Range-Axiome zur automatischen Klassifizierung von Individuals eingesetzt werden, also zum automatischen Gruppieren von Individuals zu Mitgliedern einer oder mehrerer Klassen: die implizite Einfach- oder Mehrfachklassifizierung.

Aus der OOP-Welt kommend ist man jedoch versucht, die Klassen in einer Ontologie nicht als Gruppen von Individuals, sondern als Schemata anzusehen, als einen vorgegebenen Rahmen von Eigenschaften und ihren Constraints, den die Instanzen der Klassen einhalten müssen. Generell sind semantische Datenbanken aber zunächst einmal schemalos, was bedeutet, dass jedes einzelne Individual beliebige Eigenschaften erhalten kann. Auch müssen Individuals nicht zwangsläufig über eine oder gar mehrere Klassifizierungen verfügen, weder über explizite mithilfe von rdf:type noch über implizite durch Domain- und Range-Axiome.

Was wegen seiner Offenheit und Freiheitsgerade ideal für die Abbildung komplexer realer Umgebungen, von Umwelt und Wissensdomänen ist, mag verglichen mit den Tabellen und Kollektionen aus der SQL- und NoSQL-Welt unpraktikabel erscheinen, gibt es doch beispielsweise für ERP-Systeme meist eine Vielzahl gleichartiger Instanzen wie Kunden, Produkte oder Rechnungen, die allesamt eigenen Schemata unterliegen. Doch auch OWL bietet Mechanismen, um Schemata zu definieren, wenn auch mit einem etwas anderen Blickwinkel als vielleicht erwartet.

Während mit traditionellen Schemata zum Beispiel gesagt wird: „Eine Person hat einen Namen“, wird dies in Ontologien ausgedrückt mit: „Eine Person ist eine Unterklasse aller Dinge, die einen Namen haben“. Diese Ausdrucksweise stammt aus der Description Logic (DL), hört sich etwas verwirrend an, meint aber im Prinzip das Gleiche. Da es keine konkrete Klasse Ding mit einem Namen gibt, handelt es sich technisch um die Vererbung von einer sogenannten anonymen Klasse. Weil Mehrfachvererbung integraler Bestandteil von OWL ist, ist auch die Definition mehrerer Eigenschaften pro Klasse nach diesem Konzept nicht nur kein Problem, sondern beabsichtigte und etablierte Modellierungspraxis.

Bild 2 zeigt die Klasse Product mit ihren Dateneigenschaften. Entsprechend der genannten DL-/OWL-Konventionen sind diese nicht etwa bei den Eigenschaften, sondern im Bereich SubClass Of zu finden.

Open

Die Spezifikation der Klasse „Product“ in Protégé (Bild 2)

Die Datentypen werden angegeben als sogenannte Data-Restrictions (Bild 3), eine Art Type- und Value-Constraints. Die Angaben zur Kardinalität (der erlaubten Anzahl) der Eigenschaften ist ein zusätzliches Merkmal von OWL. Wichtig sind hier zwei Aspekte:

• Zum einen werden die Restrictions – im Gegensatz zu den Domain- und Range-Axiomen – auf Klassenebene und nicht auf Ebene der Eigenschaften appliziert. Sie gelten daher nicht global, sondern nur für die entsprechende Klasse.

• Zum anderen führen Restrictions nicht wie die Axiome zu einer automatischen Klassifizierung der Individuals der Klasse. Sie haben vorrangig deskriptiven Charakter, erzeugen keine neuen Tripel, werden aber vom Reasoner bei den Konsistenz-Checks berücksichtigt.

Aufgrund der Open World Assumption ist dies ist aber nicht gänzlich mit einem Validierungsschema vergleichbar. Ist im Beispiel eine minimale Kardinalität mit 1 angegeben und verfügt ein Individual nicht über eine entsprechende Eigenschaft, so wird der Reasoner dies nicht als Verletzung erkennen, denn die OWA besagt ja, dass alles, was nicht explizit angegeben ist, schlicht unbekannt, aber nicht zwangsläufig falsch ist. Das Tripel für die unbekannte Eigenschaft könnte sich ja in einer anderen Ontologie oder Datenbank befinden. Hier hilft SHACL [4]; dazu in einem Folgeartikel mehr.

Für die Objekteigenschaften gilt Gleiches. Der wichtige Unterschied ist, dass der Restriction Filler hier im rechten Bereich anstatt der Datentypen eine Klasse in der Taxonomie (der Klassenhierarchie) zur Auswahl anbietet. Die Spezifikation der Kardinalität wirkt auf die Objekteigenschaften in identischer Weise wie bei den Dateneigenschaften.

Individuals anlegen

Die Klassen mit ihren Restrictions sind angelegt, nun kommen die Individuals an die Reihe, die eigentlichen Datensätze in der Ontologie. In Protégé wechseln Sie dazu zum Register Individuals by class und unten links in den Bereich Direct Instances. Er zeigt alle bereits vorhandenen Individuals der oben ausgewählten Klasse, in Bild 4 am Beispiel von Product.

Beachten Sie, dass in der dotnetpro-Beispiel-Ontologie zu diesem Artikel [5] alle Produkte mit Labels versehen sind und der Protégé-Renderer im Screenshot die Labels anzeigt. Schwebt der Mauszeiger über einem Artikel, zeigt der Tooltipp seinen vollständigen IRI.

Im Gegensatz zu Klassen und Eigenschaften, die pro Ontologie einmalig sind, gestaltet sich die IRI-Vergabe für eine Vielzahl von Individuals erwartungsgemäß anders. Während Klassen und Eigenschaften üblicherweise eindeutige und von Menschen lesbare Bezeichner erhalten, wäre bei mehreren Individuals mit gegebenenfalls gleichen Namen keine Eindeutigkeit des IRI pro Ressource mehr gewährleistet. Ein IRI dnp:AlexanderSchulze würde unweigerlich zu Konflikten mit einer gleichnamigen Person in der Datenbank führen.

Eine gute Praxis für die Vergabe von IRIs für Individuals ist daher die Kombination aus Klassenname und einer UUID, einer Art Primärschlüssel für die entsprechende Ressource. Glücklicherweise unterstützt Protégé das Generieren von IRIs mit UUIDs recht komfortabel.

Zum Anlegen eines neuen Individuals klicken Sie auf den Add-Button oberhalb der Liste und dann auf New Entity Options. Protégé bietet einen Assistenten, mit dem sich die Vergabe des IRI konfigurieren lässt (Bild 5).

Wählen Sie als Nächstes die Option Autogenerated ID und geben Sie weiter unten das gewünschte Präfix für den IRI ein, hier Product_. Sobald Sie dann einen Namen für das neue Individual eingeben (Bild 6), erstellt Protégé mit jedem getippten Buchstaben eine neue UUID und hängt sie an das gewählte Präfix an.

Wie im Screenshot zu sehen ist, erstellt Protégé in diesem Fall automatisch ein Label für das betreffen- de Produkt und stellt dieses auch entsprechend in der Nutzeroberfläche dar. Mit dieser Technik sind also sowohl die weltweite Eindeutigkeit von Individuals wie auch die Lesbarkeit für den Administrator gewährleistet.

Anlegen von Annotations

Annotationen sind Aussagen, die an jede Entität (Klasse, Individual oder Eigenschaft) angehängt werden können, ohne dabei deren Semantik zu beeinflussen. Verwendet werden können sie zum Beispiel für Kommentare, zur Angabe von Autoren oder Versionsnummern, aber auch für Übersetzungen in verschiedene Landessprachen. Sie werden wie Daten behandelt, lassen sich also via SPARQL abfragen und manipulieren. Reasoner berücksichtigen die Annotationen nicht.

Um eine Annotation für eine Entität anzulegen, selektieren Sie Letztere im linken Bereich des Protégé-UI. Rechts erscheinen dann deren Annotationen im gleichnamig benannten Tab. Bild 7 zeigt ein Beispiel für die Dateneigenschaft purchasePrice, für die schon zwei label- und zwei comment-Annotationen jeweils in deutscher und englischer Sprache angelegt wurden.

Um eine Annotation neu anzulegen, klicken Sie den Add- Button; um eine bestehende zu ändern, nutzen Sie den Edit-Button hinter der betreffenden Annotation. Protégé fordert Sie auf, den Typ der Annotation und deren Wert einzugeben. In Bild 8 sehen Sie die Eingabe einer Dokumentation in englischer Sprache für die Eigenschaft purchasePrice in Form einer comment-Annotation.

Das Beispiel macht deutlich, dass in Ontologien direkt eingebundene Metadaten nicht nur deren kulturübergreifende Dokumentation für Entwickler vereinfachen, sondern auch die Wartung von Inhalten für internationale Zielgruppen. OWL erlaubt es zudem, beliebige weitere und ebenso internationalisierbare Annotation-Typen anzulegen.                                                           

Kollaboration und I18N für Ontologien

Insbesondere für die Zusammenarbeit an Ontologien in internationalen Teams ist ein Merkmal von Protégé besonders nützlich: Das Rendering der Bezeichner aller Entitäten ist konfigurierbar. So können Sie zum Beispiel bestimmen, ob Sie den kompletten IRI, die Named-Prefix-Notation oder eine Annotation im UI darstellen wollen – im Fall der Annotation sogar, in welcher Sprache.

Eine gute Praxis hinsichtlich Dokumentation und internationaler Nutzbarkeit von Ontologien ist daher, jede Klasse, Eigenschaft und jedes Individual mit mindestens einer comment- und einer label-Annotation in englischer Sprache zu versehen, idealerweise auch in weiteren Sprachen, je nach Verteilung des Teams oder Umfang der Zielgruppe.

Zur Konfiguration des Renderers wählen Sie im Hauptmenü von Protégé unter dem Menüpunkt Preferences den Tab Renderer und dort die Option Render by annotation property. Den Einstellungsdialog zeigt Bild 9.

Mit einem Klick auf Configure … können Sie dann bestimmen, welcher Annotation-Typ zum Darstellen der Oberfläche und welche Sprache ver- wendet werden sollen (Bild 10).

So lässt sich dann die Ontologie leicht auf die gewünschte Sprache „umstellen“, was die Wartung von Ontologien auch kulturübergreifend sehr einfach macht. Bild 11 zeigt exemplarisch, wie die Taxonomie nun in Deutsch gerendert wird.

Da die meisten Bezeichner für Klassen und Eigenschaften in Ihrer Ontologie wahrscheinlich ohnehin in Englisch erfasst werden, mag der Einsatz und die Wartung von Labels für jede Entität zunächst umständlich erscheinen. Spätestens aber, wenn Sie eine Vielzahl an Individuals in Protégé verwalten, werden Sie die Labels schnell zu schätzen wissen. Denken Sie etwa an IRIs mit UUIDs für Produkte wie das folgende:

Product_c2318c23_2db8_4c8b_9dbf_cd20970d7723

Im Protégé-UI ist hier das eigentliche Produkt nicht praktikabel identifizierbar. Versehen Sie es aber mit einem Label, so wird es mit eben diesem dargestellt. In der Beispiel-Ontologie sieht das dann so aus:

Blu-ray Player, HD, inklusive Kabel

Was in Protégé noch manuell erfolgt, lässt sich in Applikationen leicht automatisieren. Eine gute Praxis ist, für jede Klasse eine Vorlage festzulegen, anhand der die Labels automatisch aus bestimmten Feldern der jeweiligen Individuals zusammengesetzt werden, für ein Produkt zum Beispiel aus den Feldern productCode und productName. Hierzu mehr in einem späteren Artikel, wenn es um die Programmierung mit Ontologien und semantischen Graph-Datenbanken geht.

Data Properties versus Annotations

Da der Name von Individuals üblicherweise willkürlich und daher weder semantisch noch relational relevant ist, stellt sich die Frage, ob für derartige Angaben nicht grundsätzlich Annotationen statt Dateneigenschaften verwendet werden sollten. Da Werte für Annotationen in SPARQL-­Abfragen technisch ähnlich ermittelt werden können wie die von Dateneigenschaften, erscheint dies legitim, insbesondere um unnötige Redundanzen zu vermeiden.

Und für überwiegend statische und manuell gepflegte Lookup-Listen oder Enumerationen ist dies auch durchaus vertretbar. Für dynamische Datenbestände kalkulieren Sie jedoch den manuellen Aufwand beim Erstellen gemischter Abfragen aus Annotationen und Eigenschaften. Außerdem unterliegen Annotationen keinerlei Einschränkungen – weder zu ihren Werten noch zu ihrer Kardinalität (Anzahl), was letztlich die Validierungsoptionen der Apps einschränkt und das Risiko von Mehrdeutigkeiten oder Inkonsistenzen erhöht.

Abfragen gegen Individuals von rein auf Eigenschaften basierenden Klassen hingegen lassen sich leicht programma-tisch und somit automatisch generieren. Individuals können programmatisch gegen die Property Constraints validiert und basierend darauf sogar SHACL-Shapes automatisch erzeugt werden. Hier eröffnet sich ein enormes Potenzial für Automatisierungen und Produktivitätssteigerungen, die ein Folgeartikel noch genauer beleuchten wird.

Export von Modellen

Zum Schluss dieses Beitrags sei noch ein Blick darauf geworfen, wie sich die in Protégé erzeugten Modelle für die Nutzung in W3C-konformen Graph-Datenbanken exportieren lassen. Dazu kann es aus Protégé einfach in einem der angebotenen Standardformate wie zum Beispiel RDF/XML, Turtle oder JSON-LD gespeichert werden. Wählen Sie hierzu lediglich den Menüpunkt File | Save As und selektieren Sie das gewünschte Format.

Semantische Graph-Datenbanken wie zum Beispiel Graph-DB von Ontotext verfügen über diverse Adapter, die den Import des Modells sehr vereinfachen. Für die Praxis empfiehlt es sich, Modell und Instanzen in getrennten Sub-Graphen zu verwalten. So ist es sehr leicht möglich, den Modellgraphen in der Datenbank nach Updates in Protégé zu aktualisieren, ohne dabei die bestehenden Daten zu gefährden.

Fazit

Protégé ist ein ausgereiftes Werkzeug zum Modellieren von Ontologien und ein unverzichtbarer Assistent beim Erstellen und Warten von W3C-konformen semantischen Datenmodelle und Ontologien. Es bietet nützliche Funktionen, um Klasse, Taxonomien, Eigenschaften und Constraints in einem für Entwickler komfortablen und konfigurierbaren UI zu verwalten, ohne sich um die darunterliegenden RDF-, RDFS- und OWL-Tripel und ihre vielfältigen Repräsentationen in den diversen Dateiformaten kümmern zu müssen.
Geschrieben ist Protégé in Java, es läuft somit auf allen Plattformen. Zur Seite stehen eine Vielzahl von Plug-ins, inklusive solche für SPARQL, SHACL sowie unterschiedliche und ebenfalls konfigurierbare Reasoner. So kann Protégé der umfangreichen Palette von Anforderungen an die Entwicklung einer Ontologie gerecht werden, einschließlich Annotationen und Präfixen, IRI-Automatik und Internationalisierung bis hin zum Zusammenführen mehrerer Ontologien in Katalogen zum Aufbau umfangreicher Knowledge-Graphen.

Entworfen wurde Protégé als semantisches Modellierungs-Tool mit einer Import-/Export-Schnittstelle für alle gängigen W3C-konformen Dateiformate. Den effizienten Betrieb der eigentlichen Datenbank mit Millionen und Milliarden von Tripeln überlässt Protégé etablierten Herstellern wie etwa Ontotext oder Stardog, ebenso wie das eigentliche Wissensmanagement und die App-Entwicklung den Software- und Knowledge-Graph-Entwicklern überlassen bleibt.

Der nächste Artikel hierzu wird zeigen, wie Sie eine semantische Graph-Datenbank einrichten und betreiben, ebenso wie Sie Daten und Wissen darin komfortabel verwalten und für Anwendungen bereitstellen. Bleiben Sie also dran!

[1]  Alexander Schulze, Mit Wissen anstatt Daten arbeiten, Semantisches Web Teil 1, dotnetpro 4/2020, Seite 78 ff., http://www.dotnetpro.de/A2004Semantik

[2] Alexander Schulze, Zuerst das Modell, Semantisches Web Teil 2, dotnetpro 5/2020, Seite 96 ff., http://www.dotnetpro.de/A2005Semantik

[3] Protégé, https://protege.stanford.edu

[4] Wikipedia, SHACL, http://www.dotnetpro.de/SL2006Semantik1

[5] GitHub ENAPSO dotnetpro Repository, http://www.dotnetpro.de/SL2006Semantik2

Alexander Schulze

Geschäftsführer der Innotrade GmbH, ist Ex-perte für semantisches Datenmanagement und Business Analytics. Als IT-Consultant, Speaker und Autor berichtet er regelmäßig über KI und Wissensmanagement und deren Nutzen. aschulze@innotrade.de