SEMANTISCHES WEB, TEIL 3

Vom Modell zur Datenbank

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

ie Grundlagen des „Semantischen Web“ hat die dotnet- pro 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 Ob- jekte in einer semantischen Graph-Datenbank, Reasoner, die für die Konsistenz der Daten sorgen, und die Inferenz, die lo- gische Schlussfolgerungen und damit das maschinelle Ler-nen 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 An- notationen verwalten, wie Sie Schemata und Klassifizierun- gen 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 synchro- nisiert und dort für das Wissensmanagement verwendet wer- den. Er schließt ohne Umschweife an den zweiten Teil an.

Protégé ist ein sehr ausgereiftes und eines der am häufigs- ten eingesetzten freien Tools zum Modellieren von Ontolo- gien. 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 generier- te 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ön- nen 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 UI-orientiertes Mo- dellierungswerkzeug 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 Eigen- schaften definiert werden – mit entsprechenden Auswirkun- gen 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 Com- pany wird – ohne dass dies einer expliziten Klassenzuwei- sung à 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, automa- tisch 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 Klassenzuord- nungen zu vermeiden. Eine gute Praxis ist, Axiome als Instru- ment 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 Ei- genschaft 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 In- dividuals in einem Graphen sehr leicht zu ermitteln ist, kann die Konsistenz der Ontologie ebenfalls leicht validiert wer- den, aber ohne den Effekt der automatischen Klassifizierung. Bei der Spezifikation von Klassen weiter unten wird der Arti- kel darauf noch genauer eingehen.

Object Properties anlegen

Während Dateneigenschaften konkrete Werte verschiedener Datentypen, sogenannte Literale, für Individuals enthalten,

Anlegen einer Object Property „hasCustomer“ (Bild 1)

referenzieren Objekteigenschaften (Object Properties) ande- re Individuals. Sie sind die Basis für die Beziehungen zwi- schen 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. Ent- sprechend einfach sehen auch die Tripel für die Repräsenta- tion 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 Ei- genschaft 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).

Wie bei den IRIs für die Klassen setzt Protégé per Vorgabe den IRI der Eigenschaft aus dem Ontologie-IRI, dem Trenn- zeichen # 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, Da- ten- und Objekteigenschaften ist die Spezifikation der einzel- nen Klassen mit ihren jeweiligen Eigenschaften und Con- straints. Zuvor ging es darum, wie in Ontologien Domain- und Range-Axiome zur automatischen Klassifizierung von Indivi- duals eingesetzt werden, also zum automatischen Gruppie- ren von Individuals zu Mitgliedern einer oder mehrerer Klas- sen: 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 In- stanzen der Klassen einhalten müssen. Generell sind seman- tische Datenbanken aber zunächst einmal schemalos, was bedeutet, dass jedes einzelne Individual beliebige Eigen- schaften 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 unpraktika- bel erscheinen, gibt es doch beispielsweise für ERP-Systeme meist eine Vielzahl gleichartiger Instanzen wie Kunden, Pro- dukte oder Rechnungen, die allesamt eigenen Schemata un- terliegen. Doch auch OWL bietet Mechanismen, um Schema- ta zu definieren, wenn auch mit einem etwas anderen Blick- winkel als vielleicht erwartet.

Während mit traditionellen Schemata zum Beispiel gesagt wird: „Eine Person hat einen Namen“, wird dies in Onto- ▶

Das Spezifizieren einer Dateneigenschaft für die Klasse „Product“ (Bild 3)

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

logien ausgedrückt mit: „Eine Person ist eine Unterklasse al- ler Dinge, die einen Namen haben“. Diese Ausdrucksweise stammt aus der Description Logic (DL), hört sich etwas ver- wirrend 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 anony- men Klasse. Weil Mehrfachvererbung integraler Bestandteil von OWL ist, ist auch die Definition mehrerer Eigenschaften pro Klasse nach diesem Konzept nicht nur kein Problem, son- dern beabsichtigte und etablierte Modellierungspraxis.

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

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 Eigen- schaften 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 da- her 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, erzeu- gen 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 ver- fügt ein Individual nicht über eine entsprechende Eigen- schaft, so wird der Reasoner dies nicht als Verletzung erken-

nen, 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 Be- reich anstatt der Datentypen eine Klasse in der Taxonomie (der Klassenhierarchie) zur Auswahl anbietet. Die Spezifika- tion der Kardinalität wirkt auf die Objekteigenschaften in identischer Weise wie bei den Dateneigenschaften.

Individuals anlegen

Die Klassen mit ihren Restrictions sind angelegt, nun kom- men die Individuals an die Reihe, die eigentlichen Datensät- ze in der Ontologie. In Protégé wechseln Sie dazu zum Regis- ter 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

Die Individuals in Protégé verwalten (Bild 4)

Protégé generiert automatisch eindeutige IRIs (Bild 6)

Automatische IRI-Generierung für Individuals (Bild 5)

der Protégé-Renderer im Screenshot die Labels anzeigt. Schwebt der Mauszeiger über einem Artikel, zeigt der Tool- tipp seinen vollständigen IRI.

Im Gegensatz zu Klassen und Eigenschaften, die pro Onto- logie 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 mehre- ren 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 Op- tions. Protégé bietet einen Assistenten, mit dem sich die Ver- gabe des IRI konfigurieren lässt (Bild 5).

