View
7
Download
0
Category
Preview:
Citation preview
Georg-August-Universitat
Gottingen
Zentrum fur Informatik
ISSN 1612-6793
Nummer ZFI-BM-2007-30
Masterarbeitim Studiengang ”Angewandte Informatik”
OntoScope: Interaktive Visualisierung einer
anatomischen Ontologie
Remko Ricanek
an der
Universitatsmedizin Gottingen,
Abteilung Bioinformatik
Bachelor- und Masterarbeiten
des Zentrums fur Informatik
an der Georg-August-Universitat Gottingen
28. September 2007
Georg-August-Universitat Gottingen
Zentrum fur Informatik
Lotzestraße 16-18
37083 Gottingen
Germany
Tel. +49 (5 51) 39-1 44 02
Fax +49 (5 51) 39-1 44 03
Email office@informatik.uni-goettingen.de
WWW www.informatik.uni-goettingen.de
Ich erklare hiermit, dass ich die vorliegende Arbeit selbststandig verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Gottingen, den 28. September 2007
Masterarbeit
OntoScope: Interaktive Visualisierung einer
anatomischen Ontologie
Remko Ricanek
28. September 2007
Betreut durch
Dr. Holger Michael und Dipl.-Biol. Jurgen Donitz
Universitatsmedizin Gottingen, Abteilung Bioinformatik
Georg-August-Universitat Gottingen
Referent: Prof. Dr. Edgar Wingender
Korreferent: Prof. Dr. Wolfgang May
“So eine Arbeit wird eigentlich nie fertig, man muß sie fur fertig erklaren, wenn
man nach Zeit und Umstanden das mogliche getan hat.”
∼ Johann Wolfgang von Goethe, Italienische Reise, 16. Marz 1787
Zusammenfassung
Diese Masterarbeit befasst sich mit der Implementierung der graphischen Anwendungssoftware
OntoScope zur interaktiven Visualisierung von ontologischen Daten und deren Zusammenhan-
gen. Mit OntoScope sollen Daten der Datenbank Cytomer visualisiert werden. Cytomer ist eine
Datenbank uber Organe und Gewebe, Zelltypen und physiologische Systeme in verschiedenen
Entwicklungsstadien eines Organismus und wird in der Abteilung Bioinformatik der Universi-
tatsmedizin Gottingen zur Verfugung gestellt. Anhand eines Kriterienkatalogs wurden fur die
Implementierung der Visualisierung geeignete Software-Werkzeuge ausgewahlt, analysiert und
bewertet. Als Ergebnis der Analyse realisiert das Software-Werkzeug JUNG (Java Universal Net-
work/Graph Framework) die Visualisierung der ontologischen Daten in OntoScope. OntoScope
ermoglicht es einem Anwender, einen komplexen Ontologie-Datenbestand durch die Darstellung
einer Auswahl der Elemente und deren Beziehungen untereinander nach dem“Lichtkegel-Prinzip”
genauer unter die Lupe zu nehmen: es soll nur ein Fokus des gesamten Datenbestands dargestellt
werden. Durch Hinzufugen neuer Nachbarelemente oder Enfernen bestimmter Elemente aus der
Darstellung erhalt der Benutzer die Moglichkeit, im gesamten Datenbestand zu navigieren.
Abstract
This master’s thesis deals with the implementation of the graphical application software Onto-
Scope, which provides an interactive visualization of ontological data and the interrelationships
between different elements. OntoScope is a tool for the visualization of data from the Cytomer
database. Cytomer is a database of organs and tissues, cell types and physiological systems in
various developmental stages of an organism. Cytomer is freely available at the Department of
Bioinformatics, Faculty of Medical Science, University of Gottingen. Appropriate visualization
toolkits were selected, analyzed and evaluated by means of different criteria. It was concluded
that the toolkit JUNG (Java Universal Network/Graph Framework) is most suitable to realize
the visualization of data in OntoScope. OntoScope offers the possibility to examine an ontology
dataset most closely according to a “cone of light principle”: the visualization shows only a part
of the entire dataset and enables the user to navigate through the data by adding or removing
specific elements from the visualization.
Inhaltsverzeichnis
1 Einleitung 1
1.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Grundlagen 3
2.1 Ontologien in der Bioinformatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Protege Ontology Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Protege OWL Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Cytomer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Zielsetzung 13
3.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Analyse 15
4.1 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Anforderungskatalog fur die Visualisierung . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Lizenzierung der Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 API-Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 Ubersichtlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Erweiterbarkeit und Flexibilitat . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Auswahl der Software-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.1 prefuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 JUNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5 Ergebnis der Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Implementierung 25
5.1 Grundlegende Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 OntologyClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
I
Inhaltsverzeichnis
5.1.2 OntologyRestriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.3 OntologyProperty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Die Architektur von OntoScope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Die Datenschnittstelle OntologyConnector . . . . . . . . . . . . . . . . . . . . . 29
5.4 Der Schnittstellenadapter ConnectorAdapter . . . . . . . . . . . . . . . . . . . . 31
5.4.1 Exkurs: Webprogrammierung mit Java . . . . . . . . . . . . . . . . . . . . 31
5.4.2 Lokaler Zugriff: ConnectorLocalAdapter . . . . . . . . . . . . . . . . . . 34
5.4.3 Webbasierter Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.4 Webbasierter Zugriff: Anfrage (ConnectorServletAdapter) . . . . . . . . 34
5.4.5 Webbasierter Zugriff: Antwort (OntologyConnectorServlet) . . . . . . . 35
5.5 Die graphische Benutzeroberflache OntoScope . . . . . . . . . . . . . . . . . . . . 36
5.6 Visualisierung mit JUNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.1 Die Graph-Visualisierung mit JUNG . . . . . . . . . . . . . . . . . . . . . 38
5.6.2 Interaktive Graph-Manipulation mit JUNG . . . . . . . . . . . . . . . . . 40
6 Fazit 47
6.1 Kritische Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Abbildungsverzeichnis 51
Listings 53
Abkurzungsverzeichnis 55
A Inhalt der CD 57
Literaturverzeichnis 59
II
Kapitel 1
Einleitung
1.1 Zusammenfassung
Die vorliegende Masterarbeit befasst sich mit der Implementierung einer graphischen Anwen-
dungssoftware zur interaktiven Visualisierung von ontologischen Daten und deren Zusammen-
hangen.
Zunachst erlautert Kapitel 2 die grundlegenden Begriffe, die fur das Verstandnis der Arbeit
notwendig sind. Vorab wird der Begriff Ontologie im Bereich der Bioinformatik definiert und die
formale Beschreibungssprache Web Ontology Language (kurz: OWL) zum Erstellen, Publizieren
und Verteilen von Ontologien beschrieben. Abschließend wird der in der Abteilung Bioinformatik
der Universitatsmedizin Gottingen zu visualisierende Datenbestand von Cytomer vorgestellt.
Cytomer ist eine Datenbank uber anatomische Daten und deren Zusammenhange.
Kapitel 3 dient der Darstellung und Erlauterung der Aufgabenstellung auf Basis der zuvor defi-
nierten Grundlagen. Die Daten der Cytomer-Datenbank liegen als OWL-Ontologie vor und sollen
im Rahmen dieser Arbeit visuell dargestellt werden. Ausgehend von der Aufgabenstellung wird
in Kapitel 4 ein Kriterienkatalog fur die Visualisierung definiert. Anhand dieser Kriterien und
Anforderungen werden geeignete Software-Werkzeuge ausgewahlt, ausfuhrlich analysiert und be-
wertet. Das Ergebnis der Analyse ist Voraussetzung fur die Implementierung der graphischen
Anwendungssoftware. Mit der Implementierung dieser Anwendungssoftware befasst sich Kapitel
5. Hier werden alle Bestandteile der implementierten Software beschrieben und erlautert.
Die Arbeit schließt in Kapitel 6 mit einem Fazit, welches die Ergebnisse der Implementierung
vorstellt und einen Ausblick auf zukunftige Entwicklungen und mogliche Erweiterungen gibt.
1.2 Motivation
Der Datenbestand von Cytomer wird in der Abteilung Bioinformatik kontinuierlich weiterentwi-
ckelt und erganzt. Hierfur wird der Ontologie-Editor Protege1 eingesetzt. Zur Visualisierung der
1Vgl. Stanford University School of Medicine: http://protege.stanford.edu/
1
Kapitel 1 Einleitung
Daten beinhaltet Protege das Plugin Jambalaya2. Jambalaya ermoglicht ein interaktives Editie-
ren existierender Daten. Die Visualisierung erfolgt hier mit Hilfe der Technik Simple Hierarchical
Multi-Perspective (kurz: SHriMP3), einer Visualisierungstechnik zur Untersuchung komplexer
Daten. Dieses Plugin ist fur die Visualisierung der Cytomer-Daten jedoch nicht geeignet. Cyto-
mer ist zu komplex und umfangreich, als dass Jambalaya die Daten und zahlreichen Beziehungen
der Elemente des Datenbestands untereinander vernunftig anzeigen konnte. Die Geschwindigkeit
der Darstellung ist bei dieser großen Anzahl an Daten ungenugend bis mangelhaft.
Vor diesem Hintergrund versucht diese Masterarbeit eine fur große und komplexe Datenmengen
angemessene Alternative zur visuellen Darstellung von Ontologien zu finden.
Daruber hinaus ist es im Bereich der wissenschaftlichen Forschung von großem Interesse, Infor-
mationen bzw. Daten einem großen Benutzerkreis offentlich zuganglich zu machen. Der OWL-
Standard hat genau dies zum Ziel. Somit sollte ein offentlicher Zugang zum Datenbestand von
Cytomer als OWL-Ontologie am Web moglich gemacht werden. Denkbar ware hier die offentliche
Bereitstellung der in dieser Arbeit zu entwickelnden Anwendungssoftware.
2Vgl. Computer Human Interaction & Software Engineering Lab: http://www.thechiselgroup.org/jambalaya3Vgl. Computer Human Interaction & Software Engineering Lab: http://www.thechiselgroup.org/shrimp
2
Kapitel 2
Grundlagen
Ein stetiger Fortschritt in der Informationstechnik erlaubt es, experimentelle Techniken im Be-
reich der wissenschaftlichen, speziell der biomedizinischen Forschung zu automatisieren. Dadurch
ist die Informatik und im Besonderen die Bioinformatik zu einem festen Bestandteil der wis-
senschaftlichen Forschung geworden. Die daraus resultierenden großen Datenmengen werden in
Datenbanken gespeichert und dienen so wiederum als Grundlage fur weitere Forschungsarbei-
ten.
Wenn viele Wissenschaftler mit unterschiedlichem wissenschaftlichem Hintergrund auf Informa-
tionen eines bestimmten Wissensgebiets gemeinsam zugreifen, muss uber die Art und Struktur
dieser Daten, der zu Grunde liegenden Begriffe und Zusammenhange Einigkeit herrschen. Hierfur
haben sich in den vergangenen Jahren Ontologien als nutzlich erwiesen.
2.1 Ontologien in der Bioinformatik
Im Bereich der Informatik versteht man eine Ontologie als ein allgemeines Vokabular, um verteil-
tes Wissen zu beschreiben, gemeinsam zu nutzen, die Elemente eines Wissensbereichs eindeutig
zu benennen und die Beziehungen zu anderen Elementen zu definieren. Eine Ontologie ist also
ein formal definiertes System von Konzepten, Relationen und Regeln. Diese Regeln und Kon-
zepte stehen ebenso im Zusammenhang wie bei klassischen Datenbanken deren Struktur (Sche-
ma) und Inhalt (Daten). Doch im Gegensatz zu Datenbanken besitzen Ontologien detailliertere
Beschreibungen der gespeicherten Daten sowie Regeln uber deren Zusammenhang, sogenannte
Metadaten. Durch solche Regeln ist es moglich, Ruckschlusse aus den vorhandenen Daten zu
ziehen.
Der Begriff Ontologie steht ursprunglich fur eine philosophische Disziplin uber die Lehre vom
Seienden. In der Informatik versteht man darunter eine Wissensreprasentation eines formal
definierten Systems von Begriffen und Relationen. Ontologien in der Informatik basieren im
Wesentlichen auf der Idee des Semantic Web von Tim Berners-Lee [Berners-Lee et al. 2001].
Dieses semantische Web ist kurz gesagt eine Erweiterung des World Wide Web (kurz: WWW)
um maschinenlesbare Daten, welche die Semantik der Inhalte formal festlegen. Die Grundidee
ist, Web-Dokumente mit Semantik in Form von Metadaten zu versehen, die ihren Inhalt naher
3
Kapitel 2 Grundlagen
beschreiben und diese durch Ableitungsregeln miteinander zu verknupfen. Die gespeicherten
Daten sollen nicht nur fur Menschen lesbar sein, sondern auch formal, in einer fur Maschinen
und andere elektronische Mechanismen verarbeitbaren Form dargestellt werden. Somit konnen
diese Informationen durch Computerprogramme gezielt und effizient gefunden und miteinander
verbunden werden [Hesse 2002].
Typische Beispiele gebrauchlicher biologischer Ontologien sind u.a. Gene Ontology (GO), eine
Ontologie uber molekulare Funktionen, biologische Prozesse und zellulare Komponenten nach
dem Prinzip “Ein Genprodukt kann mit einem oder mehreren Zellbestandteilen in Verbindung
stehen oder kann in einem oder mehreren biologischen Prozessen aktiv sein, wahrend es eine
oder mehrere molekulare Funktionen erfullt”1. Als weiteres Ontologie-Beispiel sei an dieser Stelle
die Foundational Model of Anatomy-Ontologie (kurz: FMA) genannt, eine Ontologie uber die
menschliche Anatomie2.
Im Allgemeinen versteht man Ontologien als abstraktes Datenmodell, welches Daten und deren
Zusammenhange formal beschreibt. Daruber hinaus konnen Ontologien als Graphen dargestellt
werden, wobei die Knoten und Kanten die Elemente und deren Beziehungen untereinander,
d.h. die Konzepte und Relationen einer Ontologie reprasentieren. Sind die Daten der Ontologie
einfach strukturiert aufgebaut und haben jeweils nur einen Elterknoten, so lasst sich eine solche
Ontologie als einfache Baumhierarchie darstellen (siehe Abbildung 2.1a). Besitzt ein Element
der Ontologie jedoch mehr als einen Elterknoten, spricht man von einem gerichteten azyklischen
Graphen (englisch: directed acyclic graph, DAG), beispielsweise “some cell is cell of organ A,
organ B” (siehe Abbildung 2.1b). Lassen sich aus der Ontologie Regeln, wie in etwa “organ A is
next to organ B” und “organ B is next to organ A” ableiten, sind die Relationen der Elemente
der Ontologie ungerichtet bzw. zyklisch. Hier spricht man von einem Graphen bzw. gerichteten
zyklichen Graphen (siehe Abbildung 2.1c) [Bard u. Rhee 2004; Bard 2003].
Neben der Darstellung einer Ontologie als Graph kann selbige in der Informatik durch OWL
als Sprache zur Beschreibung von Daten und deren Zusammenhangen beschrieben werden. Die
Web Ontology Language (kurz: OWL) ist eine Ontologiesprache, die aus der Idee des Semantic
Web entstanden ist.
2.2 Web Ontology Language (OWL)
Wie im vorherigen Abschnitt schon erwahnt, ist das Semantic Web die Vision einer Zukunft
des Webs, in dem Informationen eine ausdruckliche Bedeutung zugewiesen wird. Dies soll es
Maschinen einfacher machen, Informationen automatisch aus dem Web zu verarbeiten und zu-
sammenzufuhren. Das Semantic Web baut auf den Moglichkeiten von XML auf, angepasste
Auszeichnungsschemata zu definieren sowie auf dem flexiblen Ansatz der Datenreprasentation
1Vgl. Gene Ontology Consortium: http://www.geneontology.org2Vgl. University of Washington, School of Medicine: http://sig.biostr.washington.edu/projects/fm/
4
2.2 Web Ontology Language (OWL)
Abbildung 2.1: Darstellung einer Ontologie als Graph Haben Elemente einerOntologie nur je einen Elterknoten, ist die Ontologie in einer einfachen hierarchi-schen Baumstruktur beschreibbar (a). Bei einer Ontologie, in der ein Elementhingegen mehrere Elterknoten haben kann, spricht man von einem gerichtetenazyklischen Graphen (kurz: DAG) (b). Durch ungerichtet Kanten und mehrerenElterknoten kann ein komplexer Graph beschrieben werden (c) [Bard u. Rhee2004].
von RDF (Resource Description Framework) und der damit verbundenen Bereitstellung von Me-
tadaten. Die erste Schicht oberhalb von RDF, die fur das Semantic Web notwendig ist, ist die
Ontologiesprache OWL, welche formal die Bedeutung der in Web-Dokumenten verwendeten Ter-
minologien beschreibt (siehe Abbildung 2.2). Wenn man von Maschinen erwarten will, dass sie
nutzliche Folgerungen aus diesen Dokumenten ziehen, muss die Sprache uber die grundlegende
Semantik von RDF Schema (RDF-S oder RDFS) hinausgehen.
OWL ist Teil des Semantic Web Stacks des W3C:
XML stellt eine Syntax fur strukturierte Dokumente zur Verfugung, nutzt aber keine semanti-
sche Eingrenzung der Bedeutung dieser Dokumente. Ein Objekt wird durch einen Namen
identifiziert und durch einen Namensraum (englisch: namespace) eindeutig einem Kon-
text zugeordnet. Hierbei werden Namensraume durch URIs (englisch: uniform resource
identifier, URI) definiert.
XML Schema ist die Sprache, um die Struktur von XML Dokumenten festzulegen und erweitert
XML um spezielle Datentypen.
RDF ist ein Datenmodell fur Ressourcen und Relationen zwischen diesen. Es stellt eine einfa-
che Semantik fur das Datenmodell zur Verfugung. Diese Datenmodelle konnen in XML
reprasentiert werden.
RDF Schema ist eine Sprache zur Beschreibung der Eigenschaften und Klassen von RDF Res-
sourcen, mit einer Semantik fur verallgemeinernde Hierarchien solcher Eigenschaften und
Klassen.
OWL erweitert das Vokabular zur Beschreibung von Klassen (englisch: class) und Eigenschaften
(englisch: property). In OWL ist es zum Beispiel moglich, Relationen zwischen Klassen (z.B.
5
Kapitel 2 Grundlagen
Abbildung 2.2: Die Architektur des Semantic Web nach Tim Berners-LeeDie Ontologiesprache OWL (Ontology vocabulary) ist Teil des Semantic WebStacks des World Wide Web Contortiums (kurz: W3C) und basiert auf denPrinzipien von XML, XML-Schema und RDF. OWL eignet sich zur Erstellungund Beschreibung von Ontologien [Semantic Web 2001].
Disjunktheit), Kardinalitat (z.B.“genau einer”), Aquivalenz, mehr Typen und Charakteris-
tika von Eigenschaften (z.B. Symmetrie) zu definieren. Des weiteren ubertrifft OWL diese
Sprachen in der Moglichkeit maschineninterpretierbaren Inhalt im Web zu reprasentieren.
OWL ist eine uberarbeitete Version der Darpa Agent Markup Language + Ontology Infe-
rence Layer web ontology language (kurz: DAML+OIL), welche die aus dem Design und
der Anwendung von DAML+OIL gewonnenen Erkenntnisse in sich vereint [OWL 2004].
OWL bietet drei Untersprachen mit zunehmender Ausdrucksstarke: OWL-Lite, OWL-DL
(englisch: description logic, DL) und OWL-Full. Jede dieser Untersprachen ist eine Erweite-
rung des einfacheren Vorgangers, sowohl in dem, was korrekterweise ausgedruckt als auch in dem,
was gultig geschlussfolgert werden kann. Die OWL-Spezifikation erweitert also RDF und RDFS
um weitere Konstrukte, um damit deren Ausdrucksfahigkeit zu steigern bzw. teilweise auch
einzuschranken, um Entscheidbarkeit zu erreichen. OWL unterscheidet Klassen, Eigenschaften
und Instanzen. Klassen stehen fur Konzepte. Sie konnen Eigenschaften besitzen. Instanzen sind
Individuen einer oder mehrerer Klassen. Durch definierte semantische Regeln lassen sich einfa-
che Statements nach dem Prinzip “Subjekt Pradikat Objekt” ableiten, also “Ressource/Objekt +
Eigenschaft + zugehoriger Wert”. Mit einer Inferenzmaschine (gleichbedeutend mit Reasoner)
konnen diese Statements anhand ihrer Regeln auf ihre Gultigkeit uberpruft werden. Bei OWL
handelt es sich also um eine Sprache des Semantic Web, die oberhalb von RDF angesiedelt ist
und sich zur Erstellung von Ontologien eignet.
Zur Erstellung von OWL-Ontologien existieren zur Zeit noch relativ wenige Software-Werkzeuge,
da die OWL-Spezifikation noch vergleichsweise jung ist. Als Beispiel seien an dieser Stelle das
6
2.3 Protege Ontology Editor
Semantic Web Development Environment-Plugin (kurz: SWeDE)3 fur die Eclipse Development
Platform4, DAG-Edit/OBO-Edit des Gene Ontology Consortiums5 und der Protege Ontolo-
gy Editor der Stanford University School of Medicine6 genannt. Die Abteilung Bioinformatik
verwendet zur Erstellung und Weiterentwicklung von Ontologien den Protege Ontology Editor.
Aus diesem Grund wird im Rahmen dieser Arbeit nur auf diese Anwendungssoftware genauer
eingegangen.
2.3 Protege Ontology Editor
Der Protege Ontology Editor [Protege 2006] ist ein Open-Source Anwendungsprogramm der
Stanford University School of Medicine zur Entwicklung von Ontologien und unterstutzt den
Anwender durch eine wissensbezogene Umgebung beim Anlegen großer elektronischer Informa-
tionssammlungen eines bestimmten Wissensgebiets. Die Idee des Semantic Web, Informationen
gleichermaßen fur Menschen und Maschinen lesbar zu machen, macht es einem Anwender nicht
unbedingt leichter, gultige Wissenssammlungen und deren Dokumente manuell zu erstellen. Ein
Grund fur diese Schwierigkeit ist es, dass Informationen eines bestimmten Wissensgebietes fur
Menschen formal kaum eindeutig zu beschreiben sind. Denn Menschen konnen sich gespeichertes
Wissen zu Nutze machen, indem sie auf ihr Gund- und Kontextwissen des jeweiligen Wissens-
bereichs zuruckgreifen und mit dem gespeicherten Wissen verbinden [Hesse 2002]. Maschinen
benotigen hingegen zusatzliche Informationen uber die verwendeten Begriffe und deren Zusam-
menhange. Protege soll diese Lucke schließen, indem der Anwender durch eine einfache und
ubersichtliche Benutzeroberflache in der Erstellung von Ontologien unterstutzt wird. Durch die-
se intuitive Benutzeroberflache ist es dem Anwender moglich, diese Konzepte und Beziehungen
einer Ontologie eines konkreten Anwendungsgebiets direkt hinzuzufugen und zu bearbeiten.
Protege bietet u.a. durch eine große Anzahl an Plugins eine beachtliche Vielseitigkeit und eine
Vielzahl an Moglichkeiten, verschiedene Datenformate zu reprasentieren, seien es relationale Da-
tenbanken, UML, RDF oder OWL. Letzteres ermoglicht das Protege OWL Plugin, mit welchem
OWL konforme Daten eingelesen und verarbeitet werden konnen [Noy et al. 2003].
2.4 Protege OWL Plugin
Das Protege OWL Plugin7 [Knublauch et al. 2004] des Protege Ontology Editors stellt eigene
Programmierschnittstellen (englisch: application programming interface, API) zur Bearbeitung
von OWL-Dokumenten bereit. Es erweitert Protege um OWL-Spezifikationen. Die Architektur
von Protege teilt sich in ein zu Grunde liegendes Modell zur internen Reprasentation von Onto-
logien und Wissensgebieten sowie in eine Ansicht zur graphischen Darstellung und Bearbeitung
3Vgl. BBN Technologies: http://owl-eclipse.projects.semwebcentral.org4Vgl. Eclipse Foundation: http://www.eclipse.org5Vgl. Gene Ontology Consortium: http://geneontology.sourceforge.net/6Vgl. Stanford University School of Medicine: http://protege.stanford.edu7Vgl. Stanford University School of Medicine: http://protege.stanford.edu/overview/protege-owl.html
7
Kapitel 2 Grundlagen
des Modells. Das Modell wiederum basiert auf einem einfachen Metamodell, vergleichbar mit
objektorientierten Systemen, welches eine Ontologie als Klassen, Instanzen von Klassen und Ei-
genschaften uber diese reprasentiert. Zur Manipulation der Ontologiemodelle stellt die Protege
API entsprechende Schnittstellen bereit.
Das Protege OWL Plugin erweitert das zu Grunde liegende Metamodell von Protege durch
eine spezielle Protege OWL API um entsprechende OWL-Aspekte. Zusatzlich werden dem An-
wender speziell fur OWL-Ontologien angepasste Menus, Karteireiter und Hilfswerkzeuge in der
graphischen OWL-Benutzeroberflache angeboten.
Die Protege OWL API baut ihrerseits im Wesentlichen auf dem Jena Semantic Web Framework
fur Java8, der Jena Ontology API auf. Das Prinzip dieser API ist es, einen Anwendungsent-
wickler nicht direkt mit Ontologien arbeiten zu lassen, die dem Sprachumfang RDFS, OWL-Lite,
OWL-DL oder OWL-Full entprechen, sondern mit einem Datenmodell. Zur Unterscheidung der
Modellierungssprachen innerhalb des Datenmodells hat jede dieser Sprachen ein eigenes Pro-
fil, welches die erlaubten Konstrukte und URIs der Klassen und Eigenschaften erfasst. Jedes
Profil ist also an ein Ontologiemodell gebunden, welches das Datenmodell um profilspezifische
Merkmale erweitert [Jena 2007]. Nach dem gleichen Prinzip ist das Metamodell von Protege
konzipiert.
Bei der Bearbeitung einer Ontologie mit dem Protege OWL Plugin wird diese Ontologie
zusatzlich zur Darstellung im OWL-Metamodell als Jena-Modell bereitgehalten. Dies garan-
tiert eine standardisierte Synchronisation jeglicher Anderungen der Daten durch den Benutzer
[Knublauch et al. 2004].
Abbildung 2.3 zeigt das Schema und das Zusammenspiel der einzelnen Komponenten in der um
OWL erweiterten Protege-Software.
2.5 Cytomer
Ein Forschungsschwerpunkt der Abteilung Bioinformatik der Universitatsmedizin Gottingen ist
das Modellieren zellspezifischer, regulatorischer Prozesse und Signalwege. Hierfur wurde Cyto-
mer entwickelt, eine relationale Datenbank uber Organe und Gewebe, Zelltypen, physiologische
Systeme und Entwicklungsstadien [Wingender 2003; Michael et al. 2005]. Der Datenbestand von
Cytomer konzentriert sich hauptsachlich auf Daten der Spezies Mensch (Homo sapiens). An-
dere Spezies wie der Fadenwurm (Caenorhabditis elegans), Maus (Mus musculus) oder Ratte
(Rattus norvegicus) sind ebenfalls vorhanden bzw. in Bearbeitung. Strukturell enthalt Cyto-
mer somit Organe und Gewebe (Tabelle organ), Zelltypen (cell) und Systeme (system) in
den verschiedenen Entwicklungsstadien (stage) eines Organismus. Die Eintrage der Datenbank
enthalten spezielle Attribute wie Nummer, Name, Synonyme und entsprechende medizinische
Fachausdrucke (siehe Abbildung 2.4).
8Vgl. Hewlett-Packard Development Company : http://jena.sourceforge.net/
8
2.5 Cytomer
Abbildung 2.3: Schema des Protege OWL Plugins Das OWL Plugin vonProtege erweitert die Protege API um entsprechende OWL-Spezifikationen undbasiert im Wesentlichen auf Programmierschnittstellen des Jena Semantic WebFrameworks, der Jena API [Knublauch et al. 2004].
Die Datenstruktur von Cytomer ist so konzipiert, dass die Daten und deren Beziehungen unter-
einander einen Organbaum fur jedes Entwicklungsstadium einer Spezies aufspannen. So beginnt
zum Beispiel der Organbaum der Spezies Mensch fur jedes einzelne Entwicklungsstadium mit ei-
nem Eintrag “human, Homo sapiens” und verzweigt sich hierarchisch uber die einzelnen Organe
und Organteile bis hin zu den spezifischen Zellen. Die Beziehungen zwischen diesen Elementen
sind in Cytomer als partOf-Beziehungen definiert. Demnach lassen sich aus dieser Datenstruk-
tur Statements wie “liver is part of alimentary tract” oder “human, Homo sapiens has part
alimentary tract” definieren.
Im Rahmen einer Projektarbeit [Ricanek 2006] wurde aus der relationalen Datenstruktur von
Cytomer eine OWL-Ontologie abgeleitet. Die Struktur der Cytomer Datenbank bot in ihrer
derzeitigen Form keine Moglichkeit, die verfugbaren biologisch anatomischen Daten weiterzu-
entwickeln und einem großen Benutzerkreis offentlich zuganglich zu machen. Denn im Bereich
der wissenschaftlichen Forschung ist es von großem Interesse, dass Informationen bzw. Daten
zwischen verschiedenen Forschungsgruppen ausgetauscht werden konnen. Hierzu mussen die Da-
ten jedoch in einer standardisierten Art vorliegen, die uberall verstandlich und interpretierbar
ist. Der OWL-Standard bietet im Bereich der Ontologien genau diese Moglichkeit. Durch die
Beschreibung von Cytomer als OWL-Ontologie wurde es moglich, die verfugbaren biologisch
anatomischen Daten im Protege Ontology Editor weiterzuentwickeln und zu bearbeiten.
Das Ontologiemodell von Cytomer wurde im Rahmen der Projektarbeit um ein zu Grunde lie-
gendes abstraktes Ontologiemodell erweitert, da die partOf-Beziehungen im relationalen Modell
von Cytomer nicht ausreichten, die gesamten Daten zu beschreiben. Durch die hierarchische Klas-
9
Kapitel 2 Grundlagen
cell
cell_no
cell_acc
name_english
...
organ
organ_no
organ_acc
name_english
...
system
system_no
system_acc
name_english
...
stage
stage_no
stage_acc
name
...
organtree
organtree_no
organ_no
organ_parent_no
stage_no
organtree2cell
organtree_no
cell_no
organtree2system
organtree_no
system_no
Abbildung 2.4: Schema der relationalen Cytomer Datenbank Cytomer ist eineDatenbank uber Organe und Gewebe (organ), Zelltypen (cell) und physiolo-gische Systeme (system) in verschiedenen Entwicklungsstadien (stage) einesOrganismus. Die Eintrage der Datenbank werden zum Beispiel durch Name,Nummer oder Synonyme genauer definiert und beschrieben.
senstruktur von Ontologieklassen im Ontologiemodell wurden Elter-Kind-Beziehungen zwischen
Klassen grundsatzlich als isA-Beziehungen interpretiert werden. Demnach wurde die eigentli-
che Aussage “liver is part of alimentary tract” als “liver is an alimentary tract” aufgefasst
werden, da liver als Subklasse von alimentary tract zwangslaufig den Beziehungstyp isA zug-
wiesen bekame. Das Ontologiemodell musste also zur Darstellung in OWL diesen Umstanden
entsprechend angepasst und erweitert werden.
In diesem neuen Ontologiemodell wurden die einzelnen Ontologieklassen entsprechend ihrer Zu-
gehorigkeit eingeordnet. So finden sich die einzelnen Organe als Subklassen von Organ, Zellen als
Subklassen von Cell, Systeme als Subklassen von PhysiologicalSystem und Entwicklungssta-
dien als Subklassen von DevelopmentalStage wieder. Die Beziehungen zwischen den einzelnen
Ontologieklassen werden durch sogenannte Restriktionen uber eine bestimmte Eigenschaft be-
schrieben. Hierzu wurden verschiedene Eigenschaften definiert, jeweils als inverses Paar, um im
Ontologiemodell sowohl von Elter- zu Kind-Element, als auch zwischen verschiedenen Elemen-
ten in beide Richtungen zu navigieren. Als allgemeine Beziehungen zwischen Ontologieklassen
wurden hasPart und isPartOf festgelegt. Als weitere Eigenschaften wurden hasOrganPart und
isPartOfOrgan fur Beziehungen zwischen Organklassen, sowie hasCell und isCellOf fur Bezie-
hungen zwischen Organen und Zellen definiert. Mit diesen Eigenschaften konnen beispielsweise
Statements wie “[Organ] is part of [System]” oder invers dazu “[System] has part [Organ]”
beschrieben werden. Abbildung 2.5 zeigt die Beziehungen der einzelnen Entitaten im abstrakten
Ontologiemodell.
Weitere Beziehungen in diesem Ontologiemodell sind denkbar bzw. schon in Bearbeitung wie
beispielsweise isPartOfSystem oder isPartOfStage fur Beziehungen zu Entwicklungsstadien
oder Systemen oder auch developsFrom bzw. invers dazu developsTo als zeitliche Entwicklung
10
2.5 Cytomer
owl:Thing
AnatomicalAbstractConcept AnatomicalEntity
DevelopmentalStage PhysiologicalSystem . . .AnatomicalBuildingBlock
Species Cell Organ
1. . . i 1. . . j 1. . . k 1. . .m
1. . . n
hasCell
isCellOf
isPartOfOrgan
hasOrganPartisPartOf
hasPart
isPartOf
hasPart
hasPart
isPartOf
Abbildung 2.5: Die Beziehungen im OWL-Modell von Cytomer Die ursprung-liche einfach Baumstruktur von Cytomer wurde zu einem abstrakten Ontologie-modell erweitert. Die einzelnen Elemente der Ontologie werden hier entsprechendihrer Klassenzugehorigkeit eingeordnet. Verschiedene Beziehungstypen beschrei-ben die speziellen Beziehungen der einzelnen Elemente untereinander.
einer Entitat von einem Entwicklungsstadium zum nachsten. Die Beziehungen im Ontologiemo-
dell sind also nicht konstant, konnen sich somit im Zuge der Weiterentwicklung andern, oder
neue Beziehungstypen konnten hinzukommen.
11
Kapitel 2 Grundlagen
12
Kapitel 3
Zielsetzung
Im Folgenden werden die Ziele dieser Masterarbeit aufgestellt und Anforderungen aus Benut-
zersicht zur Umsetzung der Aufgabenstellung definiert.
3.1 Aufgabenstellung
Im Rahmen dieser Masterarbeit soll eine Software entwickelt und implementiert werden, welche
die in der Ontologie von Cytomer beschriebenen Sachverhalte als Ergebnis von Benutzeranfragen
sichtbar macht. Sie soll die Ergebnisse von Suchanfragen illustrieren und das Navigieren zwischen
den angezeigten Elementen der Ontologie ermoglichen. Die Software soll den Namen OntoScope
tragen. Das Wort OntoScope setzt sich aus dem Prafix Onto- als Kurzform von Ontologie und
dem Suffix -Scope aus dem Englischen fur ein Instrument zum Beobachten zusammen. Das
englische -scope leitet sich wiederum vom griechischen skopein (= betrachten) ab.
3.2 Anforderungen
OntoScope soll neben der visuellen Darstellung des Cytomer-Datenbestandes außerdem in An-
lehnung an die Motivation in Abschnitt 1.2 die Geschwindigkeit in der Interaktion mit dem
Benutzer erkennbar steigern. Der in der Abteilung Bioinformatik zur Erstellung und Weiterent-
wicklung von Ontologien verwendete Protege Ontology Editor zeigt große Schwachen in der Dar-
stellung großer und machtiger Ontologien bezuglich Performance. Im Rahmen dieser Arbeit soll
die Geschwindigkeit durch die Anwendung eines Fokus auf die Datenmenge verbessert werden.
OntoScope soll nur einen Ausschnitt des gesamten Datenbestands visualisieren. Einem Benutzer
sollte folglich nur das gesuchte Element des Datenbestands nebst jeweils seiner unmittelbaren
Umgebung angezeigt werden. Die Navigation im gesamten Datenbestand soll anschließend nach
dem “Lichtkegel-Prinzip” erfolgen, d.h. ein Benutzer soll Nachbarelemente eines ausgewahlten
Elements zur Darstellung hinzufugen sowie Elemente, die nicht mehr von Interesse sind, aus
der Darstellung entfernen konnen. Somit sollen nur die Elemente des Datenbestands beleuchtet
werden, die fur den Benutzer besonders wichtig sind. Daruber hinaus sollte ein Benutzer die
Moglichkeit haben, die mit den einzelnen Elementen der Ontologie assoziierten Informationen
13
Kapitel 3 Zielsetzung
abzurufen. Hier sollten Kurzinfos (Tooltips) oder ein Informationsprofil die entsprechenden In-
formationen anzeigen. OntoScope sollte ferner Benutzeranfragen beantworten konnen, bei denen
mehrere Klassen miteinander verknupft sind, beispielsweise “Zeige alle in der Leber vorkommen-
den Zelltypen an” oder “Zeige alle Carnegie Stages, in denen eine Leber vorhanden ist”. Eine
weitere und wichtige Anforderung an die Software OntoScope ist eine freundliche und intuitiv
bedienbare und vor allem ubersichtliche optische Gestaltung des Benutzerinterfaces. Die Vi-
sualisierung der einzelnen Elemente der Ontologie sollte dabei klar und uberschaubar gestaltet
sein.
14
Kapitel 4
Analyse
Dieses Kapitel befasst sich mit der Analyse von Software-Werkzeugen (englisch: toolkits) zur Dar-
stellung von Daten und deren Zusammenhangen. Auf der Grundlage der Aufgabenstellung aus
Kapitel 3 soll eine Software mit Namen OntoScope entwickelt werden, welche den Datenbestand
der Cytomer-Ontologie in anschaulicher Weise visualisiert. Sie soll dem Benutzer einen Uberblick
uber die Elemente der Ontologie und deren Beziehungen untereinander vermitteln. Der wich-
tigste Teil der graphischen Benutzeroberflache von OntoScope wird demnach ein Zeichenfenster
oder -feld (englisch: panel) sein, das die Visualisierung beeinhalten soll. Das Zeichenfeld fur die
Visualisierung der Daten soll von einem Software-Werkzeug bereitgestellt werden. Anhand eines
Kriterienkatalogs werden fur die Darstellung geeignete Software-Werkzeuge ausgewahlt und be-
wertet. Als Bewertungsgrundlage dient ein Beispielgraph, welcher mit allen Software-Werkzeugen
zu implementieren ist. Nach dem Ergebnis der Analyse wird fur die Implementierung von Onto-
Scope das geeignetste Software-Werkzeug ausgewahlt. Dieses Software-Werkzeug soll dann die
Darstellung der Cytomer-Ontologie in OntoScope realisieren.
4.1 Visualisierung
Dem Betrachter einer Visualisierung soll moglichst schnell ein Uberblick uber die in struktu-
rierten Daten enthaltenen Informationen gegeben werden. Eine Ontologie ist beispielsweise eine
solche Sammlung von Daten und Informationen, welche in einer bestimmten Form im Zusam-
menhang stehen. Die Elemente und Beziehungen einer Ontologie konnen durch Knoten und
Kanten visuell dargestellt werden. Jeder Knoten reprasentiert ein Element der Ontologie und je-
de Kante eine Beziehung zwischen zwei Elementen. Eine solche Ontologie-Darstellung bezeichnet
man auch als Graph. Wie schon im Abschnitt 2.1 kurz beschrieben, gibt es verschiedene For-
men der Darstellung einer Ontologie als Graph (siehe Abbildung 2.1). [Herman et al. 2000] gibt
einen Uberblick uber verschiedene Graphtypen wie beispielsweise Baume, Netze oder Entity-
Relationship-Diagramme.
15
Kapitel 4 Analyse
4.2 Anforderungskatalog fur die Visualisierung
In seiner ursprunglichen Form war der Cytomer-Datenbestand als einfache Baumstruktur fur
jedes Entwicklungsstadium hierarchisch aufgebaut (siehe Abschnitt 2.5). Ausgehend vom er-
weiterten Ontologiemodell von Cytomer reicht diese Form der Darstellung jedoch nicht aus.
Die Beziehungen der einzelnen Datentypen (Organe, Zelle, Systeme etc.) untereinander lassen
sich als Baumstruktur nicht mehr darstellen. Ein gerichteter azyklischer Graph (kurz: DAG) ist
hier die geeignetere Darstellungsform (entsprechend Abbildung 2.5). Mit einem DAG konnen
komplexere Beziehungen, beispielsweise mehrere Elterknoten definiert werden. Bei der Auswahl
geeigneter Software-Werkzeuge fur die Darstellung der Cytomer-Ontologie ist also darauf zu
achten, dass sie eine Visualisierung als DAG unterstutzen. Die Visualisierung sollte hierbei eine
dynamische Darstellung des Graphen ermoglichen und dem Benutzer interaktive Eingriffs- und
Steuerungsmoglichkeiten erlauben. Die Software-Werkzeuge sollten die Moglichkeit zur Integra-
tion in eigene Softwarelosungen durch geeignete Programmierschnittstellen (kurz: API) bieten
und in der Programmiersprache Java1 geschrieben sein, da die Protege OWL API und die zu-
grundeliegende Jena API ebenfalls Java-Programmierschnittstellen sind. Daruber hinaus sollten
die Software-Werkzeuge den folgenden, fur diese Arbeit aufgestellten Kriterien genugen.
4.2.1 Lizenzierung der Software
Ziel ist es, bei der Entwicklung von OntoScope kommerzielle Lizenzen fur die Nutzung von
Software-Werkzeugen moglichst zu vermeiden, um die Kosten der Entwicklung niedrig zu halten
und in der Entwicklung moglichst unabhangig zu sein.
4.2.2 API-Funktionsumfang
Unter diesem Punkt wird der Funktionsumfang und die Nutzbarkeit der Programmierschnittstel-
len des Software-Werkzeugs beurteilt. Das Software-Werkzeug sollte intuitiv einsetzbar und die
Umsetzung in eigene Softwarelosungen schnell erlernbar sein. Insbesondere sollte das Software-
Werkzeug die Darstellung von Graphen, im Speziellen DAGs, in Form vorgefertigter Schnittstel-
len unterstutzen.
4.2.3 Ubersichtlichkeit
Mit diesem Kriterium soll die Ubersicht in der Graphendarstellung bei einer großen Anzahl an
Elementen im Graphen beurteilt werden. Hierbei sollte das Software-Werkzeug Moglichkeiten
bieten, beispielsweise Farbe, Form und Große von Knoten und Kanten des Graphen zu verandern,
zwischen gerichteten und ungerichteten Kanten zu unterscheiden und Knoten- und Kantenbe-
schriftungen zu definieren, um so eine bessere Ubersicht in der Darstellung des Graphen zu
erhalten.
1Vgl. Sun Microsystems, Inc.: http://java.sun.com/
16
4.3 Auswahl der Software-Werkzeuge
4.2.4 Erweiterbarkeit und Flexibilitat
Der Datenbestand von Cytomer wird kontinuierlich weiterentwickelt. Somit ist es moglich, dass
neue Anforderungen an die Visualisierung gestellt werden konnten. Das Software-Werkzeug soll-
te fur neue Anforderungen erweiterbar und flexibel an die neuen Bedurfnisse anpassbar sein.
Nur durch Erweiterbarkeit und Flexibilitat kann gewahrleistet werden, dass sich die Visualisie-
rungssoftware mit dem Datenbestand weiterentwickelt.
4.2.5 Dokumentation
Fur die Anwendung des Software-Werkzeugs ist eine vollstandige, ubersichtlich gegliederte, ver-
standliche und mit der Funktionalitat des Programms ubereinstimmende Dokumentation von
entscheidender Wichtigkeit. Die Dokumentation sollte dabei in Form von Javadoc2 zur Beschrei-
bung der Programmierschnittstellen als Manual, Tutorial, HowTo oder in Form haufig gestellter
Fragen (englisch: frequently asked questions, FAQ) zur Verfugung stehen. Wunschenswert sind
daruber hinaus quelloffene Beispielprogramme, welche die Funktionen des Software-Werkzeugs
veranschaulichen.
4.3 Auswahl der Software-Werkzeuge
Fur die Visualisierung von Daten und deren Zusammenhangen existieren eine Vielzahl von
Software-Werkzeugen. Durch die Aufgabenstellung (Abschnitt 3.1) und den Kriterienkatalog
(Abschnitt 4.2) wird die Auswahl indes schon eingeschrankt. So kommen beispielweise kommer-
zielle, nicht frei zur Verfugung stehende Werkzeuge wie etwa SemanticWorks – Visueller RDF-
und OWL-Editor fur das Semantic Web3 oder aiSee – Graphvisualisierung4 fur die Implementie-
rung der Visualisierung der OntoScope-Software nicht in Frage. Andere Software-Werkzeuge wie
etwa Graphviz – Graph Visualization Software5 oder IsaViz – A Visual Authoring Tool for RDF 6
sind statische, nicht dynamische Visualisierungswerkzeuge und somit ebenfalls ungeeignet.
Fur die Implementierung der Visualisierung in OntoScope zeigen sich die Software-Werkzeuge
prefuse7 und JUNG8 als geeignet. Im Rahmen dieser Arbeit werden diese beiden Werkzeuge
analysiert und durch die Implementierung des Beispielgraphen beurteilt. Im Folgenden werden
die beiden Software-Werkzeuge anhand des Kriterienkatalogs ausfuhrlich analysiert.
2Vgl. Sun Developer Network : http://java.sun.com/j2se/javadoc/3Vgl. Altova, Inc.: http://www.altova.com/products/semanticworks/semantic_web_rdf_owl_editor.html4Vgl. AbsInt Angewandte Informatik GmbH : http://www.aisee.com/5Vgl. AT&T Labs, Inc.: http://www.graphviz.org/6Vgl. World Wide Web Consortium: http://www.w3.org/2001/11/IsaViz/7Vgl. Berkeley Institute of Design: http://www.prefuse.org/8Vgl. JUNG Framework Development Team: http://jung.sourceforge.net/
17
Kapitel 4 Analyse
4.4 Bewertung
Die Bewertung der Software-Werkzeuge basiert neben den definierten Entscheidungskriterien im
Wesentlichen auf der Implementierung eines Beispielgraphen. Anhand dieses Beispielgraphen soll
moglichst die gesamte Funktionalitat der Software-Werkzeuge getestet werden. Somit sollte es
abschließend moglich sein, das am besten geeignete Software-Werkzeug fur die Implementierung
der OntoScope-Software auszuwahlen. Abbildung 4.1 zeigt diesen Beispielgraphen. Er enthalt
Auszuge des abstrakten Ontologiemodells von Cytomer und eine kleine anschauliche Auswahl
an Elementen der Ontologie mit entsprechenden Beziehungen untereinander. Die Beziehungen
sind durch einfache, ungerichtete Kanten dargestellt. Die Klassenzugehorigkeiten der einzelnen
Elemente wurden in diesem Beispielgraphen farblich voneinander abgehoben. Die einzelnen Be-
ziehungstypen zwischen den Klassen des abstrakten Ontologiemodells untereinander (isA) und
zwischen den Elementen der Ontologie untereinander (z.B. isPartOf oder hasPart) sind in die-
sem Beispielgraph nicht auf verschiedene Weise dargestellt. In der Implementierung durch die
Software-Werkzeuge sollten die verschiedenen Beziehungstypen jedoch durch Farbe oder Form
zu unterscheiden sein.
Abbildung 4.1: Beispielgraph als Bewertungsgrundlage Dieser Graph dient alsBewertungsgrundlage fur die Analyse der Software-Werkzeuge. Er enthalt allewichtigen Elemente einer Ontologie-Darstellung wie beispielsweise verschiedeneBeziehungstypen von Elementen untereinander und unterschiedliche Klassenzu-gehorigkeiten der Elemente. Auf diese Weise sollte eine aussagekraftige Analysemoglich sein.
18
4.4 Bewertung
4.4.1 prefuse
Das Open-Source-Projekt und Visualization Toolkit prefuse [prefuse 2006] ist eine graphische
Benutzerumgebung zur dynamischen und interaktiven Visualisierung von sowohl strukturierten
als auch unstrukturierten Daten und bietet umfangreiche Klassen und Programmierschnittstel-
len in der Programmiersprache Java zur Integration in eigene Softwarelosungen. prefuse verfugt
uber viele Funktionen, welche fur eine flexible und skalierbare Darstellung von großen Daten-
mengen wichtig sind. Fur eine Datenquelle konnen mehrere Visualisierungen mit verschiedenen
Ansichten, sogenannten Layouts, erstellt werden. Das Paket bietet Werkzeuge fur Farb-, Großen-
und Formkodierungen und graphische Transformationen wie etwa das Andern des Fokus. Fur
die Visualisierung mit prefuse werden zuerst die Daten eingelesen und in einem abstrakten Da-
tentyp gespeichert. Anschließend werden die Daten uber einen oder mehrere Renderer, welche
visuelle Attribute wie Position oder Form der Elemente auswerten, auf dem Bildschirm angezeigt
[Heer et al. 2005].
Lizenzierung der Software prefuse ist unter der Berkeley Standard Distribution-Lizenz (kurz:
BSD-Lizenz) lizenziert und kann somit frei und kostenlos genutzt, kopiert, verandert und
verbreitet werden. Einzige Bedingung der BSD-Lizenz ist, dass ein Programmierer, der eine
unter der BSD-Lizenz stehende Software verandert und verbreitet, den Copyright-Vermerk
des ursprunglichen Programms nicht entfernen darf. prefuse ist zudem eine Open-Source-
Softwarebibliothek und wird von den Entwicklern stetig erweitert und verbessert.
API-Funktionsumfang Die API9 von prefuse ist in eine klare und umfangreiche Paket-
struktur aufgeteilt. Folglich sollte ein Einstieg in die Arbeit mit prefuse problemlos
moglich sein. Die API bietet speziell fur die Darstellung von Graphen eigene Pakete
(prefuse.action.layout.graph) und Klassen (z.B. prefuse.data.Graph). Darin wer-
den Moglichkeiten bereitgestellt, gerichtete und ungerichtete Graphen voneinander zu un-
terscheiden und verschiedene Graph-Layouts zur Verfugung gestellt, welche die Elemente
und deren Position im Graphen nach verschiedenen Kriterien plazieren. Jedes Element im
Graphen kann als VisualItem verschiedene Eigenschaften erhalten, welche durch einen
Renderer auf dem Bildschirm dargestellt werden konnen. Uber ein Display, welches Teil
der visuellen Abstraktion Visualization ist, sowie durch vordefinierte Kontrollelemente
(prefuse.controls) und Aktionen (prefuse.action) kann eine interaktive Visualisie-
rung erreicht werden. Somit sind diverse Manipulations- und individuelle Anpassungsmog-
lichkeiten fur die Visualisierung von Daten gegeben.
Ubersichtlichkeit Die Ubersicht in der Darstellung der Elemente kann durch verschiedene
Schnittstellen verbessert werden. So kann beispielsweise die Farbe, Form und Große eines
Elements oder einer Gruppe von Elementen in der Darstellung individuell angepasst wer-
den (prefuse.action.assignment). Durch Schnittstellen im Paket prefuse.data konnen
Daten in verschiedenen Darstellungsarten als Graph oder Tree organisiert werden. Mit Hil-
fe von zahlreichen Layoutalgorithmen im Paket prefuse.action.layout und speziell fur
9Vgl. prefuse API Documentation: http://www.prefuse.org/doc/api/
19
Kapitel 4 Analyse
Graphen in prefuse.action.layout.graph kann zudem die Anordnung der Elemente in
der Darstellung beeinflusst und somit die Ubersicht individuell angepasst werden. Au-
ßerdem konnen einzelne Elemente interaktiv ausgewahlt und beispielsweise zur besseren
Ubersicht in der Darstellung individuell verschoben werden.
Erweiterbarkeit und Flexibilitat Allein durch die umfangreiche API und die darin bereitgestell-
ten Schnittstellen ist ein hohes Maß an Erweiterbarkeit und Flexibilitat in der Visualisie-
rung mit prefuse gewahrleistet. Daruber hinaus kann prefuse als Open-Source-Projekt
von einer Vielzahl von Benutzern selbst weiterentwickelt oder kann selbst an eigene Be-
durfnisse angepasst werden.
Dokumentation Die API von prefuse ist sehr umfangreich und sehr ausfuhrlich dokumentiert.
Leider ist demgegenuber das online bereit gestellte User Manual10 sehr luckenhaft und
erschwert so eine intensive Anwendung. Dort werden nur die grundlegenden Funktionen
kurz beschrieben. Der Abschnitt uber die Visualisierung mit prefuse fehlt ganzlich. Die
haufig gestellten Fragen fallen bei prefuse leider auch sehr kurz aus. Ein paar wenige Pro-
grammbeispiele werden bereit gestellt, verdeutlichen allerdings auch nur die grundlegenden
Eigenschaften der Funktionen und die Anwendung der Schnittstellen.
Abbildung 4.2: Umsetzung des Beispielgraphen mit prefuse Die Kriterien furdie Analyse wurden an diesem Beispielgraph von prefuse zum Großteil um-gesetzt. Die Klassenzugehorigkeiten sind farblich voneinander zu unterscheiden.Einzig die verschiedenen Beziehungstypen konnten im Rahmen dieser Analysemit prefuse nicht mehr implementiert werden.
prefuse erfullt die in dieser Arbeit definierten Kriterien mit oben beschriebenen Einschrankun-
gen. Abbildung 4.2 zeigt das Resultat der Implementierung des Beispielgraphen. Die Anforde-
rungen konnten zum Großteil umgesetzt werden. Auf Grund des luckenhaften User Manuals
10Vgl. prefuse User’s Manual : http://www.prefuse.org/doc/manual/
20
4.4 Bewertung
und der wenigen Programmbeispiele erwies es sich jedoch als schwierig, im Rahmen der Analyse
alle wichtigen Funktionen der Visualisierung zu testen und im Beispielgraphen zu implementie-
ren. Gerade fur eine intensive Anwendung mit einem Software-Werkzeug sollten ausfuhrlichere
Beispiele die Funktionen veranschaulichen. Die Arbeit allein mit der API gestaltet sich eher
schwierig. Den Uberblick uber die Funktionen der Schnittstellen zu wahren, wird somit erheb-
lich erschwert. Aus diesem Grund war es im Rahmen dieser Analyse nicht mehr moglich, die
verschiedenen Beziehungstypen im Beispielgraphen durch unterschiedliche Farben oder Formen
zu implementieren, wenngleich passende Schnittstellen zur Verfugung standen.
4.4.2 JUNG
JUNG, das Java Universal Network/Graph Framework [JUNG 2006] ist eine allgemein anwend-
bare, flexible und machtige Open-Source-Softwarebibliothek zur dynamischen Visualisierung,
Modellierung und Analyse von Daten, die als Graph oder Netzwerk reprasentiert werden kon-
nen. JUNG bietet einfache und erweiterbare Programmierschnittstellen fur die Programmier-
sprache Java und beinhaltet eine große Anzahl von Algorithmen aus der Graphentheorie wie
zum Beispiel Filtering, Optimierung oder Clustering. Das Framework unterstutzt eine Vielzahl
von Darstellungs- und Manipulationsmoglichkeiten einzelner Elemente und deren Beziehungen
untereinander, beispielsweise gerichtete und ungerichtete Graphen, Hypergraphen und Subgra-
phen. Die einzelnen Elemente der Visualisierung konnen durch Metadaten annotiert werden.
Wie auch bei prefuse konnen bei JUNG fur die Daten mehrere Visualisierungslayouts ver-
wendet werden. Die Visualisierung kann durch verschiedene Schnittstellen individuell in Farbe,
Form und Große, sowie durch Knoten- und Kantenbeschriftungen oder Transformationen der
Darstellung angepasst werden [O’Madadhain et al. 2003].
Lizenzierung der Software JUNG ist ebenfalls unter der BSD-Lizenz lizenziert und darf so-
mit uneingeschrankt und kostenlos genutzt, kopiert, verandert und verbreitet werden. Als
Open-Source-Softwarebibliothek wird JUNG uberdies kontinuierlich weiterentwickelt und
verbessert und kann selbst an eigene Bedurfnisse angepasst und erweitert werden.
API-Funktionsumfang Die API11 von JUNG ist sehr umfangreich und enthalt eine große Anzahl
gut und klar strukturierter Pakete. Alle Schnittstellen zur Darstellung, Implementierung,
Manipulation und Annotation von Graphen ist unter dem Paket jung.graph ubersichtlich
zusammengefasst. Die Schnittstellen zum Zeichnen und Rendern von Graphen werden im
Paket jung.visualization klar strukturiert und uberschaubar aufgelistet. Eine Visuali-
sierung mit JUNG setzt sich aus drei Teilen zusammen: einer graphischen Komponente Vi-
sualizationViewer zur Integration in eine graphische Benutzeroberflache (Java-Swing),
einem Renderer, der entscheidet, wie die einzelnen Elemente eines Graphen zu zeichnen
sind, und einem Layout, welches die Positionen der Elemente eines Graphen definiert und
festlegt. Unter dem Paket jung.algorithms sind außerdem zahlreiche Algorithmen aus der
Graphentheorie, wie beispielsweise Clustering, Optimierung oder Transformationen von
11Vgl. JUNG API Documentation: http://jung.sourceforge.net/doc/api/
21
Kapitel 4 Analyse
Graphen zur Verfugung gestellt. Einzelne Elemente im Graphen konnen durch sogenannte
UserData annotiert und mit Eigenschaften versehen werden. Mit Hilfe der Schnittstellen im
Paket jung.graph.decorators und den annotierten Eigenschaften kann die Darstellung
der einzelnen Elemente eines Graphen individuell manipuliert und angepasst werden. In
Verbindung mit Schnittstellen zur Implemenierung von Mausaktionen und Graphmanipu-
lationen unter jung.visualization.control kann somit eine interaktive Visualisierung
von Daten als Graph oder Netzwerk realisiert werden.
Ubersichtlichkeit Wie schon angesprochen, kann uber vordefinierte Schnittstellen im Paket
jung.graph.decorators die Darstellung einzelner Elemente im Graph individuell an-
gepasst werden. Mit Hilfe dieser zahlreichen Schnittstellen kann auf einfache Weise die
Farbe, Große und Form von einzelnen Knoten und Kanten des Graphen nach eigenen
Bedurfnissen verandert werden. JUNG stellt zudem im Paket jung.visualization ei-
ne große Menge von Layoutalgorithmen, verschiedene Renderer und Anpassungs- und
Manipulationsmoglichkeiten einzelner Elemente des Graphen zur Verfugung. Mit den vor-
definierten Layouts konnen die Elemente eines Graphen dem Algorithmus entsprechend
angeordnet und positioniert werden. Durch Schnittstellen zu Mausaktionen im Paket
jung.visualization.control werden außerdem zahlreiche Moglichkeiten zum individu-
ellen Verschieben und Transformieren einzelner Elemente des Graphen angeboten. Dem-
zufolge kann die Ubersichtlichkeit der Darstellung von Daten als Graph oder Netzwerk
muhelos und individuellen Bedurfnissen entsprechend angepasst werden.
Erweiterbarkeit und Flexibilitat Auch JUNG bietet als Open-Source-Projekt ein hohes
Maß an Erweiterbarkeit und Flexibilitat. Beispielsweise enthalt die API im Paket
jung.visualization.contrib zusatzliche Layoutalgorithmen zur Visualisierung, welche
von Benutzern selbst entwickelt wurden. JUNG lasst sich demnach auf einfache Weise er-
weitern und an individuelle Bedurfnisse anpassen. Zudem ist die API sehr umfangreich
und bietet zahlreiche vordefinierte Schnittstellen zur Umsetzung eigener Anforderungen.
Die API von JUNG ist speziell auf die Visualisierung von Graphen und Netzwerken aus-
gerichtet und bietet somit gerade in diesem Bereich eine beachtliche Flexibilitat.
Dokumentation Die API von JUNG ist gut kommentiert und dokumentiert, jedoch nicht ver-
gleichbar mit der umfangreichen Dokumentation der prefuse-API. Fur den Einstieg in
die Arbeit mit JUNG ist dies allerdings ausreichend. Im Gegensatz dazu bietet JUNG ein
sehr gutes und umfangreiches Online-Manual12, eine ausfuhrliche FAQ und eine ausge-
zeichnete Online-Dokumentation ausschließlich zu Funktionalitaten der Visualisierung von
JUNG13. Daruber hinaus werden zahlreiche Programmbeispiele14 online zur Verfugung ge-
stellt, welche nahezu alle Moglichkeiten und Funktionsweisen der JUNG-Schnittstellen zur
Visualisierung von Daten verdeutlichen. Diese Programmbeispiele sind allesamt quelloffen
und ermoglichen dadurch einen problemlosen Einstieg in die Arbeit mit JUNG.
12Vgl. JUNG Framework Manual : http://jung.sourceforge.net/doc/manual.html13Vgl. Understanding the JUNG Visualization System:
http://jung.sourceforge.net/doc/JUNGVisualizationGuide.html14Vgl. JUNG Examples: http://jung.sourceforge.net/applet/
22
4.4 Bewertung
Die in dieser Arbeit definierten Kriterien und Anforderungen erfullt JUNG vollstandig. Das
Ergebnis der Implementierung des Beispielgraphen mit JUNG zeigt Abbildung 4.3. Die An-
forderungen an die Beispielvisualisierung konnten allesamt umgesetzt werden. Die Arbeit mit
JUNG wurde durch die große Anzahl an quelloffenen Programmbeispielen enorm erleichtert
und die Einarbeitung in die Funtionalitaten der Visualisierung war mit der sehr guten Online-
Dokumentation zur Visualisierung muhelos moglich. Der Schwerpunkt auf die Visualisierung von
Graphen und Netzwerken erleichtert daruber hinaus die Arbeit mit JUNG in hohem Maße. Die
Pakete und Schnittstellen sind sehr ubersichtlich und intuitiv bedienbar. Die Anpassungs- und
Manipulationsmoglichkeiten der Ubersichtlichkeit und Darstellung von einzelnen Elementen ei-
nes Graphen gestalten sich in Verbindung mit den Eigenschaften einzelner Elemente (UserData)
problemlos und fuhren somit zu einem sehr guten Resultat. Beispielsweise sind die verschiede-
nen Beziehungstypen und Klassenzugehorigkeiten der einzelnen Elemente des Graphen durch
unterschiedliche Farben sehr gut voneinander zu unterscheiden.
Abbildung 4.3: Umsetzung des Beispielgraphen mit JUNG Die Implementie-rung des Beispielgraphen mit JUNG erfullt die Kriterien der Analyse voll undganz. Somit konnten alle Anforderungen mit JUNG umgesetzt werden. Das Er-gebnis ist eine sehr gute Ubersichtlichkeit durch farblich abgegrenzte Elemente.
23
Kapitel 4 Analyse
4.5 Ergebnis der Analyse
In diesem Kapitel wurden die beiden Software-Werkzeuge prefuse und JUNG zur Analyse
ausgewahlt und auf ihre Funktionalitat zur Visualisierung von Daten hin beurteilt und bewertet.
Abschließend lasst sich feststellen, dass JUNG zur Darstellung und Visualisierung der Cytomer-
Ontologie in OntoScope am besten geeignet erscheint. Die Implementierung des Beispielgraphen
konnte sehr gut umgesetzt werden. Die Ubersichtlichkeit und Dokumentation konnten als sehr
gut bewertet werden. Gerade fur eine intensive Arbeit mit einem Software-Werkzeug sind
quelloffene Programmbeispiele und gute Funktionalitatsbeschreibungen mit entsprechenden Co-
debeispielen in Form von Manuals oder Tutorials von entscheidender Wichtigkeit. Fehlen diese
Dokumentationen oder sind luckenhaft, gestaltet sich die Arbeit mit dem Software-Werkzeug
und seinen Schnittstellen sehr schwierig. Tabelle 4.1 zeigt zum Abschluss der Analyse von
prefuse und JUNG die Bewertungen der einzelnen Kriterien aus Abschnitt 4.2. Daraus ergibt
sich abschließend ein sehr gutes Ergebnis fur das Software-Werkzeug JUNG. Folglich wird die
Visualisierung der Daten aus der Cytomer-Ontologie in OntoScope mit JUNG realisiert. Hierbei
wird der VisualizationViewer als grundlegende graphische Komponente von JUNG in die
graphische Benutzeroberflache von OntoScope integriert. Da der VisualizationViewer das
Java-Swing-JPanel erweitert, sollte diese Integration problemlos moglich sein.
Tabelle 4.1: Bewertung der Software-Werkzeuge prefuse und JUNG.
prefuse JUNG
Lizenzierung ++ ++API-Funktionsumfang + +
Ubersichtlichkeit + ++Erweiterbarkeit und Flexibilitat + +Dokumentation + ++
Bewertung + (1,8) ++ (1,4)
++ Sehr gut (1), + Gut (2), ⊚ Befriedigend (3), ⊖ Ausreichend (4), − Mangelhaft (5)
24
Kapitel 5
Implementierung
In diesem Kapitel wird die Implementierung der einzelnen Bestandteile des Tools OntoScope be-
schrieben. OntoScope soll den Datenbestand von Cytomer in anschaulicher Weise visualisieren.
Dem Benutzer soll eine Suche nach einzelnen Elementen der Ontologie zur Verfugung stehen
und es ermoglichen, die Darstellung der verschiedenen Beziehungstypen der einzelnen Elemente
untereinander je nach Interessensschwerpunkt zu wahlen. In der Visualisierung der Daten wird
nur ein Ausschnitt des gesamten Datenbestands sichtbar sein, und der Benutzer soll nach dem
“Lichtkegel-Prinzip” im gesamten Datenbestand navigieren konnen. So soll es moglich sein, neue
Nachbarelemente in die Darstellung aufzunehmen oder bestimmte Elemente aus der Darstellung
wieder zu entfernen. Daruber hinaus sollen dem Benutzer alle assoziierten Informationen des
gesuchten Elements angezeigt werden. Die Daten sollen interaktiv dargestellt werden, so dass
der Benutzer verschiedene Visualisierungslayouts wahlen oder durch eine Neupositionierung ein-
zelner Elemente selbst die Darstellung verandern kann.
5.1 Grundlegende Datentypen
Die Visualisierung von OntoScope basiert im Wesentlichen auf der Darstellung von Elemen-
ten einer Ontologie und den Beziehungen verschiedener Elemente untereinander. Jedes Element
wird in der OWL-Ontologie als OWL-Klasse reprasentiert. Diese Klasse hat verschiedene Ei-
genschaften wie zum Beispiel Name, Nummer oder Beschreibung. Die Beziehungen zu anderen
Klassen werden in der OWL-Ontologie als Restriktionen uber eine bestimmte Eigenschaft (z.B.
isPartOf) beschrieben (siehe Abschnitt 2.5) oder ergeben sich aus der hierarchischen Elter-
Kind-Beziehung (Superklasse-/Subklasse-Beziehung).
5.1.1 OntologyClass
Der Datentyp OntologyClass ist die grundlegende Klasse von OntoScope. Alle Informationen
und Beziehungen werden aus dem Datenbestand gesammelt und entsprechende Objekte erzeugt,
woraus ein Graph abgeleitet und die Visualisierung aufgebaut werden kann. Eine Instanz einer
OWL-Klasse OntologyClass wird eindeutig durch ihren Namen identifiziert und enthalt Listen
von Informationen uber ihre Eigenschaften (properties) sowie uber Elter- oder Kindklassen
25
Kapitel 5 Implementierung
(subClasses, superClasses). Neben den Elter-Kind-Beziehungen gibt es weitere Beziehungen
zu anderen Elementen der Ontologie uber eine bestimmte Eigenschaft wie z.B. isPartOf oder
isCellOf. So konnen beispielsweise Statements wie “[Organ] is part of [System]” oder “[Cell]
is cell of [Organ]” beschrieben werden. Aus diesen Aussagen werden schließlich someValues-
From-Restriktionen abgeleitet. Bei dieser Art von Restriktion kann eine spezielle Klasse eine
Einschrankung fur eine Property haben, die besagt, dass mindestens ein Wert dieser Eigenschaft
von einem bestimmten Typ ist. Alle Restriktionen einer OntologyClass werden in der Liste
restrictions gespeichert. Abbildung 5.1 zeigt das Klassendiagramm einer OntologyClass.
OntologyClass
name: String
properties: OntologyProperty[0...*]
property: HashMap
restrictions: OntologyRestriction[0...*]
subClasses: OntologyClass[0...*]
superClasses: OntologyClass[0...*]
getName(): String
getProperties(): Vector
getPropertyMap(): HashMap
getRestrictions(): Vector
getRestrictionsOnProperty(in propertyName: String): Vector
getSubClasses(): Vector
getSuperClasses(): Vector
setName(in name: String)
setProperties(in properties: OntologyProperty[0...*])
setPropertyMap(in property: HashMap)
setRestrictions(in restrictions: OntologyRestriction[0...*])
setSubClasses(in subClasses: OntologyClass[0...*])
setSuperClasses(in superClasses: OntologyClass[0...*])
Abbildung 5.1: OntologyClass Eine OntologyClass ist die grundlegenste Klassevon OntoScope. Sie wird durch ihren Namen eindeutig identifiziert und enthaltListen von Eigenschaften, Restriktionen und Sub- bzw. Superklassen.
5.1.2 OntologyRestriction
Wie im vorherigen Abschnitt schon angesprochen, kann eine OWL-Klasse verschiedene Be-
ziehungstypen zu anderen OWL-Klassen als Eigenschaft enthalten. Eine solche Ontology-
Restriction setzt sich aus eben dieser Eigenschaft (property), dem Bezug zur OWL-
Klasse, auf die sich die Restriktion bezieht (fillerText) und der Eigenschaft der Restrik-
tion selbst (fillerProperty) zusammen. So ergibt sich ein Statement nach dem Schema
“[OWL-Klasse] [Eigenschaft] [Restriktion] [Bezugsklasse]” wie beispielsweise “CellA isCellOf
owl:someValuesFrom OrganB”. Der Bezug zu einer anderen OWL-Klasse wird in einer Onto-
logyRestriction als String und nicht etwa als OntologyClass-Objekt im fillerText ge-
speichert. So werden OWL-Klassen, welche diesem Bezug entsprechen, erst initialisiert, wenn
26
5.2 Die Architektur von OntoScope
sie selbst fur die Darstellung benotigt werden. Abbildung 5.2 zeigt das Klassendiagramm einer
OntologyRestriction.
OntologyRestriction
fillerProperty: String
fillerText: String
name: String
onProperty: String
getFillerProperty(): String
getFillerText(): String
getName(): String
getOnProperty(): String
setFillerProperty(in fillerProperty: String)
setFillerText(in fillerText: String)
setName(in name: String)
setOnProperty(in onProperty: String)
Abbildung 5.2: OntologyRestriction Eine Restriktion definiert eine Beziehungzwischen zwei OWL-Klassen und setzt sich nach dem Schema “[OWL-Klasse][onProperty] [fillerProperty] [fillerText]”zusammen, also in etwa“CellA isCellOfowl:someValuesFrom OrganB”.
5.1.3 OntologyProperty
Eine OntologyProperty beschreibt eine Eigenschaft einer OWL-Klasse durch den Namen der
Eigenschaft (name) und einen zugehorigen Wert (value) wie zum Beispiel“nameGerman”fur den
Namen einer Eigenschaft und“Ohr”als zugehorigen Wert. Abbildung 5.3 zeigt das entsprechende
Klassendiagramm einer OntologyProperty.
OntologyProperty
name: String
value: String
getName(): String
getValue(): String
setName(in name: String)
setValue(in value: String)
Abbildung 5.3: OntologyProperty Die Eigenschaften einer OWL-Klasse werdenals OntologyProperty-Objekt definiert und setzen sich aus dem Namen der Ei-genschaft und einem zugehorigen Wert zusammen, beispielsweise“nameEnglish:ear”.
5.2 Die Architektur von OntoScope
Das Tool OntoScope gliedert sich in drei Teile: die graphische Benutzeroberflache OntoScope
(englisch: graphical user interface, GUI), eine Datenschnittstelle OntologyConnector und einen
27
Kapitel 5 Implementierung
Abbildung 5.4: OntoScope Schema OntoScope gliedert sich in drei Teile: derGUI OntoScope und dem Schnittstellenadapter ConnectorAdapter auf Client-seite, sowie der Datenschnittstelle OntologyConnector und dem Java-ServletOntologyConnectorServlet als Teil des ConnectorAdapters auf Serverseite.
Schnittstellenadapter ConnectorAdapter (siehe Abbildung 5.4). Der Schnittstellenadapter regelt
die Verbindung zwischen OntoScope und OntologyConnector entsprechend der Zugriffsart: ein
lokaler Zugriff wird durch den ConnectorLocalAdapter und ein webbasierter Zugriff uber einen
Internetbrowser durch den ConnectorServletAdapter geregelt.
28
5.3 Die Datenschnittstelle OntologyConnector
5.3 Die Datenschnittstelle OntologyConnector
Der Datenbestand von Cytomer wurde im Rahmen einer Projektarbeit als OWL-Ontologie er-
weitert und zur Annotation und Weiterentwicklung der Daten im Protege Ontology Editor im-
portiert [Ricanek 2006]. Die Daten werden als Protege-Projekt verwaltet und uber Schnittstellen
der Protege OWL API (siehe Abschnitt 2.3) kann auf diese Daten zugegriffen werden.
Die Weiterentwicklung der Daten der Ontologie durch Protege wird mit Hilfe des Protege OWL
Plugins durchgefuhrt. Um Konsistenz der Schnittstellendefinitionen mit Protege zu wahren und
Datenintegritat zu gewahrleisten, basiert die Datenanbindung von OntoScope ebenfalls auf den
Schnittstellen der Protege OWL API. Beispielsweise ware es moglich, OntoScope zukunftig um
einen Schreibzugriff auf den Datenbestand der Ontologie zu erweitern. Somit ware eine Weiter-
entwicklung der Ontologie auch mit OntoScope moglich. Durch die Verwendung gleicher Schnitt-
stellen ware dann die Integritat der Daten und somit die Konsistenz des Datenbestands gewahr-
leistet. Naheres dazu beschreibt Abschnitt 6.2.
Im Folgenden werden die einzelnen Anfragemoglichkeiten an den OntologyConnector anhand
von Pseudocode-Beschreibungen bzw. Codeausschnitten vorgestellt.
Bevor eine Anfrage an den Datenbestand gestellt werden kann, muss die Verbindung durch das
Laden der Ontologie in das OWL-Modell (siehe Abschnitt 2.4) aufgebaut werden. Das Laden des
Modells erfolgt mit einem Protege-Projekt uber eine URI oder URL beim Starten der Software.
Nachdem das Modell geladen wurde, steht durch die Schnittstellen der Protege OWL API eine
Verbindung zum Datenbestand und somit auf die Instanzen und Klassen der Ontologie zur
Verfugung.
Wie schon im Abschnitt 5.1.1 beschrieben, ist eine OntologyClass das grundlegendste Element
von OntoScope. Nach dem Start der Software und dem erfolgreichen Laden des OWL-Modells
hat ein Benutzer die Moglichkeit, durch einen Suchstring (query) ein bestimmtes Element in
einem bestimmten Namensraum (prefix) zu suchen. Wird kein Namensraum angegeben, wird
versucht, ein passendes Element ohne Angabe des prefix zu finden. Ist nach der ersten Suche
das Ergebnis weiterhin leer, wird in allen vorhandenen Namensraumen gesucht (siehe Listing
5.1, Zeile 10). Hierbei wird als Platzhalter (englisch: wildcard) das Zeichen * fur ein oder mehr
beliebige Zeichen in der Suchanfrage benutzt. Am Ende bekommt der Benutzer als Ergebnis eine
Liste aller gefundenen Elemente, aus welcher er dann das passende Element auswahlen kann.
29
Kapitel 5 Implementierung
1 Anfrage getOntologyClassList(String prefix, String query):
2
3 1.) WENN prefix nicht leer DANN
4 Suchstring ← prefix:query
5 SONST
6 Suchstring ← query
7 2.) Suche im OWL−Modell nach allen Elementen, die dem Suchstring entsprechen (maximale Anzahl der Treffer: 100):
8 owlModel.getClsNameMatches(String Suchstring, Integer 100)
9 3.) WENN Ergebnis == NULL DANN
10 Wiederhole Suche in allen Namensraumen mit Wildcard *:query
11 4.) Gib Ergebnisstring zuruck
Listing 5.1: getOntologyClassList(String prefix, String query)
Ist der exakte Name eines Elements der Ontologie bekannt, zum Beispiel durch vorheriges Suchen
in der Ontologie (siehe oben), kann dieses Element aus dem Datenbestand geholt werden. Hierbei
wird eine neue Instanz der OWL-Klasse OntologyClass erzeugt, mit allen Informationen befullt
und der Anfrage zuruckgegeben (Listing 5.2).
1 Anfrage getOntologyClass(String className):
2
3 1.) Erzeuge neues OntologyClass−Objekt
4 2.) Suche entsprechende OWL−Klasse im OWL−Modell:
5 owlModel.getOWLNamedClass(String className)
6 3.) WENN Ergebnis == NULL DANN
7 Gib NULL zuruck
8 SONST
9 Suche im OWL−Modell alle zugeordneten Informationen:
10 OWL−Properties owlClass.getRDFProperties():
11 Speichere OWL−Properties im OntologyClass−Objekt
12 OWL−Restrictions owlClass.getRestrictions():
13 Speichere OWL−Restrictions im OntologyClass−Objekt
14 OWL−SubClasses owlClass.getNamedSubclasses():
15 Speichere OWL−SubClasses im OntologyClass−Objekt
16 OWL−SuperClasses owlClass.getNamedSuperclasses():
17 Speichere OWL−SuperClasses im OntologyClass−Objekt
18 4.) Gib OntologyClass−Objekt zuruck
Listing 5.2: getOntologyClass(String className)
Listing 5.1 zeigt, wie ein Benutzer ein Element in der Ontologie suchen kann. Er hat dabei die
Moglichkeit, einen Namensraum anzugeben. In Listing 5.3 wird beschrieben, wie es moglich ist,
alle in der Ontologie vorhandenen Namensraume zu finden. So kann beispielsweise dem Benut-
zer vor der Suche eines Elements in der Ontologie eine Liste aller Namensraume zur Auswahl
angezeigt werden, aus welcher er dann einen passenden Namensraum fur die Suche auswahlen
kann.
30
5.4 Der Schnittstellenadapter ConnectorAdapter
1 Anfrage getNamespacePrefixes():
2
3 1.) Suche im OWL−Modell nach allen vorhandenen Namensraum−Prafixen:
4 owlModel.getNamespaceManager().getPrefixes()
5 2.) Gib Ergebnisstring aller Prafixe zuruck
Listing 5.3: getNamespacePrefixes()
5.4 Der Schnittstellenadapter ConnectorAdapter
Der Schnittstellenadapter ConnectorAdapter verbindet die graphische Benutzeroberflache
OntoScope mit der Datenschnittstelle OntologyConnector und entscheidet die Art des Zugriffs
auf den Datenbestand. Je nach benotigter Zugriffsart wird der passende ConnectorAdapter in-
itialisiert. Arbeitet ein Benutzer mit OntoScope direkt, also lokal auf dem Anwendungsserver
oder im Intranet der Abteilung, in der die Datenbank betrieben wird, wird als Schnittstellenad-
apter der ConnectorLocalAdapter initialisiert. Ist der Benutzer indes auf den Zugriff uber das
Web mit einem Webbrowser angewiesen, wird der ConnectorServletAdapter initialisiert.
Um zu verstehen, wie im Einzelnen ein Zugriff auf Datenbestande uber das Web ablauft und
welche Einschrankungen sich dabei ergeben, wird im Folgenden ein kleiner Exkurs uber die
Webprogrammierung mit Java aufgefuhrt.
5.4.1 Exkurs: Webprogrammierung mit Java
Grundsatzlich ist eine Datenbankanbindung durch eine clientseitige oder serverseitige Architek-
tur zu unterscheiden. Im ersten Fall wird die Anwendungslogik zum entfernten Client ubertragen
und dort in einer eigenen Umgebung ausgefuhrt. Im letzteren Fall wird die Applikationslogik
direkt am Server ausgefuhrt und nur noch die fertigen Ergebnisse an den Client ubertragen. Cli-
entseitige Anbindungen haben beispielsweise zum Vorteil, dass erweiterte Oberflachenfunktio-
nalitaten durch verschiedene GUI-Elemente moglich gemacht werden konnen. Die am weitesten
verbreitete Anbindungstechnik auf Clientseite sind Java-Applets. Bei serverseitigen Anbindun-
gen wird meist eine Webseite entsprechend der Anfrage auf Serverseite zusammengebaut, bevor
sie an den entfernten Client gesendet wird. Beispiele hierfur sind das Common Gateway Interface
(kurz: CGI), JavaServer Pages (kurz: JSP) oder Java-Servlets. Serverseitige Anbindungsarten
sind durch die Eigenschaften des HTTP-Protokolls und durch die eingeschrankten Moglichkei-
ten von HTML gekennzeichnet. So sind beispielsweise jegliche Oberflachenfunktionalitaten uber
GUI-Elemente eingeschrankt oder sogar ganzlich unmoglich [Kappel et al. 2002]. Im Folgenden
wird nur auf Java-Applets und Java-Servlets naher eingegangen.
31
Kapitel 5 Implementierung
5.4.1.1 Java-Applets
Java-Applets sind kleine Java-Programme, die auf einem Webserver abgelegt sind und bei einem
Aufruf durch einen entfernten Client zu diesem Client ubertragen und dort durch eine clienteige-
ne Java Virtual Machine (kurz: JVM) ausgefuhrt werden (siehe Abbildung 5.5). Das Applet ist
hierbei in eine HTML-Seite eingebettet (siehe Listing 5.4) und wird durch das Aufrufen dieser
Seite uber das HTTP-Protokoll an den Client ubertragen.
Abbildung 5.5: Applet Schema Ein Java-Applet wird durch den Aufruf einerWebseite vom Webserver an den entfernten Client gesendet und dort in ei-ner clienteigenen JVM ausgefuhrt. Zugriffe auf Systemressourcen außerhalb derSandbox sind aus Sicherheitsgrunden verboten und konnen nur durch den JavaSecurity Manager erlaubt werden.
1 <html>
2 <body>
3 <app le t code="applet.class" arch ive="archiv.jar" width="970" he ight="820"></ app le t
>
4 </body>
5 </html>
Listing 5.4: Einbettung eines Java-Applets in eine HTML-Seite
Die Zugriffsmoglichkeiten auf eine Datenbank und die Funktionalitaten eines Java-Applets sind
aus Sicherheitsgrunden stark eingeschrankt. Die Sicherheit von Java-Applets basiert vor allem
auf dem so genannten Sandbox-Modell. Ein Java-Applet darf nur in einer solchen Sandbox agie-
ren und wird somit vom Rest des Systems abgeschirmt. Zugriffe auf das System und andere
Ressourcen außerhalb der Sandbox sind grundsatzlich verboten. So konnen Java-Applets nor-
malerweise nur Verbindungen zu dem Server aufbauen, von dem das Applet selbst geladen wurde.
Das bedeutet, dass Datenbankserver und Webserver auf demselben System laufen mussen.
Mit Hilfe des Java Security Managers konnen jedoch teilweise bestimmte Zugriffe außerhalb der
Sandbox erlaubt werden. Dieser Sicherheitsmanager wird immer dann befragt, bevor potentiell
gefahrliche Operationen ausgefuhrt werden sollen. Auf diese Weise konnen beispielsweise Zugriffe
auf Systemressourcen oder auf das Dateiystem gestattet werden. Neben der Zugriffskontrolle
32
5.4 Der Schnittstellenadapter ConnectorAdapter
durch den Sicherheitsmanager konnte auch eine Kombination aus Java-Applet und Java-Servlet
Zugriffe auf Ressourcen außerhalb der Sandbox ermoglichen.
5.4.1.2 Java-Servlets
Java-Servlets sind serverseitige Anwendungen, welche in einem Webcontainer Anfragen von Cli-
ents entgegennehmen und beantworten. Eine Anfrage vom Client wird von einem Webserver
angenommen und an den Webcontainer weitergeleitet, welcher das Servlet anspricht. Das Serv-
let generiert eine entsprechende Antwort, welche vom Webcontainer uber den Webserver an
den Client zuruckgesendet wird. Der Inhalt einer Antwort besteht hierbei aus beliebigen Da-
ten, beispielsweise aus Daten einer Datenbank, insbesondere jedoch aus dynamisch erzeugten
HTML-Seiten.
Java-Servlets werden in einer servereigenen JVM ausgefuhrt, welche vom Webcontainer bereitge-
stellt wird. Ein Client benotigt also keine eigene lokale JVM, um die Funktionalitaten des Servlets
nutzen zu konnen. Da Servlets nicht auf das aus Sicherheitsgrunden bei Applets notige Sandbox-
Modell angewiesen sind, konnen sie die volle Funktionalitat der Java-Klassenbibliotheken nut-
zen, mit Ausnahme von GUI-Elementen [Kappel et al. 2002]. Mit der Kombination eines Java-
Applets ließen sich diese Einschrankung und die zuvor angesprochenen Zugriffsbeschrankungen
beheben. So konnte beispielsweise ein Java-Applet eine graphische Benutzeroberflache bieten
und mit Hilfe eines Java-Servlets auf einen entfernten Datenbankserver zugreifen. Das Applet
kommuniziert dabei ausschließlich mit dem auf dem Webserver arbeitenden Servlet, welches die
Verbindung zum Datenbankserver gewahrleistet (siehe Abbildung 5.6).
Abbildung 5.6: Servlet Schema Java-Servlets sind ahnlich zu Java-Applets eben-falls kleine Java-Programme, welche allerdings auf dem Server ausgefuhrt werdenund dort in der servereigenen JVM laufen. Sie generieren meist Webseiten mitdynamischen Inhalten ohne graphische Benutzeroberflache.
33
Kapitel 5 Implementierung
5.4.2 Lokaler Zugriff: ConnectorLocalAdapter
Arbeitet ein Benutzer mit OntoScope im abteilungseigenen Intranet, initialisiert die main-
Methode von OntoScope den Schnittstellenadapter ConnectorLocalAdapter, welcher eine Ver-
bindung uber den OntologyConnector zum Datenbestand bereitstellt. Der ConnectorLocal-
Adapter halt eine Instanz des OntologyConnectors bereit und leitet Anfragen an den Daten-
bestand an diese Instanz weiter. Eine Anfrage wie beispielsweise getOntologyClass(String
className) wird an die Instanz des OntologyConnectors weitergeleitet. Dieser generiert eine
entsprechende Antwort. Das resultierende Ruckgabeobjekt wird ohne jegliche Bearbeitung vom
ConnectorLocalAdapter zur anfragenden Methode zuruckgereicht.
5.4.3 Webbasierter Zugriff
Hat ein Benutzer keine Moglichkeit, OntoScope lokal zu verwenden, kann er stattdessen mit
einem Webbrowser eine Webseite aufrufen. Diese Webseite wird vom Java-Servlet Ontology-
ConnectorServlet generiert und enthalt ein eingebettetes Java-Applet, welches OntoScope in
einem Applet-Modus startet. Im Applet-Modus wird die Software nicht mit der main-Methode
gestartet, die Initialisierung ubernimmt das Applet. Somit wird statt des ConnectorLocal-
Adapters der ConnectorServletAdapter initialisiert, welcher den Zugriff auf den Datenbestand
regelt.
Bei der Kommunikation zwischen Applet und Servlet uber Datenstrome, beispielsweise zur Uber-
tragung von Daten uber Netzwerke, ist es wichtig, dass alle Objekte, die versendet oder emp-
fangen werden, serialisierbar sind, d.h. das Java-Interface Serializable implementieren. Seria-
lisierung bezeichnet das Umwandeln von Datenstrukturen in ein Format, welches es ermoglicht,
diese in einer Nachricht zu verschicken. Der Empfanger der Nachricht extrahiert die Datenele-
mente und kann so die Datenstruktur wiederherstellen. Bei der Implementierung von OntoScope
und einem webbasierten Zugriff musste also darauf geachtet werden, dass nur Objekte uber
die Leitung geschickt werden, welche auch serialisierbar sind. So muss beispielsweise auch eine
OntologyClass das Java-Interface Serializable implementieren.
5.4.4 Webbasierter Zugriff: Anfrage (ConnectorServletAdapter)
Der ConnectorServletAdapter kommuniziert uber eine URLConnection mit dem Java-Servlet,
welches beim Aufrufen der Webseite OntoScope als Java-Applet gestartet hat. Eine Anfrage vom
Applet wird hierbei durch einen ObjectOutputStream uber das HTTP-Protokoll an das Servlet
geschickt (siehe Listing 5.5, Zeile 5). Mit Hilfe eines ObjectInputStreams wird anschließend
die Antwort als Object vom Servlet empfangen (Zeile 8) und der anfragenden Methode als er-
wartetes Objekt zuruckgegeben. Beispielsweise erwartet das Applet beim Aufrufen der Methode
getOntologyClass(String className) ein OntologyClass-Objekt. Der ConnectorServlet-
Adapter nimmt diese Anfrage an, leitet sie an das Servlet weiter und gibt das empfangene Objekt
als OntologyClass-Objekt zum Applet zuruck.
34
5.4 Der Schnittstellenadapter ConnectorAdapter
1 URLConnection servletConnection = urlFromApplet.openConnection();
2 servletConnection.setRequestProperty("Content-Type","application/x-java-serialized-object");
3
4 ObjectOutputStream oos = new ObjectOutputStream(servletConnection.getOutputStream());
5 oos.writeObject(outputToServlet);
6
7 ObjectInputStream ois = new ObjectInputStream(servletConnection.getInputStream());
8 Object inputFromServlet = ois.readObject();
Listing 5.5: ConnectorServletAdapter (Auszug)
5.4.5 Webbasierter Zugriff: Antwort (OntologyConnectorServlet)
Das Java-Servlet OntologyConnectorServlet empfangt eine Anfrage (Request) vom Schnitt-
stellenadapter ConnectorServletAdapter und generiert eine entsprechende Antwort (Respon-
se), welche uber das HTTP-Protokoll an den anfragenden Client (Java-Applet) zuruckgesendet
wird. Dieses Java-Servlet halt, wie auch der ConnectorLocalAdapter, eine Instanz des Onto-
logyConnectors bereit und leitet die Anfragen an diese Instanz weiter.
Das Servlet erweitert die Java-Klasse HttpServlet und implementiert die beiden Methoden
doGet und doPost um die beiden wichtigen HTTP-Methoden GET und POST verarbeiten zu
konnen. GET ist die gebrauchlichste Methode, wenn ein Browser per HTTP ein Dokument, bei-
spielsweise eine Webseite, anfordert. POST ahnelt der GET-Methode, nur dass hier ein zusatzli-
cher Datenblock ubermittelt wird. In der Methode doGet wird zum Zeitpunkt des Servlet-Aufrufs
eine HTML-Seite generiert, in welcher die Software OntoScope als Java-Applet eingebettet wird
(siehe Listing 5.6, Zeilen 5–15).
1 protected void doGet(HttpServletRequest request, HttpServletResponse response)
2 throws ServletException, IOException {
3 response.setContentType("text/html");
4 PrintWriter out = response.getWriter();
5 out.println("<HTML>");
6 out.println("<HEAD><TITLE>OntoScope: Visualization of an Anatomical Ontology</TITLE></HEAD>");
7 out.println("<BODY>");
8 out.println("<APPLET " +
9 "code=\"de.sybig.cytomer.client.OntoScopeDriver.class\" " +
10 "archive=\"OntoScope-ext.jar\" " +
11 "width=\"970\" height=\"820\">" +
12 "OntoScope: Visualization of an Anatomical Ontology" +
13 "</APPLET>");
14 out.println("</BODY>");
15 out.println("</HTML>");
16 }
Listing 5.6: OntologyConnectorServlet: doGet (Auszug)
35
Kapitel 5 Implementierung
Die Methode doPost verarbeitet Anfragen vom Java-Applet und sendet entsprechende Antwor-
ten als Datenblock an das Applet zuruck. Eine Anfrage wird aus einem ObjectInputStream
gelesen (Listing 5.7, Zeile 5). Entspricht das empfangene Objekt einem bestimmten Typ, in die-
sem Fall einer Java-Map (Zeile 7), wird entschieden, welche Schnittstelle des OntologyConnector
aufgerufen wird, damit die passende Antwort generiert werden kann (Zeilen 11). Daraufhin wird
diese generierte Antwort uber einen ObjectOutputStream uber das HTTP-Protokoll an das
anfragende Java-Applet zuruckgesendet (Zeile 16).
1 protected void doPost(HttpServletRequest request, HttpServletResponse response)
2 throws ServletException, IOException {
3 response.setContentType("application/x-java-serialized-object");
4 ObjectInputStream inputFromApplet = new ObjectInputStream(request.getInputStream());
5 Object input = inputFromApplet.readObject();
6 Object output = null;
7 if (input instanceof Map) {
8 Map inputMap = (Map)input;
9 if (inputMap.size() == 1) {
10 String className = (String)inputMap.get("className");
11 output = getOntologyClass(className);
12 }
13 }
14 else if (...) // mache etwas anderes...
15 ObjectOutputStream oout = new ObjectOutputStream(response.getOutputStream());
16 oout.writeObject(output);
17 }
Listing 5.7: OntologyConnectorServlet: doPost (Auszug)
5.5 Die graphische Benutzeroberflache OntoScope
Arbeitet ein Benutzer mit der Software OntoScope, bekommt er eine graphische Benutzero-
berflache prasentiert, welche alle Optionen auf einen Blick vereint. Abbildung 5.7 zeigt dieses
OntoScope-GUI.
Der Bereich 5.7-1 zeigt die Visualisierung des interaktiven Graphen mit den gesuchten Elemen-
ten und Beziehungen. Nachdem der Graph aufgebaut wurde, hat der Benutzer die Moglichkeit,
ein Element seiner Wahl anzuklicken, um alle Informationen dieses Elements im Profile-Fenster
(5.7-2) angezeigt zu bekommen. Dort werden Informationen wie u.a. Name, Accessionnummer,
Definition aufgelistet. Zum Suchen eines Elements im Datenbestand hat der Benutzer mehrere
Eingabemoglichkeiten (5.7-3–5.7-5). Er kann den Beziehungstyp zu anderen Elementen auswah-
len, beispielsweise isPartOf oder hasPart (5.7-3), er kann einen Namensraum auswahlen, zum
Beispiel organ oder cell (5.7-4) und schließlich den Namen des gesuchten Elements im Suchfeld
eingeben (5.7-5). Bei der Eingabe des Namens kann als Platzhalter fur ein oder mehr belie-
bige Zeichen das Zeichen * in der Suchanfrage benutzt werden. So kann beispielsweise nach
36
5.5 Die graphische Benutzeroberflache OntoScope
1
2
3 4 5
6
7
Abbildung 5.7: OntoScope Screenshot Die graphische Benutzeroberflache vonOntoScope. (1) zeigt das Visualisierungsfeld, in welcher der Graph dargestelltwird. Das Profile-Fenster (2) enthalt nach der Auswahl eines Graph-Elementsalle assoziierten Informationen. Die Auswahlbox (3) zeigt dem Benutzer allezur Verfugung stehenden Beziehungstypen und die Auswahlbox (4) alle mogli-chen Namensraume. Unter (5) kann der Benutzer den Namen eines Elementseingeben und im Datenbestand suchen lassen. Die Auswahlmoglichkeiten unter(6) erlauben dem Benutzer interaktive Manipulationen am Graphen. Unter (7)kann der Benutzer abschließend den Graphen als Bilddatei speichern oder dasProgramm beenden.
*ear gesucht werden, wodurch alle Elemente im Datenbestand als Ergebnisliste angezeigt wer-
den, die mit dem Teilwort ear enden, zum Beispiel internal_ear. Nachdem die Suchanfrage
durch Drucken des Search-Buttons abgesendet wurde, erhalt der Benutzer eine Liste aller ge-
fundenen Elemente, aus welcher er das passende Element auswahlen kann. Anschließend wird
dieses Element als interaktiver Graph im Visualisierungsfeld (5.7-1) mit allen Nachbarelementen
entsprechend des zuvor definierten Beziehungstyps angezeigt.
Nach der erfolgreichen Suche und der Darstellung des Graphen im Visualisierungsfeld hat der
Benutzer die Moglichkeit, die Visualisierung des Graphen zu beeinflussen (siehe Optionen in der
Zeile 5.7-6). So kann er im Graphen hinein- und herauszoomen (Scale), das Layout des Graphen
andern (Layout Options) und Namenslabel fur die Elementknoten (Vertices) und -kanten (Edges)
anzeigen bzw. ausblenden lassen. Unter 5.7-7 kann ein Schnappschuss des Graphen aus dem
Visualisierungsfeld als Bilddatei gespeichert werden (Save Image). Außerdem kann der Benutzer
alle Elemente aus der Visualisierung entfernen, so dass kein Element mehr angezeigt wird (Reset
Graph). Schlussendlich kann er die Software beenden (Exit). Naheres zur Funktionsweise dieser
Optionen wird im nachsten Abschnitt 5.6 beschrieben. Der Ontologie-Cache (Ontology Cache)
37
Kapitel 5 Implementierung
ist in der aktuellen Version von OntoScope noch nicht implementiert, jedoch vorgesehen (siehe
Abschnitt 6.2).
5.6 Visualisierung mit JUNG
Die Visualisierung der Elemente einer Ontologie in OntoScope basiert, wie in Kapitel 4 entschie-
den, auf dem Softwarewerkzeug JUNG.
5.6.1 Die Graph-Visualisierung mit JUNG
Beim Starten der Software wird ein neuer Graph initialisiert, welcher alle Elemente und deren
Beziehungen je nach Suchanfrage enthalt. Ein solcher JUNG-Graph ist der wichtigste Bestand-
teil von JUNG und besteht aus Knoten (Vertex) und Kanten (Edge). Bei der Darstellung des
Graphen wird grundsatzlich zwischen dem Layout, welches die Positionen der Knoten im Gra-
phen definiert und einem Renderer, welcher gemaß diesen Vorgaben die Elemente des Graphen
zeichnet, unterschieden. Durch einen PluggableRenderer kann das Design des Graphen festge-
legt werden, beispielsweise kann der Graph auf verschiedene Weisen beschriftet oder die Farbe
der Bestandteile geandert werden. Die JUNG-Klasse VisualizationViewer vereint diese beiden
JUNG-Bestandteile und ist somit fur die komplette Darstellung des Graphen zustandig. Visua-
lizationViewer erbt von der Java-Klasse JPanel, so dass sie auf einfache Weise in eine Java-
Swing-Umgebung integriert werden kann, beispielsweise uber ein JUNG-GraphZoomScrollPane,
welches als Container fur den JUNG-VisualizationViewer dient. Listing 5.8 zeigt einen exem-
plarischen Codeausschnitt dieser grundlegenden JUNG-Konzepte.
1 // Initialisiere die graphischen Komponenten, in denen der Graph dargestellt wird ...
2 Graph graph = new DirectedSparseGraph();
3 PluggableRenderer pr = new PluggableRenderer();
4 Layout layout = new FRLayout(graph); // Ein Layout nach dem Fruchterman−Reingold−Algorithmus’
5 VisualizationViewer vv = new VisualizationViewer(layout,pr);
6 GraphZoomScrollPane panel = new GraphZoomScrollPane(vv);
Listing 5.8: Die Hautpbestandteile der Graph-Visualisierung mit JUNG
Durch Setter-Methoden der JUNG-Klassen lasst sich das Verhalten der Visualisierung individuell
anpassen. So zeigt Listing 5.9 das Andern der Hintergrundfarbe der Visualisierung (Background)
und die Setter-Methoden zum Anpassen der Knoten- und Kantenbeschriftung (VertexStringer,
EdgeStringer).
38
5.6 Visualisierung mit JUNG
1 // Passe die Visualisierung fur den VisualizationViewer vv und den PluggableRenderer pr individuell an ...
2 vv.setBackground(Color.white);
3 pr.setVertexStringer (...) ;
4 pr.setEdgeStringer (...) ;
5 // ...
Listing 5.9: Beispiele zur Anpassung der JUNG-Visualisierung
Nachdem das Aussehen und das Verhalten des Graphen festgelegt wurde, konnen durch Suchan-
fragen des Benutzers Knoten und Kanten zum Graphen hinzugefugt werden. Hierfur wird zu
Beginn die der Suchanfrage entsprechende Klasse und anschließend alle mit dieser Klasse ver-
knupften Nachbar- und Superklassen aus dem Datenbestand geholt. Diese Klassen werden als
Knoten dem Graphen hinzugefugt und durch Kanten miteinander verbunden.
Eine OntologyClass besitzt neben ihren Nachbar- und Superklassen zudem noch verschiedene
Eigenschaften (UserDatum) wie Name, Nummer oder Beschreibung. Diese Eigenschaften konnen
dem Knoten im Graphen entsprechend hinzugefugt werden, so dass dem Benutzer all diese
assoziierten Informationen im Profile-Fenster angezeigt werden konnen. Listing 5.10 zeigt das
Hinzufugen von Knoten und Kanten zum Graphen sowie das Hinzufugen der entsprechenden
Eigenschaften zu den Knoten.
1 Hinzufugen aller Knoten und Kanten entsprechend der Suchanfrage:
2
3 1.) Halte die Visualisierung an damit Anderungen im Graphen gemacht werden konnen:
4 vv.stop()
5 2.) Hole die dem Suchstring entsprechende OntologyClass aus dem Datenbestand:
6 OntologyClass elementClass = (OntologyClass) connector.getOntologyClass(query)
7 3.) Finde alle OntologyClass−Nachbarn dieser elementClass, welche dem ausgewahlten Beziehungstyps (relationType)
entsprechen:
8 elementClass.getRestrictionsOnProperty(relationType)
9 WIEDERHOLE
10 OntologyClass neighborClass = (OntologyClass) connector.getOntologyClass(neighborName)
11 SOLANGE
12 passende OntologyRestrictions existieren
13 Speichere alle gefundenen neighborClasses in einer Liste
14 4.) Finde alle Superklassen dieser elementClass:
15 WIEDERHOLE
16 OntologyClass superClass = (OntologyClass) elementClass.getSuperClasses()
17 SOLANGE
18 superClasses existieren
19 Speichere alle gefundenen superClasses in einer Liste
20 5.) Fuge die elementClass als Elter−Knoten und alle gefundenen neighborClasses und superClasses zum Graphen
hinzu
21 und verbinde diesen Elter−Knoten durch eine Kante mit allen gefundenen Nachbarn und Superklassen:
22 Vertex parentVertex = new DirectedSparseVertex()
23 graph.addVertex(parentVertex)
24 WIEDERHOLE
25 Vertex neighborVertex = new DirectedSparceVertex()
26 graph.addVertex(neighborVertex)
27 graph.addEdge(parentVertex, neighborVertex)
28 SOLANGE
29 Nachbarklassen in der Liste existieren
39
Kapitel 5 Implementierung
30 WIEDERHOLE
31 Vertex superclassVertex = new DirectedSparceVertex()
32 graph.addVertex(superclassVertex)
33 graph.addEdge(parentVertex, superclassVertex)
34 SOLANGE
35 Superklassen in der entsprechenden Liste existieren
36 6.) Fuge ggf. Namensbeschriftungen oder Eigenschaften zu den Knoten und Kanten hinzu:
37 1.) Namensbeschriftungen:
38 vertexStringer.setLabel(vertex, name)
39 2.) Eigenschaften:
40 vertex.addUserDatum(EIGENSCHAFT_ID, "Eigenschaft", UserData.SHARED)
41 edge.addUserDatum(EIGENSCHAFT_ID, "Beziehungstyp", UserData.SHARED)
42 7.) Starte die Visualisierung neu damit die Anderungen sichtbar werden:
43 vv.restart()
Listing 5.10: Hinzufugen von Knoten und Kanten zum Graphen
5.6.2 Interaktive Graph-Manipulation mit JUNG
In der graphischen Benutzeroberflache von OntoScope hat der Benutzer verschiedene Moglichkei-
ten, die Visualisierung (siehe Abschnitt 5.5) zu verandern. Jede Auswahlmoglichkeit ist hierbei
an einen Java-ActionListener geknupft, welcher die entsprechende Benutzerauswahl erkennt
und die passende Aktion veranlasst. Im Folgenden werden die verschiedenen Auswahlmoglich-
keiten im Einzelnen genauer beschrieben.
5.6.2.1 Zoom
Wenn der Graph im Visualisierungsfeld dargestellt wurde, hat der Benutzer die Moglichkeit,
im Graphen hinein- oder herauszuzoomen. Sind beispielsweise viele Knoten in der Darstellung
enthalten, so kann aus dem Graphen herausgezoomt werden, damit alle Knoten in der gesamten
Zeichenflache sichtbar sind. Listing 5.11 zeigt exemplarisch einen Codeausschnitt. Das Visuali-
sierungsfeldes wird hierbei jeweils um den Faktor 1.1 vergroßert bzw. verkleinert.
1 // Zoom in der Visualisierung ...
2 ScalingControl scaler = new CrossoverScalingControl();
3 // Vergroßere den Ausschnitt
4 scaler . scale (vv, 1.1f , vv.getCenter());
5 // Verkleinere den Ausschnitt
6 scaler . scale (vv, 1 / 1.1f , vv.getCenter());
Listing 5.11: Zoom im Graphen
40
5.6 Visualisierung mit JUNG
5.6.2.2 Namensbeschriftungen
Wahrend der laufenden Visualisierung ist es dem Benutzer moglich, die Beschriftungen von
Knoten und Kante ein- bzw. auszublenden, um somit die Ubersicht in der Darstellung bei einer
großen Anzahl von Elementen im Graphen zu verbessern. Hierfur kann er in einer Java-Swing-
JCheckBox entsprechende Haken setzen (siehe Abbildung 5.7-6). Im Folgenden wird zwischen
Knoten- und Kantenbeschriftungen unterschieden.
Knotenbeschriftung Ein Knoten im Graphen erhalt durch seine Initialisierung ein eindeutiges
Label (Listing 5.12, Zeile 4). Damit dieses Label im Graphen angezeigt wird, muss dem
Renderer der entsprechende StringLabeller ubergeben werden (Zeile 6). Um das Label
sichtbar zu machen, wird die Visualisierung schließlich neu gezeichnet (Zeile 7).
1 // Fuge ein Labelsatz zum Graphen hinzu ...
2 StringLabeller vs = StringLabeller.getLabeller(graph);
3 // Setze ein Label fur den Knoten vertex:
4 vs.setLabel(vertex, "some_unique_label");
5 // ...
6 pr.setVertexStringer(vs) ;
7 vv.repaint() ;
Listing 5.12: Setzen einer Knotenbeschriftung im Graphen
Kantenbeschriftung Fur die Beschriftung von Kanten sieht JUNG die Methode setEdgeStrin-
ger vor. Der ubergebene Parameter ist ein JUNG-EdgeStringer, welcher definiert, mit
welchem Label eine Kante beschriftet werden soll. Fur OntoScope wurde die Methode get-
Label dieses EdgeStringers so implementiert, dass als Label der Beziehungstyp zwischen
zwei Knoten angezeigt wird. Zeile 4 in Listing 5.13 zeigt, wie uber die Eigenschaften einer
Kante (UserDatum) die passende Kantenbeschriftung gesetzt wird. Im Moment der Benut-
zerauswahl wird dann dieser angepasste EdgeStringer dem Renderer ubergeben (Zeile 8)
und die Visualisierung neu gezeichnet (Zeile 9).
1 // Erstelle ein String−Label fur jede Kante...
2 EdgeStringer es = new EdgeStringer() {
3 public String getLabel(ArchetypeEdge e) {
4 return (String) e.getUserDatum("relationtype");
5 }
6 };
7 // ...
8 pr.setEdgeStringer(es);
9 vv.repaint() ;
Listing 5.13: Setzen einer Kantenbeschriftung im Graphen
41
Kapitel 5 Implementierung
5.6.2.3 Layout-Algorithmen
Die Anordnung der Knoten und Kanten im Graphen ist in JUNG durch verschiedene Layout-
Algorithmen moglich. Je nach Algorithmus werden die Knoten im Moment der Layout-Auswahl
neu angeordnet, so dass eine dem Algorithmus ensprechende Darstellung der Knoten im Gra-
phen erreicht wird. Im Folgenden werden die bei OntoScope zur Verfugung stehenden Layout-
Algorithmen und deren Funktionsweise kurz beschrieben.
CircleLayout Dieser Layout-Algorithmus ordnet die Knoten des Graphen zufallig auf einem
Kreis an. Die Knoten werden hierbei gleichmaßig auf dem Kreis angeordnet, sodass das
Layout eine naherungsweise symmetrische Darstellung bezuglich der Knoten auf dem Kreis
erhalt.
SpringLayout Ein Spring-Layout basiert auf den Anziehungs- bzw. Abstoßungskraften von Kno-
ten im Graphen zu anderen Knoten. Alle Knoten im Graphen stoßen sich ab, es sei denn,
zwei Knoten haben eine Kante gemeinsam. Hier wirkt die Anziehungskraft zwischen diesen
Knoten wie eine Feder gegen die Abstoßungskrafte. Somit werden Knoten, die miteinander
verbunden sind, moglichst nahe beieinander gezeichnet. Dieser Layout-Algorithmus termi-
niert nicht, die Knoten im Graphen werden also stets neu positioniert. Der Graph ist somit
kontinuierlich in Bewegung.
FRLayout Ein Layout nach dem Fruchterman-Rheingold -Algorithmus basiert ebenfalls auf dem
Kraftemodell und plaziert die Knoten in einem Graphen nach der idealen Entfernung der
Knoten abhangig von der Große der zur Verfugung stehenden Zeichenflache und der Kno-
tenanzahl. Bei diesem Layout werden Knoten, die miteinander verbunden sind, moglichst
dicht zueinander gezeichnet. Dabei wird im Allgemeinen großer Wert auf eine einheitliche
Kantenlange gelegt [Fruchterman u. Reingold 1991].
ISOMLayout Der Inverted-Self-Organizing-Map-Algorithmus (kurz ISOM) ist ein selbstlernen-
der Optimierungsalgorithmus, welcher fur die Positionierung der Knoten im Graphen das
Kraftemodell mit der Verteilung der Knoten in der gesamten Zeichenflache kombiniert
[Meyer 1998].
KKLayout Mit dem Layout nach dem Kamada-Kawai -Algorithmus werden Knoten im Gra-
phen auf Grundlage des kurzesten Pfades zwischen zwei Knoten moglichst symmetrisch
angeordnet [Kamada u. Kawai 1989].
Listing 5.14 zeigt das Andern des Layouts der Graph-Darstellung. Die Zeile 4 zeigt hierbei,
dass vor dem Andern des Layouts die Visualisierung angehalten werden muss, da durch das
Andern alle Knoten neu gezeichnet werden. Anschließend wird die Visualisierung neu gestartet
(Zeile 6).
42
5.6 Visualisierung mit JUNG
1 // Entferne das aktuelle Graph−Layout und setze ein neues...
2 Layout layout = new FRLayout(graph);
3 // ...
4 vv.stop() ;
5 vv.setGraphLayout(layout);
6 vv. restart () ;
Listing 5.14: Andern des Graph-Layouts
5.6.2.4 Mausaktionen
Der Benutzer kann neben der Wahl eines Layout-Algorithmus die Positionen der Knoten im Gra-
phen selbst bestimmen. Hierfur wird bei JUNG durch verschiedene Modi die Moglichkeit gege-
ben, Mausaktionen durch den Benutzer zu verarbeiten. Diese Modi sind bei OntoScope TRANS-
FORMING und PICKING. TRANSFORMING ermoglicht das Transformieren des Graphen als
Ganzes, sodass der Graph im Visualisierungsfeld verschoben (translate), gedreht (rotate) oder
verzerrt (shear) werden kann. PICKING erlaubt es, Knoten im Graphen einzeln auszuwahlen
und zu verschieben. Zeile 5 in Listing 5.15 zeigt, wie solch ein Modus gesetzt wird. Bei Onto-
Scope kann der Benutzer uber eine Auswahlbox zwischen den verschiedenen Modi wahlen (siehe
Abbildung 5.7-6).
1 // Installiere eine Standardauswahl von Plugins fur die Modi PICKING und TRANSFORMING...
2 DefaultModalGraphMouse graphMouse = new DefaultModalGraphMouse();
3 // Setze entweder den Modus TRANSFORMING oder PICKING...
4 graphMouse.setMode(ModalGraphMouse.Mode.TRANSFORMING);
5 vv.setGraphMouse(graphMouse);
6 // ...
7 // Benutze eine JComboBox zum Wechseln der Modi...
8 JComboBox mouseModeBox = graphMouse.getModeComboBox();
Listing 5.15: Mausaktionen im Graphen
Navigation im Graphen Wurde der Graph entsprechend einer Suchanfrage durch den Benut-
zer im Visualisierungsfeld gezeichnet, kann anschließend in diesem Graphen nach dem
“Lichtkegel-Prinzip”navigiert werden. Ein Benutzer hat die Moglichkeit, unmittelbare, dem
ausgewahlten Beziehungstyp entsprechende Nachbarn eines ausgewahlten Elements in die
Darstellung aufzunehmen oder ein Element aus der Darstellung zu loschen. Hierfur wahlt
der Benutzer ein Element mit der rechten Maustaste aus, sodass sich ein neues Kontextme-
nu (Java-Swing-JPopupMenu) offnet (siehe Abbildung 5.8-1). In diesem Kontextmenu hat
der Benutzer drei Auswahlmoglichkeiten, die im Folgenden genauer beschrieben werden.
43
Kapitel 5 Implementierung
Expand Graph: Show Neighbors Vom markierten Element werden alle, dem ausgewahl-
ten Beziehungstyp entsprechende Nachbarn im Datenbestand gesucht und zum Gra-
phen hinzugefugt. Diese neuen Nachbarn werden durch eine Kante mit dem mar-
kierten Knoten verbunden. Das Prinzip des Hinzufugens von Knoten und Kanten im
Graphen ist in Listing 5.10 genauer beschrieben.
Remove this Vertex and its Neighbors Der ausgewahlte Knoten und alle seine Nach-
barn, die keine weiteren Nachbarn besitzen, werden aus der Darstellung geloscht.
Hierfur werden zuerst alle Nachbarn des Knotens mit Hilfe der Methode getNeigh-
bors() gesucht und iterativ jeder Nachbarknoten aus dem Graphen geloscht. Wie ein
einzelner Knoten aus dem Graphen geloscht wird zeigt Listing 5.16.
1 // Losche einen Knoten aus dem Graphen...
2 vv.stop() ;
3 // Entferne auch das Label des Knotens vom StringLabeller ...
4 vs.removeLabel("vertexname");
5 graph.removeVertex(vertex);
6 vv.repaint() ;
Listing 5.16: Loschen eines Knotens aus dem Graphen
Help (displayed in profile) Bei der Auswahl dieser Aktionsmoglichkeit wird dem Benutzer
im Profile-Fenster der graphischen Benutzeroberflache eine Benutzerhilfe angezeigt,
welche die Funktionsweise aller Auswahlmoglichkeiten des Kontextmenus beschreibt.
5.6.2.5 Weitere Optionen
Reset des Graphen Durch ein Reset konnen alle Knoten des Graphen aus der Visualisierung
entfernt werden, sodass der Ausgangszustand des Graphen wiederhergestellt wird. An-
schließend hat der Benutzer die Moglichkeit, eine erneute Suchanfrage zu stellen. Zeile 3
in Listing 5.17 zeigt das Loschen aller Knoten im Graphen. Damit jedoch anschließend
eine neue Suchanfrage gestellt werden kann, muss auch der VertexStringer zur Knoten-
beschriftung in seinen Ausgangszustand zuruckgesetzt werden (Zeile 6). Ansonsten wurde
ein erneutes Hinzufugen eines zuvor geloschten Knotens fehlschlagen, da der VertexStrin-
ger noch ein identisches Label fur diesen geloschten Knoten enthalt.
1 // Entferne alle Knoten im Graphen...
2 vv.stop() ;
3 graph.removeAllVertices();
4 // Losche auch den gesamten VertexStringer (StringLabeller ).
5 // Nur danach konnen Knoten wieder zum Graphen hinzugefugt werden...
6 vs. clear () ;
7 vv.repaint() ;
Listing 5.17: Loschen aller Knoten und Zurucksetzen des Graphen
44
5.6 Visualisierung mit JUNG
1
Abbildung 5.8: OntoScope Screenshot mit Kontextmenu Nach der erfolgrei-chen Darstellung des Graphen im Visualisierungsfeld kann der Benutzer mit Hilfeeines Kontextmenus (1) im Graphen navigieren, d.h. neue Nachbar-Elemente zurDarstellung hinzufugen oder bestehende Elemente aus der Darstellung entfernen.
Speichern des Graphen als Bilddatei Nachdem der Benutzer seine Suchanfrage gestellt hat und
der entsprechende Graph im Visualisierungsfeld dargestellt wurde, hat er die Moglich-
keit, diesen Graphen als Bilddatei zu speichern. Hierbei wird die Methode writeJPEG-
Image der OntoScope-Software aufgerufen, in welcher der VisualisationViewer ein Java-
Graphics2D-Objekt zeichnet (Listing 5.18, Zeile 4), welches durch einen Java-ImageWriter
in eine JPG-Datei geschrieben wird (Zeile 7). Somit wird der Graph als Schnappschuss in
einer JPG-Bilddatei auf dem lokalen Rechner gespeichert.
1 private static void writeJPEGImage(File file) {
2 BufferedImage bi = new BufferedImage(vv.getWidth(), vv.getHeight(), BufferedImage.TYPE INT RGB);
3 Graphics2D graphics = bi.createGraphics();
4 vv.paint(graphics) ;
5 graphics.dispose() ;
6
7 ImageIO.write(bi, "jpeg", file ) ;
8 }
Listing 5.18: Speichern des Graphen als Bilddatei
45
Kapitel 5 Implementierung
46
Kapitel 6
Fazit
In dieser Masterarbeit wurde OntoScope, eine graphische Anwendungssoftware zur interaktiven
Visualisierung von anatomischen Ontologien, entwickelt und implementiert. Ausgehend vom
Datenbestand der Cytomer-Datenbank in der Abteilung Bioinformatik der Universitatsmedizin
Gottingen wurden geeignete Software-Werkzeuge analysiert und bewertet, welche diese Daten
und deren Zusammenhange visualisieren sollten. Als Ergebnis der Analyse wurde das Software-
Werkzeug JUNG ausgewahlt. Die Hauptkomponente von JUNG zur Visualisierung von struk-
turierten Daten ist ein VisualizationViewer, der das Java-Swing-JPanel erweitert. Dieses Vi-
sualisierungsfeld wurde Hauptbestandteil der graphischen Benutzeroberflache von OntoScope.
Mit OntoScope hat der Benutzer die Moglichkeit, eine Suchanfrage an einen Ontologie-
Datenbestand zu stellen. Anschließend wird ein Graph im Visualisierungsfeld der graphischen
Benutzeroberflache dargestellt. Dieser Graph zeigt das gesuchte Element aus dem Datenbestand
und alle Nachbarelemente, die dem ausgewahlten Beziehungstyp entsprechen. Nach der Darstel-
lung des Graphen hat der Benutzer die Moglichkeit, im selbigen interaktiv nach dem“Lichtkegel-
Prinzip”zu navigieren. Er kann weitere Nachbarelemente anzeigen oder bestimmte Elemente von
der Darstellung ausblenden lassen. Schließlich ist es moglich, einen Schnappschuss der Visua-
lierung in einer Bilddatei zu speichern. Abbildung 6.1 zeigt die graphische Benutzeroberflache
von OntoScope nach einer erfolgreichen Suchanfrage durch den Benutzer. Im Visualisierungsfeld
wird der entsprechende Graph dargestellt und im Profile-Fenster je nach Elementauswahl alle
assoziierten Informationen angezeigt. Dem Benutzer werden zudem verschiedene Optionen zur
Graph-Manipulation angeboten. So ist es beispielsweise dem Benutzer moglich, im Graph hinein-
oder hinauszuzoomen, die Positionen der einzelnen Elemente selbst oder durch die Auswahl ver-
schiedener Layout-Algorithmen zu verandern oder Knoten- und Kantenbeschriftungen ein- oder
auszublenden.
6.1 Kritische Bewertung
Mit OntoScope ist es einem Benutzer eindrucksvoll moglich, einen komplexen Datenbestand
durch die Darstellung einer Auswahl der Elemente und deren Beziehungen untereinander nach
dem “Lichtkegel-Prinzip” genauer unter die Lupe zu nehmen. In Form eines Java-Applets ist es
47
Kapitel 6 Fazit
Abbildung 6.1: OntoScope Screenshot mit visualisiertem Graphen Die graphi-sche Benutzeroberflache von OntoScope zeigt das Visualisierungsfeld, in welcherder Graph dargestellt wird. Das Profile-Fenster enthalt nach der Auswahl einesGraph-Elements alle assoziierten Informationen. Durch Auswahlboxen kann derBenutzer die Suche von Elementen verfeinern. Nach der Darstellung des Gra-phen hat der Benutzer die Moglichkeit, den Graph interaktiv zu manipulieren,beispielsweise durch Verandern der Große und Position der Elemente.
moglich, uber das Web auf den Datenbestand zuzugreifen und die gesamte graphische Benut-
zeroberflache von OntoScope anzeigen zu lassen. Die Implementierung des Webzugriffs uber ein
Java-Applet war die beste Moglichkeit, da die Hauptkomponente des Software-Werkzeugs JUNG
zur Visualisierung der Daten nur uber ein Java-Swing-JPanel in graphische Benutzeroberflachen
eingebunden werden kann. Einzige Moglichkeit zur Webanbindung blieb somit ein Java-Applet,
das allein die Moglichkeit der Nutzung einer interaktiven graphischen Benutzeroberflache bot.
Leider ist diese Form der Webanbindung eine clientseitige Technik, die vom Benutzer die Installa-
tion eines geeigneten Plugins erfordert. Diese Installation ist aus Sicherheitsgrunden nicht immer
moglich. Andere Formen der Webanbindung, beispielsweise serverseitige Techniken wie PHP1,
Perl2, JavaServer Pages3 oder Java-Servlets4 kommen fur die Visualisierung nicht in Frage, da sie
die Nutzung von graphischen Benutzeroberflachen und somit ein interaktives Visualisierungsfeld
nicht unterstutzen.
1Vgl. The PHP Group: http://www.php.net/2Vgl. The Perl Foundation: http://www.perl.org/3Vgl. Sun Microsystems, Inc.: http://java.sun.com/products/jsp/4Vgl. Sun Microsystems, Inc.: http://java.sun.com/products/servlet/
48
6.2 Ausblick
Wunschenswert ware jeglicher Verzicht auf clientseitige Techniken und Anforderungen, sodass
eine interaktive Visualisierung barrierefrei fur jeden Benutzer, mit jedem Webbrowser und oh-
ne technische Einschrankungen moglich ist. Doch beim Einsatz von barrierefreien Techniken5
musste zur Zeit noch auf eine interaktive Visualisierung verzichtet werden.
6.2 Ausblick
Der Datenbestand der Cytomer-Ontologie in der Abteilung Bioinformatik wird stetig weiter-
entwickelt und ausgebaut. Demzufolge sollte auch OntoScope den steigenden Anforderungen ge-
wachsen sein. Die sehr gute Erweiterbarkeit und Flexibilitat von JUNG als Hauptbestandteil der
graphischen Visualisierung sollte dies ermoglichen. So konnten beispielsweise durch einen neu-
en Beziehungstyp developsFrom bzw. developsTo zeitliche Entwicklungslinien von Elementen
der Ontologie modelliert und visualisiert werden. Die Visualisierung konnte hier nicht als Graph,
sondern zum Beispiel als Balkenplan, einem sogenannten Gantt-Diagramm (benannt nach Henry
Laurence Gantt (1861–1919)), dargestellt werden. Ein Gantt-Diagramm stellt zeitliche Abfolgen
von Aktivitaten graphisch in Form von Balken auf einer Zeitachse dar.
Ein weiteres Einsatzfeld fur OntoScope ware daruber hinaus die Moglichkeit eines Schreibzugriffs
auf den Datenbestand der Cytomer-Ontologie. Dadurch konnte ein Benutzer mit Hilfe von Onto-
Scope auf Basis der graphischen und interaktiven Visualisierung einzelne Elemente der Ontologie
und die Beziehungen der Elemente untereinander editieren und vervollstandigen. Anschließend
konnten diese Anderungen in den Datenbestand aufgenommen werden. Auf diese Weise konnte
die Geschwindigkeitsproblematik beim Protege Ontology Editor in Verbindung mit großen und
komplexen Ontologien umgangen und behoben werden.
Wie auch schon in Abbildung 5.7-7 in Kapitel 4 ersichtlich, ist ferner ein Ontologie-Cache bei
OntoScope geplant. Dieser Cache konnte die Geschwindigkeit der Visualisierung weiter opti-
mieren, indem ausgewahlte Elemente der Ontologie oder sogar der gesamte Datenbestand in
OntoScope im Vorfeld vorgehalten und gespeichert wird. Folglich konnte eine Suchanfrage, wel-
che ein zuvor gespeichertes Element erfragt, sehr viel schneller beantwortet werden. Gerade fur
die Benutzerfreundlichkeit von OntoScope ware dies von großem Vorteil.
Schließlich ware es wunschenswert, die Visualisierung von OntoScope mit anderen Ressourcen
der Abteilung Bioinformatik zu verknupfen. Ein Beispiel hierfur ware eine engere Integration von
Elementen des EndoNet-Datenbestands in die Visualisierung der Cytomer-Ontologie. EndoNet6
ist eine Datenbank uber Bestandteile endokriner Netzwerke und deren Beziehungen untereinan-
der zur Analyse interzellularer regulatorischer Signalwege des Menschen [Potapov et al. 2006].
Damit ware es beispielsweise moglich, intrazellulare Signalwege in einen hierarchischen, anatomi-
schen Kontext zu Organen, Zellen oder Geweben zu setzen und mit OntoScope zu visualisieren.
5Vgl. W3C Zuganglichkeitsrichtlinien fur Web-Inhalte: http://www.w3c.de/Trans/WAI/webinhalt.html6Vgl. UMG Gottingen, Abteilung Bioinformatik : http://endonet.bioinf.med.uni-goettingen.de/
49
Kapitel 6 Fazit
50
Abbildungsverzeichnis
2.1 Darstellung einer Ontologie als Graph . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Die Architektur des Semantic Web nach Tim Berners-Lee . . . . . . . . . . . . . 6
2.3 Schema des Protege OWL Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Schema der relationalen Cytomer Datenbank . . . . . . . . . . . . . . . . . . . . 10
2.5 Die Beziehungen im OWL-Modell von Cytomer . . . . . . . . . . . . . . . . . . . 11
4.1 Beispielgraph als Bewertungsgrundlage . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Umsetzung des Beispielgraphen mit prefuse . . . . . . . . . . . . . . . . . . . . . 20
4.3 Umsetzung des Beispielgraphen mit JUNG . . . . . . . . . . . . . . . . . . . . . 23
5.1 OntologyClass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2 OntologyRestriction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 OntologyProperty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 OntoScope Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5 Applet Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6 Servlet Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.7 OntoScope Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.8 OntoScope Screenshot mit Kontextmenu . . . . . . . . . . . . . . . . . . . . . . . 45
6.1 OntoScope Screenshot mit visualisiertem Graphen . . . . . . . . . . . . . . . . . 48
A.1 Verzeichnisbaum der Sourcecode-CD . . . . . . . . . . . . . . . . . . . . . . . . . 57
51
Abbildungsverzeichnis
52
Listings
5.1 getOntologyClassList(String prefix, String query) . . . . . . . . . . . . . 30
5.2 getOntologyClass(String className) . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 getNamespacePrefixes() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Einbettung eines Java-Applets in eine HTML-Seite . . . . . . . . . . . . . . . . . 32
5.5 ConnectorServletAdapter (Auszug) . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 OntologyConnectorServlet: doGet (Auszug) . . . . . . . . . . . . . . . . . . . . 35
5.7 OntologyConnectorServlet: doPost (Auszug) . . . . . . . . . . . . . . . . . . . 36
5.8 Die Hautpbestandteile der Graph-Visualisierung mit JUNG . . . . . . . . . . . . 38
5.9 Beispiele zur Anpassung der JUNG-Visualisierung . . . . . . . . . . . . . . . . . 39
5.10 Hinzufugen von Knoten und Kanten zum Graphen . . . . . . . . . . . . . . . . . 39
5.11 Zoom im Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.12 Setzen einer Knotenbeschriftung im Graphen . . . . . . . . . . . . . . . . . . . . 41
5.13 Setzen einer Kantenbeschriftung im Graphen . . . . . . . . . . . . . . . . . . . . 41
5.14 Andern des Graph-Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.15 Mausaktionen im Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.16 Loschen eines Knotens aus dem Graphen . . . . . . . . . . . . . . . . . . . . . . . 44
5.17 Loschen aller Knoten und Zurucksetzen des Graphen . . . . . . . . . . . . . . . . 44
5.18 Speichern des Graphen als Bilddatei . . . . . . . . . . . . . . . . . . . . . . . . . 45
53
Listings
54
Abkurzungsverzeichnis
API . . . . . . . . . . . . . . . . Application Programming Interface
BSD . . . . . . . . . . . . . . . . Berkeley Standard Distribution
CGI . . . . . . . . . . . . . . . . Common Gateway Interface
DAG . . . . . . . . . . . . . . . Directed Acyclic Graph
DAML+OIL . . . . . . . . Darpa Agent Markup Language + Ontology Inference Layer
DL . . . . . . . . . . . . . . . . . Description Logic
FAQ . . . . . . . . . . . . . . . . Frequently Asked Questions
FMA . . . . . . . . . . . . . . . Foundational Model of Anatomy
GO . . . . . . . . . . . . . . . . . Gene Ontology
GUI . . . . . . . . . . . . . . . . Graphical User Interface
HTML . . . . . . . . . . . . . . HyperText Markup Language
HTTP . . . . . . . . . . . . . . HyperText Transfer Protocol
ISOM . . . . . . . . . . . . . . . Inverted Self Organizing Map
JSP . . . . . . . . . . . . . . . . JavaServer Pages
JVM . . . . . . . . . . . . . . . Java Virtual Machine
OWL . . . . . . . . . . . . . . . Web Ontology Language
RDF . . . . . . . . . . . . . . . . Resource Description Framework
SHriMP . . . . . . . . . . . . Simple Hierarchical Multi-Perspective
URI . . . . . . . . . . . . . . . . Uniform Resource Identifier
URL . . . . . . . . . . . . . . . . Uniform Resource Locator
W3C . . . . . . . . . . . . . . . World Wide Web Consortium
WWW . . . . . . . . . . . . . World Wide Web
XML . . . . . . . . . . . . . . . eXtensible Markup Language
55
Abkurzungsverzeichnis
56
Anhang A
Inhalt der CD
Die zu dieser Masterarbeit beigefugte CD enthalt alle Sourcecodes der in dieser Arbeit imple-
mentierten OntoScope-Anwendungssoftware sowie die Implementierungen der Beispielgraphen
mit prefuse und JUNG. Die folgende Abbildung A.1 zeigt den Verzeichnisbaum der CD mit
Auflistungen aller fur OntoScope wichtigen Java-Klassen in den entsprechenden Java-Paketen.
msc_workspace/
cytomer/
JavaSource/
de.sybig.cytomer.client.OntoScope OntoScope-Anwendungssoftwarede.sybig.cytomer.client.OntoScopeDriver OntoScope-Appletde.sybig.cytomer.connector.ConnectorAdapter
de.sybig.cytomer.connector.ConnectorLocalAdapter
de.sybig.cytomer.connector.ConnectorServletAdapter
de.sybig.cytomer.connector.OntologyClass
de.sybig.cytomer.connector.OntologyConnector
de.sybig.cytomer.connector.OntologyConnectorImpl
de.sybig.cytomer.connector.OntologyConnectorServlet
de.sybig.cytomer.connector.OntologyException
de.sybig.cytomer.connector.OntologyProperty
de.sybig.cytomer.connector.OntologyRestrictionjung/
src/
example.JUNGGraphDemo Beispielgraph-Implementierung mit JUNGlib/
*.jar Java-Bibliothekenprefuse/
src/
example.PrefuseGraphExample Beispielgraph-Implementierung mit prefuse
Abbildung A.1: Verzeichnisbaum der Sourcecode-CD
57
Anhang A Inhalt der CD
58
Literaturverzeichnis
Bard 2003
Bard, Jonathan B. L.: Ontologies: Formalising Biological Knowledge for Bioinformatics.
In: BioEssays Bd. 25. Wiley Periodicals, Inc., 18. April 2003, S. 501–506
Bard u. Rhee 2004
Bard, Jonathan B. L. ; Rhee, Seung Y.: Ontologies in Biology: Design, Applications and
Future Challenges. In: Nature Reviews Genetics Vol. 5, No. 3 (2004), Marz 2004, S. 213–222
Berners-Lee et al. 2001
Berners-Lee, Tim ; Hendler, James ; Lassila, Ora: The Semantic Web. In: Scientific
American (2001), 17. Mai 2001
Fruchterman u. Reingold 1991
Fruchterman, Thomas M. J. ; Reingold, Edward M.: Graph Drawing by Force-directed
Placement. In: Software, Practice and Experience 21 (1991), Nr. 11, S. 1129–1164
Heer et al. 2005
Heer, Jeffrey ; Card, Stuart K. ; Landay, James A.: prefuse: A Toolkit for Interactive
Information Visualization. In: CHI 2005: Proceedings of the SIGCHI conference on Human
factors in computing systems, ACM Press, 2005
Herman et al. 2000
Herman, Ivan ; Melancon, Guy ; Marshall, M. S.: Graph Visualization and Naviga-
tion in Information Visualization: a Survey. In: IEEE Transactions on Visualization and
Computer Graphics Vol. 6, No. 1 (2000)
Hesse 2002
Hesse, Wolfgang: Aktuelles Schlagwort: Ontologie(n). In: Informatik Spektrum (2002), 16.
Dezember 2002, S. 477–480
Jena 2007
Hewlett-Packard Development Company (Hrsg.): Jena Semantic Web Framework
for Java. Software. Online Ressource. http://jena.sourceforge.net/. Version: 2.5, 2007
JUNG 2006
The JUNG Framework Development Team (Hrsg.): JUNG – Java Universal Net-
work/Graph Framework. Software. Online Ressource. http://jung.sourceforge.net/.
Version: 1.7.5, 20. Oktober 2006
59
Literaturverzeichnis
Kamada u. Kawai 1989
Kamada, Tomihisa ; Kawai, Satoru: An Algorithm for Drawing General Undirected Graphs.
In: Information Processing Letters 31 (1989), Nr. 1, S. 7–15
Kappel et al. 2002
Kappel, Gerti ; Retschitzegger, Werner ; Proll, Birgit ; Unland, Rainer ; Vojdani,
Bahram: Architektur von Web-Informationssystemen. In: Rahm, Erhard (Hrsg.) ; Vossen,
Gottfried (Hrsg.): Web & Datenbanken. dpunkt, 2002. – ISBN 3–89864–189–9, S. 101–134
Knublauch et al. 2004
Knublauch, Holger ; Fergerson, Ray W. ; Noy, Natalya F. ; Musen, Mark A.: The
Protege OWL Plugin: An Open Development Environment for Semantic Web Applications.
In: McIlraith, Sheila A. (Hrsg.) ; Plexousakis, Dimitris (Hrsg.) ; Harmelen, Frank van
(Hrsg.): International Semantic Web Conference Bd. 3298, Springer, 2004 (Lecture Notes
in Computer Science). – ISBN 3–540–23798–4, S. 229–243
Meyer 1998
Meyer, Bernd: Self-Organizing Graphs - A Neural Network Perspective of Graph Layout.
In: Whitesides, Sue (Hrsg.): Graph Drawing Bd. 1547, Springer, 1998 (Lecture Notes in
Computer Science). – ISBN 3–540–65473–9, S. 246–262
Michael et al. 2005
Michael, Holger ; Chen, Xin ; Fricke, Ellen ; Haubrock, Martin ; Ricanek, Remko ;
Wingender, Edgar: Deriving an Ontology for Human Gene Expression Source from the
Cytomer Database on Human Organs and Cell Types. In: In Silico Biology Volume 5 (2005)
Noy et al. 2003
Noy, Natalya F. ; Crubezy, Monica ; Fergerson, Ray W. ; Knublauch, Holger ; Tu,
Samson ; Vendetti, Jennifer ; Musen, Mark A.: Proege-2000: An Open-Source Ontology-
Development and Knowledge-Acquisition Environment. In: AIMA Annual Symposium Pro-
ceedings (2003)
O’Madadhain et al. 2003
O’Madadhain, Joshua ; Fisher, Danyel ; Smyth, Padhraic ; White, Scott ; Boey, Yan-
Biao: Analysis and Visualization of Network Data using JUNG. Pre-Print. In: Journal of
Statistical Software (2003). http://jung.sourceforge.net/doc/JUNG_journal.pdf
OWL 2004
World Wide Web Consortium (Hrsg.): OWL Web Ontology Language: Overview. Online
Ressource. http://www.w3.org/TR/owl-features/. Version: 10. Februar 2004
Potapov et al. 2006
Potapov, Anatolij ; Liebich, Ines ; Donitz, Jurgen ; Schwarzer, Knut ; Sasse, Nicole
; Schoeps, Torsten ; Crass, Torsten ; Wingender, Edgar: EndoNet: an information
resource about endocrine networks. In: Nucleic Acids Research Volume 34, Database-Issue
(2006), S. 540–545
60
Literaturverzeichnis
prefuse 2006
Berkeley Institute of Design (Hrsg.): The prefuse visualization toolkit. Software.
Online Ressource. http://www.prefuse.org/. Version: beta, 15. Juli 2006
Protege 2006
Stanford University School of Medicine (Hrsg.): Protege Ontology Editor. Software.
Online Ressource. http://protege.stanford.edu/. Version: 3.2 beta, 23. Juni 2006
Ricanek 2006
Ricanek, Remko: Semantisches Web in der Bioinformatik: Entwicklung eines Tools zur
Darstellung biomedizinischer Daten in OWL, Universitatsmedizin Gottingen, Abteilung Bio-
informatik, Projektarbeit (unveroffentlicht), Marz 2006
Semantic Web 2001
World Wide Web Consortium (Hrsg.): The Semantic Web: Overview. Online Ressource.
http://www.w3.org/2001/sw/. Version: 17. Mai 2001
Wingender 2003
Wingender, Edgar: TRANSFAC, TRANSPATH and CYTOMER as starting points for
an ontology of regulatory networks. In: In Silico Biology Volume 4 (2003)
Alle in dieser Masterarbeit ausgewiesenen URLs wurden am 27. September 2007 abschließend
auf ihre Erreichbarbeit uberpruft. Fur die kunftige Erreichbarkeit der verlinkten Inhalte kann
keine Garantie ubernommen werden. Falls eine URL nicht mehr erreichbar sein sollte, konnen
Kopien der Inhalte per Email an mail@ricanek.de angefordert werden.
61
Literaturverzeichnis
62
Danksagung
An erster Stelle mochte ich mich besonders bei Herrn Prof. Dr. Edgar Wingender bedanken, der
mir die Anfertigung dieser Masterarbeit an seiner Abteilung ermoglichte. Die Arbeitsatmosphare
in der Abteilung war stets sehr freundlich und bei auftretenden Fragen und Problemen wurde
gern geholfen.
Insbesondere bedanke ich mich bei Dr. Holger Michael und Dipl.-Biol. Jurgen Donitz fur die
intensive Betreuung meiner Arbeit sowie bei Dipl.-Inform. Torsten Schops fur konstruktive kri-
tische Anregungen und die stets kompetente Beantwortung technischer Fragen.
Herrn Prof. Dr. Wolfgang May an der Arbeitsgruppe Datenbanken & Informationssysteme des
Instituts fur Informatik danke ich fur seine Zustimmung, diese Masterarbeit als Korreferent zu
begutachten.
Vielen Dank an Katharina Hoff und Fabian Schreiber fur Korrektur, Tee und Kekse und stets
ein offenes Ohr bei Fragen und Problemen in jeder Hinsicht.
Vielen Dank auch an Dr. Torsten Crass fur die Wortschopfung OntoScope.
Ganz herzlich bedanke ich mich bei meiner“Unicante-Familie”fur die angenehmen Mittagszeiten
und Aufheiterungen.
Mein ganz personlicher Dank gilt meinen Eltern fur ihr Vertrauen und ihre andauernde Unter-
stutzung sowie ganz besonders meiner Freundin Isabelle fur Verstandnis, Halt und Ermutigung
in jeder Lebenslage.
Danke!
63
Danksagung
64
Recommended