Harmonisierung und Wissensmanagement

Mit semantischen Graph-Datenbanken heterogene Datenquellen harmonisieren.

In großen Unternehmen, besonders wenn diese durch Zukäufe gewachsen sind, existiert oft ein Nebeneinander der unterschiedlichsten Tool-Landschaften. Es gibt diverse Geschäftsbereiche und Kompetenzen, individuelle Prozesse und historisch gewachsene Umgebungen, die in der Praxis nicht kurzfristig oder nicht wirtschaftlich ersetzt, migriert oder standardisiert werden können. Dabei geht es um Technologien, aber auch um die Menschen, die diese nutzen.

Ist-Stand

Vom Demand- und Requirements-Management über das Product- und Application-Lifecycle-Management, Entwicklung und Versionskontrolle, Test-, Deployment- und Continuous-Integration-Tools bis hin zu Operations- und Monitoring-Tools: In der Praxis sehen sich Entwickler konfrontiert mit komplexen heterogenen Umgebungen, einer Vielzahl verteilter Datenquellen und -mengen mit unterschiedlichsten Schnittstellen, Datenformaten, Qualitätsgraden oder Verfügbarkeiten.

Kommen noch die Marketingabteilung mit ihrem CRM-System oder der Support, die Personal-, Rechts- oder Finanzabteilung mit ins Boot, so potenzieren sich schnell die Herausforderungen, wenn es darum geht, Daten bereichsübergreifend zusammenzuführen, um daraus eine Grundlage für eine Business Intelligence (BI), zum Beispiel für Reports und Leistungskennzahlen (KPIs), zu schaffen.

Mit zum Teil manuellen, häufig repetitiven Aufbereitungen, Transformationen und Übertragungen sind es nicht nur Daten, sondern auch bestehende etablierte Prozesse, die auf den Prüfstand kommen. Für das Management mögen dabei Transparenz, Wiederverwendbarkeit, Automation und Kostensenkung strategische Ziele sein. Eröffnen doch Maßnahmen wie die Formalisierung und Persistenz von Wissen oder die Analyse von Practices und Prozessen mittels Data Analytics, Semantik, künstlicher Intelligenz (KI), Process Mining (PM) oder Robotic Process Automation (RPA) hier gänzlich neue, zum Teil noch ungeahnte Möglichkeiten.

Was auf der einen Seite vielversprechende Perspektiven bedeutet, wirft auf der anderen Seite für deren Mitarbeiter Fragen über ihre zukünftige Rolle auf. Neben einem Einblick in Architektur und Technologie soll dieser Artikel klären, wie sich diese Evolution weniger zu einem Risiko als vielmehr zu einer Chance für alle Beteiligten entwickelt.

Im Gegensatz zu den Ansätzen von Data Warehouse und Data Lake steht bei einer semantischen Single Source of Truth (SSOT) das Wort Semantik an erster Stelle – und damit die Bedeutung der Informationen, die sie beinhaltet. Dies macht sie zu einer zentralen, idealerweise unternehmensweiten Quelle für Wissen. Metadaten sorgen für ein gemeinsames Verständnis hinterlegter Informationen, eine zentrale Terminologie für eine gemeinsame Sprache. Das Ziel: Zusammenarbeit effizienter zu gestalten, die zwischen Menschen ebenso wie die zwischen den Maschinen.

Wissen zu persistieren bedeutet, es teilbar und verfügbar zu machen. Es zu formalisieren macht es verständlich und damit wiederverwendbar. Informationen mit Semantik zu bereichern ermöglicht es, aus bestehendem Wissen automatisch neues zu schlussfolgern und damit eine selbstlernende Wissensdatenbank zu schaffen. Dadurch, dass in einer Single Source of Truth nicht nur die Daten selbst verwaltet werden, sondern insbesondere auch deren Bedeutung, ist Semantik eine wichtige Grundlage für eine intelligente Integration von Informationen.

