Refactoring in der Ontologiegetriebenen Softwareentwicklung

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Gliederung

2 Grundlagen
2.1 Modellgetriebene Softwareentwicklung
2.2 Refactoring

3 Ontologien und semantische Techniken
3.1 Grundlagen semantischer Techniken
3.2 Ontologien
3.2.1 Definition und Begriffe
3.2.2 Die Web Ontology Language (OWL)
3.2.3 Ontologie-Syntaxen
3.2.4 Beschreibungslogiken, Teilsprachen und Profile .
3.2.5 Abfragen mit SPARQL
3.2.6 Beispiele für Ontologien
3.3 Ontologie-Evolution und Versionierung
3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring
3.5 Zukünftige Entwicklungen - Linked Data
3.6 Zusammenfassung

4 Eingesetzte Werkzeuge
4.1 Verbindung von Ontologien und Modellen mit OntoMoPP
4.2 Generisches Modell-Refactoring mit Refactory

5 Stand der Forschung
5.1 Abbildung von Ontologien auf Domänenmodelle
5.1.1 Einsatz von Ontologien in der Modellierung
5.1.2 Abbildungen zwischen Ontologien und Datenbanken
5.2 Ontologie-Evolution
5.2.1 Anforderungen an Ontologie-Evolution
5.2.2 Elementare und komplexe Änderungsoperationen
5.2.3 KAON - Das Karlsruhe Ontology and Semantic Web Framework
5.2.4 Das NeOn-Toolkit
5.2.5 Protégé
5.2.6 Bewertung vorhandener Systeme zur Ontologie-Evolution
5.3 Co-Evolution von Metamodellen und Modellen
5.4 Zusammenfassung

6 Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme
6.1 Gesamtkonzept
6.2 OWL-Ecore-Transformation
6.3 Refactorings für OWL und Ecore
6.3.1 Definition und Katalog von Ontologie-Refactorings
6.3.2 Schema eines Ontologie-Refactorings
6.3.3 Beispiel eines Ontologie-Refactorings
6.4 Co-Refactoring
6.4.1 Definition und Ansätze
6.4.2 Herleitung und Architekturvergleich
6.4.3 Der CoRefactorer
6.5 Zusammenfassung

7 Praktische Umsetzung
7.1 Architektur und eingesetzte Techniken
7.2 Testgetriebene Entwicklung
7.3 OWL-Ecore-Transformator
7.4 Refactoring mit Refactory
7.5 CoRefactorer
7.6 Zusammenfassung

8 Evaluation
8.1 Die Beispiel-Ontologie: FrOnto
8.2 Bewertung der Umsetzung
8.3 Grenzen der Umsetzung
8.4 Grenzen der Konzeption
8.5 Zusammenfassung

9 Zusammenfassung
9.1 Ergebnisse
9.1.1 Das Gesamtkonzept
9.1.2 Beziehung zwischen Ontologien und Domänenmodellen
9.1.3 Konzeption von Refactorings und Co-Refactorings
9.1.4 Implementierung von OntoMore
9.1.5 Evaluation anhand einer Beispiel-Ontologie
9.2 Ausblick

Anhang

A Weitere Ontologie-Refactorings

B Auswirkungen von Ontologie-Refactorings bezüglich der Datenmigration

C Die MiniFrOnto vor und nach dem Refactoring

D Refactoring mit der OWL-API

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Abkürzungsverzeichnis

Literaturverzeichnis

1 Einleitung

1.1 Motivation

Die Welt ändert sich. Auch Softwaresysteme müssen sich ändern, denn sie stellen einen Teil der wirklichen Welt dar, die so genannte Anwendungs- oder Fachdomäne. Als Softwaresystem wollen wir hier ein Computerprogramm bezeichnen, das für den industriellen Einsatz in großen Unternehmen geeignet ist. Ein solches Programm ist universal einsetzbar, wurde getestet, dokumentiert, besteht aus mehreren Modulen und verfügt über ein klar definiertes Interface [Bro95]. Nehmen wir als Beispiel ein Softwaresystem, das für ein Unternehmen Daten über Kunden und verkaufte Produkte speichern und zurückgeben soll. Die Anforderungen des Unternehmens und der Mitarbeiter an dieses Softwaresystem werden sich im Laufe der Zeit ständig ändern. Softwaresysteme müssen demnach beständig weiterentwickelt werden. Andernfalls nimmt der Nutzen des Softwaresystems ab [Leh96]. Es ist also wichtig, während der Entwicklung und des Betriebs eines Softwaresystems Techniken einzusetzen, die Änderungen auf einfache Weise ermöglichen.

Ein Softwaresystem soll Daten speichern und dem Benutzer Informationen zur Verfügung stellen. Daten sind Repräsentationen von Eigenschaften von Objekten der realen Welt [Row07]. In der Unternehmensanwendung sind Daten zum Beispiel Name und Adressen der Kunden sowie Eigenschaften von Produkten. Das Domänenmodell ist eine abstrakte Beschreibung aller für das Softwaresystem relevanter Daten und deren Beziehungen und stellt damit die Struktur eines Softwaresystems dar.

Daten werden oft in Datenbanken gespeichert. Die Speicherung erfolgt dort in tabellarischer Form. Beziehungen zu Daten anderer Tabellen werden durch Schlüsselwerte ausgedrückt. Die Entwicklung des Semantic Web [BLHL01] hat zu einer Reihe neuer Techniken zur Datenspeicherung geführt, weil im Web die Daten nicht zentral gespeichert und verwaltet werden, sondern in unterschiedlicher Struktur über das ganze Web verteilt sind. Die homogene, tabellenartige Struktur der Daten ist somit nicht gegeben. Die Beziehungen zwischen den Daten treten an dieser Stelle stärker in den Vordergrund. Zu diesen neuen Techniken gehören die On- tologien. Ontologien sind Begriffsnetze, die eine netzartige Struktur von Daten beschreiben. Sie ermöglichen gegenüber Datenbanken einige zusätzliche Funktionen, die sie als Datenspeicher interessant machen. Dazu gehören beispielsweise die semantische Suche, Ableitung impliziten Wissens und Konsistenzprüfungen [HKRS08].

Im Rahmen dieser Arbeit wird untersucht, welche Möglichkeiten bestehen, Softwaresystemen mit Ontologien zu modellieren. Die in der Ontologie definierten Konzepte müssen folglich auf ein Domänenmodell abgebildet werden. Somit können die in der Ontologie gespeicherten Daten und Strukturen direkt in das Softwaresystem integriert werden. Dies erfordert jedoch, dass das Domänenmodell in einer Struktur vorliegt, die eine definierte Beziehung zwischen Domänenmodell und Ontologie erlaubt. Dies ist bei der modellgetriebenen Softwareentwicklung (MDSD) der Fall. In der MDSD werden Software-Systeme auf einer höheren Abstraktionsebene mit Modellen beschrieben [SVEH07]. Das Domänenmodell liegt hier explizit in Form von Metamodellen vor, die mit den Ontologien in Beziehung gesetzt werden können.

Die Herausforderung besteht nun darin, Änderungen der Struktur der Daten oder der Daten selbst möglichst einfach auf die Ontologie und das Domänenmodell zu übertragen. Für die Durchführung von Änderungen mit klar definierten Anfangs- und Endzuständen hat sich das Refactoring in der Softwareentwicklung etabliert. Das Prinzip des Refactorings wurde ursprünglich dazu entworfen, das Design von Programmcode durch systematische Umstrukturierungen zu verbessern. Diese Verbesserungen äußern sich beispielsweise in einer besseren Lesbarkeit oder Wartbarkeit des Programmcodes. Martin Fowler hat für objektorientierte Computerprogramme einen allgemein anerkannten Katalog von Refactorings aufgestellt [FBB+99]. Dabei beschreibt ein Refactoring eine Folge von Änderungen, die in ihrer Gesamtheit zu einer wohldefinierten Umstrukturierung führen. Außerdem existiert mit Refactory bereits ein Framework, welches Refactorings auf beliebigen Modellen durchführen kann [RSA10]. Nun soll das Prinzip des Refactorings auch auf Ontologien übertragen werden, um Änderungen systematisch durchzuführen. An dieser Stelle stehen wir vor dem Problem, dass Refactorings auf zwei zusammengehörigen Strukturen - Ontologie und Domänenmodell - synchron ausgeführt werden müssen. Um dieses Problem zu lösen, wird das Prinzip des Co-Refactorings eingeführt. Dies ermöglicht die Synchronisation von Refactorings auf zwei unterschiedlichen Strukturen. Eine Änderung der Ontologie oder des Domänenmodells führt somit zu einer Änderung der jeweils anderen Struktur, sodass die Beziehung zwischen beiden Strukturen konsistent bleibt.

1.2 Zielsetzung

Ziel der Arbeit ist es, zu untersuchen, inwieweit Ontologien zum Design von Softwaresystemen eingesetzt werden können. Dazu werden vier Teilbereiche bearbeitet. Zuerst ist die Beziehung zwischen Ontologien und Domänenmodellen zu untersuchen. Es soll festgestellt werden, in welchem Umfang Ontologien auf Domänenmodelle abgebildet werden können und wie eine entsprechende Transformation formalisiert werden kann. Im Rahmen des MOST-Projekts¹ wurde bereits eine Abbildung von Domänenmodell auf Ontologie erarbeitet. Diese kann als Ausgangspunkt für die Erarbeitung einer Abbildung in die andere Richtung dienen.

