Mit Wissen(sgraphen) anstatt Daten(banken) arbeiten

Semantik reichert Daten mit Bedeutung an. Die wird in semantischen Graph-Daten- banken gespeichert.

Graph-Datenbanken eröffnen Entwicklern in vielerlei Hinsicht neue Möglichkeiten und Perspektiven, und das nicht nur, wenn es um Modellierung, Klassen und ihre Eigen- schaften geht. Im Gegensatz zu den bekannten SQL- und NoSQL-Datenbanken mit ihren Tabellen und Spalten, Auflis- tungen und Feldern erweitern Graph-Datenbanken die ge- wohnte Sicht auf Schemata, Objekte und Vererbung um neue Merkmale wie Metadaten, Inferenz und das Verlinken meh- rerer Graph-Datenbanken zu umfangreichen KnowledgeGraphen.

Mit den entsprechenden Werkzeugen lassen sich Daten zu einem sogenannten semantischen Netz verknüpfen. Das ist gar nicht so neu. Tim Berners Lee hat den Begriff „semanti- sches Web“ bereits 2001 geprägt. Das W3C hat ihn 2004 mit Standards wie OWL (Web Ontology Language, 2012 mit OWL2) erweitert und praxistauglich gemacht. Was für lange Zeit von eher wissenschaftlichem Interesse war und ein Insel- dasein fristete, hat sich mittlerweile zu professionellen Pro- dukten gemausert, die in puncto Qualität, Laufzeitverhalten, Verfügbarkeit und Skalierbarkeit einen Reifegrad erreicht haben, der ein genaueres Hinsehen wert ist.

Dabei wäre zuerst einmal zu klären, in welchen Szenarien sich der Einsatz einer semantischen Graph-Datenbank lohnt und welche Vorteile die neuen Technologien für Entwickler und für die Nutzer bringen.

Dabei soll eine Brücke zwischen aktueller Forschung und praktischer Entwicklung geschlagen werden, rund um die Themen moderne RDF Triple Stores, neue Arten der Klassifi- zierung und Validierung von Objekten, einer neuen Perspek- tive auf Dateneigenschaften und automatisches Lernen, aber auch auf Interoperabilität, Portabilität, Wiederverwendung, Harmonisierung und die Qualität von Daten.

Das wird mehrere Beiträge erfordern und am Ende dieser Artikelreihe werden Sie in der Lage sein, ein semantisches Datenmodell mit Klassen und Eigenschaften zu erzeugen und in einer Ontologie mithilfe der Abfragesprache SPARQL in Node.js-Instanzen anlegen, lesen, aktualisieren und löschen (CRUD) zu können.

Knowledge-Graphen

Semantische Graph-Datenbanken oder auch Ontologien be- stehen im Wesentlichen aus einer Klassenhierarchie, einer Taxonomie (auch als T-Box bezeichnet) und den sogenannten Individuals, also den Instanzen der Klassen (auch als A-Box bezeichnet). Hinzu kommen Dateneigenschaften mit konkre- ten Werten verschiedener Datentypen, den sogenannten Li- teralen, und die Objekteigenschaften mit Referenzen auf an- dere Individuals, den eigentlichen Verlinkungen. All diese Entitäten werden auch als Ressourcen bezeichnet.

Innerhalb eines Graphen werden alle Ressourcen mithilfe sogenannter URIs oder IRIs identifiziert; IRI steht für Interna- tionalized Resource Identifier, dazu gleich mehr im nächsten Abschnitt. URIs/IRIs sind vergleichbar mit Primärschlüsseln aus der Welt der Tabellen und Collections, sind aber eindeu- tig über den gesamten Graphen hinweg und nicht nur bezo- gen auf die Instanzen einer bestimmten Klasse.

Das semantische Web wird auch als das „Web der Daten“ bezeichnet. Eines der Paradigmata ist dabei, dass nicht nur Ressourcen innerhalb einer Ontologie miteinander verlinkt werden können, sondern auch beliebige Ontologien unter- einander, inklusive der darin enthaltenen Ressourcen. Die Kombination mehrerer Ontologien, meist in hierarchischen Strukturen, wird als Knowledge-Graph bezeichnet.

Eine Besonderheit in semantischen  Graph-Datenbanken ist der „Reasoner“ – eine Regel-Engine innerhalb der Daten- bank selbst mit verschiedenen standardisierten, aber auch konfigurierbaren Regelsätzen.

Zum einen bildet der Reasoner die sogenannte Inferenz ab: eine Funktion, um automatisch logische Schlussfolgerungen aus bereits bestehenden Aussagen zu ziehen und diese als neues Wissen bereitzustellen.

Zum anderen dient er zum Validieren und zum Prüfen der Konsistenz, etwa um Widersprüche oder Regelverletzungen auszuweisen, und somit auch, um die Datenqualität sicherzu- stellen.

