TP4: Ontologische Infrastruktur


Dieses Teilprojekt umfasst den Aufbau einer Infrastruktur zur Definition, Implementierung und Einsatz von Ontologien in der automatischen Generierung von semantischen Webseiten und in der Analyse und Abhandlung von Benutzeranfragen. Die wichtigsten Themen dabei betreffen Fragen der Repräsentation (Wissensrepräsentationssprache), des Inhaltes ("top-level, domain, task/system"), des Zugriffes (Inferenzen, Datenbanken, "mapping") und der Wartung ("integration, extension").

Motivation

Ontologien ermöglichen eine Formalisierung von Konzepten, die von einer breiten Nutzerbasis verstanden und akzeptiert werden. Somit bilden sie die Grundlage für den Dialog mit dem Benutzer wie auch die flexible Kommunikation zwischen Anwendungen aus verschiedensten Bereichen. Aus praktischer Sicht ist eine Ontologieinfrastruktur unerlässlich. Diese Schicht bietet etliche Basisdienste wie strukturelle Anfrage an die Ontologie oder Inferenzfunktionalität.

Obige Sektion zeigt den durch Ontologien erreichten Mehrwert deutlich auf. Es stellt sich somit die Frage, welche Anforderungen sich durch die Verwendung dieses Paradigmas ergeben.

Anforderungen

A. Ontologie- und Regelsprache definieren: Zunächst muss geklärt werden, welche Sprachen zum Daten- und Wissensaustausch im System zur Anwendung kommen sollen. Dazu betrachten wir zunächst den Status der Standardisierungsbemühungen von Ontologiesprachen am World Wide Web Consortium (W3C). Die in Abbildung 4.1 dargestellte Schichtenarchitektur des Semantischen Webs sieht fünf wesentliche Ebenen vor: Daten, Ontologien, Logik, Beweis und Vertrauen. Mit dem Resource Description Framework (RDF) und der Ontology Web Language (OWL) sind seit dem 10.2.2004 die beiden unteren Schichten zu offiziellen W3C Standards erkoren worden. Um die Nachhaltigkeit und Weiterverwendbarkeit von SmartWeb zu gewährleisten, muss das Projekt auf diese beiden Fundamente gebaut werden. Es ist allgemein bekannt, dass die Ausdrucksstärke von OWL beschränkt ist. Dies manifestiert sich offensichtlich in der Tatsache, dass die Logikschicht über der Ontologieschicht angesiedelt ist. Somit ist zu untersuchen, wie diese beiden Schichten geschickt zusammenspielen können und welche Art von Regelsprache zum Einsatz kommen soll.

Abbildung 4.1: Schichtenarchitektur des Semantischen Webs
Abbildung 4.1: Schichtenarchitektur des Semantischen Webs


B. Regeln und Ontologien erstellen & verwalten: Neben der Definition der zu verwendenden Sprachen ist zu klären, welche Methoden bei der Erstellung der Ontologien und Regelbasen zum Einsatz kommen sollen. Hierbei stellt sich die Frage, wie automatische und semiautomatische Werkzeuge mit herkömmlichen Editoren zusammenspielen. Schließlich muss gewährleistet sein, dass die Ontologien und Regelbasen innerhalb des Projektes verwaltet werden, um allen Projektpartnern den Zugriff zu ermöglichen.

C. Inferenzen auf und Anfragen von Ontologien: Die Verwendung von Ontologien steht an zentraler Stelle in diesem Projekt, da etliche Komponenten anderer Arbeitspakete auf die Infrastruktur zugreifen müssen. Grob sind hierbei zwei Fälle zu unterscheiden. Zum einen kann die Struktur der Ontologie an sich abgefragt werden. Diese Funktionalität nimmt beispielsweise bei der Sprachverarbeitung eine zentrale Rolle ein. Hierbei ist zu beachten, dass auch derartige Strukturfragen Inferenzfähigkeiten voraussetzen. Der zweite Anwendungsfall bezieht sich auf Fakten, die in der Wissensbasis abgelegt sind. Abfragen an die Wissensbasis ziehen hierbei eine Reihe von logischen Verkettungen nach sich, die sowohl durch die Ontologie als auch durch gespeicherte Regelbasen definiert sind.

Abbildung 4.2: Architektur des Arbeitspakets Ontologieinfrastruktur
Abbildung 4.2: Architektur des Arbeitspakets "Ontologieinfrastruktur"