Des Weiteren sind Refactorings für Ontologien und Domänenmodelle zu entwerfen. Diese Refactorings stellen formale Änderungsoperationen dar, die es ermöglichen, Ontologien und Domänenmodelle von einem definierten Zustand in einen anderen definierten Zustand zu versetzen. Die Definition der Ontologie-Refactorings kann sich dabei an vorhandenen Arbeiten zur Ontologie-Evolution orientieren [NK04, GPS10]. Darauf aufbauend soll ein Konzept für Co-Refactorings aufgestellt werden, mit dem Refactorings auf mehreren Modellen synchron ausgeführt werden können. Refactory als Werkzeug zum generischen Modell-Refactoring soll dabei zur Umsetzung des Co-Refactorings eingesetzt werden [RSA10].

Die Implementierung eines Prototyps soll die Umsetzbarkeit der erarbeiteten Konzepte demonstrieren. Der Prototyp umfasst zwei Programmteile. Der erste Teil ermöglicht eine Transformation von Ontologien in Domänenmodelle, während der zweite Teil Co-Refactorings auf beiden Strukturen durchführt.

Die erarbeiteten Konzepte werden schließlich anhand einer Beispiel-Ontologie evaluiert, welche die Grundlage für ein Softwaresystem zum Freelancer-Management darstellt. Die Arbeit beschränkt sich dabei auf die Erstellung der Ontologie. Die Erstellung des Softwaresystems und die Anbindung der Ontologie daran liegen außerhalb des Rahmens der Arbeit.

1.3 Gliederung

Die vorliegend Arbeit gliedert sich in neun Kapitel. Im Kapitel 2 werden mit der MDSD und dem Refactoring die Grundlagen dieser Arbeit behandelt. Das Kapitel 3 stellt die Grundlagen zu Ontologien und semantischen Techniken vor. Es behandelt darüber hinaus die OntologieEvolution und die Unterschiede zwischen Ontologie-Evolution und Refactoring. Im Anschluss an diese theoretischen Betrachtungen werden im Kapitel 4 mit OntoMoPP und Refactory die in dieser Arbeit verwendeten Werkzeuge vorgestellt. Das Kapitel 5 stellt ausführlich den aktuellen Stand der Forschung bezüglich der Ontologie-Domänenmodell-Abbildung, der OntologieEvolution und der Co-Evolution dar. Der Schwerpunkt dieser Arbeit, das Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme, wird in Kapitel 6 präsentiert. Das Kapitel 7 zeigt die praktische Umsetzung dieses Konzepts. Anschließend erfolgt im Kapitel 8 die Evaluation der implementierten Refactorings und Werkzeuge anhand einer Beispiel-Ontologie. Zum Schluss fasst das Kapitel 9 die Ergebnisse der Arbeit zusammen und gibt einen Ausblick auf mögliche zukünftige Entwicklungen.

2 Grundlagen

2.1 Modellgetriebene Softwareentwicklung

Die modellgetriebene Softwareentwicklung (MDSD) „ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen“ [SVEH07, S. 11]. In diesem Zusammenhang werden Softwaresysteme auf abstrakter Ebene durch formale Modelle beschrieben.

Zur Unterscheidung zwischen dem Design eines Systems und dessen tatsächlicher Umsetzung werden die Begriffe Problemraum und Lösungsraum verwendet. Der Problemraum ist die Zusammenfassung aller Ideen, die beschreiben, welches Problem vom Softwaresystem zu lösen ist. Dazu werden die Begriffe der Anwendungsdomäne verwendet. Mit Bezug auf das Beispiel der Unternehmensanwendung aus der Einleitung werden im Problemraum die Abläufe im Unternehmen beschrieben. Es wird beispielsweise festgehalten, welche Daten zu Kunden des Unternehmens gespeichert werden sollen, welche Daten zu Produkten gespeichert werden sollen und welche Beziehungen zwischen Kunden und Produkten bestehen. Der Lösungsraum umfasst hingegen die Art und Weise, wie Techniken zur Lösung des Problems eingesetzt werden. Wird ein Softwaresystem zur Lösung des Problems verwendet, beschreibt der Lösungsraum, wie Programmiersprachen, Frameworks oder andere Computerprogramme zur Anwendung kommen. In der genannten Unternehmensanwendung kann beispielsweise Java mit dem Enterprise-Application-Framework zur Abbildung der Geschäftsprozesse eingesetzt werden. Die Daten können in einer relationalen Datenbank gespeichert und Informationen über eine Weboberfläche, die ein Webframework verwendet, angezeigt werden. In der MDSD ist der Lösungsraum austauschbar, der Softwareentwickler kann sich so auf das eigentliche Problem

- das Design des Systems - konzentrieren.

In der MDSD nimmt das Metamodell die Rolle des Domänenmodells ein und beschreibt damit die Struktur des Softwaresystems [SVEH07]. Auf Basis dieser Beschreibung können nun formale Modelle erstellt werden. Formal bedeutet hier, dass durch das Metamodell genau festgelegt ist, was Bestandteil eines Modells ist und was nicht. Abbildung 2.1 zeigt einen Ausschnitt der Begriffswelt der Modellierung nach Stahl et al. Danach hat ein Metamodell eine abstrakte Syntax, die definiert, welche Konzepte in Modellen vorkommen dürfen, welche Eigenschaften diese Konzepte haben und wie diese in Beziehung stehen. Die Modelle eines Metamodells können mit einer oder mehreren domänenspezifischen Sprachen (Domain Specific Language, DSL) dargestellt werden. Die DSL ist somit eine spezielle Schreibweise für Modelle des Metamodells und enthält eine konkrete Syntax sowie eine Semantik. Die konkrete Syntax beschreibt die Notation der Modelle. Das kann zum Beispiel eine textuelle oder auch grafische Repräsentation sein. Die Semantik definiert hingegen die Bedeutung der Sprachelemente und somit auch die Bedeutung der Modelle. Die DSL stellt somit eine Sprache dar, mit der Modelle einer bestimmten Domäne beschrieben werden. DSLs setzen dazu Sprachelemente ein, die spezifisch für die Domäne sind und beschränken sich auf die Elemente, mit denen die Konzepte der Domäne ausreichenden beschrieben werden können. Darin unterscheiden sie sich von General Purpose Languages (GPL) wie Java oder C++.

Eine Besonderheit der MDSD ist die automatische Codegenerierung. Sobald das Metamodell erstellt ist, kann daraus automatisch Programmcode erzeugt werden, der die Struktur

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Begriffswelt MDSD nach [SVEH07, S. 28]

des Systems beschreibt. Dies verringert den Implementierungsaufwand und erhöht somit die Entwicklungsgeschwindigkeit. Außerdem führt dieses Vorgehen zu besserer Codequalität, da einmal geschriebener (und getesteter) Code immer wieder verwendet werden kann. Darüber hinaus kann die automatische Codegenerierung genutzt werden, um automatisch Editoren zu erzeugen, mit denen die Modelle erstellt und bearbeitet werden können.

Die Object Managmement Group (OMG)¹ hat mit der Meta Object Facility (MOF) einen Standard aufgestellt, der die Beziehungen zwischen Modellen und Metamodellen beschreibt [OMG06]. Es wird von einer Architektur mit vier Metaebenen ausgegangen, wie sie schon von Karagiannis und Kühn beschrieben wurde [KK02]. Die vier Metaebenen sind in Abbildung 2.2 dargestellt.

Die bisher besprochenen Modelle befinden sich auf Ebene M1. Sie repräsentieren einen Teil der Realität, in diesem Fall Softwaresysteme. Diese Modelle werden mit einer Modellsprache erstellt, die wiederum eine konkrete Repräsentation (d. h. eine Syntax) eines Modells auf der nächsthöheren Ebene ist. Wenn eine solche Beziehung zwischen zwei Modellen besteht, ist das Modell der oberen Metaebene das Metamodell des Modells auf der darunter liegenden Metaebene. Somit wird das Modell auf Ebene M2 zum Metamodell. Die Beziehung zwischen Metamodell und Modell ist demnach eine andere als zwischen dem Modell und den Softwareobjekten. Zwischen dem Metamodell auf der Ebene M2 und dem Meta-Metamodell auf der Ebene M3 besteht ebenfalls eine Metamodell-Beziehung. Die Abstraktionsschritte vom Modell zum Metamodell könnten in dieser Art beliebig fortgesetzt werden. In der Praxis hat sich jedoch eine Abstraktion bis zur Ebene M3 als zweckmäßig herausgestellt [KK02, S. 182]. Das Meta-Metamodell ist ausdrucksstark genug, um sich selbst beschreiben zu können. Das heißt, dass das Meta-Metamodell mit einer Repräsentation seiner selbst erstellt werden kann, woraus wiederum folgt, dass die Metamodellsprache und die Meta-Metamodellsprache gleich sind. Die MOF ist ein Beispiel für ein solches Meta-Metamodell. Die Einteilung in Modell und Metamodell ist immer in Abhängigkeit vom betrachteten Objekt zu treffen, da, je nach Betrachtungsweise, ein Modell mehreren Metaebenen zugeordnet werden kann.

Das Eclipse Modeling Framework (EMF)² ist ein Framework zur Anwendung des MDSDAnsatzes im Eclipse-Umfeld [SBPM09]. Das EMF baut auf Essential MOF (EMOF) auf, welches die wichtigsten Konzepte der MOF vereint und bietet mit Ecore eine Implementierung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Die vier Metaebenen nach [KK02, S. 182]