Begriffe und Abkürzungen

Wer sich mit dem semantischen Web beschäftigt, stößt auf eine Reihe neuer Begriffe und Abkürzungen, deren Kenntnis zum Verständnis von Modellen, Relationen und Funktionen wichtig sind. Zuerst noch einmal eine kurze Zusammenfas- sung zu den Unterschieden von URL, URI und IRI.

Ein Uniform Resource Locator (URL) gibt den Ort einer be- stimmten Ressource an, er dient also zum Lokalisieren. Da- runter fallen Adressen, also Referenzen zu Inhalten, die sich fortwährend ändern können, zum Beispiel zu einer HTML- Seite oder einer Datenbank.

Nach dem RFC 1738 [1] von 1994 ist für einen URL nur ei- ne Teilmenge von 60 US-ASCII-Zeichen erlaubt, was für in- ternationalisierte Anwendungen heute eine erhebliche Ein- schränkung darstellt. Der Begriff des Base-URL wird verwen- det, um eine Adresse mit einem Pfad in mehrere Unteradres- sen einzuteilen, zum Beispiel http://my.baseurl.com/cat1/ func2. Das Schema https statt http für den URL hat eine be- sondere Bedeutung, denn hier bewirkt es die Verschlüsse- lung des Transfers, in der Regel zwischen Webserver und Browser.

Der Uniform Resource Identifier (URI) dient dazu, bestimm- te Ressourcen global eindeutig zu identifizieren. Im Web sind dies beispielsweise konkrete Dateien oder Schnittstellen zu Diensten. Sie bestehen aus einem URL gefolgt von einem Da- tei- oder Servicenamen, optional mit zusätzlichen Abfrage- parametern oder Hash-Werten, etwa http://my.domain/db/ customers?id=7 oder http://my.domain/db/product#46510; URLs sind insofern eine Untermenge der URIs. Laut RFC 3986

[2]   unterliegen URIs den gleichen Zeichensatzbeschränkun- gen wie die URLs.

Bleibt als Dritter im Bund noch der IRI, der Internationa- lized Resource Identifier. Er wurde 2005 von der IETF (Inter- net Engineering Task Force) standardisiert, um den moder- nen Anforderungen nach einem globalen Einsatz gerecht zu werden. Wie der URI dient er dazu, eine bestimmte Ressour- ce weltweit eindeutig zu identifizieren. Er erfüllt den gleichen Zweck wie der URI, jedoch ohne die Einschränkung beim ASCII-Zeichensatz. Nach RFC 3987 sind für IRIs bis auf we- nige Ausnahmen alle UTF-8-Zeichen erlaubt [3].

Im Kontext des semantischen Webs sind IRIs zusammenge- setzt aus einem Namensraum, einem Separator und einem so- genannten Localname. Als De-facto-Standard hat sich das #-Zeichen etabliert, auch wenn noch einige weitere erlaubt sind. Analog zu URL und URI sollte der Namensraum konse- quenterweise eigentlich IRL heißen, also International Re- source Locator, doch hat sich dieser Begriff nie durchgesetzt.

Ein gültiger IRI für eine Ressource in einer Ontologie ist zum Beispiel:

http://ont.dotnetpro.de/erp#product_1

Der Namensraum ist hier http://ont.dotnetpro.de/erp# und der Localname product_1, im weiteren Verlauf dieses Artikels schlicht als Name oder Identifier bezeichnet. Im Gegensatz zum URL ist bei IRIs das Schema https nicht nur unüblich, es bewirkt aufgrund des reinen Identifikationscharakters auch keinerlei Verschlüsselung – weder des Transports noch der Inhalte.

Namensräume und Domänen

Für die Interoperabilität von Ontologien gilt es als gute Pra- xis, nur solche Namensräume zu verwenden, deren offiziel- ler Domäneninhaber Sie auch selbst sind. In der Beispiel-On- tologie zu diesem Text könnte er zum Beispiel http://ont.dot­ netpro.de/[...] lauten. Zwar wird die Gültigkeit der Namens- räume bei der Veröffentlichung von Ontologien bisher weder von Nameservern (DNS) noch von einer offiziellen Institu- tion geprüft, doch riskieren Sie mit Namensräumen wie etwa http://foo.bar/ Fehler in Applikationen oder bei Nutzern da- durch, dass die Ressourcen nicht mehr global eindeutig refe- renziert und deshalb in international zusammengesetzten Knowledge-Graphen nicht verwendet werden können.

Namen mit Präfixen

