Paper - Institut für Informatik - Hu

TAMBIS
Das TAMBIS – Projekt
Markus Schulz*
Institut für Informatik – Humboldt Universität zu Berlin
Resumé
In der heutigen Zeit produzieren biologische Experimente riesige Datenmengen, die maschinell gespeichert und
verarbeitet werden müssen, um sie der Forschungsgemeinschaft zugänglich zu machen. Unterschiedliche Sichten
auf bestimmte biologische Sachverhalte (semantische Heterogenität) sowie verschiedenste Plattformen und
Datenbankimplementationen fordern einen nicht unerheblichen Arbeitsaufwand bei der Informationssuche bzw.
Informationsverarbeitung. Das in diesem Paper vorgestellte TAMBIS-System ist ein möglicher Ansatz, den
Arbeitsaufwand zu verringern, indem es über mehreren molekularbiologische Datenbanken operiert, dem
Benutzer jedoch eine einheitliche Arbeitsoberfläche bietet und quellenunabhängige Anfragen erlaubt. Aufgrund
der TaO, einer Ontologie, die speziell für TAMBIS entwickelt wurde, ist dem Benutzer sowohl die
molekularbiologische Terminologie als auch die semantische Bedeutung derer Elemente vorgegeben. Der
Benutzer verlinkt die in der Ontologie gespeicherten molekularbiolgischen Konzepte zu einer komplexen
Anfrage, die dann intern weiterverarbeitet wird. Die Komponenten dieser noch quellenunabhängigen Anfrage
werden bewertet, optimiert und ein Abarbeitungsplan erstellt, der kosteneffizient ist und quellenspezifische
Funktionsaufrufe enthält, um letztlich die gewünschten Informationen aus den verschiedenen Datenbanken zu
erhalten. Aus diesem Grund vermeidet TAMBIS nicht nur etwaige Fehler, sondern bietet auch ein hohes Maß an
Transparenz der darunterliegenden Datenquellen. Trotz dieses innovativen Ansatzes gibt es noch viele
ungeklärte Fragen und Probleme, die der Verbreitung und erfolgreichen Kommerzialisierung des Projektes im
Weg stehen.
Mengen an Informationen produziert, die
dann in verschiedenen Datenbanken
gespeichert werden. Das WorldWideWeb
bietet eine offene Plattform, um auf diese
molekularbiologischen Daten zuzugreifen.
Bei der Suche nach Informationen jedoch
gibt es viele Hürden zu meistern, die sich
zum Einen mit gravierenden Unterschieden
in der Aktualität und der thematischen
Spezialisierung
der
verschiedenen
Datenquellen, zum Anderen mit den
unterschiedlichen Datenbanksystemen und
Interfaces begründen lassen. So reicht es
oftmals nicht aus, Anfragen an nur eine
Datenquelle zu stellen, um umfassend
informiert zu werden. Anschließend müssen
große Datenmengen oft durchgearbeitet und
die wirklich relevanten Informationen
extrahiert werden, um diese später effizient
weiterverarbeiten zu können. Äußerst
wichtig ist der Fakt, dass es verschiedene
subjektive Sichten auf einen bestimmten
1. Einleitung und Motivation
Die Biologie ist seit je her eine stark
wissensbasierte Disziplin. Das heißt, dass
bereits bestehendes Wissen als Grundlage
dient,
um
neue
Erkenntnisse
zu
interpretieren bzw. den möglichen Nutzen
biologischer Experimente vorherzusagen.
Aufgrund der Komplexität und Spezifität
von Domänenwissen innerhalb der Biologie
gab es bis vor einigen Jahren nur wenige
Spezialisten, denen aktuelle Erkenntnisse
ihrer Fachdisziplin bekannt waren. Auch
waren die gewonnenen Erfahrungen vieler
Experimente im Wesentlichen überschaubar.
Heutzutage bietet sich jedoch ein ganz
anderes Bild. Durch Experimente wie z.B.
das „Human-Genom-Projekt“ werden vor
allem in der Molekularbiologie riesige
* [email protected]
1
dafür vorgesehenen Quellen geschickt. So
bleiben während des gesamten Prozesses die
Datenquellen für den Benutzer transparent.
Momentan sind zwei Versionen des Systems
auf der Projektseite [8] verfügbar. Die
„Browse-only“
Version
erlaubt
den
vollständigen Zugriff auf die TAMBISOntologie. Es ist möglich, komplexe
Anfragen zu formulieren, jedoch nicht sie
abzuschicken. Das „Functional-System“
bietet Zugriff auf einen Teil der TaO und
hier können die Anfragen auch bearbeitet
werden. Diese Version greift auf die
Datenbanken
„SwissProt“,
„Enzyme“,
„Cath“, „Prosite“ und „Blast“ zurück.
biologischen Sachverhalt geben kann, d.h.
die Semantik vieler Begriffe ist nicht
eindeutig.
Solche
semantischen
Heterogenitäten können leicht zu Fehlern
und
Misserfolgen
bei
Suche
und
Interpretation molekularbiologischer Daten
führen. Ein großes Maß an Handarbeit bleibt
also bestehen. Das TAMBIS-System [1] [8]
wurde entwickelt, um die Suche nach Daten
zu erleichtern und viele der obengenannten
Prozesse zu automatisieren und zu
simplifizieren. TAMBIS heißt Transparent
Access to Multiple Biological Information
Sources und ist ein Gemeinschaftsprojekt
der School of Biological Sciences und der
Information Mangement Group an der
University of Manchester, UK. Der
Pharmakonzern Zeneca Pharmaceuticals
stellte neben den öffentlichen Geldern einen
großen Anteil an Förderungsmitteln zur
Verfügung. Der Beginn des Projekts war
1999, eine Hauptkomponente des Systems,
die TAMBIS Ontologie (TaO), wurde
jedoch bereits früher entwickelt und dann in
das System integriert. Bis zum heutigen Tag
dient
das
TAMBIS-Projekt
als
Forschungsgegenstand und wird von der
Forschungsgemeinschaft als das Paradebeispiel für den sinnvollen Einsatz von
Ontologien angesehen.
3. Das graphische Benutzerinterface
Durch das graphische Benutzerinterface ist
der User in der Lage, komplexe Anfragen zu
stellen. Er beginnt mit einem Basiskonzept
und spezifiziert es nach Wunsch, indem er
es mit anderen Konzepten verbindet. Das
GUI stellt eigentlich nur ein Interface
zwischen Benutzer und Ontologie dar.
Neben dem „Query-Builder“, der das
Hauptwerkzeug bei der Formulierung von
Anfragen ist, besteht auch die Möglichkeit,
über einen „Explorer“ durch die Konzepte
der Ontologie zu browsen. In Abbildung 1
ist exemplarisch eine mögliche Anfrage
dargestellt. Die Konzepte Motif und Protein
werden hier mit der Relation isComponentOf
verknüpft. Protein wiederum wird mit
Species
durch
die
Relation
hasOrganismClassification verbunden und
Species wird durch das Attribut „guppy“
spezifiziert. Demnach sucht man hier ein
Proteinmotiv, welches eine Komponente
eines Proteins darstellt, was wiederum der
Spezies Guppy zuzuordnen ist.
Abb.: 1
2. Features des TAMBIS-Systems
Der Hauptgedanke bei der Entwicklung des
TAMBIS-Systems war die Erleichterung der
Informationssuche und –verarbeitung über
molekularbiologischen Datenbanken. Dem
Benutzer stellt TAMBIS ein einziges,
quellenunabhängiges, graphisches Benutzerinterface (GUI) zur Verfügung, mit dem er
vorgegebene, in der TAMBIS Ontologie
(TaO) [1] gespeicherte Konzepte zu
komplexen Anfragen kombiniert. Dabei geht
er von einem wählbaren Grundkonzept aus.
Die TaO enthält cirka 1800 Konzepte und
Relationen, die dem Benutzer nicht nur eine
einheitliche Fachterminologie vorgeben,
sondern auch gleichzeitig die Semantik der
einzelnen molekularbiologischen Begriffe
festlegen. So sollen zum Einen mögliche
semantische
Uneinigkeiten
minimiert
werden, zum Anderen können keine
„Nonsense“-Anfragen gestellt werden, da
die Konzepte und deren mögliche
Relationen
zu
anderen
Konzepten
vorgeschrieben sind. Eine mögliche Anfrage
wird von TAMBIS automatisch in Subqueries unterteilt und dann spezifisch an die
2
4. Die TAMBIS Ontologie (TaO)
werden.
In
TAMBIS
stellt
ein
zusammengesetztes Konzept genau die
Anfrage dar, die dann vom System
weiterverarbeitet wird. Ein typisches GRAIL
Modell [2] besteht im Wesentlichen aus 3
Teilen:
Die TAMBIS-Ontologie TaO ist eine der
wichtigsten Systemkomponenten. Sie ist
eine Nachschlagewerk molekuarbiologischer
Konzepte und Relationen und enthält
elementare,
molekularbiologische
Ausdrücke,
Strukturen,
Substrukturen,
Funktionen und Relationen. Damit schafft
sie
Rahmenbedingungen
für
eine
einheitliche Semantik und Terminologie
ihrer Domäne. Die TAMBIS-Ontologie
wurde in GRAIL [2] geschrieben, einer
Sprache, die zur Familie der Description
Logic’s (DL) gehört. DL’s sind speziell dazu
designed, Wissen systematisch darzustellen,
indem bestimmte Konzepte und binäre
Relationen (oder auch Rollen genannt)
definiert und dann in einer Hierarchie
eingeordnet
werden.
Aus
den
Basiskonzepten lassen sich aufgrund ihrer
hierarchischen Einordung rekursiv komplexe
Konzepte aufbauen („kind-of“-Beziehung).
Auch können sie durch bestimmte
Relationen mit anderen Konzepten verknüpft
und das zusammengesetzte Konzept dann
durch einen „Reasoning-Service“ [2]
automatisch in die Hierarchie eingeordnet
a) Festlegungen:
Die Basiskonzepte werden per Hand in die
Hierarchie der Ontologie einfügt. Dies
bedeutet nicht nur einen gewissen Aufwand
für den Programmierer, zudem können durch
falsche Klassifizierung oder ungenaue
Definition der Basiskonzepte Fehler
entstehen, die später mühselig gesucht und
behoben werden müssen. In Abbildung 2,
der schematischen Darstellung eines Teils
der TaO, sind die Konzepte Organism,
Hydrolase, Protein, Function, Poecilia
reticulata, Motif und SequenceComponent
per Hand definiert worden. Des Weiteren
stehen sie in Teilmengenbeziehungen
zueinander, d.h. Poecilia reticulata is a
kind of
Organism wird durch den
durchgezogenen Pfeil repräsentiert und
bedeutet formal „Organism ⊇ Poecilia
reticulata“.
Abb.: 2
3
c) Sanktionen:
Sanktionen beschränken die Konstruktion
komplexer Konzepte. So ist es zum Beispiel
nicht möglich, zwei zufällig gewählte
Basiskonzepte mit einer beliebigen Relation
zu verknüpfen. In GRAIL müssen
Verknüpfungen
zwischen
Konzepten
explizit und per Hand vom Programmierer
sanktioniert werden. Dabei unterscheidet
man grammatikalische und konkrete (eng.:
sensible) Sanktionen. Abbildung 3 zeigt
diese beiden Arten von Sanktionen in
Bezug auf die Relation hasComponent
(gestrichelter Pfeil). Die durchgezogenen
Pfeile stellen „kind-of“ Beziehungen dar.
Bei den in diesem Beispiel aufgeführten
Konzepten handelt es sich ausnahmslos um
Basiskonzepte. Grammatikalisch werden
nur Beziehungen zwischen zwei abstrakten
und generellen Konzepten sanktioniert.
Dies bedeutet, dass unbestimmt viele, aber
nicht
alle
Biomoleküle
strukturelle
Komponenten
haben
können.
Eine
grammatikalische Sanktion wird an alle
Kinder
des
Basiskonzepts,
z.B.
Biomolecule weitervererbt und bildet die
Voraussetzung, dass eine Relation konkret
sanktioniert werden kann. In Abbildung 3
wird die Relation hasComponent zwischen
den Konzepten AlphaHelix und Protein
konkret sanktioniert. Das heißt, das alle
Proteine eine Komponente AlphaHelix
haben können, es aber nicht müssen. Es
bedarf einiges an Sorgfalt, um Sanktionen
zu setzen, da sie zu weit oben in der
Hierarchie zu Fehlpaarungen zweier
Konzepte und damit zu semantischen
Fehlern führen können. Solche Fehler treten
meist erst im laufenden Betrieb der
Ontologie auf und müssen nachträglich
behoben werden.
b) Operationen und Reasoning Services:
Neben den bereits bekannten „kind-of“Beziehungen können Relationen/Rollen
dazu verwendet werden, um komplexe
Konzepte zu bilden. Dabei wird zum
besseren Verständnis der Relation und wie
schon in Abbildung 1 gesehen das Wort
„which“ hinter das Basiskonzept eingefügt.
Die in Abbildung 2 gezeigten Konzepte
Sequence Component und Protein stehen
demnach wie folgt in Beziehung:
SequenceComponent (which)
isComponentOf Protein
Diese Konstruktion ist ein komplexes
Konzept der Ontologie und wird
automatisch klassifiziert und in die
Hierarchie
eingebettet.
Dabei
wird
„isComponentOf Protein“ auch als
Kriterium
oder
Attribut
für
SequenceComponent bezeichnet. Protein
spielt in diesem komplexen Konzept den
Rollenfüller. Die in Abbildung 2 als
gestrichelte
Pfeile
dargestellten
Beziehungen lassen sich aus den gegebenen
Basiskonzepten und den gegebenen
Relationen ableiten. Man sieht also, dass
sich
eine
große
Anzahl
an
zusammengesetzten Konzepten aus relativ
wenigen Basiskonzepten und deren
sanktionierten Relationen ableiten lassen.
Diese Vorgehensweise ist überschaubar,
effizient und fehlerunanfälliger, als wenn
man
beispielsweise
alle
möglichen
Konzepte per Hand einfügen und
klassifizieren müsste. Des Weiteren zeigt
der „Reasoning-Service“ Konzepte an, die
aufgrund ihrer durch den Programmierer
definierten Attribute nicht mehr erreichbar
sind. Dadurch wird das Auftreten von
Inkonsistenzen weiter gesenkt.
Abb.: 3
4
Abb.: 4
5. Die TaO Infrastruktur
Geht man von der Struktur [2] der TaO aus,
läßt diese sich in zwei große Abschnitte
gliedern:
TopThing bildet die Wurzel der TaO und ist
das allgemeinste Konzept überhaupt.
DomainCategory und DomainAttribute
sind dessen Kinder und haben nicht minder
große Bedeutung, da sie im zweiten Teil der
Ontologie, der Low-Level-Division, mit
biologischen Konzepten und Relationen
korrespondieren. In Abbildung 5 wird
exemplarisch die weitere Gliederung des
Konzepts GeneralisedStructure dargestellt.
Offenbar wird es in PhysicalStructure und
AbstractStructure unterteilt, wobei ersteres
diskrete,
physikalische
Phänome
repräsentiert
und das zweite weitere
Konzepte enthält, die Möglichkeiten der
abstrakten Klassifikation solcher Phänomene
darstellen.
a) High-Level-Division:
Die
High-Level-Division
definiert
grundlegende und allgemeine Basiskonzepte
und bildet somit das Grundgerüst der
Ontologie. Sie wurde zum großen Teil von
der im „Galen-Project“ benutzten Ontologie
übernommen. Dieses Projekt hatte vor allem
das Ziel, eine universell einsetzbare
Ontologie für den Fachbereich der Medizin
zu schaffen, die später wie das TAMBISSystem funktionell einsetzbar sein sollte. In
Abbildung 4 wird ein Teil der High-LevelDivision schematisch dargestellt.
Abb.: 5
5
b) Low-Level-Division:
Die
Low-Level-Division
[2] enthält
Konzepte und Relationen, die die
molekularbiologische Domäne der TaO
wiederspiegeln. Im Gegensatz zur HighLevel-Division ist sie sehr spezifisch,
molekularbiologische Begriffe und Prozesse
sind explizit genannt. Zudem finden sich
hier fast alle Sanktionen des GRAILModells wieder.
6. TAMBIS-Anfragebearbeitung
Dieses Kapitel geht nur kurz auf die in
Abbildung 6 schematisch dargestellten
Verfahrensweisen
bei
der
Anfragebearbeitung ein. Tiefergehende Recherchen
lassen sich am besten mit den in der
Referenz erwähnten Paper [5] durchführen.
Als Ausgangspunkt für die weitere
Anfragebearbeitung dient eine vom Benutzer
gestellte Anfrage in GRAIL, die bis zu
diesem Zeitpunkt quellenunabhängig ist. Da
GRAIL-Anfragen verschachtelte Strukturen
sind und sich deshalb nicht ohne Probleme
weiterverarbeiten lassen, werden sie
zunächst in eine unverschachtelte, interne
Form (QIF) umgewandelt. Eine Anfrage
wird dazu in ihre Komponenten zerlegt und
vom System jeweils mit den folgenden fünf
Attributen belegt:
Abb.: 6
Language), die später zu den entsprechenden
Quellen geschickt werden. Es enthält
weiterhin die Beschreibungen von drei
grundlegenden Informationskategorien:
-Iteratoren: ähnlich Pointern, erhalten
Instanzen molekularbiologischer Konzepte
-Relationsbewerter: erhalten oder berechnen
Werte für bestimmte Relationen
-Filter: entfernen Instanzen, die nicht
anfragerelevant sind.
-Konzept: Basiskonzept, auf das sich die
entsprechende Komponente bezieht
-Kriterien: Kriterien des QIF Konzepts
-Variable: die an die Instanzen des
Basiskonzepts gebunden wird
-Technik: CPL-Funktionsaufruf, um die
Instanzen zu erhalten
-Auswahlkriterium: das Kriterium, welches
benutzt wird, um Instanzen aufgrund der
angewandten Technik zu erhalten.
Weiterhin enthält das SSM Informationen
über
unterschiedliche
Mappings
(Abbildungen) bestimmter ontologischer
Konzepte sowie spezielle CPL-Funktionen,
die
verschiedene
Repräsentationen
möglicher Instanzen eines Konzepts
zusammenfassen können. Zusätzlich ist
jeder CPL-Funktion ein Wert „Kosten“
zugeordnet, der sich vor allem aus der
Latenz
zwischen
Anfrage
und
Ergebnisrückgabe errechnet. Eine Anfrage
von TAMBIS (Manchester, UK) an die
Protein Datenbank SwissProt (Schweiz)
kann beispielsweise bis zu 25 Sekunden
dauern.
Die Werte für Auswahlkriterium und
Technik werden zunächst mit „null“ belegt
und erst im nächsten Schritt gefüllt. Die
QIF-Transformierung erfolgt „straightforward“ und in einem einzigen Durchlauf.
Die beiden folgenden Komponenten sind
maßgeblich
an
der
weiteren
Anfragebearbeitung beteiligt:
b) Query Planner und Wrapper:
Der Query Planner bedient sich eines
speziell
für
TAMBIS
entwickelten
Suchalgorithmus, um unter Zuhilfenahme
der im SSM gespeicherten Daten einen
effizienten Anfrageplan zu erstellen. Der
Algorithmus
bewertet
die
einzelnen
Komponenten der Anfrage und sucht deren
kostengünstigstes Glied. Wurde es gefunden,
a) SSM:
Das SSM (Sources and Services Model)
speichert die Beziehungen zwischen
Konzepten und Relationen der Ontologie
sowie die damit korrespondierenden CPLFunktionen (Collection Programming
6
sind ebenfalls möglich. Eine Reihe weiterer
Features wie zum Beispiel die Einbindung
externer Reasoner (standardmäßig FaCT)
machen SHIQ und im Endeffekt auch OIL
sehr ausdrucksstark und flexibel.
dient es als Ausgangspunkt für die
Bewertung der anderen Komponenten. Der
Query Planner führt solange seine Arbeit
aus, bis die komplette Anfrage verarbeitet
wurde und nun im optimierten QIF vorliegt.
Dabei werden die bislang fehlenden
Attribute Technik und Auswahlkriterium für
jede Anfragekomponente mit Werten belegt.
Schließlich wird der CPL-Code generiert
und spezifisch an die jeweiligen Quellen
verschickt. Die Sprache CPL stellt eine
umfangreiche Funktionenbibliothek zur
Verfügung,
um
den
Zugang
zu
verschiedenen Bioinformatik-Quellen zu
erleichtern. TAMBIS benutzt cirka 300 der
CPL-Funktionen, von denen einige exklusiv
für das Projekt entwickelt wurden.
c) OIL orientiert sich stark an bereits
bekannten Web-Sprachen wie XML (XMLDTD und XML Schema Definition) oder
RDFS (RDFSchema Definition). Deshalb
kann eine OIL Ontologie beispielsweise
auch von RDFS kompatibler Software
verwendet werden.
d) Die Sprache OIL besitzt eine
schichtweise Architektur. Damit wird
verhindert, dass die Kernsprache überladen
und somit Features vermischt werden, die
beim Reasoning zu Fehlern führen können.
Durch die verschiedenen Schichten sind die
Grenzen der Sprache klar und übersichtlich.
7. TAMBIS in OIL
Die Sprache OIL (Ontology Inference
Layer) gilt heutzutage als Standard für die
Entwicklung von Ontologien [3]. Deswegen
haben die Entwickler von TAMBIS auch
beschlossen, die TaO in OIL zu
konvertieren. Zum Einen soll dadurch die
Weiterenwicklung der Ontologie vereinfacht
werden. Zum Anderen war ein Schwerpunkt
die Steigerung der Portabilität, so dass die
TaO vielleicht auch in anderen Systemen
zum Einsatz kommen könnte.
Im
wesentlichen zeichnet sich die Sprache OIL
durch folgende vier Haupcharakteristika aus:
8. Ontology Engineering
Die Modellierung einer Ontologie, die so
komplex ist wie die TaO, erfordert einiges
an Fachwissen und Vorüberlegung, damit
sich nicht schon im Ansatz der Entwicklung
Fehler einschleichen. Ein solcher Prozeß in
OIL [4] kann in drei grundlegende Schritte
eingeteilt werden:
a)
Zunächst
müssen
wesentliche
Basiskonzepte
sehr
gründlich
und
ausführlich definiert werden.
a) OIL läßt sich intuitiv erlernen und
bedienen, d.h. „learning by doing“ ist
möglich. So ist der Einsteiger schon nach
kurzer Einarbeitungsphase in der Lage,
Ontologien zu modellieren und während
dieses Prozesses immer tiefer in die
Feinheiten der Sprache einzutauchen.
Zudem sind momentan bereits mehrere
Tools (OilEd, OntoEdit, usw.) erhältlich, die
den Programmierer bei der Entwicklung
einer Ontologie unterstützen.
b) Anschließend werden diese Konzepte
durch
erste
„kind-of“-Beziehungen
verknüpft und somit eine Art Grundgerüst
der Ontologie erstellt. Abbildung 7 zeigt ein
mögliches Modell, welches sich in diesem
frühen Stadium befindet. Es ist sehr breit
und flach, da bestimmte Superkonzepte
definiert wurden, die eine große Anzahl an
Kindern (orange) haben können. Die Tiefe
des dargestellten Graphen ist nicht sehr
groß, d.h. um Fehler zu vermeiden, wurde es
relativ einfach gehalten.
b)
Der
Sprache
OIL
liegt
die
ausdrucksstarke Description Logic SHIQ
zugrunde, die neben der syntaktischen
Korrektheit der Ontologie auch eine
wohldefinierte Semantik der Konzepte und
Relationen erlaubt. Weiterhin bietet sie eine
unbegrenzte
Verschachtelung
von
Konzepten, die Möglichkeit, Konzepte durch
boolesche Operatoren zu verknüpfen, und
das Festlegen genereller Axiome durch den
Programmierer an. Inverse (hasComponent
invers zu partOf) oder transitive Relationen
c) Schließlich werden die Konzepte durch
den
eingebundenen
Reasoning-Service
automatisch klassifiziert. Abbildung 8 zeigt
das Beispielmodell nach diesem Schritt.
Man erkennt, dass der Status der
Superkonzepte aufgehoben wurde, also die
Konzepte wesentlich gleichmäßiger verteilt
sind. Zudem ist der Graph schmaler und
tiefer als am Anfang.
7
Abb.: 7
Abb.: 8
„atomic-number“ eine große Rolle, da es
ausreicht, um alle Atome klar zu
unterscheiden. Im Periodensystem der
Elemente wird jedem Atom eine eindeutige
Ordnungszahl zugewiesen. Genau diese
repräsentiert „atomic-number“. Kohlenstoff
hat zum Beispiel die Ordnungszahl 6 und
das entsprechende ontologische Konzept den
Wert 6 bei „atomic-number“.
Nach dem letzten Schritt kann man wieder
bei b) beginnen und das nun vorhandene
Modell sowohl „Bottom-up“ als auch „Topdown“ zu verfeinern. Es können neue
Konzepte und Relationen hinzugefügt und
entfernt sowie Fehler beseitigt werden. Das
„Ontology-Engineering“ ist also ein
zyklischer Prozess, bei dem die Ontologie
sukzessive aufgebaut wird. Dabei hängt die
Effizienz des „Reasoners“ vor allem von der
exakten und ausführlichen Beschreibung der
einzelnen Konzepte ab. Beispiel 1 gibt einen
kurzen Einblick, dass dies nicht unbedingt
auch umständlich ist.
9. Die Grenzen des TAMBIS-Systems
TAMBIS bietet einen guten und innovativen
Ansatz, die heutigen Probleme bei der
Informationssuche über bioinformatische
Datenquellen zu lösen. Das Projekt wird von
den Entwicklern als erfolgreich angesehen
und gilt in vielen Veröffentlichungen als ein
Paradebeispiel für die Einbettung einer
Ontologie in ein funktionierendes System.
Trotzdem ist TAMBIS bis heute noch nicht
über den Projektstatus hinausgekommen, da
es einige Mankos aufweist, deren Lösung
Ziel weiterer Studien sein wird. Vor allem
die Geschwindigkeit bei der Kommunikation
mit den einzelnen Datenquellen gilt es zu
erhöhen. So sorgen nicht nur die großen
Entfernungen und die jeweiligen technischen
Gegebenheiten der durchquerten Netze,
sondern auch das hohe Datenaufkommen bei
Beispiel 1 – „ATOM“
class-def defined atom
subclass-of chemical
slot-constraint atomic-number
cardinality 1
value-type integer
has-value (min 1)
Dieses Beispiel stammt offensichtlich aus
der molekularbiologischen Domäne und
stellt das Basiskonzept „Atom“ dar. Neben
der Definition des Namens und der Angabe
des parentalen Konzeptes, spielt das Attribut
8
sehr allgemeinen Anfragen für hohe
zeitliche Latenz. Außerdem planen die
Entwickler den Anschluss an bis zu 15
verschiedene Datenquellen, was das
Transfervolumen nochmals erhöht. Es
existiert zwar der Vorschlag, einige stark
frequentierte Quellen (z.B.: SwissProt) lokal
zu speichern, jedoch ist dies wiederum mit
hohen Kosten (Serverfarm, Lizenzen)
verbunden. Zudem bleibt offen, wie
TAMBIS selbst auf starke Frequentierung
reagiert, also wie das System mit mehreren
tausend Zugriffen pro Tag zurechtkommt.
Die ständig neuen, wissenschaftlichen
Erkenntnisse
im
Bereich
der
Molekularbiologie
erfordern
eine
fortwährende Wartung und Aktualisierung
des Systems. Schließlich bleibt immer noch
offen, wie gut TAMBIS von der
biologischen
Forschungsgemeinschaft
angenommen wird, da die Arbeit mit den
bereits etablierten Systemen zur Gewohnheit
geworden ist und TAMBIS einen nicht
unerheblichen
Einarbeitungsaufwand
erfordert. Dies gilt vor allem mit der in der
TaO festgelegten Semantik vieler molekularbiologischer Begriffe, die sich stark von den
Vorstellungen der Benutzer unterscheiden
kann. Abschließend bleibt es also offen,
inwieweit sich TAMBIS in der Zukunft
durchsetzen kann.
[3] Building a Bioinformatics Ontology
Using OIL
Robert Stevens, Carole Goble, Ian Horrocks
and Sean Bechhofer
[4] Building a Reason-able Bioinformatics
Ontology Using OIL
Robert Stevens, Ian Horrocks, Carole Goble
and Sean Bechhofer
[5] Query Processing in the TAMBIS
Bioinformatics Source Integration System
Norman W. Paton, Robert Stevens, Pat
Baker, Carole A. Goble, Sean Bechhofer,
Andy Brass
[6] TAMBIS: Transparent Access to
Bioinformatics Information Sources
Final Report: BIF/05344 Andy Brass, Carole
Goble and Norman Paton
[7] Anfragebearbeitung unter
Verwendung von Ontologien
J. Forberg
http://www.dbis.informatik.huberlin.de/lehre/SS02/SemGen/Buch/kapitel9
[8] TAMBIS - Projektseite
http://imgproj.cs.man.ac.uk/tambis/
Referenzen
[1] TAMBIS - Transparent Access to
Multiple Bioinformatics Information
Sources
Patricia G. Baker, Andy Brass, Sean
Bechhofer, Carole Goble, Norman Paton,
Robert,Stevens
[2] An Ontology For Bioinformatics
Applications
Patricia G. Baker,Carole A. Goble Sean
Bechhofer, Norman W. Paton, Robert
Stevens, Andy Brass
9