dieses Meta-Metamodells. Mit EMF können Metamodelle auf unterschiedliche Weise entworfen werden. Es ist möglich, Metamodelle aus Java-Interfaces, von XML-Schemas oder von UML-Diagrammen abzuleiten. Alternativ können Metamodelle auch direkt mit Ecore modelliert werden. Anschließend kann auf Basis der Metamodelle ausführbarer Programmcode generiert werden.

In dieser Arbeit kommt EMF zum Einsatz, da hier das Domänenmodell explizit in Form der Metamodelle vorliegt. Somit kann die Domänenbeschreibung, die in Form einer Ontologie vorliegt, auf diese explizite Darstellung abgebildet werden. Aus der Domänenbeschreibung in Form der Ontologie wird so, über den Zwischenschritt der EMF-Metamodelle, ein Softwaresystem erzeugt.

2.2 Refactoring

Schon in den 1980er Jahren entdeckten Ward Cunningham und Kent Beck die Bedeutung der Umstrukturierung von Programmcode während sie mit Smalltalk arbeiteten [FBB+99]. Die Idee, die Struktur des Programmcodes und somit das Design des Softwaresystems kontinuierlich zu verbessern, ist allerdings schon wesentlich älter. Harlan D. Mills schlägt schon 1971 vor, Softwaresysteme inkrementell zu entwickeln [Mil71]. Das heißt, zu Beginn der Entwicklung wird ein Design des Gesamtsystems aufgestellt. Dieses wird aber während der Entwicklung kontinuierlich weiterentwickelt. Programmcode und Systemdesign werden also beständig umstrukturiert. Dieser Ansatz resultiert daraus, dass der erste Designentwurf kaum korrekt und vollständig sein kann, insbesondere für große Systeme [Bro95]. Der Begriff Refactoring wurde erstmals 1990 von Opdyke und Johnson eingeführt [OJ90]. Opdyke beschäftigte sich anschließend in seiner Doktorarbeit mit der genaueren Betrachtung von Refactorings als Umstruktu- rierungen von objektorientierten Frameworks zur besseren Wiederverwendung [Opd92]. Weitreichende Verbreitung fand Refactoring mit dem 1999 veröffentlichten Buch „Refactoring“ von Martin Fowler et al. [FBB+99]. In diesem Buch hat Fowler einen Katalog von 72 Refactorings zusammengetragen³. Jedes Refactoring hat einen Namen, eine kurze Beschreibung mit einem Klassendiagramm oder Codeausschnitt, eine Motivation, eine Schritt-für-Schritt-Anleitung und ein Beispiel.

Martin Fowler definiert Refactoring wie folgt.

„Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.“ [FBB+99, S. xvi]

Es ist zu beachten, dass Refactoring aus drei Blickwinkeln betrachtet werden kann. Refactoring ist (1) der Prozess der Umstrukturierung eines Softwaresystems zur Verbesserung der „internen Struktur“, (2) die Änderung am Programmcode und (3) die Tätigkeit der Umstrukturierung. Wie bereits geschehen, wird auch weiterhin für die ersten beiden Einsatzzwecke der Begriff Refactoring verwendet. Aus dem Kontext sollte immer ersichtlich sein, ob der Prozess oder die Änderung gemeint ist. Als Verb zur Bezeichnung der Tätigkeit wird in dieser Arbeit refaktorieren verwendet.

Fowler sagt, ein Refactoring dürfe das sichtbare Verhalten („external behavior“ oder „observable behavior“) der Software nicht ändern. Er definiert aber nicht exakt, was unter Verhalten zu verstehen ist. Fowler bezieht sich jedoch sehr häufig auf Tests, um das Verhalten eines Programms zu prüfen. Dies macht deutlich, dass die Tests eines Programms das Verhalten darstellen. Das heißt, dass die Tests die gleichen Ergebnisse vor und nach dem Refactoring liefern müssen. Opdyke hingegen sagt, dass das Programm vor und nach dem Refactoring für alle Eingaben die gleichen Ausgaben liefern muss [Opd92, S. 2]. Dafür definiert er formale Vorbedingungen, die vor Ausführung des Refactorings erfüllt sein müssen. Dies funktioniert jedoch nur für sehr einfache Refactorings, wie die Umbenennung einer Variable. Komplexe Refactorings, die sich aus mehreren Einzelschritten zusammensetzen, erfordern Test, um zu prüfen, ob die Ausführung des Refactorings das Verhalten des Programms nicht verändert hat [FBB+99]. In seinem Buch „Refactoring“ nimmt Fowler bereits einen starken Bezug zu Tests, mit deren Hilfe ein Softwaresystem inkrementell entwickelt wird. Dieser Ansatz wurde später wesentlich durch Kent Beck zur Testgetriebenen Entwicklung (Test-Driven Development, TDD) weiterentwickelt [Bec03]. Der Abschnitt 7.2 geht näher auf diesen Ansatz der Softwareentwicklung ein.

Betrachten wir ein Beispiel, um zu verstehen, wie ein Refactoring funktioniert. Replace Data Value with Object ist eines der Refactorings aus dem Katalog von Fowler. Wir gehen davon aus, dass unser Softwaresystem eine Klasse hat, die eine Bestellung repräsentiert (Order). Jede Bestellung hat einen Kunden, von dem zu Beginn lediglich der Name als String gespeichert wird (Listing 2.1). Die Absicht des Refactorings besteht nun darin, diesen String durch ein vollwertiges Objekt zu ersetzten, um zusätzliche Informationen zum Kunden abspeichern zu können. Dazu wird eine neue Klasse angelegt, die den Kunden repräsentiert (Customer). In der Order-Klasse wird anschließend der String durch das Customer-Objekt ersetzt und die Getund Set-Methode sowie der Konstruktor werden entsprechend angepasst (Listing 2.2). Die Tests in Listing 2.3 zeigen, dass das Refactoring erfolgreich ausgeführt wurde. Das CustomerObjekt ist in diesem Zustand ein reines Daten-Objekt, das heißt, jede Bestellung hat ihren

2.2 Refactoring

Listing 2.1: Replace Data Value with Object vor dem Refactoring

Abbildung in dieser Leseprobe nicht enthalten

Listing 2.2: Replace Data Value with Object nach dem Refactoring

Abbildung in dieser Leseprobe nicht enthalten

eigenen Kunden. Um es in ein Referenz-Objekt zu verwandeln, kann im Anschluss ein weiteres Refactoring angewandt werden - Change Value to Reference. Der gezeigte Programmcode ist an das Beispiel von Fowler zu diesem Refactoring angelehnt [FBB+99, S. 176].

Nun stellt sich nur noch die Frage, in welcher Situation welches Refactoring ausgeführt werden sollte. Um diese Frage zu beantworten, haben Fowler und Beck das Prinzip der „Bad Smells“ eingeführt [FBB+99]. Ein „Bad Smell“ beschreibt Strukturen, die Indikatoren dafür sein können, dass bestimmte Refactorings durchzuführen sind. Darüber hinaus wird eine Empfehlung gegeben, welche Refactorings in Frage kommen. Einer der wichtigsten „Bad Smells“ ist Duplicated Code. Er tritt immer dann auf, wenn derselbe oder sehr ähnlicher Programmcode an mehreren Stellen im System vorkommt. Eine derartige Redundanz kann beispielsweise entfernt werden, indem der sich wiederholende Programmcode in eine Methode ausgelagert wird, die an allen benötigten Stellen aufgerufen wird. Robert C. Martin hat in seinem Buch „Clean Code“ das Prinzip der „Smells“ aufgegriffen und weiterentwickelt [Mar09].

Refactoring kann also zur inkrementellen Entwicklung von Software eingesetzt werden. Daraus ergibt sich eine Reihe von Vorteilen. Der Wichtigste ist ein sauberer Programmcode („Clean Code“). Einen sauberen Programmcode zu schreiben, war die ursprüngliche Motivation für Refactoring und ist immer noch das wichtigste Ergebnis. Ein Programmcode ist dann sauber, wenn er einfach verständlich, schlicht, direkt und seine Absicht sofort zu erkennen ist [Mar09]. Obwohl Refactoring während der Entwicklung zusätzliche Zeit in Anspruch nimmt, führt es im Endeffekt zu einer kürzeren Entwicklungszeit und einer einfacheren Wartung der erstellten Software [MAP+08, S. 263]. Dies resultiert vor allem aus einer ständigen Verbesserung des Designs, was zur Folge hat, dass der Programmcode einfacher zu verstehen ist und Fehler in der Software reduziert werden [FBB+99].

Die ersten Ansätze des Refactorings wurden für Smalltalk entwickelt und ein Großteil der heutigen Dokumentation zu Refactoring basiert auf Java oder C++. Obwohl ursprünglich für objektorientierte Programmiersprachen entwickelt, ist Refactoring jedoch nicht auf diese beschränkt. Im Rahmen der modellgetriebenen Softwareentwicklung kommt der Bedarf auf, nicht nur Programmcode, sondern auch Modelle zu refaktorieren. Dies führte zur Entwicklung des Modell-Refactorings [RSA10, MMBJ09], in dem Modelle umstrukturiert werden, um deren Struktur zu verbessern.

3 Ontologien und semantische Techniken

3.1 Grundlagen semantischer Techniken

