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