Würden Ressourcen in RDF/OWL-Dateien oder in SPARQL- Kommandos immer durch ihren vollen IRI referenziert – syn- taktisch sind sogar noch zusätzlich umgebende <- und >-Zei- chen nötig –, so könnten diese recht schnell unübersichtlich werden und schwer zu lesen sein. Stellen Sie sich folgendes Tripel (siehe den Abschnitt „RDF“) vor:

<http://ont.dotnetpro.de/erp#invoice_1>

<http://ont.dotnetpro.de/props#hasProduct>

<http://ont.dotnetpro.de/erp#product_1>

Zur Abkürzung dieser umständlichen Schreibweise wurden sogenannte Präfixe für die Dateien ebenso wie für SPARQL eingeführt. Diese trennen den IRI in ein Kürzel, das Präfix, gefolgt von einem Doppelpunkt und dem eigentlichen Iden- tifier der Ressource. Diese werden am Anfang einer RDF/ OWL-Datei oder eines SPARQL-Kommandos deklariert und können im Folgenden als Stellvertreter für ihre Langversion verwendet werden:

prefix erp: <http://ont.dotnetpro.de/erp#> prefix props: <http://ont.dotnetpro.de/props#>

Tripel lassen sich dann anschließend einfach und in deutlich besser lesbarer Kurzform notieren:

erp:invoice_1 props:hasProduct erp:product_1

Im Rahmen von RDF, OWL und SPARQL wird diese Notation als Prefixed Name bezeichnet.

Primärschlüssel und Relationen

Neben den Konventionen zu den Namensräumen gibt es wei- tere bewährte Verfahren zu den IRIs. Da jede Ressource über einen eigenen datenbankübergreifenden und international eindeutigen IRI verfügt, sind in einem Graphen keine zusätz- lichen Primärschlüssel erforderlich; es müssen also keine spe- ziellen ID-Felder vorgesehen werden, etwa in Form von Da- teneigenschaften. Hierzu reichen die bestehenden IRIs völlig aus – de facto sind diese die globalen Primärschlüssel.

Gleiches gilt für Relationen und Fremdschlüssel. In einer 1:1- oder 1:n-Beziehung referenzieren eine oder mehrere Ob- jekteigenschaften eines Master-Individuals einfach dessen Child-Individuals mithilfe der Child-IRIs.

Das folgende Beispiel zeigt eine 1:n-Relation zwischen Rechnungen und Produkten, hier in sogenannter Prefixed- Names-Notation dargestellt:

erp:invoice_1 props:hasProduct erp:product_1 erp:invoice_1 props:hasProduct erp:product_2

erp:invoice_1 props:hasProduct erp:product_3

Der Vorteil eines Graphen ist, dass selbst n:m-Relationen kei- ne zusätzlichen Hilfstabellen oder -objekte mehr benötigen, wie man sie aus klassischen relationalen Datenbank-Archi- tekturen kennt, da die gleiche Objekteigenschaft von einem Individual mehrfach genutzt werden kann. Nutzer und Rol- len zum Beispiel lassen sich in einem RDF Triple Store wie folgt in Beziehung zueinander setzen:

erp:user_1 props:hasRole erp:role_1 erp:user_1 props:hasRole erp:role_2 erp:user_2 props:hasRole erp:role_1 erp:user_2 props:hasRole erp:role_2

RDF

RDF ist die Abkürzung für Resource Description Framework [4], ein vom World-Wide-Web-Konsortium (W3C) standardi- siertes Modellierungskonzept für das semantische Web, das mithilfe von Tripeln aus Subjekt, Prädikat und Objekt einfa- che logische Aussagen ermöglicht, die sich in gerichteten Graphen formulieren lassen und leicht von Maschinen gele- sen, verstanden und visualisiert werden können. Beispiele: Max hasAge 32 (Dateneigenschaft) oder Josef hasSpouse Maria (Objekteigenschaft).

Eine Sammlung von Tripeln wird auch als Triple Store be- zeichnet. Auf unterster Ebene ist eine semantische Graph- Datenbank ein solcher Triple Store. Wie die Tripel intern möglichst effizient verwaltet werden, obliegt dem Hersteller der Datenbank.

Für den Import in und den Export aus Dateien werden die RDF-Tripel in verschiedenen Formaten repräsentiert. Diese können zum Beispiel Turtle, Trig, N-Tripels, JSON-LD oder auch RDF/XML sein, mit ihren jeweiligen Vor- und Nachtei- len. Während Turtle (.ttl) wegen seiner Kompaktheit und leichten Lesbarkeit populär ist, ist Trig (.trig) eher für Backup und Wiederherstellen von Knowledge-Graphen geeignet, da auch die Angaben zu Subgraphen serialisiert und deseriali- siert werden.