2001 erkannten Tim Berners-Lee et al., dass nahezu alle Informationen, die im World Wide Web gespeichert sind, nur für Menschen zugänglich und nicht für die automatische Verarbeitung geeignet sind [BLHL01]. Berners-Lee et al. entwickelten die Idee, die Bedeutung von Daten im Web explizit anzugeben und führten dafür den Begriff Semantic Web ein. Das Ziel hinter dieser Idee ist, dass Computerprogramme (so genannte Software-Agenten) Informationen im Web „verstehen“ und so miteinander in Beziehung stehende Daten als zusammengehörig erkennen können. Als Beispiel kann man sich einen Software-Agenten zur Reiseplanung vorstellen. Der Benutzer gibt lediglich den Zeitraum und das gewünschte Reiseziel ein und der Software-Agent sucht automatisch alle nötigen Informationen aus dem Web zusammen, wie zum Beispiel Reiseverbindungen, Unterkünfte, Sehenswürdigkeiten. Alle diese Informationen können mit einer herkömmlichen Textsuche nicht gefunden oder in Beziehung gesetzt werden. Ein „Gästehaus“ wird als Unterkunft nicht gefunden, wenn man nach einem „Hotel“ sucht, einfach deshalb, weil es sich um zwei unterschiedliche Suchbegriffe handelt. Im Semantic Web hingegen werden allen Daten zusätzliche maschinenlesbare Informationen hinzugefügt, die diese Daten und deren Beziehungen zu anderen Daten näher beschreiben. So könnte zu einer Stadt gespeichert werden, welche Unterkünfte es in dieser Stadt gibt und zu einem Hotel oder einem Gästehaus könnte gespeichert sein, dass beides eine Unterkunft ist. Wenn diese Informationen maschinenlesbar gespeichert sind, kann ein Software-Agent logische Schlüsse aus Daten ziehen, für die bislang menschliches Verständnis nötig war. Die Fähigkeit von Computerprogrammen, die Bedeutung von Daten zu verstehen, hat zu dem Namen Semantic Web geführt. Die Vision von Berners-Lee et al. ist nun, nahezu alle Dinge der realen Welt und alle Daten im Web mit derartigen zusätzlichen Informationen zu versehen. Dieser Ansatz wird auch als das Netz der Dinge bezeichnet wird [Con10].

Betrachten wir nun die technischen Grundlagen des Semantic Web. Die Abbildung 3.1 zeigt die vom World Wide Web Consortium (W3C)¹ entworfene Schichtenarchitektur des Semantic Web [KM01]. Im Folgenden werden die unteren drei Schichten - URIs, XML und RDF - besprochen. Im Abschnitt 3.2 werden die darauf aufbauenden Konzepte RDF Schema, Ontologien und Logik behandelt. Alle weiteren Konzepte der Architektur sind im Rahmen dieser Arbeit nicht von Belang.

In der untersten Schicht befindet sich der Uniform Resource Identifier (URI) als Basis der Semantic Web-Architektur. Der URI ist eine Verallgemeinerung des durch das Web bekanntgewordenen Uniform Resource Locator (URL). Beides sind Zeichenketten, doch während der URL eine bestimmte Internetseite bezeichnet, kann mit einem URI jedes beliebige Objekt der wirklichen oder virtuellen Welt referenziert werden. Ein wesentliches Konzept des Semantic Web ist, dass jedes einzelne dieser Objekte eindeutig identifiziert werden kann. Der URI bietet genau diese Möglichkeit [BLHL01]. In Abbildung 3.2 ist das Namensschema eines URI zu sehen, wie es vom W3C im RFC 3986 definiert wird [BLFM05]. Der URI enthält fünf Teile. Das Schema definiert das Protokoll, über das die angefragte Ressource geladen wird und ist der Teil vor dem ersten Doppelpunkt. Beispiele für Protokolle sind „http“, „ftp“ und „doi“.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Schichtenarchitektur des Semantik Web aus [KM01]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2: URI-Schema nach dem RFC 3986

Als nächstes folgt, falls vorhanden, die Authority beginnend mit zwei Schrägstrichen. Dies ist die Identifikation für den Server auf dem die Daten liegen, optional gefolgt von einem durch Doppelpunkt getrennten Port. Der Path beginnt mit einem Schrägstrich und bezeichnet den Verzeichnispfad und den Dateinamen. Query und Fragment sind wiederum optional und werden verwendet um Ressourcen mit bestimmten Eigenschaften abzufragen bzw. bestimmte Teile von Ressourcen zu identifizieren.

Wird der URI, wie im RFC 3987 beschrieben, in Unicode codiert, spricht man von einem Internationalized Resource Identifier (IRI) [DS05]. Dieser kann Zeichen aus beliebigen Zeichensätzen verwenden. Bezeichner, wie URIs und IRIs, können also eingesetzt werden, um beliebige Objekte zu identifizieren und bilden somit die Basis des Semantic Web.

In der zweiten Schicht der Semantic Web-Architektur befindet sich die Extensible Mar- kup Language (XML) [BPSM+08]. Diese Sprache wird zur Beschreibung von Dokumenten verwendet. Sie kann dazu eingesetzt werden, einzelne Teile eines Dokuments mit beliebigen Informationen zu versehen. Eine Besonderheit der XML sind die Namensräume, mit denen der Gültigkeitsbereich von Bezeichnern angegeben wird. Somit ist bei Reduzierung der URIs auf das Fragment eine eindeutige Bezeichnung von Ressourcen auch dann noch möglich, wenn es mehrere Ressourcen mit dem gleichen Fragment aus unterschiedlichen Quellen gibt.

Die erste tatsächliche Erweiterung der bisher besprochenen Technologien zum Semantic Web stellt das Resource Description Framework (RDF) dar, das sich in der dritten Schicht der Semantic Web-Architektur befindet [MM04]. Das RDF nutzt eine Tripel-Syntax, um beliebige Dinge näher zu beschreiben. Hierbei kann es sich um Personen oder Objekte der realen Welt aber auch um Ideen oder elektronische Dokumente handeln. Jedes Tripel besteht aus Subjekt, Prädikat und Objekt [Hor08]. Das Subjekt ist das Element, welches durch das Tripel näher beschrieben wird. Das Prädikat stellt dabei eine Beziehung des Subjekts zu einem anderen Element oder zu einem Wert dar. Beide werden durch einen IRI eindeutig identifiziert. Das Objekt schließlich ist das Ziel der Beziehung. Dies kann ein anderes, durch einen IRI identifiziertes Element oder ein Literal sein. Ein Literal ist ein atomarer Wert, wie eine Zahl oder eine

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Beispiel eines RDF-Graphen

Zeichenkette. Mehrere RDF-Tripel können so Eigenschaften und Beziehungen vieler Elemente beschreiben und bilden dadurch einen RDF-Graphen. Die Abbildung 3.3 zeigt ein Beispiel eines solchen RDF-Graphen, in dem das Subjekt John durch drei Tripel näher beschrieben wird.

Das Prädikat rdf:type sagt aus, dass John „vom Typ“ Mitarbeiter ist. Die Zeichenkette rdf: ist hierbei eine Abkürzung für den Namesraum http://www.w3.org/1999/02/22-rdf- syntax-ns#. Das Objekt des Prädikats hatEMailAdresse ist ein einfaches Literal, wohingegen das Prädikat hatKollege auf Bob, also ein anderes Element, zeigt. Sämtliche Namen von Elementen im Diagramm sind lediglich Abkürzungen für vollständige IRIs. Das W3C hat mit RDF/XML eine XML-Syntax zur Speicherung und zum Austausch von RDF-Tripeln definiert [Bec04]. Das Listing 3.1 zeigt das Beispiel aus Abbildung 3.3 in dieser RDF/XML-Syntax. Zur Vereinfachung der Schreibweise hat das W3C außerdem die Turtle -Syntax eingeführt [BBL08]. Diese Syntax ging aus der von Berners-Lee entwickelten Notation 3 (N3) hervor [HKRS08, S. 40] und basiert auf einer Tripel-Darstellung, wie das Listing 3.2 zeigt.

Listing 3.1: RDF/XML-Syntax für den RDF-Graphen aus Abbildung 3.3

Abbildung in dieser Leseprobe nicht enthalten

3.2 Ontologien

3.2.1 Definition und Begriffe

Der Begriff Ontologie kommt ursprünglich aus der Philosophie. Dort bezeichnet er die Lehre vom Sein der Dinge [Yil06]. Die erste wissenschaftliche Definition von Ontologien im Bereich der Informatik wird 1993 von Gruber angegeben.

„An ontology is an explicit specification of a conceptualization.“ [Gru93, S. 2]

Durch den Artikel „The Semantic Web“ von Berners-Lee et al. hat dieser Begriff auch in der Informatik eine weite Verbreitung gefunden [BLHL01]. Nach Berners-Lee et al. bezeichnet eine Ontologie ein Begriffsnetz, das alle Konzepte einer Anwendungsdomäne und ihre Beziehungen untereinander klar definiert. Die Ontologie stellt damit ein gemeinsames Vokabular von Begriffen und deren Bedeutung dar. Als Ontologie wird weiterhin das Software-Artefakt bezeichnet, in der dieses Vokabular gespeichert wird.