Dem Management bietet die smarte Harmonisierung von Daten höhere Transparenz und Qualität sowie bessere Analysen für ihre Geschäftsentscheidungen – über die Grenzen von Tools und Abteilungen hinaus. Für uns bietet sie ein gemeinsames Verständnis und die Wiederverwendbarkeit von Wissen und damit wieder mehr Raum und Zeit für Kreativität und Innovationen – über persönliche Skills, unterschiedliche Arbeitsmodelle und Kulturen hinaus.

Herausforderungen

Viele Aufgaben bei der Zusammenführung von Informationen sind offensichtlich und können meist durch sogenannte Extrakt-Transform-Load-Tools (ETL) gelöst werden. So etwa der Download von Daten aus den Primärquellen, deren Transformation in ein Standardformat, optional eine Validierung und letztlich deren Bereitstellung über APIs.

Kommen aber Inkompatibilitäten, unterschiedliche Terminologien und damit Mehrdeutigkeiten – also semantische Differenzen zwischen den Tools – ins Spiel, so stößt eine einfache Eins-zu-eins-Transformation schnell an Grenzen. Erschwerend kommen mögliche Inkonsistenzen – also Unstimmigkeiten zwischen mehreren Umgebungen – hinzu, etwa bei Fehlern in der Synchronisierung zwischen den Systemen oder bei unkontrolliert durchgeführten Updates einzelner Tools.

Gerade wenn es um Business Analytics, um Reports und KPIs geht, sind Aspekte wie Richtigkeit, Vollständigkeit und Konsistenz der Informationen essenziell. Die in diesem Artikel behandelte SSOT basiert auf der W3C-kompatiblen semantischen Graph-Datenbank GraphDB aus dem Hause Ontotext. Version 8.x kann für Entwicklungszwecke kostenlos geladen [1] werden. Sie ist auf zwei gleichzeitige Verbindungen sowie in Bezug auf Clustering und externe Konnektoren, nicht aber in Bezug auf die Datenmenge limitiert.

Die Unterstützung nicht nur bei der Zentralisierung von Daten, sondern auch bei der Verbesserung der Datenqualität in den Primärsystemen ist ein weiterer entscheidender Faktor für den Erfolg einer Single Source of Truth (SSOT).

● Glossar – die wichtigsten Begriffe für das Verständnis von Graph-Datenbanken

A-Box: Die Assertional Box ist Bestandteil einer Ontologie und enthält das Wissen über die konkreten Instanzen (Individuals, Objekte) einer Domäne. Sie enthält Fakten (siehe Axiome) über Individuals und deren Properties sowie ihrer Relationen untereinander. Die A-Box repräsentiert den Zustand einer in der T-Box modellierten Welt.

Annotation: Annotations sind Aussagen, die an jede Entität, also an jede Klasse, Individual oder Property angehängt werden können, ohne dabei deren Semantik zu beeinflussen. Annotations können unter anderem für Kommentare, zur Angabe von Autoren oder Versionsnummern, aber auch zur Internationalisierung von Ontologien verwendet werden, also für die Übersetzung von Wissen in verschiedene Landessprachen. Annotations werden wie Daten behandelt, vom Reasoner jedoch nicht berücksichtigt.

Assertions: Assertions sind Behauptungen in einer Ontologie, welche nicht zwangsläufig wahr, vollständig oder konsistent sein müssen. Beispielsweise könnte das Alter eines Menschen negativ oder mit zwei widersprüchlichen Aussagen angegeben werden. Die Ontologie weist invalide Behauptungen nicht per se zurück. Der Reasoner einer Graph-Datenbank weist Regelverletzungen und semantische Inkonsistenzen in Form von Explanations jedoch aus und unterstützt eine Korrektur zu einem vom Anwender wählbaren Zeitpunkt, wobei die gesamte Ontologie trotz innerer Inkonsistenz nach außen verfügbar bleibt.

