Entwicklungsmethodik, Ontologieentwurf und

Entwicklungsmethodik, Ontologieentwurf und Wissensrepräsentation
für ein domänen-unabhängiges Recherchewerkzeug unter
Einbeziehung der Semantik von Recherchekontexten
Sachbericht
zu den Arbeiten des Projektpartners
Hochschule für Technik und Wirtschaft Dresden (FH)
H. Fritzsche, A. Kischkel, E. Lofing
18. Juli 2008
In dem vorliegenden Sachbericht werden die Teilleistungen der HTW Dresden (FH) als
beteiligte Forschungseinrichtung im Kooperationsprojekt „Domänen-unabhängiges
Recherchewerkzeug“ (Kurztitel) abgerechnet. Das Kooperationsprojekt wurde vom BMWi im
Programm PRO INNO II unter dem Förderkennzeichen KF 0435101SS6 im Zeitraum 1. März
2007 - 14. März 2008 gefördert.
Inhalt
1
2
3
Aufgabenstellung ............................................................................................................... 2
Abrechnung der Arbeitspakete........................................................................................... 2
Darstellung der erreichten Ergebnisse................................................................................ 4
3.1
Technologie (Entwicklungsmethodik, Wissensrepräsentation, Ontologieentwurf)... 4
3.2
Werkzeuge.................................................................................................................. 9
4
Verwertung der Ergebnisse .............................................................................................. 12
5
Einschätzung der Marktaussichten................................................................................... 12
6
Gemeinsame zukünftige Verwertung............................................................................... 12
7
Fortschreibung des Konzepts der Erfolgskontrolle .......................................................... 12
Literaturverzeichnis.................................................................................................................. 13
1
1 Aufgabenstellung
Recherchesysteme sind heute unverzichtbare Werkzeuge zum Auffinden von Informationen
in großen und heterogenen Datenbeständen (in Form von Dokumentensammlungen). Solche
Systeme orientieren nicht wie Content Management Systeme auf eine spezifische Verwaltung
und Archivierung von Datenbeständen, sondern nutzen bereits existierende Datenbestände
unterschiedlichster Art als Quellen. Das Vorhaben zielt auf die Schaffung eines
Prototypsystems einer Klasse von Recherchewerkzeugen, die es bisher am Markt nicht gibt
und die aus Recherchevorgängen selbst Informationen gewinnen, mit denen Anwender in
qualitativ neuer Weise in ihrer Arbeit unterstützt werden können.
Die von der HTW Dresden (FH) zu leistenden Arbeiten stehen in engem Zusammenhang mit
den vom Projektpartner Interface Projects GmbH im Kooperationsprojekt durchzuführenden
Entwicklungsarbeiten. Grundlage bildet das Recherchewerkzeug inter:gator der Interface
Projects GmbH. Das Werkzeug ist als Client-Server-Applikation realisiert. Der Client besitzt
ein Web-Portal. Metainformationen über indizierte bzw. recherchierte Dokumente werden
über eine zu definierende Schnittstelle des inter:gator-Clients aus einem Repository für die
Erstellung von Kontext-Modellen zugänglich gemacht und sind semantisch auszuwerten. Zu
unterschiedlichen Zeitpunkten erhaltene Metainformationen sind in einem dynamischen
Kontext-Modell zu speichern. Das Navigieren in „gespeicherten Zusammenhängen“ soll
unterstützt werden. Zur Unterstützung der Beschreibung und Verarbeitung von
Recherchekontexten ist ein Formalismus (Wissensrepräsentation) zu entwickeln und zu
definieren, der auch die Möglichkeit zur Speicherung und Nutzung von Ontologien
einschließt. Durch die Nutzung von semantischen Kontext-Modellen (Kontextsemantik) und
Ontologien sollen Recherchen mit der Client-Software qualifizierter als bisher realisiert
werden können. Ontologien sind für Fallbeispiele zu entwerfen. Erfahrungen von P. Schnupp
mit dem von ihm entwickelten Omni-Composer/Omni-Manager sollen für die Erstellung von
Kontextsemantiken einfließen und werden über Aufträge realisiert. Gewonnene
Kontextinformationen sollen dynamisch, d.h. zur Laufzeit in die Metadatenbasis des
inter:gator-Systems integriert und im Rechercheprozess nutzbar gemacht werden können.
2 Abrechnung der Arbeitspakete
Es wurden folgende Arbeitspakete (AP) gemäß Projektantrag bearbeitet und termingerecht
(einschließlich kostenneutraler Verlängerung) abgeschlossen:
1.
2.
3.
4.
5.
Entwicklungsvorbereitung und Erstellung eines detaillierten Pflichtenheftes
Wissenschaftliche Untersetzung der Beschreibungsmethodik
Theoretische Analyse zu abstrakten Kontextsemantiken
Entwurf einer Ontologie
Unterstützung bei der Entwicklung von Funktionalitäten spezieller Komponenten der
Systemarchitektur
6. Wissenschaftliche Auswertung der Testverfahren, Unterstützung bei der Optimierung
Im AP 1 wurde neben einer fachlichen Analyse des aktuellen Arbeitsstandes auf dem Gebiet
des Information Retrieval (IR) insbesondere gemeinsam mit der Interface Projects GmbH die
Schnittstellenproblematik des Systems inter:gator untersucht. Die Projektmitarbeiter der
HTW Dresden wurden mit der inter:gator-Problematik vor Ort vertraut gemacht. Detaillierte
und mit den Arbeitspaketen des Projektpartners abgestimmte Zielstellungen wurden in einem
Pflichtenheft erfasst und konkrete Arbeitsschritte für die Mitarbeiter abgeleitet [FKL07].
2
Diese Vorgehensweise entsprach Empfehlungen der modernen Softwaretechnologie [Som07].
Das AP wurde bis zum 20.04.2007 abgeschlossen.
Die Beschreibung von Metadaten und Recherchekontexten muss auf dynamischen
Datenstrukturen aufbauen, da sich Objektmengen und Zusammenhänge im Laufe von
Recherchen mit der Zeit verändern. Im AP 2 wurde deshalb als eines der wesentlichen
Arbeitsergebnisse ein Formalismus zur Wissensrepräsentation als Beschreibungsmittel für
Kontext-Modelle und Ontologien definiert (die Nachnutzung der in einzelnen existierenden
Entwicklungsumgebungen angebotenen Beschreibungsmittel erwies sich als zu unflexibel).
Ein solcher Formalismus ist eine formale Sprache, wobei auch Programme zu deren
Interpretation einbezogen sind. Es wurde eine Horn-Klausel-Repräsentation unter
Zugrungelegung der Syntax einer Listennotation entsprechend der Programmiersprache
Scheme [Dyb87] festgelegt. Ein vom Projektleiter früher entwickelter Scheme-Interpreter
wurde im Rahmen des Kooperationsprojektes angepasst und verfügbar gemacht [FL08].
Damit ist eine hohe Variabilität bzgl. der Horn-Klauselverarbeitung geschaffen worden und es
gibt es keinerlei Lizenzprobleme. Weitere Angaben zur Wissensrepräsentation sind im
Abschnitt 3.1 enthalten. Das AP 2 wurde bis Ende 06/2007 abgeschlossen.
Im AP 3 wurde untersucht, was Recherchekontexte sind und wie sie zu beschreiben sind.
Vom inter:gator-Client wird auf Anforderung ein inter:gator-Modell aufgebaut und
exportiert. Die in diesem extern mittels RDF repräsentierten Modell enthaltenen
Metainformationen wurden klassifiziert. Eine Eigennamenerkennung ist integriert. Aus
Beispielen konnten Erkenntnisse über praktisch vorkommende Inhalte und Metadaten
gewonnen werden. Davon ausgehend wurden typische Prädikate definiert (z.B. Person,
Vertrag etc.). Allgemeingültige Beziehungsinformationen (Klasse-Instanz-Beziehung,
Generalisierungs-Spezialisierungs-Beziehungen, Teil-Ganzes-Beziehungen, vgl.
Projektantrag) wurden mit Klauseln (Regeln) beschrieben. Das AP 3 wurde teilweise
überlappend mit AP 2 bis Ende 09/2007 bearbeitet und erforderte einen intensiven Austausch
mit dem Kooperationspartner.
Im AP 4 wurden beispielhaft Ontologien unter Nutzung des in AP 2 beschriebenen
Formalismus erstellt. Dabei handelte es sich um Lösungen zu den Anwendungsgebieten
Projektmanagement Geschäftsprozesse im Dekanat einer Hochschule. Das Fallbeispiel
„Wissen von Sachverständigen für Softwaretechnik“ wurde überwiegend der Interface
Projects GmbH zugeordnet. Die Arbeiten wurden bis 11/2007 durchgeführt, wurden aber auch
später im Rahmen der anderen Arbeitspakete noch inhaltlich aktualisiert.
Im AP 5 wurden benötigte Werkzeuge entwickelt und beschrieben. Dabei wurden an der
HTW Dresden bereits geleistete Vorarbeiten fortgesetzt. Das Programmiersystem JamusScheme, das im Kontext des Projektes als Implementierungsbasis für die Programme zur
Interpretation von Kontext-Modellen verwendet wird, wurde erweitert und dokumentiert
[FL08]. Es wurde ein Horn-Klausel-Interpreter in Jamus-Scheme entwickelt. Durch die
Eigenentwicklung wurde es möglich, unterschiedliche Interpretationsstrategien (vorwärts
verkettend, rückwärts verkettend) zu realisieren. Auf der definierten formalen Sprache
aufbauend wurde als wichtigstes Ergebnis ein Klassifikator für Dokumente entwickelt. Alle
entwickelten Werkzeuge wurden in einer Programmdokumentation beschrieben [LF08]. Die
Werkzeugentwicklung erfolgte parallel zu den Arbeitspaketen 2, 3 und 4 und wurde 11/2007
wesentlich abgeschlossen. Im AP 6 ergaben sich Korrekturen und Erweiterungen im Verlaufe
der Testung.
Im AP 6 wurden Beispiele von Kontext-Modellen erprobt (getestet). Dabei wurden Szenarien
für das Navigieren in Kontext-Modellen entwickelt. Durch die Nutzung der entwickelten
Werkzeuge konnten implizit bekannte Sachverhalte explizit dargestellt und
Schlussfolgerungen gezogen werden. An diesem AP 6 wurde bis Projektende 02/2008
3
(einschließlich kostenneutraler Verlängerung) gearbeitet. Die Zielstellung wurde erfüllt. es
wurden weiterführende Ziele abgesteckt. Diese betreffen insbesondere die Einbindung von
Metainformationen über Recherchekontexte in die Funktion von inter:gator-Clients.
3 Darstellung der erreichten Ergebnisse
Nachfolgend wird zunächst die im Projekt erarbeitete und umgesetzte Technologie für den
Umgang mit Kontextinformationen und Metadaten erläutert. Im Anschluss daran werden die
verwendeten und im Rahmen des Projekts entwickelten und erprobten Werkzeuge
beschrieben.
3.1 Technologie (Entwicklungsmethodik, Wissensrepräsentation,
Ontologieentwurf)
Durch die Interface Projects GmbH wurde im Rahmen des geförderten Kooperationsprojektes
u.a. ein neuer Typ von inter:gator-Client entwickelt. Instanzen dieses Typs können mit
einem inter:gator-Server kommunizien. Der Client kann über ein Web-Portal genutzt
werden:
Die an der HTW Dresden prototypisch entwickelte Software bildet zunächst eine
eigenständige Applikation, kann aber aufgrund der einheitlich für die Implementierung als
Basis benutzten Programmiersprache Java [G+05] später in den inter:gator-Client integriert
werden (Plug-in-Technologie). Die an der HTW Dresden entwickelte Software kann
4
grundsätzlich mit der inter:gator-Client-Software über eine von dieser bereitgestellten
Schnittstelle (API) zusammenarbeiten. Zur Realisierung der Speicherung von Metadaten wird
im inter:gator-Client das Jena-Framework eingesetzt [Jena]. Das Framework implementiert
RDF sowie DAML+OIL.
Das Ziel von Recherchen mit einem Retrieval-System wie dem inter:gator ist das gezielte
Auffinden von Dokumenten in großen Dokumentbeständen. Nachdem ein Dateisystem –
dieses repräsentiert einen Dokumentenbestand - vom inter:gator-Server indiziert wurde, kann
der inter:gator-Client über seine Admin-Konsole unter Bezugnahme auf einen serverseitig
verwalteten Index ein inter:gator-Modell in externer Repräsentation in Form einer RDF-Datei
[RDFW3C, RDF06] erzeugen (intergator-model.rdf).
Das inter:gator-Modell ist der Ausgangspunkt für die Erfassung und Verarbeitung von
Textinhalten und Metadaten durch die an der HTW entwickelten Werkzeuge. In inter:gatorModellen werden u.a. Namensräume unterschieden. Innerhalb eines intergator-Modells sind
Beschreibungen einzelner Dokumente strukturell abgegrenzt. Typische Metadaten zu einem
Dokument sind Dateiname, Dateiextension, der im Ergebnis von Recherchen gelieferte
Quellpfad zur Dokumentquelle (URI), der Autor sowie im Dokument enthaltene Phrasen und
Schlüsselworte.
Auf der Grundlage des in AP 2 definierten Formalismus wird eine Wissensbasis weitgehend
durch die ebenfalls im Projekt entwickelten Werkzeuge aus inter:gator-Modellen erstellt.
Entwicklungsmethodik
Unterschiedliche Möglichkeiten zur Verarbeitung von inter:gator-Modellen wurden
untersucht. Dazu wurden frei verfügbare Software-Werkzeuge erprobt. In einer das Projekt
begleitenden Diplomarbeit von Christian Gnüchtel wurden insbesondere auch frei verfügbare
Komponenten für die Analyse von textuellen Inhalten analysiert [Gnü08].
In die Arbeiten zur Entwicklungsmethodik flossen auch die von E. Wagner und P. Schnupp
erbrachten Leistungen ein [Ws07]. Der von P. Schnupp entwickelte Omni-Manager diente als
Referenzsystem und beeinflusste insbesondere die Arbeiten zu Kontext-Modellen und
Ontologien. Kontextinformation wird während einer Sitzung mit dem inter:gator-Client durch
Nutzereingaben (textuell bzw. ereignisgesteuert bei Betätigung interaktiver Elemente)
aufgebaut. Die Nutzung von Kontext-Modellen dient u.a. der Selektion (Ausblendung) für
Nutzer nicht relevanter Informationen. In Kontext-Modellen gespeicherte Informationen
können im Kontext von Anfragen wieder verwendet werden, müssen also nicht erneut
eingegeben werden.
Die wesentlichen Werkzeuge wurden in Prolog deklarativ programmiert, eine eigene
Wissensrepräsentationssprache wurde definiert und ein flexibler und erweiterbarer Interpreter
in Jamus-Scheme programmiert. Da Jamus-Scheme selbst in Java implementiert ist und auch
eine Schnittstelle (API) zu Java besitzt, kann der gesamte Wissensrepräsentationsformalismus
von Java-Applikationen genutzt werden. Andererseits können auf der Basis von Java
Erweiterungen vorgenommen werden, so z.B. die Verbindung zu Persistenz-Frameworks
(Hibernate) oder die Anbindung an Datenbanksysteme wie etwa MySQL. Durch die
Verwendung von Scheme können wegen der Eigenschaften dieser Sprache (z.B. Funktionen
als Objekte erster Ordnung, lexikale Bindung) Objektstrukturen als Basis von
Wissensstrukturen dienen. Eine entsprechende „hybride“ Softwareentwicklungsumgebung ist
von H. Fritzsche implementiert und beschrieben worden [Fri94].
Zu Testzwecken wurde während der Entwicklung der Programmkomponenten die frei
verfügbare Entwicklungsumgebung SWI-Prolog eingesetzt [Wie03]. Dieses System erfordert
für die Notation der Prolog-Programme eine spezielle Syntax und stellt eine Vielzahl
5
nutzbarer Prädikate bereit. Genutzt wird u.a. auch die Fähigkeit dieses Prolog-Systems,
Wissensstrukturen in einer dynamischen Clause-Datenbank zu speichern.
In Kontext-Modellen kann mittels Prolog-Anfragen recherchiert werden. Ergebnisse von
Anfragen können leicht wiederum in Klauselform gespeichert werden.
Wissensrepräsentation
Der von uns verwendete Formalismus zur Wissensrepräsentation basiert auf der
Prädikatenlogik 1. Stufe (FOL) [KB07, Hod01]. Wissen wird in Form von Horn-Klauseln
dargestellt. Klauseln können Fakten, Regeln oder Anfragen sein. Die Prädikatenlogik ist gut
geeignet zur Darstellung von Fakten (Sachverhalten) und Inferenzregeln, wenn eine zur
Bildung von Ausdrücken geeignete Menge von Funktionen und Prädikaten bereitsteht.
Prädikate dienen der Darstellung von Relationen [Tan90].
In der externen Repräsentation von Horn-Klauseln wird von uns neben der von SWI-Prolog
unterstützten Notation parallel eine Listendarstellung verwendet. Die Syntax der
Listendarstellung entspricht der Scheme-Syntax [R3RS]. Da in Scheme (in Lisp allgemein)
syntaktisch kein Unterschied in der Repräsentation von Daten und Programmen existiert, lässt
sich der in Scheme implementierte Interpreter unmittelbar anwenden.
In der definierten Sprache sind folgende Arten von Bezeichnern verfügbar:
Konstantensymbole (als Symbole, Zahlen oder Strings in Scheme dargestellt),
Variablensymbole (als Scheme-Symbole dargestellt),
Prädikatsymbole und Funktionssymbole (mit klein geschriebenen Scheme-Symbolen
dargestellt).
Funktionssymbolen und Prädikatsymbolen sind jeweils eine Stelligkeit zugeordnet, die die
Anzahl der Argumente angibt.
Objekte eines Grundbereiches werden durch Terme bezeichnet.
term
→ konstantensymbol
|
variablensymbol
|
( funktionssymbol [ term ... ] )
prädikat → (prädikatsymbol [ term … ] )
Die Menge der logischen Symbole: { not, and, or}
atom
→ prädikat
literal
→ atom | ( not atom )
Eine Klauselmenge wird als Liste von Klauseln dargestellt.
Jede Klausel wird als Liste von Literalen dargestellt. Das 1. Element dieser Liste repräsentiert
ein nicht negiertes Literal, alle anderen Elemente repräsentieren negierte Literale. Negierte
Literale sind implizit and-verknüpft.
Ein Ziel (eine Anfrage) wird ebenfalls als Liste von Literalen notiert und soll nicht mit einem
Element einer Klauselliste verwechselt werden können.
Ein Beispiel zur Klauselinterpretation enthält der Abschnitt 3.2.
Ontologieentwurf
Grundsätzlich sind unterschiedliche Techniken zur internen) Speicherung von Ontologien als
dynamische Datenstrukturen realisierbar:
6
1. Bei der Ausführung übersetzter Java-Programme entstehen HS-intern Objekt-Strukturen,
die sich während der Laufzeit der Programme verändern (z.B. Erzeugung von Objekten,
Zustandsänderungen). Schnappschüsse von Objektstrukturen können durch Serialisierung
extern abgelegt, d.h. persistent gemacht werden. Objektstrukturen können durch
Deserialisierung wieder hergestellt werden. In diesem Sinne wären Klassen in einer
Ontologie durch Java-Klassen zu implementieren. Elemente der Ontologie wären als
Instanzen solcher Klassen realisiert. Beziehungen sind über Instanzvariablen („benutzt“Beziehung) zu modellieren.
Java-Programme können sich selbst untersuchen: Für Teile der Strukturen können
Graphen erzeugt werden, und diese können weiter verarbeitet werden.
2. Ein Quellprogramm (einer formalen Sprache) kann geparst werden, wobei ein
Syntaxbaum entsteht (Ebene M1). Dabei gibt es spezielle Klassen zur Repräsentation von
Baum-Knoten (abstrakte Syntax). Ein Syntaxbaum kann
-
transformiert werden (z.B. in Java-Bytecode)
-
„gerendert“ werden (Ausgabe Quelltext)
-
interpretiert werden, das bedeutet abgearbeitet (symbolisch!).
Syntaxbäume können als DOM-Bäume repräsentiert werden. In diesem Fall kann das
Parsen durch Xerxes erfolgen.
3. Es werden Symbole zur Realisierung von Kategoriebezeichnungen verwendet.
Eigenschaften werden mit Hilfe von Prädikaten (und Funktionen) beschrieben.
Im Projekt wurden die Ansätze 2 und 3 verfolgt. Ansatz 1 erschien nach Analyse zu
aufwändig.
Ontologien sind typischerweise branchenspezifisch, und sie beschreiben Sachverhalte aus
mehreren Modellebenen (M0 – M3) bzw. auch ebenenübergreifend [R3RS].
Ontologien werden nicht ausschließlich als Datenstrukturen betrachtet. Sie sind formale
Systeme und werden so auch genutzt. Anfragen und Inferenzen sind möglich. Mittels
Editoren automatisch durch vorwärts verkettende Inferenz-Strategien können Ontologien
erweitert werden.
Klassen werden mit Hilfe eines Klassifikator-Werkzeuges gebildet.
Beispiel 1: Ermittlung aller in einem inter:gator-Modell erfassten Vertäge, d.h. aller
Intanzen zur Klasse Vertrag. Es wird zu jedem Dokumentnamen eine
Gewichtsangabe bestimmt.
2 ?- load_test('RBC/intergator-model.rdf'), vertrag(X, Rank).
X =
docname(['file:/M:/work/Inter=Project/Test%20Ordner/Sortierte%20Dokumente/
Tutorial/Introduction.htm'])
Rank = 0.5
Yes
2 ?-
...
Das Prädikat load_test realisiert als Seiteneffekt das Parsen des inter:grator-Modells.
Im Prädikat vertrag/2 ist definiert, was ein Vertrag ist. Die Variable X wird an Namen
von Dokumenten gebunden, die die festgelegten Eigenschaften besitzen. Alle möglichen
7
Bindungen der Variablen X werden ausgegeben (eine sehr große Anzahl). Die benannten
Dokumente sind gemäß der in der Ontologie vorhandenen Beschreibung „Verträge“.
Beispiel 2: Die Namen aller Dokumente ermitteln, die Verträge sind, und die Namen der
Vertragspartner auflisten:
4 ?- load_test('RBC/intergator-model.rdf'),
vertrag(X, _),
metadata(X, _, _, _, persons(Persons), _, _).
X =
docname(['file:/M:/work/Inter=Project/Test%20Ordner/Sortierte%20Dokumente/
Tutorial/Introduction.htm'])
Persons = ['Engler, Hendrik', 'Naughton, Patrick', 'Joy, Bill',
'Andreesen, Marc']
Yes
5 ?-
...
Im Beispiel werden mögliche Bindungen der Variablen X an Dokumentnamen ausgegeben.
Dokumentnamen werden durch den Quellpfad des Dokuments dargestellt. Die im jeweiligen
Vertrag benannten Personen werden namentlich in einer Liste zusammengestellt.
Zum Aufbau von Ontologien wurden die Erfahrungen von P. Schnupp einbezogen.
Entsprechende Leistungen sind im Kooperationsprojekt vertraglich gebunden worden (FuEFremdleistung). Die folgende Abbildung zeigt einen Ausschnitt der grafischen Oberfläche des
von ihm entwickelten Omni-Managers.
Die in Beispiel 1 und Beispiel 2 verwendeten Beschreibungsmittel zeigen Individuen
(Instanzen) als Variablenwerte oder Konstanten, Prädikate stehen für Klassennamen. Auf den
Ebenen M1 – M2 werden Beziehungen ebenfalls durch Prädikate dargestellt. Im Prädikat
8
class( ′Vertrag′) ist die Klassenbezeichnung Instanz der Metaklasse ′class′.
Das Wechseln der Abstraktionsebenen ist bei Anwendung des von uns unterstützten
Wissensrepräsentationsformalismus sehr gut möglich, alle Strukturierungsvorgänge können
auf der Grundlage von Klauseln mit einem einzigen Interpretationsalgorithmus zur Laufzeit
verarbeitet werden.
Anhand der Ontologie können z.B. Hinweise auf weitere Subklassen zu Verträgen gegeben
werden. Solche Hinweise in Form von Fakten und Regeln sind für spätere Recherchen sehr
nützlich. Man denke in diesem Zusammenhang an die Strukturierung des Systems Wikipedia
(http://de.wikipedia.org/), das eine Navigation in der M2-Ebene unterstützt.
Hervorzuheben ist, dass Ontologien von Benutzern (Wissensarbeitern) überwiegend implizit
zu benutzen sind. In Ontologien erfasste Zusammenhänge zwischen unterschiedlichen
Abstraktionsstufen werden Nutzern als Assoziationen oder Handlungsvorschläge angeboten.
Im Geschäftsprozess einer Hochschulverwaltung beispielsweise wird ein Kooperationsvertrag
mit einer ausländischen Partnerhochschule einerseits der Thematik „Internationale
Beziehungen“ zuzuordnen sein, andererseits der Thematik „Verträge“. Im Moment der
Handhabung (z.B. Ablage) eines konkreten Vertrages (Instanz) spielen Probleme der
Kategorisierung eine untergeordnete Rolle (der Ordner „Internationale Beziehungen“ existiert
bereits), wohl aber in einem Geschäftsprozess der Organisation der Verwaltung (z.B. bei
Übernahme einer Funktion durch eine Person, der Ordner wird angelegt). Während der
Organisation (Metaebene) spielen wiederum Vertragsinhalte einzelner Verträge keine Rolle.
Eine während der Projektbearbeitung erkannte und künftig wissenschaftlich zu bearbeitende
Problematik bzgl. Ontologien ist die formale Beschreibung von zeitlichen Abläufen mittel
nicht-klassischer Logik (modale und temporale Logiken).
3.2 Werkzeuge
Klassifikator
Es wurde ein regelbasierter Klassifikator entwickelt (Constructor im Sinne der
Systemarchitektur des Projektantrages). Die Aufgabe des Klassifikators besteht darin,
Dokumente nach vorgegebenen Regeln zu klassifizieren. An Hand der Regeln können
Dokumente einer bestimmten Klasse nachgefragt werden. Geliefert werden u.a. die
Dokumentnamen aller zur Klasse gehörenden Dokumente, die im inter:gator-Modell
enthalten sind. Der Klassifikator beinhaltet einen RDF-Parser zur Erzeugung eines (internen)
Kontextmodells.
Die Interpretation der Regeln erfolgt durch einen Horn-Klausel-Interpreter in Verbindung mit
einer Faktenbasis.
Der in SWI-Prolog realisierte Klassifikator besteht aus einem Main-Modul, der seinerseits
die Module Rules, Utils und Token. verwendet (konsultiert).
Der Main-Modul (Prolog-Syntax) realisiert das Parsen einer RDF-Datei, die ein inter:gatorModell enthält. Zum Parsen wird die SWI-Erweiterungsbibliothek library(sgml)
verwendet. Die enthaltene Funktionalität unterstützt das Parsen SGML-basierter als auch
XML-basierter Sprachen (darunter RDF). Es werden Informationen über das Dokument selbst
und seine Dokumenttyp-Definiton (DTD) geliefert.
Der Parse-Vorgang wird mit dem Prädikat load_test/1 realisiert. Das Parsen erfolgt im
Main-Modul ereignisgesteuert, was besonders vorteilhaft bei größeren Dokumenten ist.
Folgende Auslöser-Reaktionstabelle gibt einen groben Überblick über den Parse-Vorgang.
9
Auslöser/Ereignis
Anfang der RDF-Datei
Anfang des ID-Elementes eines der
indizierten Dokumente
Anfang eines Person-Elementes eines der
indizierten Dokumente
Anfang eines Keyword-Elementes eines der
indizierten Dokumente
Anfang eines Format-Elementes eines der
indizierten Dokumente
Ende eines der indizierten Dokumente
Reaktion
Alle Metadaten aus der internen Prolog-DB
löschen
Den Wert des ID-Elementes in die PrologDB eintragen
Den Wert des Person-Elementes in die
Prolog-DB als eine Liste eintragen
Den Wert des Keyword-Elementes in die
Prolog-DB als eine Liste eintragen
Den Wert des Format-Elementes in die
Prolog-DB eintragen
Aus den in der Prolog-DB gespeicherten
Einzeleinträgen wird ein strukturierter
Dokumenten-Metadaten-Fakt generiert und
in die Prolog-DB eingetragen. Die benutzten
Einzeleinträge werden anschließend gelöscht.
Die auf diese Weise erstellte Metadaten-DB enthält die wichtigsten verwertbaren Metadaten
aller vom inter:gator indizierten Dokumente. Bei Benutzung der dynamischen SWI-PrologDatenbank werden Daten ausschließlich im Arbeitsspeicher gehalten. Zum
Hinzufügen/Entfernen von Klauseln stehen die Prädikate assert/1, retract/1 und
retractall/1 zur verfügung. Beim Eintragen in die Datenbank werden Klauseln
compiliert.
Die Benutzung des Klassifikators kann in zwei Rollen erfolgen:
Aus Sicht eines recherchierenden Benutzers (d.h. eines „Wissensarbeiters“,
vgl. [Ws07])
Aus Sicht eines Regeladministrators, der Klassifikationsregeln erstellt. Anhand
der Klassifikationsregeln werden Dokumente Klassen zugeordnet
(Konfiguration des Systems im Sinne der Systemarchitektur).
Der Rules-Modul wird vom Regel-Administrator erstellt und enthält Beschreibungen von
Klassen und Beziehungen. Beispiele für Klassen sind Vertrag, Mietvertrag,
Beschwerdeschreiben etc. Dieser Modul dient wesentlich zur Speicherung von
Ontologien.
Beispiel 3: Klassifikationsregel für die Definition von Verträgen:
vertrag(X, Rank) :document(X),
word(X, 'vertrag', 1, G1),
persons(X, 2, 1, G2),
average([G1, G2], Rank).
Die einzelnen Merkmale der Regel werden mit Gewichten versehen, dadurch ist es möglich,
einen Rang der Ergebnisse zu berechnen.
Der Keyword-Gen-Modul enthält einen Keyword-Generator, der anhand von vorhandenen
Regeln eine Liste der in den Regeln verlangten Keywords (das sind semantisch relevante
Keywords) generiert. Diese Erzeugung wird notwendig, weil die im inter:gator-Modell
10
enthaltenen und statistisch generierten Keywords häufig unbrauchbar für eine semantische
Klassifizierung sind. Die intergator-Keywords sind aus semantischer Sicht nicht die
wichtigsten Wörter, sondern die am häufigsten vorkommenden. Die meisten semantisch
relevanten Wörter fehlen. Der Keyword-Gen-Modul konsultiert den Rules-Modul.
Keyword-Merkmale wie z.B. in word(X, 'mieter', 1, G1) sind Case-insensitiv,
d.h.: ‚Mieter’ = ‚mieter’. Es wird auch eine Suche mit Teilzeichenketten durchgeführt. Zum
Beispiel ist word(X, ‚miet’, 1, G) auch für Keywords wie „Mietvertrag“,
„Vermieter“, „mieten“ usw. gültig.
Der Token-Modul definiert die Prädikate exists/1, document/1 und word/4.
document/1 und word/4 beziehen sich auf das Prädikat metadata/7. metadata/7
identifiziert ein Meta-Datum in der Prolog-Datenbank.
Der Utils-Modul enthält Prädikate, die zur Verarbeitung von Zeichenketten und Listen
benötigt werden, aber keine Standard-Prädikate sind (z.B. ein Prädikat average/2 zur
Berechnung des Mittelwertes einer Liste numerischer Werte).
Horn-Klausel-Interpreter
Es wurde ein Horn-Klausel-Interpreter entwickelt. Er basiert auf den Publikationen von H.
Fritzsche [Fri94] und H. Stoyan [Sto88]. Praktische Aspekte der Prolog-Programmierung
werden von P. Schnupp und K. Höß beschrieben [SH89].
Wesentliche Bestandteile des selbst entwickelten Horn-Klausel-Interpreters sind ein
Unifikations-Algorithmus (inklusive einer Implementierung des Occur-Check) und die
Klauselverarbeitung nach dem Prinzip der Resolution (Resolventenbildung nach Robinson).
Das nachfolgende Beispiel demonstriert den Horn-Klausel-Interpreter.
Beispiel 4: Das Programm prolog interpretiert die Anfrage (goal) in Bezug auf eine
Klausel-Menge (clauses).
(prolog
; clauses
'(
((intersect (cons X Y) Z (cons X U))
(member X Z)
(intersect Y Z U))
((intersect (cons X1 Y1 ) Z1 U1)
(intersect Y1 Z1 U1))
((intersect nil Y3 nil))
((member X2 (cons X2 Y2)))
((member Z2 (cons U2 V2))
(member Z2 V2))
)
; goal
'(
(intersect (cons a (cons b (cons c nil)))
(cons c (cons d (cons a nil)))
H))
)
=> ((H cons a (cons c nil ) ) )
Das erhaltene Resultat entspricht dem erwarteten Wert H = (a b).
11
Konverter
Ein von E. Lofing entwickeltes Konverter-Programm benutzt einen SAX-Parser [SAX] und
kann damit eine Transformation der externen RDF-Darstellung des Modells in eine interne
Darstellung und in der Folge in eine externe Scheme-Darstellung [R3RS] vornehmen.
4 Verwertung der Ergebnisse
Die Ontologie-Thematik wird im Rahmen des inter:gator-Projektes sowohl durch die
Interface GmbH als auch durch die HTW Dresden weiter verfolgt, da sie noch viel
Innovationspotential enthält. Zu dieser Thematik wird gegenwärtig eine Diplomarbeit
angefertigt (Herr S. Janosch).
Auch wenn das Produkt inter:gator weiterhin kommerziell durch die Fa. Interface Projects
GmbH vertrieben wird, sind die an der HTW Dresden erarbeiteten Programme auch im
Kontext der an der Hochschule verfolgten Forschungslinien unmittelbar nutzbar.
Die Nutzung erfolgt z.B. im Rahmen der Etablierung eines Wissenschaftsnetzwerkes mit
einer Plattform in der HTW Dresden als zentralem Knoten. Eine solche Plattform kann z.B.
im Rahmen von Diplom-/Bachelor-/Master-Abschlussarbeiten erbrachte wissenschaftliche
Leistungen kommunizieren und nutzbar machen. In diesem Kontext spielen Recherchen auf
der Basis von Ontologien eine zentrale Rolle.
5 Einschätzung der Marktaussichten
Die Marktaussichten des Gesamtsystems inter:gator haben sich durch die Erweiterung des
inter:gator-Clients und die Bearbeitung der Thematik Kontextsemantik deutlich verbessert.
Durch die von der HTW Dresden geleisteten Beiträge zur Modellierung von
Recherchekontexten und die Entwicklung von Ontologien können Recherchen zielgerichtet
unterstützt werden. In der Hochschule wird damit auch das Potential für weitere
Forschungsprojekte gestärkt.
6 Gemeinsame zukünftige Verwertung
Der HTW Dresden wurde im Juli 2007 von der Interface GmbH eine Lizenz der RetrievalSoftware inter:gator zur Verfügung gestellt. Die Ergebnisse des Kooperationsprojektes
werden künftig durch die Interface GmbH und die HTW Dresden gleichermaßen genutzt.
Eine gemeinsame Weiterentwicklung ist vorgesehen. Dabei wird es darum gehen, die
experimentellen Ergebnisse der Arbeit mit Kontext-Modellen und Ontologien in der
Metadatenverwaltung des inter:gator praktisch zu nutzen. Durch Forschungsarbeiten an der
Hochschule sollen auch neue Anwendungsgebiete für Ontologien erschlossen werden. Dazu
zählen z.B. Untersuchungen zur Beschreibung von Zugriffsschutzmodellen im Sinne der
„sicheren“ (erlaubten) Handhabung von Informationen (das Gebiet Informationssicherheit
vertritt der Antragsteller u.a. an der HTW Dresden).
7 Fortschreibung des Konzepts der Erfolgskontrolle
12
Die im Projektantrag in vier Punkten beschriebenen Ziele zum Konzept der Erfolgskontrolle
sind erfüllt worden. Die theoretischen Grundlagen wurden erarbeitet (z.T. aus Quellen
zusammengestellt), Algorithmen zur Klassifikation wurden erarbeitet und sind im
Klassifikator umgesetzt worden. Die wissenschaftlich in der Modellierung/Programmierung
unterschiedenen Beschreibungsebenen (Mo – M3) sind dargestellt und als Basis für die
Realisierung von Ontologien verwendet worden. Die erarbeiteten Erkenntnisse wurden an
Beispiel-Implementierungen erprobt.
Die im Projektantrag definierten Meilensteine wurden gemeinsam mit dem
Kooperationspartner erfüllt (Bereitstellung eines neuen inter:gator-Clients erfolgte durch die
Interface Projects GmbH).
Die im Projekt tätigen Mitarbeiter haben die HTW Dresden nach Projektende verlassen. Einer
der Projektmitarbeiter (Herr Andre Kischkel) ist vom Projektpartner Interface Projects GmbH
übernommen worden und arbeitet in der Firma weiter an der Thematik. Der zweite
Mitarbeiter (Herr Eugen Lofing) konnte zunächst nicht weiter beschäftigt werden, ist aber an
einer Promotion (kooperatives Promotionsverfahren) auf dem Gebiet Wissensverarbeitung/
Wissenserwerb (Knowledge Mining) interessiert.
Das durch das Kooperationsprojekt gewonnene Know-how wird sowohl bei der HTW als
auch bei der Interface Projects GmbH weiter genutzt und verwertet. Unter anderem dient die
Diplomarbeit von Herrn Stephan Janosch zur Thematik des Entwurfs und der
Implementierung eines Modelleditors für abstrakte Ontologien der Fortführung der Arbeiten.
Schwerpunkt dabei ist die grafische Handhabung von Ontologien.
Weitere Arbeiten an der HTW Dresden stehen im Kontext des Kooperationsprojektes. Die
Diplomarbeit von S. Bley ist der technologischen Basis gewidmet und beschäftigt sich mit der
Modell-getriebenen Softwareentwicklung (MDSD) bei Java-basierte Software-Architekturen
[Ble08]. Auch für Herrn S. Bley wird perspektivisch ein Promotionsverfahren angestrebt.
Literaturverzeichnis
AH04 Antoniou, G.; van Harmelen, F.: A Semantic Web Primer. The MIT Press, 2004
Ble08 Bley, S.: Konzeption und Entwicklung einer Software-Factory für Java-EnterpriseAnwendungen basierend auf der Eclipse-Plattform. Diplomarbeit, HTW Dresden (FH),
2008
CNV96 Covington, M.A.; Nute, D.; Vellino, A.: Prolog Programming in Depth, 1996
DOMW3C Document Object Model (DOM) Hompage beim W3C.
http://www.w3.org/DOM/
Dyb87 Dybvig, K.R.: The Scheme Programming Language. Prentice-Hall, 1987
Fle02 Fleming, D.: Repräsentation inhaltlicher Verwandtschaftsbeziehungen von
Textdokumenten auf der Grundlage von Kohonen-Karten, Diplomarbeit, HTW Dresden
(FH), 2002
FKL07 Fritzsche, H; Kischkel, A.; Lofing, E.: Entwicklungsmethodik, Ontologieentwurf und
Wissensrepräsentation für ein domänen-unabhängiges Recherchewerkzeug unter
Einbeziehung der Semantik von Recherchekontexten, Pflichtenheft. HTW Dresden, 2007
FL08 Fritzsche, H; Lofing, E.: Jamus-Scheme: An Implementation of a Scheme subset
conform to the Revised4-5 Report on the Algorithmic Language Scheme. Technischer
Report, HTW Dresden (FH), 2008
13
Fri94 Fritzsche, H.: Architektur und Entwicklung einer hybriden Softwareentwicklungsumgebung. Habilitationsschrift, Fakultät Informatik, TU Dresden, 1994
FM00 Fritzsche, H.; Michel, T.: Formalization and proof of design guidelines within the
scope of testing formally specified electronic product catalogues. Interacting with
Computers 12 (2000), 209 - 223
Gnü08 Gnüchtel, C.: Evaluierung und Entwicklung von Softwarekomponenten in einem
Prozess zur IT-gestützten Analyse und Bewertung von textuellen Inhalten aus dem
Umfeld der elektronischen Medien. Diplomarbeit, HTW Dresden (FH), 2008.
G+05 James Gosling, Bill Joy, Guy Steele, Gilad Bracha: The Java Language Specification.
Third Edition. Addison-Wesley 2005, ISBN 0-321-24678-0
Hel01 Helbig, H.: Die semantische Struktur natürlicher Sprache. Wissensrepräsentation mit
MultiNet. Springer, Heidelberg 2001
Her02 Hermsdorf, K.: Inhaltliche Verwandtschaftsbeziehungen von Textdokumenten auf
Grundlage selbstorganisierender Karten. Diplomarbeit, HTW Dresden, 2002.
Hod01 Wilfrid Hodges: 2001, "Classical Logic I: First Order Logic," in Lou Goble, ed., The
Blackwell Guide to Philosophical Logic. Blackwell.
Hof04 Hofmann, M.: Suche von inhaltlich ähnlichen textuellen Dokumenten auf Basis von
Jakarta-Lucene unter Verwendung ausschließlich freier Bibliotheken. Diplomarbeit,
HTW Dresden, 2004.
Jena Jena – A Semantic Web Framework for Java. http://jena.sourceforge.net/
Koe03 Köhler, S.: Visualisierung von Wissensmodellen auf der Grundlage des Oracle
Internet File Systems. Diplomarbeit, HTW Dresden (FH), 2003.
KB07 Kutschera/Breitkopf, Einführung in die moderne Logik, 8. Aufl. (2007), ISBN 978-3495-482711
LF08 Lofing, E, Fritzsche, H;.: Werkzeuge zur Erstellung und Nutzung von
Kontextsemantiken. Programmdokumentation, HTW Dresden, 2008
Lor02 Lorenz, J.: Untersuchungen zur Implementation und Einbindung von Komponenten
eines Content Management Systemes, basierend auf dem Oracle iFS (Internet File
System). Diplomarbeit, HTW Dresden (FH), 2002
LUCENE Apache Lucene, http://jakarta.apache.org/lucene
OWL04 M. K. Smith, C. Welty, D. L. McGuinnes: OWL Web Ontology Language Guide.
W3C Recommendation, 10. Febr. 2004, http:/www.w3.org/TR/owl-guide
R3RS Jonathan Rees and William Clinger, editors. The revised3 report on the algorithmic
language Scheme. In ACM SIGPLAN Notices 21(12), pages 37-79, December 1986.
RDF06 Resource Description Framework (RDF) Model and Syntax. www.w3.org/TR/WDrdf-syntax-971002
RDFW3C Resource Description Framework (RDF) Homepage beim W3C.
www.w3.org/RDF/
SAX Simple API for XML (SAX) Homepage. http://www.saxproject.org/
SH89 P. Schnupp, K. Höß: TerminalBuch Prolog. Oldenbourg-Verlag, 1989
Ws07 E. Wagner, P. Schnupp: Eine Kontext-Semantik-Umgebung für den praktischen
Einsatz. Projektbericht, 2007
Som07 Sommerville, J.: Software Engineering, Addison-Wesley, München, 2007
Ste04 Stephan, A.:Untersuchungen zur grafischen Visualisierung der Beziehungen von
Akteuren eines Wissensnetzwerkes und prototypische Umsetzung. Diplomarbeit, HTW
Dresden (FH), 2004.
14
Sto88 Stoyan, H.: Programmiermethoden der Künstlichen Intelligenz, Band 1. SpringerVerlag, 1988
Tan90 Tanimoto, S.L.: KI – Die Grundlagen. Oldenbourg-Verlag, München, Wien, 1990
Wie03 Wielemaker, J. et al.: SWI-Prolog and the Web. University Amsterdam, January 2003
15