Die wichtigsten Elemente zur Modellierung von Wissen in einer Ontologie sind Klassen, Propertys und Individuen [Hor08]. Abbildung 3.4 zeigt diese Elemente anhand einer kleinen Beispiel-Ontologie. Eine Klasse ist eine Menge von Individuen mit bestimmten Eigenschaften. Das Konzept einer Klasse ist also vergleichbar mit dem mathematischen Konzept der Menge. Ein Individuum ist demnach ein konkretes Element, das zu einer Klasse gehören kann aber nicht gehören muss. Die Unterscheidung in Klasse und Individuum ist dabei keineswegs eindeutig. So können beispielsweise Länder als Klassen dargestellt werden, die Ortschaften als Individuen enthalten oder selbst Individuen der Klasse Geografische Region sein. Als Faustregel gilt, dass Individuen diejenigen Elemente einer Ontologie sind, welche selbst keine weiteren Elemente enthalten [NM01]. Sowohl Beziehungen zwischen Klassen als auch zwischen Individuen werden durch Propertys angegeben. Propertys entsprechen somit den Prädikaten des RDF. Es wird dabei zwischen ObjectPropertys, die Beziehungen zu anderen Elementen anzeigen und DataPropertys, die Beziehungen zu Literalen anzeigen, unterschieden. Die Menge aller Klassen und deren Beziehungen untereinander beschreibt die Struktur der Ontologie und wird auch als Terminology Box (TBox) bezeichnet. Die Menge der Individuen und deren Beziehungen stellt den Datenbestand der Ontologie dar und wird als Assertion Box (ABox) bezeichnet. Gemeinsam ergeben TBox und ABox die so genannte Knowledge Base [Hor08].

Um Ontologien beschreiben zu können, wurde das RDF zum RDF Schema (RDFS) weiterentwickelt [BG04]. Das RDFS definiert eine Reihe von Prädikaten mit besonderer Bedeutung, wodurch es möglich wird, mit RDF-Tripeln Ontologien zu beschreiben. Beispiele für solche Prädikate sind rdfs:Class, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain und rdfs:range. Durch derartige Prädikate können Klassen- und Property-Hierarchien sowie Definitions- und Wertebereich von Propertys definiert werden. Im vorherigen Abschnitt wurde zum Beispiel durch das RDF-Prädikat rdf:type angegeben, dass John „vom Typ“Mitarbeiter ist. Mitarbeiter ist jedoch ein beliebiges Element im RDF-Graphen. Erst durch die RDFS-Definition rdfs:Class wird Mitarbeiter zu einer Klasse.

3.2.2 Die Web Ontology Language (OWL)

Die heute geläufigste Beschreibungssprache für Ontologien ist die Web Ontology Language (OWL² ) [MvH04]. Sie setzt auf dem RDFS auf und erweitert es um zusätzliche Konzepte [Hor08]. So ist es beispielsweise möglich, Klassen auf Basis bestehender Klassen und logischer Mengenoperationen zu definieren. Die Klasse der Java-Experten kann zum Beispiel als

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Beispiel einer Ontologie

Schnittmenge der Menge aller Personen, die mit Java arbeiten und der Menge aller Personen, die mindestens fünf Jahre Berufserfahrung haben, beschrieben werden.

Eine Klasse, die mit einer IRI eindeutig beschrieben ist, wird als benannte Klasse bezeichnet. In OWL 2 ist es jedoch auch möglich, anonyme Klassen mit Klassen-Ausdrücken zu definieren [MPSP09]. Die Klassen werden hierbei nicht durch einen Namen, sondern durch eine Beschreibung der Eigenschaften aller zur Klasse gehörenden Individuen definiert. Dies erfolgt zum Beispiel durch eine Aufzählung aller zulässigen Individuen, durch Einschränkungen von Eigenschaften, oder durch logische Mengenoperationen, wie Vereinigung, Schnittmenge oder Komplement.

Zusätzliche Eigenschaften von Klassen und Propertys werden über Axiome angegeben. Mit dem SubClassOf-Axiom wird beispielsweise die Unterklassen-Beziehungen zwischen zwei Klassen definiert. Domain- und Range-Axiome geben die Klasse von Quelle bzw. Ziel einer Property an. Individuen werden mit speziellen Axiomen, so genannten Aussagen (engl. assertions), näher beschrieben. Diese Aussagen geben an, zu welcher Klasse ein Individuum gehört und welche Beziehungen es zu anderen Individuen hat. Die OWL 2-Spezifikation listet alle zur Verfügung stehenden Axiome und Aussagen mit Erklärungen und Beispielen auf [MPSP09].

Des Weiteren können mit OWL Einschränkungen (engl. restrictions) von Klassen und Propertys vorgenommen werden. Die Klasse aller Arbeitnehmer kann beispielsweise definiert werden, indem die Klasse aller Personen auf diejenigen Personen eingeschränkt wird, welche einen Arbeitgeber haben. Mit Einschränkungen kann auch die Anzahl der Propertys für alle Individuen einer Klasse angegeben werden. So kann beispielsweise definiert werden, dass jeder Kunde exakt zwei Propertys hatAdresse besitzt, die ihn mit seiner Rechnungs- und seiner Lieferadresse verbinden. Die angegebene Anzahl wird auch als Kardinalität bezeichnet, da sie angibt, wie groß die Menge der Individuen ist, zu denen eine Beziehung besteht. Die Einschränkung ist dabei selbst eine anonyme Klasse. Je nach dem in welcher Beziehung die Einschränkungen mit den benannten Klassen stehen, werden die benannten Klassen in primitive und definierte

Klassen eingeteilt [Hor11, S. 53]. Primitive Klassen sind Unterklassen der Einschränkungen. Die Einschränkungen stellen somit notwendige Bedingungen dar. Das heißt, ein Individuum muss diese Einschränkung erfüllen, damit es zur Klasse gehört, es kann aber auch noch andere Individuen mit diesen Einschränkungen geben, die nicht zur Klasse gehören. Definierte Klassen sind dagegen äquivalent zu den Einschränkungen. Die Einschränkungen sind also notwendige und hinreichende Bedingungen. Somit enthält die Klasse alle Individuen mit diesen Einschränkungen.

Die OWL Working Group des W3C³ hat im Oktober 2009 die neue Version OWL 2 (früher unter dem Namen OWL 1.1 bekannt) veröffentlicht [W3C09]. OWL 2 erweitert den bisherigen OWL-Standard um zusätzliche Ausdrucksmittel [Hor08]. Dazu gehört die Möglichkeit, numerische Klassen-Einschränkungen mit „qualifizierten“ Zielen anzugeben (engl. qualified number restrictions). Damit ist es beispielsweise möglich, eine Hand als etwas zu beschreiben, das vier Finger und einen Daumen hat. Die Propertys, welche die Beziehungen in Ontologien darstellen, können in OWL 2 mit weiteren Attributen, wie reflexiv, transitiv oder symmetrisch näher beschrieben werden. Eine transitive Property, die Beziehungen zwischen geografische Regionen herstellt, ist zum Beispiel befindetSichIn. Darüber hinaus führt OWL 2 Datentypen und Annotationen ein.

An dieser Stelle sei noch auf einige Besonderheiten von Ontologien hingewiesen. RDFGraphen und somit auch Ontologien gehen von der „ Annahme nicht-eindeutiger Namen “ (engl. non-unique name assumption) aus [HKRS08, S. 65]. Das bedeutet, dass zwei unterschiedliche Bezeichner (IRIs) denselben Gegenstand bezeichnen können, solange nicht explizit angegeben ist, dass beide Bezeichner unterschiedliche Dinge bezeichnen. Ein wesentlicher Unterschied zwischen Ontologien und anderen Speichertechnologien, wie Datenbanken, ist die „ Offene- Welt-Annahme “ (engl. open-world assumption, OWA) [HKRS08, S. 145]. In Ontologien geht man immer davon aus, dass die vorliegenden Daten unvollständig sind und behandelt daher alle nicht vorliegenden Informationen als ungewiss, anstatt als falsch. Stellen wir uns vor, in einer Ontologie ist ein Mitarbeiter John gespeichert, zu dem keine weiteren Informationen vorliegen. Mit einer Klasse aller Mitarbeiter, die an keinem Projekt arbeiten, soll nun festgestellt werden, welche Mitarbeiter neuen Projekten zugewiesen werden können. Allerdings erscheint John nicht als Individuum dieser Klasse. Es könnte sein, dass John zwar an einem Projekt arbeitet, jedoch die Information darüber nicht vorliegt. Damit abgeleitet werden kann, dass John ein Individuum der Klasse ist, muss also explizit angegeben werden, das John an keinem Projekt arbeitet. Die OWA bedingt weiterhin, dass sich Klassen überlappen können, solange nicht angegeben ist, dass sie disjunkt sind. Im Gegensatz zur OWA funktionieren Datenbanken nach der „ Geschlossenen-Welt-Annahme “ (engl. closed-world assumption, CWA). Das heißt, dass alle nicht vorliegenden Informationen als falsch behandelt werden. Steht der Mitarbeiter mit der Nummer 1234 nicht in der Datenbank, gibt es ihn nicht.

3.2.3 Ontologie-Syntaxen