Wählen Sie als Nächstes die Option Auto-genera- ted ID und geben Sie weiter unten das gewünsch- te Präfix für den IRI ein, hier Product_. Sobald Sie dann einen Namen für das neue Individual einge- ben (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 Indivi- duals wie auch die Lesbarkeit für den Administra-

Anlegen von Annotations

Annotationen sind Aussagen, die an jede Entität (Klasse, In- dividual 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 Übersetzun- gen in verschiedene Landessprachen. Sie werden wie Daten behandelt, lassen sich also via SPARQL abfragen und mani- pulieren. 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 erschei- nen 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 eng- lischer Sprache für die Eigenschaft purchasePrice in Form ei-

ner comment-Annotation.

Das Beispiel macht deutlich, dass in Ontologien direkt ein- gebundene Metadaten nicht nur deren kulturübergreifen-  ▶

tor gewährleistet.                                                                   

     Internationale „label“- und „comment“-Annotations (Bild 7)

Annotation in Englisch zu einer Dateneigenschaft hinzufügen (Bild 8)

de Dokumentation für Entwickler vereinfachen, sondern auch die Wartung von Inhalten für internationale Zielgrup- pen. 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 inter- nationalen 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 ei- ne Annotation im UI darstellen wollen – im Fall der Annota- tion sogar, in welcher Sprache.

Eine gute Praxis hinsichtlich Dokumentation und interna- tionaler Nutzbarkeit von Ontologien ist daher, jede Klasse, Ei- genschaft und jedes Individual mit mindestens einer com- ment- 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 Hauptme- nü von Protégé unter dem Menüpunkt Preferences den Tab Renderer und dort die Option Render by annotation proper- ty. 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 ge- wünschte Sprache „umstellen“, was die Wartung von Ontologien auch kulturübergreifend sehr ein- fach macht. Bild 11 zeigt exemplarisch, wie die Taxo- nomie nun in Deutsch gerendert wird.

Da die meisten Bezeichner für Klassen und Ei- genschaften in Ihrer Ontologie wahrscheinlich oh- nehin in Englisch erfasst werden, mag der Einsatz und die Wartung von Labels für jede Entität zu- nä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 praktika- bel identifizierbar. Versehen Sie es aber mit einem Label, so wird es mit eben diesem dargestellt. In der Beispiel-Ontolo- gie sieht das dann so aus:

Blu-ray Player, HD, inklusive Kabel

Was in Protégé noch manuell erfolgt, lässt sich in Applikatio- nen leicht automatisieren. Eine gute Praxis ist, für jede Klas- se eine Vorlage festzulegen, anhand der die Labels automa- tisch aus bestimmten Feldern der jeweiligen Individuals zu- sammengesetzt werden, für ein Produkt zum Beispiel aus den Feldern productCode und productName. Hierzu mehr in ei- nem 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

Den Renderer von Protégé einstellen (Bild 9)                                         

Die Anzeige auf deutsche Labels umschalten (Bild 10)

sollten. Da Werte für Annotationen in SPARQL-Abfragen technisch ähnlich ermit- telt werden können wie die von Dateneigen- schaften, erscheint dies legitim, insbesonde- re um unnötige Redundanzen zu vermeiden. Und für überwiegend statische und manuell gepflegte Lookup-Listen oder Enumeratio- nen ist dies auch durchaus vertretbar.

Für dynamische Datenbestände kalkulie- ren Sie jedoch den manuellen Aufwand beim Erstellen gemischter Abfragen aus An- notationen und Eigenschaften. Außerdem unterliegen Annotationen keinerlei Ein- schränkungen – weder zu ihren Werten noch zu ihrer Kardinalität (Anzahl), was letztlich die Validierungsoptionen der Apps einschränkt und das Risiko von Mehrdeutig- keiten oder Inkonsistenzen erhöht.

Internationalisierung in Protégé, hier die deutschen Klassenbezeichner (Bild 11)

und ebenfalls konfigurierbare Reasoner. So kann Protégé der

Abfragen gegen Individuals von rein auf Eigenschaften ba- sierenden 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 Auto- matisierungen und Produktivitätssteigerungen, die ein Folge- artikel noch genauer beleuchten wird.

Export von Modellen

Zum Schluss dieses Beitrags sei noch ein Blick darauf gewor- fen, wie sich die in Protégé erzeugten Modelle für die Nut- zung in W3C-konformen Graph-Datenbanken exportieren lassen. Dazu kann es aus Protégé einfach in einem der ange- botenen Standardformate wie zum Beispiel RDF/XML, Turt- le oder JSON-LD gespeichert werden. Wählen Sie hierzu le- diglich 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 Im- port 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 Datenmodel- le und Ontologien. Es bietet nützliche Funktionen, um Klas- se, Taxonomien, Eigenschaften und Constraints in einem für Entwickler komfortablen und konfigurierbaren UI zu verwal- ten, ohne sich um die darunterliegenden RDF-, RDFS- und OWL-Tripel und ihre vielfältigen Repräsentationen in den di- versen 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, in- klusive solche für SPARQL, SHACL sowie unterschiedliche

umfangreichen Palette von Anforderungen an die Entwick- lung einer Ontologie gerecht werden, einschließlich Annota- tionen und Präfixen, IRI-Automatik und Internationalisierung bis hin zum Zusammenführen mehrerer Ontologien in Kata- logen 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 Wissens- management und die App-Entwicklung den Software- und Knowledge-Graph-Entwicklern überlassen bleibt.

Der nächste Artikel hierzu wird zeigen, wie Sie eine seman- tische 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