Axiome: Axiome sind Aussagen in einer Ontologie, die bestimmen, was in einer Domäne wahr ist. Beispiel: Mensch ist eine Unterklasse von Lebewesen. Ist Max ein Mensch, so ist er auch ein Lebewesen. Axiome bestimmen unter anderem Klassen, Daten- und Objekt-Properties, Datentypen oder auch Annotations. Axiome über Individuals werden häufig auch als Fakten bezeichnet.

Data Warehouse: Ein Data Warehouse ist ein zentrales Repository für strukturierte Daten, für einen Zweck aufbereitet, gefiltert, validiert und transformiert. Bereits beim Schreiben in das Warehouse wird ein Schema genutzt (Schema on Write). Inhalte sind leicht zu verstehen, Änderungen jedoch eher aufwendig, da Konsumenten wie Business-Intelligence-Tools diese direkt nutzen, etwa für Dashboards. Zielgruppe sind eher Business-Professionals und der Zweck schnelle Analyseergebnisse.

Data Lake: Ein Data Lake ist die Zusammenführung von Rohdaten an einer zentralen Stelle, deren Zweck und Nutzung noch nicht bestimmt ist, dynamisch, ungefiltert, umfangreich und wenig organisiert. Inhalte sind ideal für Machine Learning, schwerer zu verstehen, aber leichter zu ändern. Navigation, Datenqualität und Data Governance sind schwieriger. Ein Schema wird erst beim Lesen aus dem Lake angewendet (Schema on Read). Zielgruppe sind eher Data Scientists.

Viele Aufgaben sind gar nicht rein technischer Natur. So dürfen beispielsweise feingranulare Zugriffsberechtigungen auf die Primärquellen nicht einfach durch eine redundante zentrale Datenhaltung à la Data Lake ausgehebelt werden. Neben Rechten und Rollen müssen gegebenenfalls Personendaten anonymisiert werden. Möglicherweise schließen Betriebsvereinbarungen oder die DSGVO die Nutzung bestimmter Daten gänzlich aus. Andere Informationen mögen Geheimhaltungsrestriktionen wie zum Beispiel einer Exportkontrolle oder Kundenvereinbarungen unterliegen.

Sind Sicherheits- und juristische Bedenken ausgeräumt, kommen individuelle Datenhoheiten hinzu. Sind die aufgelöst und ist damit eine allseitige Bereitschaft zur Harmonisierung geschaffen, dann kann es weitergehen im Bestreben, ein gemeinsames Verständnis der zur Verfügung stehenden Informationen zu schaffen.

Harmonisierung versus Standardisierung

Komplexe heterogene Umgebungen bedeuten vielfältige Herausforderungen. Anwendungen wie Menschen meinen häufig dasselbe – sprechen aber unterschiedliche Sprachen, verwenden nicht nur unterschiedliche Daten, sondern auch unterschiedliche Terminologien. Und das führt zu Reibung an den Schnittstellen, technisch wie menschlich.

Versuchen Sie einmal, einen gemeinsamen Report aus Daten zweier Anwendungen oder Abteilungen zu generieren. Schnell wird hier ein Ruf nach Standardisierung laut mit dem Argument, dass diese Kosten senke. Dieses etwas weitergedacht, käme aber eine abteilungs- oder gar unternehmensweite Standardisierung, zum Beispiel durch die technische Vereinheitlichung praktisch unterschiedlicher Workflows, nicht nur einer unliebsamen Zwangsjacke für die Mitarbeiter gleich, sondern wäre wohl auch ebenso impraktikabel wie unwirtschaftlich.

Bei einer Single Source of Truth geht es daher nicht um die Standardisierung von Informationen und Prozessen, sondern um deren Harmonisierung, mit dem Ziel, Kompatibilität statt Konformität zu schaffen und damit letztlich strategische Unternehmensziele zu unterstützen.

Kompatibilität versus Konformität