Im vorherigen Abschnitt wurden bereits die RDF/XML-Syntax und die Turtle-Syntax zur Speicherung von RDF-Tripeln vorgestellt. Diese Syntaxen eignen sich ebenfalls zur Speicherung von Ontologien. Die RDF/XML-Syntax wurde vom W3C zur Standard-Syntax für Ontologien ernannt [W3C09]. Darüber hinaus gibt es eine Reihe weiterer Syntaxen, in denen Ontologien gespeichert werden können. Die OWL/XML -Syntax folgt wie die RDF/XML-Syntax dem XML-Standard, verwendet aber spezielle Ausdrucksmittel für Konzepte des OWL-Standards [MPPS09]. Die Functional Syntax ist eine sehr kompakte Syntax, die sich an der Schreibweise der Prädikatenlogik orientiert [MPSP09]. Die OWL/XML- und Functional Syntax sind

Axiom-basiert. Das bedeutet, dass alle Axiome der Ontologie als eigenständige Konzepte geschrieben werden. Die Aussage, dass John zur Klasse der Mitarbeiter gehört, ist unabhängig von der Definition des Individuums John. Die Manchester OWL Syntax hingegen ist Framebasiert und wurde mit dem Ziel erschaffen, die Ontologie für den Menschen möglichst einfach lesbar darzustellen [HPS09]. Die Manchester OWL Syntax schreibt dazu alle Axiome, die ein bestimmtes Element betreffen in einen Frame. Die Listings 3.3, 3.4, 3.5 und 3.6 stellen die unterschiedlichen Syntaxen für eine Ontologie, die dem RDF-Graphen aus Abbildung 3.3 basiert, gegenüber.

Listing 3.3: RDF/XML-Syntax für eine Ontologie basierend auf dem RDF-Graphen aus Abbildung 3.3

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.5: Functional Syntax für eine Ontologie basierend auf dem RDF-Graphen aus Abbildung 3.3

Abbildung in dieser Leseprobe nicht enthalten

Listing 3.6: Manchester OWL Syntax für eine Ontologie basierend auf dem RDF-Graphen aus Abbildung 3.3

Abbildung in dieser Leseprobe nicht enthalten

Wie wir in diesem Abschnitt gesehen haben, sind die meisten Syntaxen für Ontologien nicht besonders zugänglich für die direkte Bearbeitung. Es sind also Werkzeuge nötig, die eine grafische Benutzeroberfläche zur komfortablen Erstellung und Bearbeitung von Ontologien zur Verfügung stellen. Das Kapitel 5 geht näher auf solche Werkzeuge ein.

3.2.4 Beschreibungslogiken, Teilsprachen und Profile

Bisher wurden die Bestandteile von Ontologien und deren Darstellung behandelt. Nun soll es um die formale Semantik (also die formale Bedeutung) gehen. Die formale Semantik von Ontologien wird mit Beschreibungslogiken ausgedrückt [HKRS08, S. 163]. Eine Beschreibungslogik definiert, welche Konzepte in einer Ontologie zur Wissensmodellierung eingesetzt werden können und bestimmt damit die Ausdruckstärke der Ontologie⁴. Auf der Basis dieser Beschreibungslogiken kann ein Reasoner⁵ logische Schlussfolgerungen über den Daten einer Ontologie ziehen. Damit ist es unter anderem möglich, die logische Klassenhierarchie aufzustellen (man sagt: die Ontologie klassifizieren) und Konsistenzprüfungen durchzuführen. Die Konsistenzprüfungen prüfen dabei die semantische Konsistenz der Ontologie. Diese kann in zwei Fällen verletzt sein. Erstens, es gibt eine Klasse, die keine Individuen enthalten kann. Dies geschieht immer dann, wenn eine Klasse als die Schnittmenge zweier disjunkter Klassen definiert wird. Zweitens, ein Individuum gehört zu zwei disjunkten Klassen. Dieser Fall tritt zum Beispiel ein, wenn ein Individuum durch eine Property referenziert wird, die Klasse des Individuums aber disjunkt zum Wertebereich der Property ist. Die Klassifizierung und Konsistenzprüfung können bei großen Ontologien einige Zeit in Anspruch nehmen, je nachdem, welche Konzepte zur Beschreibung der Ontologie eingesetzt werden. Beschreibungslogiken stellen also einen Kompromiss zwischen Ausdrucksstärke und der Zeit, die für logische Schlussfolgerungen benötigt wird, dar [HKRS08, S. 163].

Die einfachste Beschreibungslogik, die in Ontologien sinnvoll zum Einsatz kommen kann, ist ALC (Attribute Language with Complement)⁶. Mit ihr können die Negation, Mengen und deren Komplemente, Konjunktionen, Disjunktionen und allgemeine Klassen-Einschränkungen definiert werden⁷. ALC ist die Basis für alle weiteren Beschreibungslogiken. OWL 2 umfasst insgesamt drei Teil-Sprachen, denen unterschiedlich mächtige Beschreibungslogiken zugrunde liegen [HKRS08]. OWL Lite ist die Teilsprache mit der geringsten Ausdrucksstärke, ihr liegt die Beschreibungslogik SHIF zugrunde. Mit dieser Teilsprache können Klassen- und PropertyHierarchien dargestellt und einfache Eigenschaften von Propertys (transitiv, funktional, invers) angegeben werden. OWL Lite dient dazu, Taxonomien in Ontologien zu überführen.

Die Teilsprache OWL DL enthält OWL Lite und führt eine Reihe weiterer Konzepte ein, sodass die damit beschriebenen Ontologien für die meisten Anwendungsfälle ausdrucksstark genug sind. OWL DL basiert auf der schon wesentlich mächtigeren Beschreibungslogik SHOIN (D) und wird von den meisten Ontologie-Werkzeugen unterstützt.

Der komplette Sprachumfang von OWL 2 wird auch als OWL Full bezeichnet. OWL Full basiert auf der Beschreibungslogik sROIQ, bietet die größte Ausdrucksstärke, ist aber, im Gegensatz zu OWL Lite und OWL DL, nicht mehr entscheidbar. Das heißt, es gibt Situationen, in denen eine Klassifizierung oder Konsistenzprüfung nicht mehr in endlicher Zeit durchgeführt werden kann.

Abgesehen von den Teilsprachen bietet OWL seit der Version 2 auch so genannte Profile [MGH+09, Hor08]. Profile sind syntaktische Teilsprachen von OWL DL, mit denen logische Schlussfolgerungen in höchstens polynomieller Laufzeit, bezogen auf die Anzahl der in der Ontologie definierten Konzepte, durchgeführt werden können. Es gibt insgesamt drei Profile. OWL 2 EL ist für sehr große aber einfach strukturierte Ontologien gedacht. OWL 2 QL ist speziell für Abfragen über Ontologien mit vielen Individuen ausgelegt. OWL 2 RL basiert auf einer Regelsprache und stellt die größte Ausdrucksstärke der drei Profile zur Verfügung.

3.2.5 Abfragen mit SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) ist eine Abfragesprache für RDFGraphen [PS08]. SPARQL orientiert sich an der SQL-Abfragesprache für relationale Datenbanken und nutzt die Turtle-Syntax zur Definition von Abfragen. Dazu werden in einer WHEREKlausel beliebig viele RDF-Tripel in Turtle-Syntax definiert, welche Variablen enthalten können, die wiederum in einer SELECT-Klausel zu einer Ergebnismenge zusammengefügt werden. Eine Beispiel-Anfrage an den RDF-Graphen aus Abbildung 3.3 ist in Listing 3.7 zu sehen. Das Ergebnis der Abfrage besteht aus nur einem Datensatz mit einem Wert: Bob.

3 Ontologien und semantische Techniken

Listing 3.7: SPARQL-Abfrage an den RDF-Graphen aus Abbildung 3.3

Abbildung in dieser Leseprobe nicht enthalten

Um Abfragen auch über Ontologien durchführen zu können, wird aktuell der Nachfolger SPARQL 1.1 entwickelt. Diese neue Version ermöglicht Abfragen über der OWL DLTeilsprache. Zum Zeitpunkt der Erstellung dieser Arbeit liegt ein erster Entwurf des W3C für SPARQL 1.1 vor [GO10]. Die Turtle-Syntax, auf der SPARQL basiert, wurde jedoch für RDFTripel und nicht für Ontologien entwickelt. Deshalb werden Abfragen an Ontologien schnell umfangreich, kompliziert zu schreiben und schwierig zu verstehen. Aus diesem Grund wird mit Terp eine neue Abfrage-Syntax entwickelt [SBS10]. Terp kombiniert die Turtle-Syntax mit der Manchester OWL Syntax, um kurze, aussagekräftige Anfragen an Ontologien stellen zu können. Einen ähnlichen Ansatz verfolgt SPARQLAS. Es erweitert Abfragen um OWL-Elemente (wie Klassen, Propertys oder Individuen) und wandelt diese dann in herkömmliche SPARQLAbfragen um [Sch10b].

3.2.6 Beispiele für Ontologien

Ontologien sollen ein gemeinsames Vokabular von Begriffen definieren, das weltweit verfügbar ist. Sie haben bereits vor allem in der Medizin, Biologie und Geografie Anwendung gefunden [Hor08]. Als Beispiele können hier die SNOMED CT⁸ (Systematized Nomenclature of Medicine

- Clinical Terms), die GO⁹ (Gene Ontology), die BioPAX¹⁰ (Biological Pathway Exchange) und die SWEET¹¹ (Semantic Web for Earth and Environmental Terminology Project) genannt werden. Dies sind Beispiele für teils sehr große Verzeichnisse, die ein gemeinsames Vokabular für viele verteilte Anwender zur Verfügung stellen. Die SNOMED CT allein enthält knapp 300.000 Klassen und wird vom National Health Service (NHS) in Großbritannien landesweit in der Gesundheitsversorgung eingesetzt [Hor08].