Erwartungsgemäß ist JSON-LD verstärkt in JavaScript- Umgebungen und RDF/XML eher im Java-Bereich zu fin- den. Semantische Graph-Datenbanken wie beispielsweise GraphDB von Ontotext verfügen aber im Sinne von Interope- rabilität über Import- und Exportfunktionen für alle wichti- gen Formate.

RDFS

Die Abkürzung RDFS steht für Resource Description Frame- work Schema [5], eine semantische Erweiterung des RDF-Vo- kabulariums speziell für die Datenmodellierung. Es enthält Mechanismen insbesondere zum Gruppieren von Ressourcen und deren Beziehungen untereinander. Es ist vergleichbar mit dem Klassensystem, wie man es von der objektorientier- ten Programmierung (OOP) kennt, jedoch mit einer wesent- lichen und wichtigen Erweiterung: Während in der OOP für eine Klasse definiert wird, welche Eigenschaften sie hat und haben darf, kann ein RDF-Schema für Eigenschaften angelancer folgen und unter Employee vielleicht Developer, Architect und Manager. Da zeigt sich schon das erste Problem: Denn selbst wenn ein Freiberufler vielleicht kein Manager werden kann, wa- rum sollte er nicht auch ein Ent- wickler oder Softwarearchitekt sein können? Warum nicht gleich- zeitig Architekt und Manager?

Verallgemeinert ausgedrückt vermischen sich hier vertikale Vertragsarten horizontal mit Rol- len in einem Unternehmen (Bild 1). Was sich in kleinen Modellen noch umständlich durch Klassen- bezeichner mit Mehrfachbedeuben, welcher Klasse ein Individual automatisch zugeordnet wird, wenn es die betreffende Eigenschaft enthält oder refe- renziert. Eingeschlossen ist hier auch die Unterstützung von subClassOf und subPropertyOf, um Klassen und Eigenschaf- ten hierarchisch zu organisieren.

RDFS plus schließlich ist eine erweiterte Version von RDFS, die symmetrische, inverse und transitive Eigenschaften un- terstützt. Diese im Gegensatz zur OOP neuen Konzepte wer- den im Folgenden noch näher erläutert. Viele der RDFS- und RDFS-plus-Komponenten sind auch Teil der noch ausdrucks- stärkeren Web Ontology Language (OWL).

Open

OWL

Die Abkürzung OWL steht für Web Ontology Language [6]. Die Sprache wurde speziell für das semantische Web entwor- fen, um das Wissen über Objekte und Klassen (als Gruppen von Objekten) und deren Beziehungen untereinander darzu- stellen. Ontologien basieren auf RDF und OWL und können mit SPARQL als Abfragesprache gelesen und verändert wer- den. Reasoner unterstützen OWL.

Klassenbäume

Die Taxonomie ist ein wesentlicher Bestandteil eines seman- tischen Datenbankmodells. Sie entspricht eher dem hierar- chischen Klassenmodell aus der objektorientierten Program- mierung als den Schemata der traditionellen SQL- und No- SQL-Datenbanken für Tabellen oder Kollektionen. Die Klas- sen in der Taxonomie sind in einer Baumtopologie organi- siert, und sie können ihre Eigenschaften auch vererben.

Unzulänglichkeit der Baumtopologie

Mit konventionellen Klassenbäumen ist es jedoch schlecht praktikabel bis unmöglich, reale komplexe Umgebungen ab- zubilden. Zwar eignen sie sich, um Vererbungen vertikal um- zusetzen. Horizontale Aspekte jedoch, also solche, die meh- rere Teilbäume betreffen, lassen sich in Baumtopologien nicht abbilden.

Nehmen Sie als Beispiel die Mitarbeiter einer Firma. In ei- nem traditionellen Klassenbaum würde an oberster Stelle vielleicht Person stehen, dann würden Employee und Free­

tung vermeintlich lösen lässt, eskaliert beim Wachsen des Modells schnell zu einem semantischen Chaos.

Um dieses Problem anzugehen, fügen Sie in der klassi- schen OOP nun Felder wie beispielsweise Role ein. Aber wo? Für die Klasse Person ist es zu spezifisch, bei Employee und Freelancer schon wieder redundant – womit der Code wächst und der Wartungsaufwand steigt. Oder Sie fügen eine weite- re Hilfsklasse namens Personnel dazwischen ein. Semantisch ist das mehrdeutig und ebenfalls zusätzlicher Code.

Doch nicht nur das; auch hier werden wieder zwei Konzep- te vermischt, nämlich das der Klassifizierung und das der Ei- genschaften. Geradlinig wäre, wenn ein Individual gleichzei- tig Mitglied mehrerer Klassen sein könnte, im Beispiel also beispielsweise von der Oberklasse Person abstammen und gleichzeitig Mitglied einer Rollenklasse und einer Vertrags- artenklasse sein könnte. Semantische Datenbanken unter- stützen genau das.