Als Beispiel sei der Einsatz unterschiedlicher Task-Tracking-Systeme herangezogen, der Einfachheit halber GitLab und Jira. Wollen Sie für Ihre Projektsteuerung in einem Report-Tool übergreifend ausweisen, wie viele Tasks mit welcher Priorität offen sind, so setzt dies voraus, dass beide Systeme die gleichen Konfigurationen und Werte für die Angabe der Priorität haben – das ist in der Praxis selten der Fall.

So mag das eine System die Prioritäten 1 bis 5 als numerische Werte führen, das andere Kritisch, Hoch, Mittel und Niedrig als Textwerte. Ziel sollte nicht sein, alle Systeme in ein standardisiertes Korsett zu zwängen, sondern die Informationen so zu harmonisieren, dass beide Systeme weiter existieren können, aber für eine systemübergreifende Berichterstattung dennoch kompatibel sind.

● Glossar (Fortsetzung)

Domäne: Im semantischen Web wird eine Domäne als ein inhaltlich oder logisch verflochtener Wissensbereich, ein Interessengebiet oder eine Ansammlung von Ressourcen, Personen oder Maschinen bezeichnet. Sie wird durch einen Namen identifiziert und darf nicht mit einer Internet-Domain verwechselt werden.

Graph-Datenbank: Ein Graph besteht im Wesentlichen aus Knoten (Nodes) und den Verbindungen zwischen ihnen, den sogenannten Kanten (Edges). Eine Graph-Datenbank ist ideal, um vernetzte Informationen zu repräsentieren und damit Wissen zu verwalten. RDF ist das bekannteste Konzept für eine semantische Graph-Datenbank. Hier werden Aussagen in Form sogenannter Tripel aus Subjekt, Prädikat und Objekt formuliert (siehe RDF). Graph-Datenbanken können üblicherweise mehrere Ontologien in verschiedenen Kontexten (Graphen) innerhalb eines einzelnen Datenbankschemas enthalten. Eine solche Kombination von Ontologien, insbesondere zusammen mit vielen Instanz-Informationen, wird häufig auch als Knowledge-Graph bezeichnet.

Individuals: Im Kontext des semantischen Webs und von Ontologien werden Objekte meist als Individuals bezeichnet, technisch zu verstehen als Instanzen von Klassen, die wiederum gelegentlich auch als Konzepte bezeichnet werden. Individuals können Daten- und Objekt-Properties enthalten sowie einer oder mehreren Klassen zugeordnet sein. Während in der objektorientierten Welt üblicherweise eine Instanz einer bestimmten Klasse erzeugt wird – etwa var Max = new Person() –, kann im semantischen Web ein Individual auch ohne Klasse angelegt, die Klassenzuordnung(en) über Properties aber erschlossen werden. Beispiel: Hat ein Individual die Eigenschaft hasWheels und hasWheels die Domain Vehicle, so ist das Individual automatisch Mitglied der Klasse Vehicle, ohne dass dies hierfür explizit definiert wurde.

Inferenz: Inferenz bedeutet das logische Schlussfolgern neuer Aussagen auf Basis bereits bestehender. Beispiel: Wenn A äquivalent zu B und B äquivalent zu C ist, lässt sich folgern, dass A auch äquivalent zu C ist. Während die ersten zwei Aussagen explizit formuliert sind, ist die dritte erschlossen – also implizites, automatisch generiertes Wissen. Verantwortlich für die Inferenz ist der Reasoner anhand von Regelsätzen, sogenannten Profilen. Das W3C definiert den Umfang der Profile für OWL, jedoch nicht, wie diese zu implementieren sind. Die großen Hersteller von Graph-Datenbanken erlauben neben den vorgegebenen Profilen meist die Anpassung bestehender oder die Definition eigener Rule-Sets.