Die genannten Beispiele sind Domain-Ontologien [NV04]. Das heißt, sie definieren Begriffe für eine bestimmte Anwendungsdomäne. Erstellen nun viele Anwender unabhängig voneinander Ontologien zu einer Anwendungsdomäne, kommt es schnell dazu, dass für dieselben Konzepte unterschiedliche Begriffe verwendet werden. Weiterhin gibt es auch Konzepte, die in vielen unterschiedlichen Anwendungsdomänen immer wieder vorkommen, beispielsweise das Konzept einer Person mit deren Namen und Beziehungen zu anderen Personen. Um derartige Konzepte domänenübergreifend zu definieren, wurden Top-Level-Ontologien (auch Foundational Ontologies oder Upper Ontologies) entwickelt [NV04]. Top-Level-Ontologien enthalten Konzepte, die in Domain-Ontologien unterschiedlicher Domänen wiederverwendet werden können. Die bekanntesten Beispiele dafür sind die Dublin Core-Ontologie¹² (DC) und die Friend-of-aFriend-Ontologie¹³ (FOAF). Die größte aktuelle Ontologie ist DBpedia¹⁴, eine Ontologie, die ihren Datenbestand aus der Wikipedia bezieht. Weitere Informationen über öffentliche Ontologien können auf der Linked Data-Website http://linkeddata.org/ eingesehen werden.

3.3 Ontologie-Evolution und Versionierung

Ontologien sind, wie Softwaresysteme, Änderungen unterworfen. Deshalb soll an dieser Stelle die Ontologie-Evolution näher betrachtet werden. Sie stellt den Teilbereich der OntologieForschung dar, der sich mit der Veränderung und Weiterentwicklung von Ontologien beschäftigt. Haase und Stojanovic definieren den Begriff der Ontologie-Evolution wie folgt.

„Ontology Evolution can be defined as the timely adaptation of an ontology to the arisen changes and the consistent management of these changes.“ [HS05, S. 1]

Ontologie-Evolution ist demnach eine Anpassung der Ontologie an sich ändernde Rahmenbedingungen. Dabei müssen Änderungen an der Ontologie immer so ausgeführt werden, dass die Ontologie konsistent bleibt. Das heißt, sie darf keine logischen Widersprüche aufweisen. Der Teil der Definition „consistent management of these changes“ bezieht sich weiterhin darauf, dass die Änderungen unter Umständen auch auf andere verteilte Ontologien angewendet werden. Im Bereich der Ontologie-Evolution wird von Änderungsoperationen statt Refactorings gesprochen. Diese lassen sich in elementare und komplexe Änderungsoperationen einteilen [Sto04, S. 60]. Elementare Änderungen sind dabei das Hinzufügen, Verändern oder Löschen einzelner Elemente. Während sich komplexe Änderungen aus beliebigen Kombinationen der elementaren Änderungen ergeben.

Die Umsetzung entsprechender Änderungen in der Ontologie erfordert einen Prozess mit wohldefinierten Tätigkeiten [SMMS02]. Stojanovic et al. definieren dafür einen Evolutionsprozess, der aus sechs Phasen besteht, die in Abbildung 3.5 zu sehen sind. (1) Zu Beginn werden die Anforderungen an die Ontologie analysiert und nach neuen Begriffen gesucht, die in die Ontologie aufgenommen werden sollen. Daraus werden die gewünschten Änderungen der Ontologie abgeleitet. (2) Dies können elementare oder komplexe Änderungen sein. Aus der genauen Definition der durchzuführenden Änderungen ergibt sich die Repräsentation der Änderung. (3) Als nächstes müssen die Auswirkungen einer Änderung überprüft werden. Wird beispielsweise ein Element gelöscht, das an anderer Stelle referenziert wird, ist die Ontologie (syntaktisch) inkonsistent. In diesem Fall müssen weitere Änderungen (das Löschen der Referenz) ermittelt werden, um die Konsistenz der Ontologie zu erhalten. (4) Ist die Erhaltung der Konsistenz sichergestellt, können die Änderungen tatsächlich ausgeführt werden. (5) Die Änderung der Ontologie erfordert eine entsprechende Anpassung aller abhängigen Artefakte, wie andere Ontologien oder Softwaresysteme, die auf die Ontologie zugreifen. (6) Der letzte Schritt im Evolutionsprozess besteht in der Überprüfung der Korrektheit der Änderungen.

Die im Punkt (3) erwähnte Konsistenz einer Ontologie hat drei Formen. Die semanti- sche Konsistenz wurde bereits im Rahmen der Beschreibungslogiken erwähnt (im Abschnitt 3.2.4). Sie beschreibt die Korrektheit der Ontologie bezüglich logischer Schlussfolgerungen. Das Beispiel aus diesem Abschnitt beschreibt die syntaktische Konsistenz. Sie stellt sicher, dass die Ontologie konform zur abstrakten und konkreten Syntax der verwendeten Beschreibungssprache ist. Die dritte Form der Konsistenz ist die natürliche Bedeutung der Konzepte der Ontologie [SMMS02, S. 289]. Diese sollen, unter Berücksichtigung des gesunden Menschenverstandes, sinnvoll sein. So wäre Computer als Unterklasse von Mitarbeiter bezüglich syntaktischer und semantischer Konsistenz korrekt, jedoch nicht sehr sinnvoll. Die natürliche Bedeutung kann durch eine ausführliche Beschreibung der Konzepte explizit in der Ontologie dargestellt werden. Würde man die zwei Konzepte des Beispiels den disjunkten Superklassen Technisches Gerät bzw. Person zuweisen, ist die semantische Inkonsistenz offensichtlich. Die natürliche Bedeutung lässt sich also idealerweise auf die semantische Inkonsistenz reduzieren und wird deshalb in dieser Arbeit nicht weiter betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Ontologie-Evolutionsprozess aus [SMMS02]

Noy et al. haben festgestellt, dass die Ontologie-Evolution vergleichbar mit der DatenbankSchema-Evolution ist [NK04]. Jedoch gibt es bedeutende Unterschiede zwischen beiden Ansätzen, die näher erläutert werden sollen. Ein Datenbankschema stellt nur die Struktur der Datenbank dar. Eine Ontologien hingegen enthält Struktur und Daten. Änderungen der Ontologie umfassen also gegebenenfalls auch die in der Ontologie gespeicherten Daten. Weiterhin definieren die Konzepte und Beziehungen in der Ontologie eine explizite Semantik, die bei Änderungen berücksichtigt werden muss. Darüber hinaus greifen viele unabhängige Institutionen, wie private Benutzer und Unternehmen, direkt auf die Ontologien zu. Andere Ontologien verwenden Teile der Ontologie wieder und Anwendungen greifen auf den Datenbestand zu. Somit müssen alle Änderungen an alle abhängigen Ontologien und Programme weitervermittelt werden. Auf Datenbanken wird hingegen meist über eine Zugriffsschicht zugegriffen, die sich unter der Kontrolle des Eigentümers der Datenbank befindet. Aufgrund dieser Indirektion können Änderungen an der Datenbank vorgenommen werden ohne dass notwendigerweise die Programme, die auf die Datenbank zugreifen, ebenfalls geändert werden müssen [NK04, S. 432]. Ontologien und Datenbankschemata unterscheiden sich weiterhin in der Wissensrepräsentation. Ontologien haben eine größere Ausdrucksstärke als Datenbankschemata. So ist es beispielsweise möglich, mit Ontologien die Kardinalität von Beziehungen zu definieren. Dies ist über die reine Schema-Definition einer Datenbank nicht möglich. Außerdem gibt es in Ontologien keine klare Trennung zwischen der Struktur und den Daten. Das heißt, dass Individuen von Klassen wiederum Klassen sein können. Daraus folgt, dass Ontologien und damit die darauf ausgeführten Änderungsoperationen wesentlich komplexer sind als Datenbankschemata. Die Betrachtung dieser Unterschiede macht deutlich, dass zwar Erkenntnisse der Schema-Evolution in begrenztem Rahmen auf Ontologien übertragen werden können, jedoch die Besonderheiten von Ontologien berücksichtigt werden müssen.

Eine besondere Erwähnung gilt an dieser Stelle der Beziehung zwischen Evolution und Versionierung. Wie in Abbildung 3.6 gezeigt, werden bezüglich der Weiterentwicklung von Datenbankschemata Evolution und Versionierung als zwei getrennte Aktivitäten verstanden. In der Evolution wird das Datenbankschema weiterentwickelt und es soll sichergestellt werden, dass auf Datenbestände des alten Schemas auch über das neue Schema zugegriffen werden kann. Die Versionierung beschäftigt sich hingegen mit der Frage, wie Datenbestände unterschiedlicher Versionen über Schemata anderer Versionen verfügbar sind. Im Unterschied dazu sind in

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6: Ontologie-Evolution vs. Ontologie-Versionierung nach [NK04]

Ontologien die Struktur und die Daten nicht getrennt, weshalb Evolution und Versionierung als eine gemeinsame Aktivität betrachtet werden müssen [NK04, S. 433]. Ontologien unterstützen diesbezüglich ein Versionierungskonzept. Das bedeutet, dass einer Ontologie eine eindeutige Versionsnummer zugewiesen werden kann. So können mehrere Versionen derselben Ontologie gleichzeitig existieren.