Lösung der Mehrfachklassifizierung

In der OOP werden Klassen vorrangig als Schema verwen- det, also als eine Art Spezifikation für Instanzen. Aus dieser Perspektive ist es naturgemäß schwierig, Schemata mit et- waigen Überschneidungen oder Widersprüchen zu vermi- schen. Gleiches gilt für die Schemata der traditionellen rela- tionalen Datenbanken.

In Ontologien hingegen werden Klassen vorrangig als Gruppen von Individuals betrachtet. Individuals können da- bei explizit einer oder mehreren Klassen zugeordnet werden oder auch implizit durch den Einsatz bestimmter Eigenschaf- ten. Im Folgenden ist daher auch besser von Mehrfachklassi- fizierung die Rede als von Mehrfachvererbung.

Eine gute Praxis für das obige Beispiel wäre es zunächst, nur eine Klasse Person einzuführen; dann eine Klasse Rolle und darunter die Unterklassen Developer, Architect und Ma­ nager. Dazu kommt noch die Klasse Personnel und darunter die Unterklassen Employee und Freelancer.

Mithilfe dieses Konstrukts kann eine bestimmte Person, ge- nau genommen ein Individual der Klasse Person, nun Mit- glied der Klassen Person und entweder der Klasse Employee

(exklusiv) oder  Freelancer  sein  und zusätzlich Mitglied von einer oder mehreren Rollen- klassen, also Developer, Architect oder Manager, siehe Bild 2.

Ein einzelnes Individual kann also Mitglied vieler Klassen sein. Dieses Modell lässt sich nun belie- big erweitern. Denken Sie zum Beispiel an die Klasse WorkTime­ Model mit den Unterklassen Full­ TimeWorker und PartTimeWorker, die völlig unabhängig von Rolle und Vertragsart sein können.

Als weiterer Vorteil neben der einfacheren  Modellierung  kommt

noch hinzu, dass mit der Abfrage-

Open

Saubere Trennung der Aspekte durch mehrfache Klassifizierung (Bild 2)

sprache SPARQL auch ebenso einfach alle Mitglieder einer bestimmten Klasse abgefragt werden können. Dies macht Abfragen sehr übersichtlich und ebenso leicht lesbar.

Disjoint Classes

Nun kommt es in der Praxis häufig vor, dass eine einzige Per- son mehrere Rollen gleichzeitig innehat. Im Gegensatz dazu kann sie jedoch normalerweise nicht gleichzeitig Employee und Freelancer sein. Deswegen werden diese zwei Klassen auch als „disjoint“ (auf Deutsch disjunkt, das heißt schnitt- mengenfrei) bezeichnet.

Dies sagt aus, dass ein Individual nicht gleichzeitig Mit- glied dieser beiden Klassen sein kann. Den Versuch, dieses so festzulegen, würde der Reasoner als Regelverletzung er- kennen und als Inkonsistenz in der Datenbank ausweisen.

Schemata

Ein Entwickler aus der OOP-Welt wäre zunächst versucht, Klassen in einer Ontologie als Schema anzusehen. Und tat- sächlich kann eine Graph-Datenbank auch in diesem Sinne genutzt werden. Für jede Klasse werden hierzu Daten- und Objekteigenschaften spezifiziert, und alle Individuals dieser Klasse können dann Werte oder IRI-Referenzen für diese Ei- genschaften erhalten.

Die Betonung liegt hier auf „können“, denn für Ontologien gilt die Open-World-Vermutung (Open World Assumption, OWA). Diese besagt, dass alles, was nicht explizit angegeben ist, schlicht unbekannt, aber damit nicht zwangsläufig falsch ist. Das heißt: Der Reasoner wird das Fehlen zum Beispiel ei- nes Wertes für ein Individual in einer Ontologie nicht als Re- gelverletzung ausweisen, denn es bedeutet im Sinne  der OWA nicht, dass der fehlende Wert nicht vielleicht in einer anderen referenzierten Ontologie definiert wird.

Theoretisch können in einer Graph-Datenbank also alle In- dividuals beliebige Eigenschaften verwenden. Auch müssen Individuals nicht zwangsläufig über eine oder mehrere Klas- sifizierungen verfügen. Mit anderen Worten: Eine Graph-Da- tenbank ist zunächst einmal schemalos. Dennoch ist die Zu- ordnung eines Individuals zu einer Klasse natürlich sinnvoll, etwa um in einer ERP-Applikation unterschiedliche Arten von Individuals wie Kunden, Produkte oder Rechnungen un- terscheiden zu können.

Explizite und implizite Klassifizierung

Eine explizite Zuordnung eines Individuals zu einer oder mehreren Klassen erfolgt über Typ-Statements. Hier legen entsprechende Aussagen pro Individual dessen Mitglied- schaften fest:

dnp:Max rdf:type dnp:Person dnp:Max rdf:type dnp:Freelancer dnp:Max rdf:type dnp:Developer

Für Graph-Datenbanken mit vielen Instanzen ohne umfang- reiche Semantik und dem Bedarf, diese auch ohne Reasoner mit einfachen CRUD-Operationen (Create, Read, Update und Delete) zu verarbeiten, ist das bereits ein ausreichender und praktikabler Ansatz.

Ein großer Vorteil dieser Art von Modellierung ist, dass bezogen auf das obige Beispiel – nun sehr einfach alle Per- sonen, alternativ aber auch alle Freiberufler oder alle Ent- wickler mit einem einzelnen Kommando abgefragt werden können.

Als weiterer Vorteil kommt noch dazu, dass Sie auch alle Individuals der Klasse Personnel abfragen können. Hierzu benötigen Sie jedoch den Reasoner mit RDFS-Unterstützung. RDFS kann die Eigenschaft subClassOf spezifizieren und er- laubt es somit, Klassenhierarchien oder auch Taxonomien zu bilden:

dnp:Employee rdfs:subClassOf dnp:Personnel dnp:Freelancer rdfs:subClassOf dnp:Personnel

Eine wichtige Erkenntnis hieraus ist, dass nun nicht pro Person explizit definiert werden muss, dass sie Mitglied der Klasse Per­ sonnel ist, sondern dass dies implizit und nur einmalig über die zentrale subClassOf-Definition innerhalb der Taxonomie er- folgt.

Diese Aufgabe übernimmt der Reasoner. Er verwendet hierzu zwei unabhängige Informationen, nämlich „Max ist ein Mitglied von Employee“ und „Employee ist eine Unter- klasse von Personnel“, und schließt daraus logisch: Max ist ein Mitglied von Personnel. Diese Schlussfolgerung wird als Inferenz bezeichnet und stellt eine der Stärken semantischer Datenbanken dar.

Um das Wissen effizient abfragen zu können, erzeugt die Datenbank intern temporäre Tripel und verwaltet diese auch. Das ist auch der Grund, warum semantische Graph-Daten- banken bei intensiv genutzter Inferenz auch mehr Speicher benötigen als reine Triple Stores.

Exporte lassen sich jedoch mit oder ohne die inferierten Tri- pel ausführen, zum Beispiel um OWL2-Ontologien mit Rea- soning-Support in einfache RDF-Graphen zu überführen, oh- ne die automatisch generierten Zusatzinformationen zu ver- lieren.

Um die Verwaltung dieser Angaben brauchen Sie sich aber nicht zu kümmern, dies übernimmt die Datenbank mit dem Reasoner automatisch.

Domains und Ranges

Eine weitere Besonderheit semantischer Graph-Datenban- ken ist die implizite Klassifizierung von Individuals mithilfe von Eigenschaften. Wie alle Informationen in einem Graphen werden auch Eigenschaften über RDF-Tripel abgebildet, et- wa in der folgenden Form:

dnp:EbnerVerlag rdf:type dnp:Company dnp:SemanticDatabases rdf:type dnp:Document dnp:EbnerVerlag dnp:publishedArticle dnp:SemanticDatabases

Das Individual EbnerVerlag ist Mitglied der Klasse Company und das Individual SemanticDatabases gehört zur Klasse Do­ cument. Angenommen, es gäbe zudem die Klassen Publisher und Article. Über die Eigenschaft publishedArticle kann eine Klassifizierung des Subjekts, hier EbnerVerlag, wie auch des Objekts, hier SemanticDatabases, erfolgen.

In RDF Schema wurden hierzu die sogenannten Domain- und Range-Axiome eingeführt. Axiome beschreiben Fakten, der Reasoner berücksichtigt diese also auch unabhängig von der Open-World-Annahme.

Insbesondere das Range-Axiom wird häufig mit einer Wert- einschränkung verwechselt, doch hier geht es nicht um Ein- schränkungen oder Validierungen, sondern um die Klassifi- zierung von Individuals.

Während das Domain-Axiom die Klassifizierung des Sub- jekts steuert, bestimmt das Range-Axiom die Klassifizierung des Objekts. Hierzu ein Beispiel:

dnp:publishedArticle rdfs:domain dnp:Publisher dnp:publishedArticle rdfs:range dnp:Article

Das erste Tripel sagt aus, dass jedes Subjekt, das die Eigen- schaft publishedArticle verwendet, ein Publisher ist (Axiom). Das zweite Tripel drückt aus, dass jedes Objekt, das durch die- se Eigenschaft referenziert wird, ein Article ist. Durch das Statement ist EbnerVerlag somit implizit Mitglied der Klasse Publisher und SemanticDatabases ein Mitglied der Klasse Ar­ ticle:

dnp:EbnerVerlag dnp:publishedArticle dnp:SemanticDatabases

Im Umkehrschluss liefert eine Abfrage nach Publisher auch EbnerVerlag und eine Abfrage nach Article auch Semantic­ Databases, obwohl dies wiederum für keines der beiden In- dividuals explizit so definiert wurde.

Was auf der einen Seite ein äußerst nützliches und willkom- menes Merkmal ist – schließlich spart dies viele redundante Deklarationen und damit letztlich eine Menge Wartungsauf- wand –, birgt auf der anderen Seite eine gewisse Gefahr. Wird beispielsweise die Aussage dnp:EbnerVerlag dnp:published­ Article dnp:Max getroffen, so inferiert der Reasoner auto- matisch, dass Max ein Article ist. Hier sollte man also eine gewisse Sorgfalt walten lassen.

Da der Reasoner solche semantischen Fehler nicht automa- tisch ausweist, sind sie in umfangreichen Ontologien später nur schwer zu identifizieren und zu beheben. Die auf RDF- Graphen aufsetzende Shapes Constraints Language (SHACL [7]) ist ein geeignetes Hilfsmittel, um unter anderem Typver- letzungen aufzudecken. Dies wird noch das Thema in einem weiteren Artikel der dotnetpro sein.

Eigenschaften wiederverwenden

In traditionellen SQL-Datenbanken hat jede Tabelle ihr eige- nes Schema und somit auch individuelle Bezeichner pro Spal- te. Dabei erschließt sich jedoch nicht automatisch, ob gleiche Bezeichner auch tatsächlich das Gleiche oder unterschiedli- che Bezeichner tatsächlich etwas anderes meinen.

Die Spalten und ihre Datentypen sind hier unabhängig von- einander und die wenigen Metadaten für eine Spalte bestim- men meist lediglich, ob ein Wert vorhanden oder innerhalb ei- ner Tabelle eindeutig sein muss, ob Default-Werte eingesetzt oder ein automatisches Inkrement ausgeführt werden sollen. Der Nachteil ist hier, dass das eigentliche Wissen über die Daten nicht in der Datenbank selbst, sondern im Code der Ap- plikation steckt, die diese Daten nutzt. Und dort ist das Wissen nur schwer wieder extrahierbar und ebenso schwer für Appli- kationen in anderen Programmiersprachen wiederverwendbar. In semantischen Datenbanken, in RDF-Graphen und OWL- Ontologien werden zunächst die Eigenschaften unabhängig von Klassen und Instanzen angelegt – sind es doch die Eigen- schaften mit den Metadaten, die den Inhalten einer Daten- bank erst ihre eigentliche Bedeutung verleihen. Klassen nut- zen anschließend diese Eigenschaften gemeinsam, was si- cherstellt, dass gleichnamige Felder hier auch tatsächlich im-

mer das Gleiche meinen.

Das vermeidet nicht nur Inkompatibilitäten und Inkonsis- tenzen, sondern vereinfacht auch signifikant die Lesbarkeit und das gemeinsame Verständnis von Daten zwischen ver- schiedenen Nutzern. Das Wissen über die Daten (die Meta- daten) steckt hier in der Datenbank selbst und lässt sich so- mit unabhängig von Code und Programmiersprache teilen und wiederverwenden.

Dateneigenschaften

Während es sich bei den Objekteigenschaften um Beschrei- bungen von Beziehungen zwischen Individuals handelt, be- schreiben Dateneigenschaften bestimmte Charakteristiken eines bestimmten Individuals. Sie sind vergleichbar mit ▶

den Datenfeldern eines Objekts in der OOP oder auch mit Wertespalten aus SQL-Datenbanken.

In einem RDF-Graphen werden Dateneigenschaften – wie alle anderen Aussagen auch – durch Tripel dargestellt. Bei- spiel:

dnp:EbnerVerlag dnp:companyName

"Ebner Media Group GmbH & Co. KG"^^xsd:String

Datentypen

Für die Dateneigenschaften steht in OWL2 eine Vielzahl von Datentypen zur Verfügung [8]. Zu den numerischen gehören die folgenden:

●  Tabelle 1: Charakteristika von Eigenschaften

owl:real owl:rational xsd:decimal xsd:integer

xsd:nonNegativeInteger xsd:nonPositiveInteger xsd:positiveInteger xsd:negativeInteger xsd:long

xsd:int xsd:short xsd:byte xsd:unsignedLong xsd:unsignedInt

xsd:unsignedShort xsd:unsignedByte xsd:double xsd:float

Die String-Typen umfassen folgende Varianten:

xsd:string xsd:normalizedString xsd:token xsd:language xsd:Name