D. Ontologien integrieren: Weiterhin muss eine Möglichkeit erarbeitet werden, Transformationen zwischen den erstellten und bestehenden Ontologien zu ermöglichen. Dies ist in jedem heterogenen Szenario, welches sich aus vielen verschiedenen Daten- und Wissensquelle zusammensetzt, unerlässlich. Ein Szenario, in dem mit einer einzigen zentralen Ontologie gearbeitet wird, ist in dem Beispielkontext der WM 2006 unrealistisch. Es wird immer eine Vielzahl von Anbietern geben, die sich auf unterschiedliche Ontologien beziehen.

Architektur

Das Schaubild 4.2 gibt einen Überblick der geplanten Architektur des Arbeitspakets "Ontologieinfrastruktur". Wir erläutern im folgenden Text die einzelnen Komponenten und beziehen uns hierbei darauf, wie diese den im vorigen Abschnitt definierten Anforderungen genügen. Der Architektur unterteilt sich in zwei wesentliche Bereiche: "Laufzeit" und "Entwurf". Die rechte Seite deckt den Entwurf von Ontologien mit Editoren, verschiedenen Ontologielernverfahren und der Ontologieverwaltung ab. Links sind die Laufzeitaspekte durch verschiedene Inferenzmaschinen und Datenbanken gezeigt. Diese Zweiteilung reflektiert sich auch in der oben angedeuteten geteilten Schnittstelle zu anderen Komponenten, welche die unter Punkt C genannten Anwendungsfälle widerspiegeln.

OWL + Xtriple

Die erste Anforderung zeigt sich in der unterschiedlichen Verwendung der Sprachen. Die Ontologiesprache OWL hat ihre Stärken eindeutig in der Modellierung, weswegen sie auf der rechten Seite auftaucht. Es gibt allerdings kaum Systeme, die effizient mit OWL-Instanzen rechnen können. Die erste Aufgabe muss demnach sein, Ontologie- und Regelsprache in der Laufzeitumgebung zu vereinigen. Dies ist durch die Übersetzungskomponente in der Mitte verdeutlicht. Die Projektpartner leisteten bereits erhebliche Vorarbeit bezüglich der zu verwendenden Regelsprache. Hierbei besteht innerhalb des Konsortiums der Konsens, die F-Logik-basierte Sprache Triple einzusetzen und entsprechend zu erweitern.

Architektur zum Erstellen und Verwalten von Ontologien und Regelbasen

SmartWeb legt ein sehr heterogenes Szenario zugrunde. Weiterhin impliziert die Verwendung von offenen, Internet-basierten Sprachen, dass eine Standardisierung der zu verwendenden Werkzeuge nicht sinnvoll ist. Stattdessen wird die Interoperabilität durch die Ontologie- und durch die Regelsprache gewährleistet, die durch die verschiedenen Editoren unterstützt werden. Abbildung 4.2 zeigt weiterhin, dass Lernverfahren automatisch Ontologien erstellen, die danach manuell mit Editoren verfeinert werden können. Ähnlich verhält es sich mit Methoden zur Definition von Abbildungen zwischen Ontologien.

Inferenzarchitektur

Wie bereits anfangs erwähnt, sind beim Zugriff externen Komponenten über die API zwei Modi denkbar. Dies sind zum einen strukturelle Anfragen an die Ontologien sowie Inferenzen über die Instanzen. Beide Zugriffsarten müssen durch die Inferenzkomponente unterstützt werden. Bei dem Zugriff auf Instanzen sind folgende Kriterien zu beachten: Zum einen ist es auf Grund des weitreichenden Szenarios WM-2006 zwingend erforderlich, dass die Infrastruktur extrem skalierbar ist. Weiterhin muss erwartet werden, dass eine Vielzahl von Daten und Informationen in relationalen Datenbanken vorliegen wird. Es ist hierbei auch durchaus denkbar, dass Teile der Berechnungen direkt in der Datenbank bearbeitet werden um auf die dort implementierten Optimierung zurückgreifen zu können. Eine weitere wichtige Komponente ist die Rankingkomponente. Deren Aufgabe ist eine sinnvolle Bewertung von Anfrageergebnissen, die mit Hilfe von Hintergrundwissen über zuvor gestellte Anfragen erstellt wird.

Architektur zur Ontologieintegration

Anforderung D wird durch Komponenten in der Entwurfs- und Laufzeitseite abgedeckt. Die mit Hilfe von Editoren definierten Abbildungen von Ontologien müssen natürlich durch die entsprechende Laufzeitumgebung durchgeführt werden. Hierbei ist eine Repräsentation durch Regeln vorstellbar, um Abbildungen optimal mit der Maschinerie für Ontologien und Regeln zu verknüpfen.



© Webmaster
Last modified: Thu Mar 3 13:39:37 CET