Ontologie: Eine Ontologie umfasst die formale Definition von Konzepten (Klassen), Eigenschaften und Beziehungen zwischen den Entitäten einer Domäne. Ontologien sind besonders geeignet, um Wissen mithilfe eines gemeinsamen Vokabulars zu teilen. Sie bestehen aus einer T-Box, der Taxonomie (Klassenhierarchie), und einer A-Box, den Individuen (Instanzen). Reasoner sind für die Inferenz (logische Schlussfolgerungen) in Ontologien verantwortlich. Annotations können für Kommentare oder die Internationalisierung von Ontologien verwendet werden. Ontologien können sich untereinander referenzieren und so zu umfangreichen, selbstlernenden Wissensdatenbanken heranwachsen.

Nicht nur, dass die Werte unterschiedlich sind, auch lässt deren Anzahl kein eindeutiges Eins-zu-eins-Mapping zu. Konformität herzustellen würde bedeuten, einen Standard zu definieren und die Primärsysteme dahingehend anzupassen, dass sie alle über identische Werte verfügen. Sofern dies technisch überhaupt möglich ist, bedeutet dies mindestens einen Eingriff in die Arbeitsweisen der betroffenen Anwender. Ganz zu schweigen davon, ob und wie eine Migration – insbesondere historischer Daten (Legacy) – erfolgen kann.

Kompatibilität hingegen bedeutet, die Primärsysteme so zu belassen, wie sie sind, und mithilfe eines semantischen Referenzmodells den Werten der jeweiligen Umgebungen eine Bedeutung zu geben, die für Mensch und Maschine gleichermaßen verständlich und damit semantisch vergleichbar sind.

Mit Kompatibilität ist nicht zwangsläufig gemeint, auf der reinen Feldebene eine verlustfreie bidirektionale Transformation zu erreichen. So können, isoliert betrachtet, ja fünf Werte nicht auf vier Werte und in der anderen Richtung dann wieder zurück auf fünf Werte gemappt werden. Dieses Problem können auch Graphen und Semantik nicht per se eliminieren, aber sie können es deutlich reduzieren.

Graphen zeichnen sich durch die Verlinkung von Informationen aus. So mag ein Task-Tracking-System weitere Felder wie den Typ einer Aufgabe, zum Beispiel Feature oder Bug, haben, ein Bug wiederum einen Schweregrad (Severity) und eine Auftrittshäufigkeit (Frequency). Semantisch sollte das Feld Priorität also nicht vorgegeben, sondern berechnet beziehungsweise erschlossen werden.

Hat ein Referenzmodell zum Beispiel vier Werte für Priorität, so kann ein Mapping unter Einbeziehung weiterer Felder auch bei unterschiedlichen Werten in den Primärquellen, eine semantisch eindeutige Aussage treffen. In

Open

Bild 1 sehen Sie ein Beispiel dazu.

Eine Priorität 2 im System A wird abhängig von der Auftrittshäufigkeit auf Critical oder High im Referenzmodell gemappt, eine Priorität B eines Fehlers im System B auf High oder Medium im Referenzmodell, abhängig vom Schweregrad. Da das Referenzmodell sowohl die Terme Auftrittshäufigkeit als auch Schweregrad kennt, sind ein semantisches Mapping und so auch die Harmonisierung unterschiedlicher Systeme möglich.

● Glossar (Fortsetzung)

Open World Assumption: Die Closed World Assumption (CWA) besagt, dass alles, was nicht als wahr bekannt ist, falsch sein muss. Besagt ein Zugfahrplan, dass ein Zug um 10 und um 14 Uhr fährt, so impliziert dies in der CWA, dass er nicht um 12 Uhr fährt. Im Gegensatz dazu besagt die Open World Assumption (OWA), dass alles, was nicht als wahr bekannt ist, schlicht unbekannt ist. Weist ein Telefonregister die Nummer zweier Teilnehmer aus, so heißt dies nicht, dass keine weiteren Teilnehmer existieren. Ontologien im semantischen Web arbeiten nach der Open World Assumption. Vorteilhaft ist dies, da eingestellte unrichtige, widersprüchliche oder regelverletzende Infos nicht die Funktionalität der Ontologie als Ganzes einschränken, diese aber durch den Reasoner identifiziert, ausgewiesen und erklärt werden können.