xsd:NCName xsd:NMTOKEN

Boolesche, binäre und Zeittypen:

xsd:Boolean

xsd:hexBinary xsd:base64Binary

xsd:dateTime xsd:dateTimeStamp

Die Zeichenfolge Hello World würde im hexBinary-Format 48656c6c6f20576f726c64 lauten und in base64 SGVsbG8gV 29ybGQ=.

Die beiden Datums-/Zeit-Typen werden im ISO8601-For- mat notiert [9]. Der Unterschied zwischen den beiden ist, dass bei dateTime die Angabe der Zeitzone optional, bei dateTime­ Stamp jedoch erforderlich ist. Ein gültiger dateTime-Wert ist beispielsweise 2020­02­15T12:45:00Z, als dateTimeStamp- Wert lautet er 2020­02­15T12:45:00­05:00.

In OWL ist es möglich, auch eigene Datentypen anzulegen. Auf dieses Thema und den Nutzen für Anwendungen wird ein Folgeartikel noch genauer eingehen.

Property-Charakteristika

Ein großer Vorteil semantischer Datenbanken ist die Mög- lichkeit, Eigenschaften mit umfangreichen Metaangaben zu bereichern und ihnen damit eine große Ausdrucksstärke zu verleihen, die auch standardisiert von Maschinen verstanden

●  Tabelle 2: Einschränkungen von Eigenschaften in OWL

werden kann. Tabelle 1 zeigt die unterstützten Charakteris- tika und ihre Bedeutung.

Im vollständigen OWL-Profil [10] sind Dateneigenschaften eine Unterklasse von Objekteigenschaften. Daher kann hier auch für Dateneigenschaften eine invers-funktionale Eigen- schaft definiert werden. Im Profil OWL-DL sind Objekteigen- schaften und Datentypeigenschaften getrennt, sodass eine invers-funktionale Eigenschaft für Datentypeigenschaften hier nicht definiert werden kann. Eine gute Übersicht vieler OWL2-Axiome und -Restriktionen stellt die Website des W3C zur Verfügung [11].

Einschränkungen von Eigenschaften

Zusätzlich zu den Charakteristika von Eigenschaften können in OWL2 sogenannte Property Restrictions definiert werden. Für Dateneigenschaften treffen diese Aussagen über Anzahl und Datentyp, für Objekteigenschaften über Anzahl und Klasse der referenzierten Individuals. Tabelle 2 zeigt die un- terstützten Einschränkungen.

Aufgrund der Open-World-Annahmen wirken Einschrän- kungen in OWL anders als in SQL- oder NoSQL-Datenban- ken. Zwar kann der Reasoner zum Beispiel das Überschrei- ten einer Begrenzung der Kardinalität für Eigenschaften er- kennen, denn schließlich gibt es in diesem Fall ja tatsächlich zu viele Eigenschaften.

Das Unterschreiten einer Grenze, die eine Mindestkardina- lität festlegt, weist er aufgrund der OWA jedoch nicht als Feh- ler aus, denn die fehlenden Eigenschaften könnten ja in an- deren Ontologien definiert sein.

Für Validierungszwecke von Individuals gegen Schemata eignet sich SHACL besser. Eine der nächsten Ausgaben der dotnetpro wird hierüber detailliert berichten.

Fazit

Graph-Datenbanken tragen mithilfe von Semantik und um- fangreichen Metadaten dazu bei, Wissen statt in Code in Da- tenbanken anzulegen und zu verwalten. Wissen wird dadurch leicht verständlich, maschinenlesbar und damit wie- derverwendbar. Reasoner erschließen durch Inferenz neues Wissen automatisch aus bestehendem, Datenbanken lernen maschinell und Entwickler deklarieren weniger redundant und explizit, sondern nur noch einmalig und zentral und im- plizieren dann. Das reduziert Wartungskosten und Fehler- anfälligkeit.

RDF, RDFS und OWL bieten leistungsfähige Mechanismen für Metadaten, die den Inhalten einer Datenbank eine Be- deutung geben. Frei nach dem Motto „Gute Auswertungen brauchen gute Daten und gute Daten brauchen gute Meta- Daten“ tragen diese Technologien zur Verbesserung der Qualität von Daten bei und zu deren besserem Verständnis. W3C-Konformität sorgt für bessere Interoperabilität, Herstel- lerunabhängigkeit und damit auch für eine höhere Investi- tionssicherheit.

Die nächste Folge dieser Artikelreihe wird darlegen, wie das Modellierungs-Tool Protégé hilft, eigene semantische Datenmodelle zu erstellen, und wie Sie mit der Sprache SPARQL  und  Ontotext  GraphDB  Free  eigene  Knowledge-

Graphen verwalten.