3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring

Die Änderungsoperationen der Ontologie-Evolution stellen Umstrukturierungen der Ontologie dar. Deshalb soll hier die Beziehung zum Refactoring betrachtet werden. Ontologie-Refactorings unterscheiden sich grundsätzlich von Refactorings, wie sie aus der objektorientierten Programmierung bekannt sind. Wie in Kapitel 2.2 behandelt, werden bei einem Refactoring Änderungen am Programmcode vorgenommen, wobei die Semantik des Programms erhalten bleiben soll. Die Semantik ergibt sich in diesem Zusammenhang aus dem Verhalten des Programms. Eine Ontologie repräsentiert stattdessen Daten und deren Struktur. Die Semantik einer Ontologie hat damit eine statische Beschaffenheit und ist mit der Ausführungssemantik eines Programms nicht vergleichbar. Bei der Umstrukturierung einer Ontologie liegt das Augenmerk also auf der Erhaltung der syntaktischen und semantischen Konsistenz, wie sie im Abschnitt 3.3 definiert werden. Noy et al. beschreiben die Konsistenz einer Ontologie mit so genannten Verträglichkeitsdimensionen noch detaillierter [NK04, S. 434]. Sie führen dabei das Konzept der Erhaltung der Individuen ein, das die Auswirkungen einer Änderung auf den Datenbestand der Ontologie beschreibt. Für jede Änderung muss also nicht nur die Erhaltung der syntaktischen und semantischen Konsistenz geprüft werden, sondern auch, ob die bestehenden Individuen und deren Beziehungen noch konsistent zur Struktur der Ontologie sind. Noy et al. gehen davon aus, dass eine automatische Einteilung der Änderungsoperationen entsprechend ihrer Konsistenzerhaltung nicht möglich ist [NK04, S. 435].

Der Unterschied zwischen Refactorings von objektorientierten Programmen und Refactorings von Ontologien wird besonders deutlich, wenn das Prinzip der zwei Hüte von Kent Beck betrachtet wird [FBB+99]. Beck sagt, dass das Programmieren aus zwei klar voneinander getrennten Aktivitäten besteht. Die eine Aktivität besteht darin, Tests und Produktionscode zu schreiben, um dem Programm neue Funktionalitäten hinzuzufügen. Die andere Aktivität besteht in der Umstrukturierung des vorhandenen Programms ohne die Semantik (die Funk- tionalität) zu ändern. Der Programmierer setzt sich also im übertragenen Sinne entweder den einen oder den anderen Hut auf und arbeitet immer an nur genau einer dieser beiden Aufgaben. Bei Ontologien ist diese Unterscheidung jedoch nicht immer sinnvoll. Es gibt nur wenige Änderungen einer Ontologie, welche die Semantik einer Ontologie erhalten. Dazu gehören die Umbenennung von Konzepten, das Austauschen semantisch äquivalenter Konzepte oder die Verwendung von unterschiedlichen Schreibweisen für dasselbe Konzept. Im Unterschied zum Refactoring aus der objektorientierten Programmierung zielen also Umstrukturierungen aus der Ontologie-Evolution darauf ab, die Semantik bewusst zu verändern und dabei die Konsistenz zu erhalten.

Ein Vergleich von Ontologien und objektorientierten Programmen lässt weiterhin erkennen, dass Ontologien keine Interfaces haben, die interne Strukturen verbergen. Das Prinzip der Datenkapselung nach David Parnas ist eines der wichtigsten Prinzipien der objektorientierten Programmierung [Par76]. Es erlaubt, die interne Implementierung eines Programms zu ändern, während die Schnittstelle und das Verhalten nach außen gleich bleibt. Ontologien verfolgen hingegen das Prinzip, dass alle Strukturen nach außen sichtbar sein sollen. Ändert man Teile der Ontologie, hat das also zwangsläufig auch Auswirkungen auf deren äußere Erscheinung.

Diese Betrachtungen decken nur einen kleinen Teil aller Unterschiede zwischen OntologieEvolution und Refactorings ab. Lediglich erwähnt werden sollen an dieser Stelle die strukturellen Unterschiede zwischen den Konzepten einer Ontologie und den Konzepten der objektorientierten Programmierung. Konzepte wie die Annahme nicht-eindeutiger Namen, die Offene-WeltAnnahme, anonyme Klassen und globale Propertys sind Eigenheiten von Ontologien, die in objektorientierten Ansätzen nicht zu finden sind.

3.5 Zukünftige Entwicklungen - Linked Data

Bizer, Heath und Berners-Lee haben 2009 einen Artikel veröffentlicht, in dem sie den aktuellen Stand semantischer Techniken begutachten und einen Ausblick auf mögliche zukünftige Entwicklungen geben [BHBL09]. Bizer et al. heben insbesondere die Relevanz der Vernetzung von unstrukturierten, global verteilten Daten hervor. Diese soll einen freien Zugriff auf alle im Web verfügbaren Informationen ermöglichen. Dieser Ansatz wird mit dem Begriff Linked Data beschrieben. Linked Data folgt vier einfachen Regeln.

- „ Use URIs as names for things
- Use HTTP URIs so that people can look up those names.
- When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL)
- Include links to other URIs, so that they can discover more things. “ [BL06].

Die Vision von Linked Data ist, dass alle Daten der Welt über frei verfügbare Ontologien klassifiziert werden können. Dies hätte eine wesentliche Vereinfachung der Kommunikation über das Web zur Folge, da vorhandene Klassifikationen wiederverwendet werden können und somit eine einheitliche Begriffswelt für alle Beteiligten existiert. Bevor diese Vision wahr werden kann, müssen zuerst entsprechende Ontologien erstellt werden, die für eine einheitliche Klassifikation geeignet sind. Besonders erwähnenswert ist in diesem Zusammenhang das Projekt Linking Open Data ¹⁵ (LOD), dessen Ziel es ist, im Web frei verfügbare Daten zu finden, in RDF-Tripel zu übersetzen und nach den Prinzipen von Linked Data der Öffentlichkeit zur Verfügung zu

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.7: Ausschnitt aus dem Linking Open Data Cloud Diagram [CJ10]

stellen. Der aktuelle Stand dieses Projekts wird im Linking Open Data Cloud Diagram grafisch dargestellt. Abbildung 3.7 zeigt einen Ausschnitt dieses Diagramms. Jeder Kreis repräsentiert eine Ontologie, wobei die Größe der Kreise in etwa zur Anzahl der Konzepte korreliert, die in der Ontologie definiert sind. Die Pfeile verdeutlichen Referenzen zwischen den Ontologien.

Das Semantic Web Journal ¹⁶, dessen erste Ausgabe im Dezember 2010 erschienen ist, enthält darüber hinaus die neusten wissenschaftlichen Erkenntnisse aus dem Bereich Semantic Web.

3.6 Zusammenfassung

Dieses Kapitel gab einen Überblick über die Konzepte, welche dieser Arbeit zugrunde liegen. In der MDSD dienen Metamodelle dazu, die Struktur von Softwaresystemen zu beschreiben und die Möglichkeiten der Codegenerierung zu nutzen. Refactorings strukturieren Programmcode so um, dass dessen Struktur verbessert wird, jedoch das Verhalten des Programms unverändert bleibt. In Ontologien können Daten und deren Struktur gespeichert werden. Sie bilden die Grundlage des Semantic Web. Ontologien lassen sich darüber hinaus zur Darstellung von Softwaresystemen ähnlich den Metamodellen der MDSD einsetzten. In der Ontologie-Evolution werden Ontologien mit Änderungsoperationen, die den Refactorings ähnlich sind, weiterentwickelt. Dies ebnet den Weg, um Ontologien zum Design von Softwaresystemen einzusetzen, wobei diese jederzeit an sich ändernde Bedingungen angepasst werden können.

[...]

---

¹ http://www.most-project.eu

¹ http://www.omg.org/

² http://www.eclipse.org/modeling/emf/

³ Aktualisierungen und Erweiterungen dieses Katalogs können unter http://www.refactoring.com/ abgerufen werden.

¹ http://www.w3.org

² Die Abkürzung ist tatsächlich OWL und nicht WOL, da die Aussprache von OWL klar ist, und zwar wie beim englischen Wort für Eule: /a l/. [HKRS08, S. 125]

³ http://www.w3.org/2007/OWL/

⁴ Verglichen mit der MDSD legt eine Beschreibungslogik die Elemente der abstrakten Syntax der OntologieBeschreibungssprache fest.

⁵ Für weitere Informationen über Reasoner sei auf den Artikel [DCtTdK11] von Dentler et al. verwiesen.

⁶ Für detaillierte Informationen zu Beschreibungslogiken sei auf die Website http://www.cs.man.ac.uk/ ~ezolin/dl/ und auf die Arbeiten von Franz Baader et al. verwiesen [BHS05, BCM+10].

⁷ In Beschreibungslogiken spricht man von Concepts anstelle der Klassen und von Roles anstelle der Propertys.

⁸ http://www.ihtsdo.org/snomed-ct/

⁹ http://www.geneontology.org/

¹⁰ http://www.biopax.org/

¹¹ http://sweet.jpl.nasa.gov/

¹² http://dublincore.org/

¹³ http://www.foaf-project.org/

¹⁴ http://dbpedia.org/

¹⁵ http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData

¹⁶ http://semantic-web-journal.net/