OWL: OWL steht für Web Ontology Language, eine für das semantische Web designte Sprache, um Wissen über Objekte und Klassen (als Gruppen von Objekten) und deren Beziehungen untereinander zu repräsentieren. Ontologien basieren auf RDF und OWL und können mit SPARQL als Abfragesprache gelesen und verändert werden. Reasoner unterstützen RDF und OWL.

Profile: OWL2 (http://www.w3.org/TR/owl2-profiles ) definiert Sets von Inferenz-Regeln, sogenannte Profile, mit unterschiedlicher Ausdrucksstärke und Effizienz für bestimmte Einsatzzwecke. Prominente Beispiele sind EL für Ontologien mit vielen Klassen und Properties, QL für Ontologien mit vielen Instanzen und RL für Applikationen, die eine ausgewogene Balance zwischen skalierbarem Reasoning (Inferenz) und Ausdrucksstärke erfordern.

Properties: Properties beschreiben die Charakteristika von Individuals, den Instanzen in einer Graph-Datenbank. Data Properties enthalten konkrete Werte verschiedener Datentypen (www.3.org/TR/owl2-syntax/#Datatype_Maps), Object Properties beschreiben die Relationen zwischen Individuals. Die Ausdrucksstärke von Ontologien wird unter anderem durch sogenannte Restrictions bestimmt. Es gibt transitive – nutzt ein Kunde A die App B und die App B den Service C, dann erschließt sich hieraus: Kunde A nutzt auch den Service C –, symmetrische – interagiert zum Beispiel ein Service A mit einem Service B, so interagiert der Service B ebenso mit Service A – und inverse Properties – eine inverse Property zu App A uses Service B, wäre beispielsweise usedBy. Eine Abfrage nach Service B usedBy App A würde der Reasoner also mit true beantworten.

Mit dem Wissen über die Erschließung der Werte kann nun nicht nur ein Tool-übergreifender Report realisiert, sondern dieser mithilfe der Verlinkungen im semantischen Modell dem Betrachter auch erklärt werden. Was in diesem Beispiel noch recht einfach erscheint, kann mittels Semantik auf weit komplexere Argumentationsketten erweitert werden. Ist ein Fehler bei einem Kunden aufgetreten, so kann dessen Wichtigkeit die Priorität beeinflussen, die Wichtigkeit des Kunden kann durch den Umsatz mit ihm oder die Dauer der Geschäftsbeziehung bestimmt sein, et cetera. In der Praxis unübersichtliche Bewertungskriterien können mithilfe von Verlinkung und Semantik zusammengeführt und Entscheidungen so leicht objektiviert werden. An dieser Stelle wird bereits deutlich, wie semantische Graphen als Assistenzsysteme unsere tägliche Arbeit erleichtern können.

Nun kommt die Frage auf, ob ein vom Benutzer manuell pflegbares Feld Priorität semantisch überhaupt sinnvoll ist. Denn es erschließt sich ja aus dem Typ eines Eintrags, dem Schweregrad eines Fehlers, dessen Auftrittshäufigkeit und vielleicht auch noch aus der Wichtigkeit des Kunden, und diese wiederum aus dem Umsatz. Geht es doch eigentlich vielmehr um die Ermittlung einer Reihenfolge, ein Ranking, in dem die anstehenden Aufgaben abgearbeitet werden sollen, abhängig von definierten Kriterien.

Durch die Verlinkung von Informationen in einem semantischen Graphen entstehen attraktive Automatisierungs-Potenziale, allerdings eben nur auf der Basis der definierten Kriterien, Ausnahmefälle bleiben unberücksichtigt. Ein Assistenzsystem sollte daher nicht die Übernahme der Kontrolle über alle Entscheidungen bedeuten, sondern es sollte uns unterstützen. Um bei der Priorität zu bleiben, darf eine manuelle Einflussnahme zur Steuerung des Rankings im Rahmen valider Werte also durchaus erhalten bleiben.

Gemeinsame Sprache, Terminologie

Ein strategisches Ziel in großen Unternehmen ist häufig die Verbesserung der internen Zusammenarbeit. Eine Maßnahme dazu ist, die Kommunikation zu verbessern. Um dies zu erreichen, hilft eine einheitliche Terminologie, eine gemeinsame Sprache – technisch eine gemeinsame semantische Definition von Bezeichnern und von deren Synonymen.

Im Bereich des Application-Lifecycle-Managements (ALM) existieren zum Beispiel Terme wie Issues, Items oder Elements, Tasks, Features oder Functions, Bugs, Errors oder Defects, die in ihren jeweiligen Kontexten unterschiedliche Bedeutungen haben können, aber nicht müssen. Hier entstehen Mehrdeutigkeiten, dadurch Missverständnisse und als Folge letztlich hohe Kosten, um diese wieder aufzuklären.

● Glossar (Fortsetzung)

Reasoner: Ein Reasoner ist eine sogenannte Inferenz-Engine. Eine Software, die in der Lage ist, aus Axiomen und Assertions neue logische Schlussfolgerungen zu ziehen, ohne diese explizit zu persistieren, wobei sie diese jedoch in SPARQL-Abfragen implizit bereitstellen kann: A = B (explizit) und B = C (explizit) => A = C (implizit). Daher kann es auch vorkommen, dass Ontologien durch das dynamisch generierte Wissen im Speicher erheblich mehr Platz als auf dem Datenträger beanspruchen. W3C-konforme semantische Graph-Datenbanken bieten unterschiedliche Sets von Inferenz-Regeln, in OWL2 sogenannte Profile. Reasoner sind ebenfalls verantwortlich für die Ausweisung und Erklärung von Inferenzen und Inkonsistenzen in einer Ontologie.

RDF: RDF ist die Abkürzung für Resource Definition Framework (http://www.w3.org/RDF ), ein vom W3C standardisiertes Modellierungskonzept des semantischen Webs, das mithilfe von Tripeln aus Subjekt, Prädikat, Objekt einfache logische Aussagen in gerichteten Graphen formuliert, die leicht von Maschinen gelesen, verstanden und visualisiert werden können. Beispiele: Max hasAge 32 (Data Property) oder Josef hasSpoose Maria (Object Property). Das Format ist RDF/XML.

Semantisches Web: Gemäß dem Erfinder des Internets, Tim Berners-Lee, ist das semantische Web „das Web der Daten, die von Maschinen verarbeitet werden können". Das W3C definiert es so: „Das semantische Web stellt ein Framework bereit, welches es erlaubt, Daten über Applikations-, Unternehmens- und Community-Grenzen hinaus zu teilen und wiederzuverwenden." Das semantische Web wird daher auch als Integrator über verschiedene Inhalte, Informationsanwendungen und -systeme hinweg betrachtet.

SPARQL: Ist der Name des auf HTTP aufsetzenden Protokolls (http://www.w3.org/TR/sparql11-protocol ) und gleichzeitig die Abkürzung für SPARQL Protocol And RDF Query Language (http://www.w3.org/TR/sparql11-overview ), eine vom W3C standardisierte Abfrage- (SPARQL 1.0) und Manipulationssprache (SPARQL 1.1) im Semantic Web für RDF-Graphen. SPARQL ist an SQL angelehnt, unterstützt die Integration mehrerer, auch externer RDF-Graphen und ist für die RDF-Triple-Stores optimiert. Mit SPARQL kann nicht nur persistiertes explizites Wissen, sondern auch das durch Reasoner und Inferenz automatisch generierte implizite Wissen abgefragt werden. Implementierungen existieren für fast alle Programmiersprachen.

Taxonomie: Im Sinne von Ontologien und des semantischen Webs ist eine Taxonomie ein Modell für eine hierarchische Klassifikation von Objekten, oder in einfachen Worten: eine Klassenhierarchie mit Klassen und Unterklassen. Sie ermöglicht einfache Zusammenfassungen (Aggregationen) auf Klassenebene. Beispiel: Unfallstatistik einer Versicherung für Pkws und Lkws als Unterklassen aller Fahrzeuge.

T-Box: Die Terminological Box ist die konzeptionelle Komponente einer Knowledge Base, auch Schema oder Vokabularium genannt. Sie enthält das Wissen über die Klassen einer Domäne sowie deren Hierarchie (Taxonomie) und ihrer Charakteristiken (Properties). Es existieren mächtige Ontologien, die lediglich aus einer T-Box bestehen, die jedoch keine Instanzen enthalten.

Ambiguitäten zu eliminieren oder zumindest zu reduzieren ist eines der Ziele einer SSOT. Ein Glossar ist hier ein nützliches Feature. Es stellt eine zentrale Referenz von Bezeichnern inklusive einer menschlich verständlichen Beschreibung, der eigentlichen Bedeutung, dar. Wichtige Bezeichner zum Verständnis der Terminologie finden Sie im Kasten Glossar.

Semantik

Eine semantischer Graph, auch als Ontologie bezeichnet, besteht im Wesentlichen aus einer Klassenhierarchie, der sogenannten Taxonomie oder auch T-Box, und den Individuals sowie den Instanzen der Klassen, der sogenannten A-Box. Auch Mehrfachvererbung ist unterstützt. Hinzu kommen die Properties, die sich in Data Properties und Object Properties unterteilen, sowie die Annotations.

Während die Data Properties Werte für Felder eines Individuals enthalten, beschreiben die Object Properties die Relationen zwischen verschiedenen Individuals. Beide Properties können mit Meta-Informationen versehen werden, die zur eigentlichen Stärke der Semantik beitragen. Properties können hierarchisch strukturiert werden, ihre Bedeutung somit auch vererben.

Annotations sind Zusatzinformationen, die an alle genannten Entitäten angehängt werden können, aber vom sogenannten Reasoner nicht berücksichtigt werden. Sie können zum Beispiel für Kommentare, für Versionsnummern, den Autor der Information oder für die Internationalisierung einer Ontologie genutzt werden.

Der Reasoner ist eine Engine für logische Schlussfolgerungen, die sogenannte Inferenz, und damit eine Kernkomponente jeder semantischen Graph-Datenbank. Einige nützliche Beispiele hier sind folgende Meta-Informationen für Object Properties:

Transitive Properties sagen aus, dass wenn ein Individual A auf eine anderes Individual B referenziert, und B auf C, dass auch A auf C referenziert. Eine transitive Property "uses" würde so für eine App nicht nur die direkten Abhängigkeiten der eigenen High-Level Services, sondern zusätzlich auch die von diesen genutzten Low-Level Services des Cloud-Providers ausweisen.

Inverse Properties beschreiben Relationen in umgekehrter Richtung. Eine Property "usedBy" für einen Service wäre eine Umkehrung von "uses". Dies unterstützt Top-Down-Queries wie „Welche App benutzt welche Services" ebenso wie Bottom-Up-Queries wie „Welche Services werden von welcher App verwendet" – und dies in einem beliebig komplexen Graphen als Repräsentation der Microservice-Infrastruktur.

Symmetrische Properties wie zum Beispiel "interactsWith" sagen aus, dass wenn der eine Service mit dem anderen interagiert, das Gleiche auch für den anderen Service gilt, ohne dass dies für Letzteren explizit definiert sein muss. Genau das ist Aufgabe und Funktion des Reasoners, der diese logischen Schlussfolgerungen für die gespeicherten Informationen automatisch vornimmt.

So viel für diesmal. In der folgenden dotnetpro-Ausgabe lesen Sie den zweiten Teil dieses Artikels, der ein Referenzmodell sowie das Mapping im Referenzmodell vorstellt. ■

[1] GraphDB, http://graphdb.ontotext.com