Studienarbeit

Entwicklung einer Schnittstelle zur Abfrage von Protein-Protein-Interaktionsgraphen Benjamin Gehrels 27. M¨arz 2012

Betreut durch Prof. Dr. Ulf Leser, Philippe Thomas und Andr´e Koschmieder

Zusammenfassung Proteine und deren Interaktionen sind von großem Interesse in der biowissenschaftlichen Forschung. Aufbauend auf einer bestehenden Datenbank von aus den Literaturdatenbanken PubMed und PubMed Central extrahierten Interaktionsdaten wurde im Rahmen dieser Arbeit eine Java API entwickelt. Diese basiert auf der Graphdatenbank Neo4j und unterst¨ utzt die Selektion von Teilgraphen anhand vom Nutzer bestimmbarer Suchkriterien. Auf Basis dieser API wurde ein Plugin zur Selektion und Anzeige dieser Interaktionsgraphen in der Graphenvisualisierungssoftware Cytoscape entwickelt. Dies erm¨oglicht Nutzern mit Interesse an Proteininteraktionsdaten eine schnelle Vorauswahl und eine einfache Navigation durch die enormen Mengen wissenschaftlicher Texte in PubMed.

Inhaltsverzeichnis 1. Motivation

7

2. Ziel dieser Arbeit

8

3. Hintergrund 3.1. Biologische Netze . . . . . . . . . . . . 3.2. Datenquellen biologischer Netze . . . . 3.3. Datenextraktion und Textmining . . . 3.4. Anzeige, Gruppierung und Navigation

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

9 9 10 10 11

4. Grundlegende Begriffe 4.1. Graphentheoretische Begriffe . . . . . . . . . . . . . 4.2. Relationale und Graphdatenbanksysteme . . . . . . 4.3. Eingebettetes Datenbankmanagementsystem . . . . 4.4. OLAP und OLTP . . . . . . . . . . . . . . . . . . . 4.5. Der ETL-Prozess: Extraction, Transformation, Load 4.6. Dom¨ anenspezifische Sprachen . . . . . . . . . . . . . 4.7. Interne Dom¨ anenspezifische Sprachen . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

13 13 15 16 16 17 18 19

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5. Anforderungen und Konzeption 21 5.1. Anfragem¨ oglichkeiten der API . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Anforderungen an die Datenbank . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Das Cytoscape Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Auswahl eines geeigneten Datenbankmanagementsystems 6.1. Relationale Datenbankmanagementsysteme . . . . . . . 6.1.1. MySQL Community Server . . . . . . . . . . . . 6.1.2. SQLite . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3. Apache Derby und H2 Database Engine . . . . . 6.2. Graphbasierte Datenbankmanagementsysteme . . . . . . 6.2.1. Neo4j . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2. HyperGraphDB . . . . . . . . . . . . . . . . . . . 6.2.3. InfoGrid . . . . . . . . . . . . . . . . . . . . . . . 6.3. Vergleich der Datenbankmanagementsysteme . . . . . . 6.4. Abschließende Auswahl eines DBMS . . . . . . . . . . .

3

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

25 25 25 26 26 26 27 27 28 29 30

7. Implementierung 7.1. Das Datenbankschema . . . . . . . . . . . . . . . . . . 7.1.1. Das Quellschema . . . . . . . . . . . . . . . . . 7.1.2. Das Zielschema . . . . . . . . . . . . . . . . . . 7.2. Datenextraktion, Schematransformation, Bef¨ ullung der 7.2.1. Datenextraktion und Schematransformation . . 7.2.2. Das Bef¨ ullen der Zieldatenbank . . . . . . . . . 7.3. Implementierung der Java API . . . . . . . . . . . . . 7.4. Entwicklung eines Plugins f¨ ur Cytoscape . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

34 34 34 36 38 39 42 42 48

8. Auswertung

50

A. Literaturverzeichnis

53

B. Die Schnittstellen der Java-API

58

C. Abschließendes

70

4

Abbildungsverzeichnis 6.1. Evaluation der H2 Database Engine: ER-Modell des Schemas . . . . . . . 31 6.2. Evaluation von Neo4j: Ausschnitt aus der Datenbank . . . . . . . . . . . . 31 7.1. 7.2. 7.3. 7.4. 7.5. 7.6.

Das Quellschema der vorliegenden Daten . . . . . . . . . . . . . . . . . ER-Modell des entwickelten Zielschemas . . . . . . . . . . . . . . . . . Datenfluss w¨ ahrend des ETL-Prozesses . . . . . . . . . . . . . . . . . . Neo4j: fiktiver Ausschnitt aus der Datenbank . . . . . . . . . . . . . . Grafische Schnittstelle zum Erstellen von Suchanfragen gegen die API Ein Anfrageergebnis mit selektierten Proteinen und deren Attributen .

5

. . . . . .

. . . . . .

35 38 39 43 48 49

Listings 4.1. Mockito als Beispiel einer internen dom¨anenspezifischen Sprache . . . . . 19 7.1. 7.2. 7.3. 7.4. 7.5.

SQL-Code zur Abfrage interagierender Proteine (Quellschema) . . . . . . SQL-Code zur gefilterten Abfrage interagierender Proteine (Quellschema) Abfrage aller Interaktionen u ¨ber die Java API . . . . . . . . . . . . . . . . Beispielanfragen gegen die API . . . . . . . . . . . . . . . . . . . . . . . . Ausschnitt aus der Klasse GraphDatabaseProtein . . . . . . . . . . . . . .

B.1. info.gehrels.ppi.api.Algorithm . . . . . . . . . . . . . . . . . . . . . . B.2. info.gehrels.ppi.api.Algorithms . . . . . . . . . . . . . . . . . . . . . B.3. info.gehrels.ppi.api.Citation . . . . . . . . . . . . . . . . . . . . . . . B.4. info.gehrels.ppi.api.Interaction . . . . . . . . . . . . . . . . . . . . . . B.5. info.gehrels.ppi.api.InteractionFilter . . . . . . . . . . . . . . . . . . B.6. info.gehrels.ppi.api.graphImpl.selectors.interaction.InteractionFilters B.7. info.gehrels.ppi.api.InteractionQuery . . . . . . . . . . . . . . . . . . B.8. info.gehrels.ppi.api.InteractionRepository . . . . . . . . . . . . . . . B.9. info.gehrels.ppi.api.Protein . . . . . . . . . . . . . . . . . . . . . . . . B.10.info.gehrels.ppi.api.ProteinSelector . . . . . . . . . . . . . . . . . . . B.11.info.gehrels.ppi.api.graphImpl.selectors.protein.ProteinSelectors . . .

6

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

36 37 44 45 47 58 58 58 59 60 60 64 66 67 68 68

1. Motivation Proteine und deren Interaktionen sind von großem Interesse in der biowissenschaftlichen Forschung. Es gibt daher bereits einige Datenbanken mit Informationen, welche Proteine miteinander interagieren (vgl. Kim et al. [2008]). Gleichwohl liegt ein nicht unerheblicher Anteil dieser Informationen nicht in strukturierten Datenbanken, sondern in unstrukturierter Textform als Publikation in wissenschaftlichen Journalen und anderen Medien vor [Temkin und Gilder, 2003]. Die Erschließung dieser bisher unstrukturierten Informationen f¨ ur eine automatisierte Analyse und Verarbeitung sowie die Integration mit bestehenden, strukturierten Informationen stellt daher einen interessanten Weg bei der Erforschung biologischer Prozesse dar [Hoffmann et al., 2005]. Eine solche Datenbank liegt am Lehrstuhl f¨ ur Wissensmanagement in der Bioinformatik der Humboldt-Universit¨ at zu Berlin vor. Die hierin enthaltenen Daten wurden mittels TextMining-Verfahren aus biomedizinischen Fachtexten der Literaturdatenbanken PubMed1 und PubMed Central2 gewonnen. Diese Interaktionsdatenbank umfasst ungef¨ahr 170.000 Proteinnamen mit u ¨ber 1,6 Millionen unterschiedlichen Interaktionen in circa 6 Millionen S¨atzen aus circa 1,4 Millionen Abstracts3 . Um solche Informationsmengen f¨ ur menschliche Nutzer begreifbar zu machen, bedarf es einer M¨ oglichkeit, einzelne Aspekte aus dieser Datenmenge herauszugreifen, isoliert zu betrachten und durch diese Daten zu navigieren, beispielsweise mittels einer Selektion kleiner Teilgraphen nach bestimmten Kriterien. Aber auch die Selektion gr¨oßerer Teilgraphen zur algorithmischen Verarbeitung bietet interessante M¨oglichkeiten, beispielsweise zur Vorhersage bisher nicht bekannter Interaktionen anhand von Struktureigenschaften ¨ ur et al. [2008]). des Graphen (vgl. bspw. Ozg¨ Eine etwaige Weitergabe oder gar Ver¨offentlichung der vorliegenden Interaktionsdaten b¨ote auch Nutzern außerhalb des Lehrstuhls die M¨oglichkeit, diese Daten f¨ ur ihre Forschungsprojekte zu nutzen und sie mit anderen Datenbanken zu verkn¨ upfen.

1

PubMed ist zu finden unter http://www.pubmed.gov. PubMed Central ist zu finden unter http://www.ncbi.nlm.nih.gov/pmc. 3 Pubmed umfasst deutlich mehr S¨ atze und Abstracts. In der Datenbank enthalten sind nur die S¨ atze und Abstracts, in denen eine Interaktion gefunden wurde.

2

7

2. Ziel dieser Arbeit Ziel dieser Arbeit ist, die vorliegenden Interaktionsdaten in ein einfach verteilbares Format zu u uhren, um eine Weitergabe und eventuelle Ver¨offentlichung der Daten zu ¨berf¨ erm¨oglichen. Es soll eine Java API entwickelt werden, welche die Selektion von Protein-ProteinInteraktionen (im Folgenden kurz PPIs“) nach betimmbaren Kriterien erm¨oglicht. Auch ” die Abfrage von aus PPIs bestehenden Teilgraphen soll m¨oglich sein. Als Kriterien sind hier beispielsweise die beteiligten Taxa, die Namen der interagierenden Proteine, aber auch Daten bez¨ uglich der Fundstellen (Anzahl, Journal, Ver¨offentlichungsdatum u.¨a.) denkbar. Zur graphischen Darstellung der Graphen soll ein Plugin f¨ ur die Graphenvisualisierungssoftware Cytoscape [Shannon et al., 2003] entwickelt werden, welches die Java API nutzt.

8

3. Hintergrund Proteine sind ein wichtiger Bestandteil biologischer Zellen. Sie erf¨ ullen eine Vielzahl von Funktionen, unter anderem als Katalysatoren biochemischer Reaktionen, als Garanten physischer Stabilit¨ at, zur Steuerung der Genexpression und als Signal¨ ubermittler. Dies geschieht durch die biochemische Interaktion mit anderen Proteinen und Substanzen. Das Wissen u ¨ber die Menge der Proteine in einem Organismus (das sogenannte Proteom) und die Menge ihrer Interaktionen (das sogenannte Interaktom) ist daher grundlegend f¨ ur die Erforschung biologischer Prozesse [B¨ornke, 2008].

3.1. Biologische Netze Beziehungen zwischen einzelnen Entit¨aten lassen sich h¨aufig als Netze interpretieren, wobei die Entit¨ aten die Knoten des Netzes und ihre Beziehungen die Verbindungen (Kanten) zwischen den Knoten darstellen. Im biologischen Bereich werden solche Netze, die das Zusammenspiel verschiedener biologischer Entit¨aten (Gene, Proteine, Enzyme, etc.) beschreiben auch als Pathways bezeichnet. Auch das Interaktom l¨asst sich als ein solches Netz interpretieren, wobei die einzelnen Proteine als Knoten und Interaktionen als Kanten zwischen den Knoten modelliert werden [Junker, 2008]. Eine solche Interpretation ist nicht nur als Veranschaulichung komplexer biologischer Zusammenh¨ ange interessant. Sie erm¨oglicht es auch, das Interaktom als Graphen zu interpretieren und somit graphentheoretische Algorithmen darauf anzuwenden. So kann man nicht nur einzelne Proteine und ihre Interaktionen, sondern auch das Netz als ganzes betrachten und seine Eigenschaften untersuchen. Es k¨onnen beispielsweise besonders zentrale Proteine, stark in sich verkn¨ upfte Teilgraphen oder bestimmte Muster im ¨ ur et al. [2008] schlagen beispielsweise vor, Graph gefunden werden [Junker, 2008]. Ozg¨ ausgehend von einem Geninteraktionsnetz und einer kleinen Mege bekanntermaßen mit einer Krankheit assoziierter Gene im Umfeld dieser Gene nach zentralen Knoten zu suchen. Diese k¨ onne man dann darauf untersuchen, ob sie ebenfalls mit dieser Krankheit assoziert sind. Jeong et al. [2001] haben f¨ ur das Beispiel Backhefe gezeigt, dass die Wahrscheinlichkeit that removal of a protein will prove lethal correlates with the number ” of interactions the protein has“. Die Entfernung sehr zentraler Proteine scheint also kritischer als die Entfernung weniger zentraler Proteine.

9

3.2. Datenquellen biologischer Netze M¨ochte man solche Interaktionsnetze betrachten oder verarbeiten, so gilt es, Datenquellen f¨ ur die Interaktionsdaten zu finden. Hier gibt es bereits verschiedene teils frei verf¨ ugbare Datenbanken [Fischer et al., 2005]. Gewonnen werden dieses Daten haupts¨achlich u ¨ber zwei Wege: Zum einen gibt es Hochdurchsatz-Methoden, welche im Labor automatisiert große Mengen von Proteinen auf ihre paarweise Interaktion testen [B¨ornke, 2008]. Diese werden meist automatisiert in einzelne PPI-Datenbanken eingepflegt [Brosy, 2010, 1.1]. Zum anderen lassen sich Interaktionsdaten manuell oder automatisiert aus wissenschaftlichen Publikationen zusammentragen [B¨ornke, 2008]. Da die Nutzung von Hochdurchsatzmethoden meist mit einer hohen Fehlerquote einher geht, sind die Informationen aus wissenschaftlichen Publikationen, welche mit Niedrigdurchsatzmethoden gewonnen wurden, von besonderem Interesse [Brosy, 2010, 1.2]. Textquellen k¨ onnen hierf¨ ur beispielsweise PubMed und PubMed Central sein. PubMed ist ein Onlinedienst des United States National Center for Biotechnology Information. Er stellt eine Literatursuche f¨ ur Artikel aus Life Science Journals dar. Momentan sind dort u ¨ber 21 Millionen Artikel1 aus u ¨ber 5.500 Journals2 zu finden, wobei die Daten st¨andig aktualisiert werden. F¨ ur viele dieser Artikel steht ein Abstract kostenlos zur Verf¨ ugung. PubMed Central (PMC) ist ein kostenfreies Volltext-Archiv der U.S. National Institutes of Health’s National Library of Medicine. Es enth¨alt rund 2.3 Millionen Artikel. Die Abstracts aus PubMed und die Volltexte aus PubMed Central bieten zusammen eine beachtliche Datengrundlage f¨ ur die manuelle und auch f¨ ur die automatische Suche nach PPI-Daten.

3.3. Datenextraktion und Textmining Mehrere Arbeiten haben bereits versucht, aus diesen Texten biologische Pathways zu extrahieren. Hierbei wurden verschiedene Methoden des Text-Minings eingesetzt (vgl. Hoffmann et al. [2005]). Gemeinsam ist ihnen, dass sie meist in einem ersten Schritt Entit¨atsnamen in den Texten suchen und dann aufgrund von Co-Occurrence, also dem Vorkommen von zwei Entit¨ atsnamen in einem Kontext (Satz, Absatz o. ¨a.), eine Eingrenzung der zu verarbeitenden Textmengen vornehmen. Danach gilt es festzustellen, bei welchen der Co-Occurrences es sich wahrscheinlich tats¨achlich um eine Interaktion handelt. Hierf¨ ur sind verschiedene Verfahren m¨oglich: So k¨onnte man alle Co-Occurrences als Treffer zur¨ uckgeben, wie beispielsweise in [Stapley und Benoit, 1999]. Als weitere einfache Methode sind schl¨ usselwortbasierte Verfahren zu nennen. So haben Blaschke et al. [1999] nur solche Kandidaten als Interaktion bewertet, bei denen zwischen den Proteinnamen genau ein Wort steht. Dieses Wort muss dabei 1 2

Quelle: http://www.ncbi.nlm.nih.gov/books/NBK3827/, abgerufen am 22. Dezember 2012. Quelle: http://www.ncbi.nlm.nih.gov/sites/entrez?Term=currentlyindexed&Cmd= DetailsSearch&Db=journals, abgerufen am 22. Dezember 2012.

10

eines von 14 vorgegebenen Verben in einer von 49 vorgegebenen Flexionsformen sein. Ein komplexeres Verfahren, welches auf Basis der grammatischen Struktur des Satzes und der semantischen Bedeutung erkannter Begriffe versucht, Interaktionen zu bestimmen, wurde durch Rindflesch et al. [1999] beschrieben. Zuletzt seien an dieser Stelle noch Methoden des maschinellen Lernens erw¨ahnt. Brosy [2010] nutzt einen sogenannten GoldStandard-Korpus3 , unterzieht diesen einer oberfl¨achlichen linguistischen Behandlung (Lemmatisierung, Part-of-Speach-Tagging) und trainiert darauf eine Support Vector Machine ( jSRE“, vgl. [Giuliano et al., 2006]). Diese wird dann zur Klassifizierung der ” Co-Occurrences genutzt. Auch die Reichhaltigkeit der extrahierten Daten unterscheidet sich je nach Arbeit. So extrahieren einige nur die Tatsache, dass zwei Proteine interagieren, andere hingegen extrahieren auch Beziehungen zwischen anderen biologischen Entit¨aten, die Art der Beziehung (beispielsweise Aktivierung, Phosporylisierung) oder eine etwaige Richtung (A aktiviert B oder B aktiviert A). Die im Rahmen dieser Arbeit zug¨anglich gemachten Interaktionsdaten wurden durch Philippe Thomas mit einem Verfahren, welches im Wesentlichen dem durch Brosy [2010] entwickelten entspricht, aus PubMed und PubMed Central extrahiert.

3.4. Anzeige, Gruppierung und Navigation M¨ochte man in der großen Menge biomedizinischer Texte bestimmte Informationen mit Proteinbezug finden, so bedarf es eines Konzepts, wie diese kognitiv erfassbar dargestellt werden k¨ onnen. Hoffmann und Valencia [2005] haben die These aufgestellt, dass es, will man diese Texte in ein navigierbares Netzwerk konvertieren, n¨otig sei, diese in Cluster ” gleicher Gr¨ oße und gleichen Informationsgehalts zu teilen“. Sie haben ein System namens iHoP“4 entwickelt, welches f¨ ur jedes Protein einen solchen Cluster bildet, bestehend aus ” allen S¨atzen in PubMed, welche den Proteinnamen enthalten. Sucht man dort nach einem Protein, so bekommt man eine Webseite mit den Volltexten all dieser S¨atze angezeigt, zusammen mit je einem Link zum dazugeh¨origen PubMed Abstract. Jedes andere Protein im Text ist als Hyperlink auf den dazugeh¨origen Cluster farblich hervorgehoben. So ist es m¨oglich, manuell von Protein zu Protein durch das Netz zu navigieren. Es ist außerdem m¨oglich, einzelne S¨ atze zu selektieren, wobei die enthaltenen PPIs als grafisches Netz gezeichnet werden. Einen Schritt weiter gehen Stark et al. [2011] mit dem System BioGRID“5 . Hierbei ” handelt es sich, wie auch bei iHOP, um eine Web-Schnittstelle, wobei BioGRID manuell aus Prim¨ arliteratur kurierte Protein- und Geninteraktionsdaten beinhaltet. BioGRID bildet ebenfalls Cluster zu jeder Interaktion. Ruft man ein Protein auf, so wird – neben 3

Ein Korpus, bei dem bereits bekannt und annotiert ist, bei welchen Termen es sich um interagierende Entit¨ aten handelt. 4 iHop ist zu finden unter http://www.pdg.cnb.uam.es/UniPub/iHOP/. 5 BioGRID ist zu finden unter http://thebiogrid.org/.

11

den aus mehreren anderen Datenbanken zusammengetragenen Proteinannotationen – auch zu jedem interagierenden Protein der Fundstellencluster der Interaktion angezeigt. Neben den S¨ atzen der Fundstellen werden auch die zu Grunde liegenden experimentellen Methoden sowie die Information, ob es sich um ein Hochdurchsatzexperiment handelte, angezeigt. Es gibt Filterm¨ oglichkeiten, sowohl nach Taxon des Proteins als auch danach, ob es sich um ein Hochdurchsatzexperiment handelt. Mit BSQA“6 haben He et al. [2010] ein Web-Interface entwickelt, welches drei Grunden” tit¨aten kennt: Gene, Verhaltensweisen und K¨orperteile. Gesucht werden k¨onnen Gen-Gen-, Gen-Verhaltens- und Gen-K¨ orperteil-Beziehungen sowie einfache Worte in den Volltexten. F¨ ur letzeres steht nach Eingabe des Suchbegriffes eine Ergebnisliste mit einem ErgebnisRanking zur Verf¨ ugung. Interaktionssuchen k¨onnen hier auch kleine Muster im Graphen finden, so beispielsweise: Find pairs of regulator-target genes that are expressed in ” anatomical tissue X.“. M¨ochte man statt einer einfachen Webseite oder eines gerenderten Bildes eine interaktive Graphdarstellung, so bietet sich u. a. Cytoscape [Shannon et al., 2003] an. Cytoscape dient der Anzeige von Property-Multigraphen, also Property-Graphen (siehe Abschnitt 4) mit ggf. mehreren Kanten zwischen zwei Knoten (vgl. Abbildung 7.6). Cytoscape bringt auch Layout-Algorithmen zur automatischen Anordnung der Knoten mit und der VizMapperTM “ erlaubt es, Darstellungsmerkmale einzelner Graphelemente abh¨angig ” von Attributwerten zu machen. Somit kann man beispielsweise die Strichdicke einer Interaktionskante abh¨ angig von der Anzahl ihrer Textfundstellen machen. Durch die Entwicklung von Plugins lassen sich auch eigene Datenquellen und Algorithmen in Cytoscape einbinden und ansteuern. Ein solches Plugin stellt iRefScape“ dar, welches dem Import von Interaktionsdaten ” aus der Integrationsplattform iRefIndex“ dient [Razick et al., 2011]. Es erlaubt das ” Importieren der direkten Nachbarschaft eines Knotens, also all seiner umgebenden Kanten, aber auch den Import des dadurch gegebenen induzierten Teilgraphen. Es nutzt die Attribute des Graphen, um viele Annotationen einzubetten, wie beispielsweise Taxon-Zuordnungen oder Querreferenzen auf andere Datenbanken. Auch die Erstellung komplexer Filter ist m¨ oglich.

6

BSQA ist zu finden unter http://www.beespace.uiuc.edu/QuestionAnswer.

12

4. Grundlegende Begriffe Im Folgenden werden einige f¨ ur diese Arbeit relevante grundlegende Begriffe eingef¨ uhrt, beginnend mit einigen Graphentheoretischen Begriffen. Darauf folgen Klassifizierungsund Anwendungsm¨ oglichkeiten f¨ ur Datenbankmanagementsysteme sowie einige Begriffe aus dem Bereich der dom¨ anenspezifischen Sprachen, welche f¨ ur die sp¨atere Schnittstellendefinition der Java API relevant sind.

4.1. Graphentheoretische Begriffe Da die Datengrundlage dieser Arbeit als Graph aus Proteinen und ihren Interaktionen darstellbar ist, werden einige Begriffe der Graphentheorie vorausgesetzt. Zuerst w¨are hier der Graph selbst zu nennen: Definition 1. Gegeben sei eine Menge V und eine Menge von zweielementigen Mengen E, wobei gilt: e ∈ E ⇒ e ⊆ V . Das Tupel G = (V, E) heißt (ungerichteter) Graph. Ein v ∈ V wird Knoten von G genannt, ein e ∈ E Kante von G. Zwischen zwei Knoten eines Graphen k¨onnen Pfade existieren: Definition 2. Ein n-Tupel (v1 , . . . , vn ) mit n ∈ N wird Pfad im Graphen G = (V, E) genannt, wenn v1 , . . . , vn ∈ V und f¨ ur alle i ∈ {1, . . . , n − 1} gilt: {vi , vi+1 } ∈ E. Definition 3. Sei p = (v1 , . . . , vn ) mit n ∈ N ein Pfad. Dann ist κ(p) = {{vi , vi+1 }|1 ≤ i < n, i ∈ R} die Kantenmenge von p. Aufbauend hierauf l¨ asst sich der Property-Graph definieren, eine Spezialform eines Graphen: Definition 4. Seien G = (V, E) ein ungerichteter Graph, die Schl¨ usselmenge K sowie die Wertemenge W beliebige Mengen und p : (V ∪ E) × K → W eine partielle Funktion. Dann ist P G = (V, E, p) ein Property-Graph. p wird hierbei Attributfunktion genannt. Gilt f¨ ur ein x ∈ (V ∪ E), dass p(x, k) = w, dann wird (k, w) als Attribut von x bezeichnet, wobei k Schl¨ ussel und w Wert des Attributs genannt werden. Die Menge aller Attribute eines x ∈ (E ∪ V ) wird Attributmenge von x genannt.

13

Ein Proteininteraktionsnetz l¨ asst sich als Property-Graph modellieren. Hierbei stellen die Proteine Knoten, die Interaktionen zwischen den Proteinen Kanten dar. Die Attributmenge eines Proteinknotens p k¨ onnte wie folgend aussehen: {(N ame, BRCA1), (Entrez − Id, 672), (T axon − Id, 9606)}. Da auch Mengen und Tupel Werte eines Attributs sein k¨onnen, kann man die Interaktionskanten auch mit komplexen, zusammengesetzten Attributen annotieren: {(quellen, {(P M C 1797634 Satz 5, Konf idenz 3)})}. M¨ochte man beispielsweise das menschliche Interaktom visuell analysieren, so macht es kaum Sinn, den gesamten so gebildeten Property-Graphen zu betrachten, insbesondere, da die Menge der Kanten und Knoten nicht zu u ¨ berblicken ist. Vielmehr erscheint es sinnvoll, lediglich Teilgraphen zu betrachten: Definition 5. Seien G = (V, E) und GT = (VT , ET ) ungerichtete Graphen. GT ist ein Teilgraph von G, wenn gilt: VT ⊆ V und ET ⊆ E. Drei M¨oglichkeiten der Teilgraphselektion seien besonders hervorheben. Die ersten beiden werden als Anfragemuster f¨ ur die API genutzt: Definition 6. Seien G = (V, E) ein ungerichteter Graph, GT = (VT , ET ) ein Teilgraph von G, die Ausgangsknotenmenge C ⊆ V und n ∈ N. GT ist der Kleine-Welt-Graph der Tiefe n von C in G, wenn f¨ ur jedes x ∈ (V ∪ E) gilt: Ein Pfad p = {v1 , . . . , vn } mit v1 , vn ∈ C, x ∈ p ∪ κ(p) und |κ(p)| ≤ n existiert gdw. x ∈ (VT ∪ ET ). Der Begriff Kleine-Welt-Graph“ ist hierbei angelehnt an das von Milgram [1967] be” schriebene Kleine-Welt-Problem“: ” Given any two people in the world, person X and person Z, how many intermediate aquiantance links are needed before X and Z are connected? Der hier definierte Kleine-Welt-Graph enth¨alt genau alle solchen Pfade zwischen zwei Knoten mit einer definierten maximalen L¨ange. Definition 7. Seien G = (V, E) ein ungerichteter Graph, GT = (VT , ET ) ein Teilgraph von G, die Ausgangsknotenmenge C ⊆ V und n ∈ N. GT ist der Nachbarschaftsgraph der Tiefe n von C in G, wenn f¨ ur jedes x ∈ (V ∪ E) gilt: Ein Pfad p = {v1 , . . . , vn } mit v1 ∈ C, x ∈ p ∪ κ(p) und |κ(p) ≤ n| existiert gdw. x ∈ (VT ∪ ET ). Die dritte M¨ oglichkeit der Teilgraphendefinition, der induzierte Teilgraph, wird sp¨ater als Postprocessing-Stufe der Ergebnismenge genutzt werden: Definition 8. Seien G = (V, E) ein ungerichteter Graph und GT = (VT , ET ) ein Teilgraph von G. GT ist ein induzierter Teilgraph von G, wenn f¨ ur alle v1 , v2 ∈ VT gilt: {v1 , v2 } ∈ E ⇔ {v1 , v2 } ∈ ET .

14

4.2. Relationale und Graphdatenbanksysteme Datenbanksysteme lassen sich prim¨ar aufgrund des zugrundeliegenden Datenmodells klassifizieren. Neben dem sehr verbreiteten relationalen Modell [Codd, 1970], sei an dieser Stelle das Modell des gerichteten oder ungerichteten Graphen hervorgehoben. Datenbanken, die auf obiger oder anderen (vgl. Angles und Gutierrez [2008]) GraphDefinitionen beruhen, werden als Graphdatenbankmanagementsysteme bezeichnet. Die h¨aufig genutzten relationalen Datenbanksysteme basieren auf dem Konzept der Relation, einer Menge von Tupeln gleicher L¨ange. Beziehungen zwischen verschiedenen Tupeln verschiedener Relationen k¨onnen dargestellt werden, indem eines der Tupel den identifizierenden Schl¨ ussel des anderen Tupels als Attribut enth¨alt ( Fremdschl¨ ussel“). ” Die Abfrage von Daten basiert auf Selektion, dem Filtern von Tupeln anhand bestimmter Kritierien, sowie Projektion, der Reduktion von Tupeln auf bestimmte Elemente des Tupels. Mit Joins lassen sich die Tupel mehrerer Relationen zu einer neuen Relation verkn¨ upfen. Angefragt werden relationale Datenbanken in der Regel mit SQL [SQL, 1999], welches auch die M¨ oglichkeit der Datenaggregation durch Gruppierung unter Verwendung von Aggregationsfunktionen bietet. Joins gelten im Allgemeinen als sehr rechenaufwendig, wobei sich der Aufwand durch Indexstrukturen u ¨ber den Relationen verringern l¨asst. Graphdatenbanken hingegen stellen nicht Mengen von Entit¨aten in den Vordergrund, die dann u upft werden k¨onnen. Vielmehr steht hier die ¨ber Attribute mit anderen verkn¨ einzelne Entit¨ at und ihre Beziehung zu anderen Entit¨aten im Kern der Betrachtung. Je nach System k¨ onnen die Kanten gerichtet oder ungerichtet sein, k¨onnen Knoten und Kanten gef¨ arbt sein und k¨ onnen Attribute im Sinne eines Property-Graphen an Knoten oder Kanten annotiert sein. Ergibt sich also im relationalen Modell die Verkn¨ upfung zweier Tupel aus (meist) verschiedenen Relationen indirekt aus dem Verh¨altnis bestimmter Attributwerte beider Tupel (h¨ aufig aus der Gleichheit dieser), so ist bei Graphdatenbanken die Verkn¨ upfung zweier Entit¨ aten prim¨ arer Bestandteil des Datenmodells (vgl. Angles und Gutierrez [2008, 3.2]). Das Datenmodell ist somit spezialisiert auf Anfragen, die sich auf die Beziehungen von Objekten beziehen. Der Schwerpunkt liegt dabei h¨aufig auf dem Traversieren von Beziehungsketten (Pfaden im Graphen). Mengenbasierte Anfragen hingegen, insbesondere Gruppierungen und Aggregationen, sind mit Graphdatenbanksystemen zwar m¨oglich, liegen aber nicht im Fokus des Datenmodells. Rodriguez [2011b, 42:30] stellt diese Fokussierung auf das schnelle Traversieren des Graphen sogar in den Mittelpunkt seiner Definition von Graphdatenbanken: The ability to move from vertice to vertice to any arbitrary depth without incurring a locking cost or hitting an index to do a join every time you move along this graph – if you can do that very very fast, if you don’t have the notion of an index for adjacency, thats when you can call this thing a graph database in my mind.

15

F¨ ur die Abfrage von Graphdatenbanken beschreibt Iordanov [2010] drei Muster: So k¨onnen die Knoten- und Kantenmengen mit mengenbasierten Anfragesprachen (vergleichbar mit SQL) gefiltert, verkn¨ upft (Join) und zur¨ uckgegeben werden. Desweiteren besteht die M¨oglichkeit, Knoten- und Kantenmengen durch iteratives Traversieren des Graphen (beispielsweise Breiten- oder Tiefensuche) zu generieren. Hierbei k¨onnen Selektionen dadurch realisiert werden, dass nur Knoten und Kanten verfolgt oder zur¨ uckgegeben werden, welche bestimmten Kriterien entsprechen. Als dritte Anfragevariante werden Anfragen auf Basis von Mustererkennung (sog. Graph Pattern Matching) genannt.

4.3. Eingebettetes Datenbankmanagementsystem Eine weitere Klassifizierungsm¨ oglichkeit f¨ ur Datenbankmanagementsysteme stellt die Einbettbarkeit dar. Hiernach lassen sich Datenbankmanagementsysteme im Wesentlichen in zwei Klassen aufteilen: Zum einen solche, die als eigenst¨andige Anwendungen (Server) unabh¨angig von der Software laufen, welche sie nutzt (Client). Zum anderen solche, welche in die Software, welche sie nutzt, eingebettet (engl. embedded“) sind. ” Erstere laufen in der Regel als eigenst¨andige Prozesse im Betriebssystem, werden seperat von der sie nutzenden Software entwickelt, vertrieben und gewartet und kommunizieren mit der sie nutzenden Software u ¨ber Mechanismen der Interprozesskommunikation oder h¨aufig u ¨ber Netzwerkprotokolle. Sie sind somit oftmals sogar von verschiedenen Rechnern im Netzwerk nutzbar. Letztere sind Teil der Anwendung, welche sie nutzt. Sie werden h¨aufig als Softwarebibliothek eingebunden. Die Abfrage erfolgt u ¨ ber APIs der Programmiersprache, in welcher das DBMS und die Software, die es nutzt, geschrieben sind. Die Einbettung als Softwarebibliothek erlaubt es, das DBMS zusammen mit der Anwendung auszuliefern. Eine seperate Installation durch den Nutzer ist nicht n¨otig. F¨ ur den Nutzer der Software ist weder sichtbar noch relevant, ob und wenn ja welches DBMS genutzt wird. Auch etwaige Updates des DBMS werden vom Anbieter der Software zusammen mit dieser selbst ausgeliefert. Nachteil hierbei ist, dass die Datenbanken meist nicht von verschiedenen Prozessen gleichzeitig genutzt werden k¨onnen und auch eine Kommunikation u ¨ ber ein Netz in der Regel nicht vorgesehen ist.

4.4. OLAP und OLTP In der Literatur werden h¨ aufig zwei grundlegende Nutzungsmuster f¨ ur Datenbanken (vgl. hierzu bspw. Malinowski und Zim´anyi [2008, 2.5]) unterschieden: Weit verbreitet ist das Online Transactional Processing“ (OLTP), wobei die genutzten Datenbanken als OLTP ” ” System“ oder Operational Database“ bezeichnet werden. OLTP-Systeme sind darauf ” optimiert, sehr viele einfache, konkurrierende Zugriffe, sowohl lesend als auch schreibend, auf einen f¨ ur das aktuelle Tagesgesch¨aft notwendigen Datenbestand zu bieten. In ihnen

16

liegen in der Regel zeitlich aktuelle, detailierte Daten in einer stark normalisierten Form vor. Abgegrenzt wird hierzu in der Literatur das sogenannte Online Analytical Processing“ ” (OLAP), wobei die hierzu genutzten Systeme als OLAP System“ oder Data Ware” ” house“ bezeichnet werden. Data Warehouses sind optimiert f¨ ur verh¨altnism¨aßig seltene Schreibzugriffe und komplexe Lesezugriffe. Komplexe Lesezugriffe bedeuten in diesem Zusammenhang meist langl¨ aufige, mehrdimensionale Aggregationen und Selektionen. Die Daten sind bereits nach bestimmten Aspekten zusammengefasst und liegen h¨aufig denormalisiert vor, um JOIN-Operationen zu vermeiden. In der Regel werden nicht nur aktuelle, sondern auch historische Daten gespeichert, um beispielsweise die Entwicklung bestimmter Kennzahlen u ¨ber verschiedene Zeitabschnitte hinweg betrachten zu k¨onnen. Einmal geschriebene Daten werden in der Regel nur noch gelesen und nicht mehr aktualisert oder gel¨ oscht. Die Bef¨ ullung erfolgt periodisch mit Daten, die meist aus einem OLTP-System stammen. Beipiele f¨ ur OLTP-Anfragen sind Gib mir alle offenen Rechnungen von Kunde 0815“ ” oder Wie hoch ist der Lagerbestand von roten Tulpen in Bielefeld“. OLAP-Systeme ” hingegen beantworten eher Anfragen nach dem Muster Wie hat sich die durchschnittli” che Gewinnmarge aller verkauften Produkte der letzten 3 Jahre monatlich entwickelt, aufgeschl¨ usselt nach Produktkategorie, Monat und Filiale“.

4.5. Der ETL-Prozess: Extraction, Transformation, Load F¨ ur die Bef¨ ullung von OLAP-Systemen wird meist ein sogenannter ETL-Prozess implementiert (vgl. bspw. Malinowski und Zim´ anyi [2008, 6.8.2]). Hierbei handelt es sich um einen dreistufigen Prozess bestehend aus einer Datenextraktions-, einer Schematransformations- und einer Bef¨ ullungsphase. W¨ahrend der Datenextraktionsphase werden die f¨ ur das Data Warehouse notwendigen Rohdaten aus einem oder mehreren Quellsystemen zusammengetragen. Dies k¨ onnen nicht nur relationale Datenbanken sein, sondern beispielsweise auch Textdateien oder Web Services. Hierbei muss auch entschieden werden, ob f¨ ur die weitere Pflege des Data Warehouses inkrementelle Updates mit jeweils nur den seit der letzten Bef¨ ullung ver¨ anderten Daten erfolgen sollen, oder ob stets alle Daten (oder Teilbereiche des Data Warehouses) neu eingef¨ ugt werden sollen. In der zweiten Phase, der Schematransformation, werden diese Daten vom Schema der Datenquelle in das Schema des Data Warehouses transformiert. Dies erfolgt h¨aufig in einem Bereich einer relationalen Datenbank, der sogenannten staging area“. ” In der letzten Phase wird das Data Warehouse mit den Daten bef¨ ullt. Hierbei ist insbesondere darauf zu achten, dass die verwendeten Einf¨ ugemethoden hinreichend schnell sind. Dies kann beispielsweise durch das Umgehen der Transaktionskontrolle und damit den Verzicht auf einige der ACID-Eigenschaften erreicht werden.

17

4.6. Dom¨ anenspezifische Sprachen Nach Fowler und Parsons [2011, S. 27] lassen sich dom¨anenspezifische Sprachen1 wie folgt definieren: Domain-specific language (noun): a computer programming language of limited expressiveness focused on a particular domain. Sie beschreiben im Weiteren vier Kernelemente dieser Definition: • DSLs sind Programmiersprachen, Sie werden also genutzt, um das Verhalten eines Computers zu steuern. Sie sind so gestaltet, dass Menschen sie verstehen k¨onnen, sie aber dennoch durch Computer ausf¨ uhrbar sind. • DSLs sind Sprachen, sie sollten also eine Art von Sprachfluss entwickeln, so dass sie ihre Ausdrucksst¨ arke nicht alleine aus der Aneinanderreichung von Ausdr¨ ucken sondern auch aus der Art beziehen, wie diese zusammengef¨ ugt werden. • Der Fokus einer DSL liegt auf einer bestimmten Dom¨ane. utzen nur ein Minimum an Funktionalit¨at, welches notwendig ist, um • DSLs unterst¨ die Dom¨ ane abzubilden. Sie sind daher nicht geeignet, ganze Softwaresysteme zu bauen. Sie sind ebenso nicht zwingend Turing-vollst¨andig. Die Menge der dom¨ anenspezifischen Sprachen l¨asst sich nach Fowler und Parsons [2011, S. 28] weiter in drei Klassen unterteilen. Als Unterscheidungskriterium dient hierbei das Zusammenspiel der DSL mit der Umgebung, in der sie genutzt wird. Sogenannte Language Workbenches“ stellen eine Kombination aus einer Sprache und der ” Entwicklungsumgebung dar, mit der sie genutzt wird. Die Kopplung ist dabei so stark, dass die Sprache kaum ohne die Entwicklungsumgebung und die Entwicklungsumgebung kaum ohne die Sprache nutzbar ist. Als Beispiel k¨onnen hier g¨angige Tabellenkalkulationen gesehen werden2 : Sie erreichen nur einen Bruchteil ihrer Ausdrucksst¨arke ohne die M¨oglichkeit, einzelnen Zellen den Berechnungsinhalt einer mittels einer DSL definierten Formel zuzuweisen. Gleichzeitig lassen sich die DSLs ohne die Einbettung in ein Tabellendokument und die Anzeige der Ergebnisse in diesem kaum sinnvoll nutzen. Externe DSLs k¨ onnen aus Software heraus genutzt werden, sind aber syntaktisch unabh¨angig von der Programmiersprache, in der die sie nutzende Software geschrieben ist. Sie werden in der Regel durch die nutzende Software (oder durch von dieser genutzte Software) geparsed und ausgef¨ uhrt. Als Beispiele k¨onnen hier regul¨are Ausdr¨ ucke und SQL genannt werden. Eine dritte Klasse von DSLs stellen die sogenannten internen DSLs dar. 1 2

Nachfolgend wird teilweise die Abk¨ urzung DSL“ f¨ ur domain-specific language“ verwendet. ” ” Fowler und Parsons [2011, S. 31] merken hierzu an, Tabellenkalkulationen h¨ atten nicht wirklich einen Dom¨ anenbezug und ordnet sie daher als Allzwecksprachen ein. Ich sehe hier allerdings einen Fokus auf der Verarbeitung numerisch-tabellarischer Daten, was durchaus als Dom¨ ane begriffen werden kann.

18

4.7. Interne Dom¨ anenspezifische Sprachen Interne DSLs stellen lediglich eine bestimmte Art dar, eine Allzweckprogrammiersprache zu nutzen. Sie sind somit formal nur eine Teilmenge der Sprache, in der sie genutzt werden. Sie unterscheiden sich von anderen in dieser Allzweckprogrammiersprache geschriebenen APIs lediglich in zwei Aspekten. Zum einen in der Beschr¨ankung auf eine bestimmte Dom¨ane, zum anderen durch den Sprachfluss, der bei ihrer Benutzung entsteht. Sie vermitteln so den Eindruck einer Sprache in der Sprache“. ” Als Beispiel einer internen DSL kann die Java-Bibliothek Mockito3 angef¨ uhrt werden, welche zum Erstellen von Mock- und Stub-Objekten4 in Unit-Tests dient:





Stack s t a c k = mock ( Stack . c l a s s ) ; doReturn ( true ) . when ( s t a c k ) . isEmpty ( ) ; a s s e r t T r u e ( s t a c k . isEmpty ( ) ) ;





Listing 4.1: Mockito als Beispiel einer internen dom¨anenspezifischen Sprache Auch ohne die genaue Funktionsweise des Java-Codes zu kennen, ergibt sich aus den ersten beiden Zeilen intuitiv, dass hier ein Objekt erstellt wird, welches das Interface von Stack implementiert und true zur¨ uckgibt, wenn stack.isEmpty() aufgerufen wird. Insbesondere Zeile 2 ist ein nahezu korrekter englischer Satz und zeigt deutlich den oben beschriebenen Sprachfluss. Verst¨arkt wird diese Unterscheidung zwischen Java als umgebender und der von Mockito definierten internen Sprache dadurch, dass es f¨ ur den Nutzer eigentlich irrelevant ist, welchen R¨ uckgabewert doReturn(boolean b) und when(Object o) tats¨ achlich haben. Die Nutzungsm¨oglichkeiten des Frameworks ergeben sich hier weitgehend schon aus der Sprachsyntax, da nur bestimmte Termfolgen (in der englischen Sprache) sinnvoll erscheinen. Laut Fowler und Parsons [2011] liegt hierin auch eines der Hauptunterscheidungskriterien zwischen klassischen Command-Query-APIs und DSLs: Ergeben sich die M¨oglichkeiten ersterer aus der isolierten Betrachtung ihrer einzelnen Methoden, ergeben diese sich bei letzterer erst aus der Verkettung mehrerer Funktionen, welche als Terme einer Sprache fungieren und erst im Zusammenspiel, quasi als Satz, ihre Funktion erf¨ ullen. Als großer Vorteil solcher interner DSLs kann die Lesbarkeit des Codes gesehen werden. Der Code kommuniziert deutlich klarer die Intention, mit der er geschrieben wurde. Dies kann die Suche von Fehlern vereinfachen und erspart Dokumentationsaufwand. DSLs lenken den Fokus des Lesers auf die Frage, was der Code bewirkt und abstrahieren von dem genauen Wie?“, was bisweilen als deklarative Programmierung bezeichnet wird. ” 3 4

Mockito ist zu finden unter http://www.mockito.org/. Stub-Objekte sind Objekte, welche nach außen hin die Schnittstelle eines anderen Objektes imitieren, deren Implementierung aber deutlich einfacher ist. Mock-Objekte imitieren ebenfalls die Schnittstelle eines anderen Objektes, dienen dabei aber der Verifikation bestimmter Interaktionsmuster. (vgl. Fowler [2007])

19

Abschließend erleichtern DSLs die Kommunikation zwischen Softwareentwicklern und Dom¨anenspezialisten: Da DSLs auf die Terminologie und die Konzepte der zugrundeliegenden Dom¨ ane zugeschnitten sind, sind sie im Optimalfall f¨ ur Dom¨anenspezialisten lesund bez¨ uglich ihrer Korrektheit bewertbar. (nach Fowler und Parsons [2011, 2.2]) Der Vorteil der Abstraktion kann aber auch zum Nachteil werden: Die zus¨atzliche Abstraktionsebene einer internen DSL bringt auch eine zus¨atzliche Indirektion in die entwickelte Software. In F¨ allen, in denen es n¨otig ist, den Blick auf das Wie?“ der ” Ausf¨ uhrung zu lenken, verschleiert eine DSL den bei klassischen Command-Query-APIs sehr klaren Programmfluss und kann die Fehlersuche so erheblich erschweren. Das Erlernen einer neuen DSL stellt eine Einstiegsh¨ urde f¨ ur Entwickler dar, welche eventuell h¨oher ist als bei der Nutzung einer gut dokumentierten Command-Query-API – auch wenn dieser Lernaufwand durch die starke Beschr¨ankung im Funktionsumfang einer DSL gering sein sollte. Bei der kontinuierlichen Erweiterung von DSLs besteht dar¨ uber hinaus die Gefahr, dass versucht wird, alle Erweiterungen in das Konzept der bestehenden DSL zu zw¨angen, selbst wenn dies nicht zweckm¨ aßig ist. (nach Fowler und Parsons [2011, 2.3])

20

5. Anforderungen und Konzeption ¨ Dieses Kapitel soll einen Uberblick u ¨ber die drei entwickelten Systeme und deren Zusammenspiel geben. Kernziel dieser Arbeit ist die Entwicklung einer Java API zur Abfrage von Teilgraphen aus einer bereits vorliegenden Protein-Protein-Interaktionsdatenbank. Als Grundlage f¨ ur diese API soll eine eingebettete Datenbank dienen, aus welcher die Daten abgefragt werden. Ein Konsument der Java API ist ein Plugin f¨ ur Cytoscape.

5.1. Anfragem¨ oglichkeiten der API Die Java API soll es einer aufrufenden Software erm¨oglichen, Zugriff auf die vorliegenden PPI-Daten zu erhalten. Hierf¨ ur sind verschiedene Anfrageszenarien denkbar, welche durch die API unterst¨ utzt werden sollen. Besonders f¨ ur die algorithmische Verarbeitung erscheint es n¨ utzlich, den kompletten PPI-Graphen, also alle vorhandenen Daten, mittels einer Anfrage zu erhalten. Dies erm¨oglicht Nutzern der API beispielsweise, eigene Zentralit¨atsmaße auf Grundlage der Daten zu berechnen oder selbst bestimmte Teilgraphen mittels eigener Algorithmen zu selektieren. M¨ochte ein Nutzer der API nur bestimmte Teilgraphen betrachten, so sind mehrere M¨oglichkeiten der Teilgraphenselektion denkbar, wovon zwei umgesetzt wurden: Zum einen soll die Betrachtung der Interaktionen m¨oglich sein, an denen bestimmte Proteine beteiligt sind. Hierf¨ ur wurde die M¨oglichkeit geschaffen, den Nachbarschaftsgraph bestimmter Proteine bei frei w¨ ahlbarer Tiefe zu selektieren. Zum anderen soll die Betrachtung der Interaktionen zwischen einer gegebenen Menge von Proteinen m¨oglich sein. Diese M¨oglichkeit wurde durch die Selektierbarkeit des Kleine-Welt-Graphen bestimmter Proteine bei frei w¨ ahlbarer Tiefe geschaffen. Die Ausgangsproteine sind anhand ihrer Annotationen selektierbar, momentan sind dies ihr kanonischer Name nach HUGO1 , ihre ID in Entrez Gene2 “, die ID des zugeordneten biologischen Taxons auf Grundlage der ”

1

The HUGO Gene Nomenclature Committee (HGNC) aims to assign a unique gene symbol and name ” to every human gene“ [Seal et al., 2011]. HUGO ist zu finden unter http://www.genenames.org/. 2 Entrez Gene (http://www.ncbi.nlm.nih.gov/gene) is National Center for Biotechnology Information ” (NCBI)’s database for gene-specific information.“ [Maglott et al., 2011]

21

NCBI Taxonomy3 sowie die Namen, unter denen sie in der Literatur gefunden wurden4 . Sowohl die konjunktive und disjunktive Verkn¨ upfung mehrerer solcher Selektionen als auch die Angabe beliebig verschachtelter Ausdr¨ ucke ist m¨oglich. Die Datenbasis umfasst nicht nur tats¨achliche Interaktionen, sondern alle Kolokationen zweier Proteinnamen in einem Satz. Diese Fundstellen sind annotiert mit jeweils einem Konfidenzwert, welcher angibt, ob das Extraktionstool diese tats¨achlich als Interaktion bewertet, und wie sicher diese Einsch¨atzung ist. Es scheint daher sinnvoll, auch die Menge der zur¨ uckgegebenen Interaktionen nochmals filtern zu k¨onnen. Filterbar sind Interaktionen nach dem Konfidenzwert der Interaktionsfundstellen, der Anzahl der Fundstellen einer Interaktion sowie nach dem Corpus und der Dokumenten-ID (PubMed-ID) der Interaktionsfundstelle. Auch hier sind die Filterpr¨adikate konjunktiv und disjunktiv verkn¨ upfbar und eine beliebige Verschachtelung m¨oglich. Es ist ebenfalls m¨ oglich induzierter Teilgraphen zu berechnen. Die zugrundeliegende Knotenmenge kann durch einen der beiden beschriebenen Teilgraphselektionsmechanismen gewonnen werden. Auch hier greifen die oben beschriebenen Interaktionsfilter. Es kann also beispielsweise zuerst ein Nachbarschaftsgraph der Tiefe 2 um das Protein BRCA1 gesucht, um dann f¨ ur die in diesem Graph enthaltenen Proteine den induzierten Teilgraph zu berechnen. Bez¨ uglich der Anfragem¨ oglichkeiten wurde Wert gelegt auf eine einfache Erweiterbarkeit, um insbesondere neue Annotationen wie beispielsweise Ver¨offentlichungsdatum, assoziierte Krankheiten und ¨ ahnliche Attribute zu einem sp¨ateren Zeitpunkt erg¨anzen zu k¨onnen. Aber auch die Erweiterung um weitere Subgraphdefinitionen und damit weitere Anfragesemantiken sollte einfach m¨oglich sein. Ein zweiter Aspekt der Arbeit lag darin, die M¨oglichkeit zur Anbindung von Graphalgorithmen, beispielsweise Zentralit¨atsmaße, an die API zu schaffen. Hierf¨ ur wurde eine Schnittstelle sowie eine Beispielimplementierung, welche alle gefundenen Kanten in einem Graphen z¨ ahlt, umgesetzt.

5.2. Anforderungen an die Datenbank Da es m¨ oglich sein soll, die Interaktionsdaten u ¨ber die eine Webseite zum Download zur Verf¨ ugung zu stellen, muss es m¨ oglich sein, das System als einzelne Datei zu paketieren. Diese Datei muss unabh¨ angig von dem System, auf welchem sie erstellt wurde, les- und verarbeitbar sein. Um die Nutzung der Software m¨oglichst einfach zu gestalten, ist es sinnvoll, ein eingebettetes DBMS zu verwenden, so dass keine separate Installation und 3

The NCBI Taxonomy database (http://www.ncbi.nlm.nih.gov/taxonomy) is the standard nomen” clature and classification repository for the International Nucleotide Sequence Database Collaboration (INSDC)“ [Federhen, 2011] 4 In den Korpora wurde beispielsweise BRCA1“ auch unter den Namen Breast Cancer 1“ und BRCA-1“ ” ” ” gefunden.

22

Pflege eines DBMS durch den Nutzer notwendig ist. Auch die Anfrageperformance einer lokalen Datenbank d¨ urfte, insbesondere f¨ ur Nutzer außerhalb des Universit¨atsnetzes, deutlich besser sein als die eines zentralen, von der HU Berlin verwalteten, Servers. Razick et al. [2011] nennen als weitere Vorteile einer solchen L¨osung die Datenstabilit¨at und den Datenschutz. So lange ein Nutzer nicht explizit zu einer neueren Datenbankversion greift, kann er sich ob der Reproduzierbarkeit seiner Anfrageergebnisse sicher sein. Und: Niemand außer ihm selbst weiß, welche Anfragen er abgesetzt hat. Hinzu kommen Anforderungen hinsichtlich der Abfragem¨oglichkeiten und der Abfragegeschwindigkeit. Proteine, ihre Interaktionen sowie die Annotationen bez¨ uglich beider bilden gemeinsam einen Property-Graphen, wobei Proteine als Knoten, ihre Interaktionen als Kanten und die Annotationen als Attribute der Knoten und Kanten aufgefasst werden k¨onnen. Die im Abschnitt 5.1 beschriebenen zu implementierenden Anfragem¨oglichkeiten erfordern hierbei auch das Selektieren von Teilgraphen aus den gespeicherten Daten, unter anderem unter Beachtung verschiedener Selektionskriterien. Hierf¨ ur sollte das Datenbanksystem einfache Abfragem¨oglichkeiten mit hinreichend kurzen Antwortzeiten zur Verf¨ ugung stellen. Da das Datenbankmanagementsystem als Teil der im Rahmen dieser Arbeit erstellten Software verbreitet werden soll, muss dies aus urheberrechtlicher Perspektive auch erlaubt sein. Es muss also seitens des Urhebers des Datenbankmanagementsystems allen Empf¨angern der Software das Recht einger¨aumt worden sein, das Datenbankmanagementsystem unentgeltlich zu nutzen und zu vervielf¨altigen. Außerdem muss den Erstellern von Software das Recht einger¨ aumt worden sein, das Datenbankmanagementsystem zusammen mit der hier entwickelten API in die eigene Software einzubetten und zu verbreiten. Gespeichert werden sollen Proteine, deren Interaktionen und die Literaturreferenzen zu den einzelnen Interaktionen. Zu den Proteinen geh¨oren ihr kanonischer Name, ihre Entrez-ID und die Taxon-ID. Interaktionen verkn¨ upfen Proteine, Interaktionsfundstellen haben Quellenangaben wie Korpus, Dokumenten-ID und Satznummer sowie einen Konfidenzwert. Da im Rahmen dieser Arbeit eine Java-Anwendung entstehen soll, ist eine Nutzbarkeit aus Java heraus Voraussetzung f¨ ur die Eignung.

5.3. Das Cytoscape Plugin Das Cytoscape Plugin soll es Anwendern erm¨oglichen, Teilgraphen anhand der in Abschnitt 5.1 genannten Kriterien zu selektieren und anzuzeigen. Hierbei wird den Anwendern nicht nur der Graph selbst pr¨asentiert, sondern auch die annotierten Attribute. Das Cytoscape Plugin bildet alle Anfragem¨oglichkeiten der API ab, es lassen sich also beide Anfragemechanismen – Nachbarschaftsgraphen und Kleine-Welt-Graphen – nutzen sowie induzierte Teilgraphen selektieren. Auch die Kombination von Selektions- bzw.

23

Filterkriterien mittels UND“- sowie ODER“-Verkn¨ upfungen und das Erzeugen beliebig ” ” komplexer zusammengesetzter Ausdr¨ ucke wird vom Plugin unterst¨ utzt. F¨ ur Cytoscape stehen bereits diverse Plugins zur Verf¨ ugung, um Graph-Algorithmen auf die angezeigten Netze anzuwenden. So lassen sich beispielsweise mit dem ShortestPath ” Plugin“ von Marcio Rosa da Silva5 k¨ urzeste Pfade im Graphen sowie mit dem Network” Analyzer“ [Assenova et al., 2008] verschiedenste Kennzahlen wie der Netzdurchmesser, die durchschnittliche Anzahl an Nachbarn der enthaltenen Knoten und vieles mehr ¨ berechnen. Eine Ubersicht der vielen verschiedenen Graphanalyse-Plugins findet sich auf den Webseiten von Cytoscape6 . Vor diesem Hintergund erschien es wenig sinnvoll, eine Anbindung f¨ ur die Graphalgorithmenschnittstelle der API an Cytoscape zu entwickeln, insbesondere, da die API derzeit nur eine Beispielimplementierung zur Verf¨ ugung stellt.

5

Zu finden unter http://chianti.ucsd.edu/cyto_web/plugins/displayplugininfo.php?name= ShortestPath%20Plugin 6 ¨ Die Liste ist zu finden unter der Uberschrift Analysis“ auf http://chianti.ucsd.edu/cyto_web/ ” plugins/

24

6. Auswahl eines geeigneten Datenbankmanagementsystems Im ersten Schritt werden verschiedene Datenbankmanagementsysteme evaluiert und daraus ein geeignetes ausgew¨ ahlt. Um trotz der sehr großen Anzahl am Markt befindlicher Datenbankmanagementsysteme die Evaluation in einer angemessenen Gr¨oßenordnung zu haltenbeschr¨ ankt sich diese auf die beiden Klassen der relationalen und der graphbasierten Datenbankmanagementsysteme, welche f¨ ur diesen Anwendungsfall am vielversprechendsten erschienen.

6.1. Relationale Datenbankmanagementsysteme Es gibt derzeit einige relationale Datenbankmanagementsysteme, welche Einbettbarkeit und die erw¨ ahnten urheberrechtlichen Freiheiten kombinieren. Im Rahmen dieser Evaluation ber¨ ucksichtigt wurden MySQL Community Server, SQLite, Apache Derby und H2 Database Engine.

6.1.1. MySQL Community Server MySQL Community Server ist ein klassisches Client-Server-System, welches normalerweise als eigenst¨ andige Software l¨ auft und Clients Zugriff auf die verwalteten Datenbanken unter anderem u ¨ber ein Netzwerk erlaubt. Dieses System hat nachtr¨aglich die M¨oglichkeit erhalten, zus¨ atzlich auch in einem eingebetteten Modus gestartet und genutzt zu werden. MySQL Server bietet hier mit MySQL Connector/MXJ eine L¨osung, welche ausf¨ uhrbare Bin¨ardateien des MySQL Servers f¨ ur jede unterst¨ utzte Plattform zusammen mit einer Java-Komponente paketiert. Die Java-Komponente startet abh¨angig von der ausf¨ uhrenden Plattform die passende Bin¨ ardatei [Oracle, 2009]. Dies f¨ uhrt zu einer Gesamtgr¨oße von 406 MB1 alleine f¨ ur das Datenbankmanagementsystem. Die aktuellste Version von MySQL Connector/MXJ basiert auf MySQL Community Server 5.1, welcher vom Hersteller Oracle f¨ ur eine sehr große Anzahl an Betriebsystemen auf den x86, x86 64, IA64 und SPARCArchitekturen unterst¨ utzt wird, unter anderem f¨ ur Windows, Linux und verschiedene UNIX-Varianten [Oracle, 2011].

1

MySQL Connector/MXJ 5.0.11, entpacktes ZIP-Archiv, Stand 08. M¨ arz 2011

25

6.1.2. SQLite SQLite ist ein gr¨ oßtenteils aus C/C++-Projekten heraus genutztes relationales Datenbankmanagementsystem. SQLite ist ausschließlich als eingebettetes Datenbankmanagementsystem nutzbar und wird von seinen Entwicklern als die meistgenutzte SQL-Datenbank bezeichnet. Es ist unter anderem Teil von Mozilla Firefox und der Peer-to-Peer-MessagingSoftware Skype [Hipp, Wyrick & Company, Inc, 2011]. SQLite ist in C geschrieben und wird in Form einer Shared Library genutzt, muss also in der Maschinensprache des jeweiligen Zielsystems vorliegen. F¨ ur die Benutzung in Java existiert ein Wrapper namens SQLiteJDBC eines Drittanbieters, welcher ¨ahnlich wie MySQL Connector/MXJ Bin¨ardateien f¨ ur alle unterst¨ utzten Systeme mitliefert. Dies sind momentan Windows, ” Mac OS X, und Linux x86“ [Crawshaw, 2009]. SQLiteJDBC ist als 2,6 MB2 großes JAR-Archiv paketiert.

6.1.3. Apache Derby und H2 Database Engine Sowohl Apache Derby [Apache Software Foundation, 2010] als auch die H2 Database Engine [H2 Group, 2011a] sind ausschließlich als eingebettetes Datenbankmanagementsystem nutzbar. Sie sind vollst¨ andig in Java geschrieben und funktionieren auf allen Betriebssystemen und Plattformen, f¨ ur welche eine Java Virtual Maschine existiert. Sie sind als JAR-Archiv packetiert, wobei das der H2 Database Engine eine Gr¨oße von 1,2 MB3 , das von Apache Derby eine Gr¨ oße von 2,3 MB4 hat. Apache Derby ist ab Java 6 unter dem Namen Java DB Bestandteil des JDKs. Beide sind per JDBC nutzbar. Die H2 Database Engine bietet – als einziges der evaluierten Systeme – auch eine teilweise, experimentelle Unterst¨ utzung des optionalen SQL [1999]-Features T131 (Rekursive SQL-Abfragen), was insbesondere f¨ ur das Selektieren von Teilgraphen von großem Nutzen sein k¨onnte [H2 Group, 2011a, Recursive Querys].

6.2. Graphbasierte Datenbankmanagementsysteme Auch unter den Graphdatenbankmanagementsystemen gibt es einige Systeme, welche die zuvor definierten Anforderungen an die Einbettbarkeit und die urheberrechtlichen Bedingungen erf¨ ullen. Im Rahmen dieser Evaluation wurden Neo4j, HyperGraphDB und InfoGrid untersucht. Es zeigt sich, dass sich die in 4.2 beschriebenen drei Anfragemuster in den im Folgenden evaluierten Graphdatenbankmanagementsystemen wiederfinden.

2

SQLiteJDBC v056, gepacktes JAR-Archiv, Stand 08. M¨ arz 2011 H2 Database Engine 1.3.152, JAR-Archiv, Stand 13. M¨ arz 2011 4 Apache Derby 10.7.1.1, JAR-Archiv, Stand 13. M¨ arz 2011 3

26

6.2.1. Neo4j Neo4j5 ist in Java geschrieben und umfasst in Form mehrerer JAR-Archive etwa 3,7 MB6 . Neo4j ist sowohl als eingebettete Datenbank als auch als selbstst¨andiger Server-Prozess mit HTTP- / REST-Schnittstelle nutzbar und l¨auft auf allen Plattformen, f¨ ur die eine Java Virtual Machine existiert. Es basiert auf dem Modell eines gerichteten PropertyGraphen mit f¨ arbbaren Kanten. Diese k¨onnen dann mittels der mitgelieferten und in die Neo4j API eingebundenen Lucene-Indexbibliothek indiziert und als Suchkriterium zum Auffinden von Knoten und Kanten genutzt werden k¨onnen. Die Index-Schnittstelle von Neo4j bietet Nutzern dar¨ uber hinaus die M¨oglichkeit, eigene Indexstrukturen einzubinden und zu nutzen. Anfragen sind mittels verschiedener, graphbasierter Anfragesprachen m¨oglich. Gremlin [Rodriguez, 2011a] ist eine interne, urspr¨ unglich in Groovy geschriebene DSL zum Traversieren von Property-Graphen. Gremlin hat inzwischen auch eine native JavaImplementierung. Gremlin erinnert in ihrer Handhabung und Konzeption an XPath und jQuery, welche ebenfalls der Anfragebearbeitung in (baumf¨ormigen) Graphen dienen. Cypher [Neo Technology, 2011, Kapitel 16] ist eine syntaktisch eher an SQL und die aus dem RDF/Semantic Web-Umfeld bekannte Anfragesprache SPARQL [W3C, 2008] angelehnte Anfragesprache. Im Gegensatz zu Letzterem unterst¨ utzen Cypher und Gremlin auch Pfade variabler L¨ ange, also nicht nur zwischen A und B muss eine freundVon‘-Kante ” ’ liegen“, sondern auch B muss von A aus transitiv u ¨ber maximal 4 freundVon‘-Kanten ” ’ erreichbar sein“. Auch SPARQL selbst l¨asst sich – mittels Zusatzkomponenten – nutzen. Abseits der Anfragesprachen existiert eine Java-Schnittstelle zum Traversieren von Graphen. Diese erm¨ oglicht es, von einem Knoten ausgehend u ¨ber den Graphen zu iterieren. Hierbei k¨ onnen spezifiziert werden: Abbruchbedingungen, die Reihenfolge (Breiten- oder Tiefensuche), Typen und Richtungen7 der zu verfolgenden Kanten, Anforderungen an die Duplikatsbehandlung sowie ein Selektionskriterium f¨ ur die auszugebenden Knoten/Kanten. Dies scheint eine sehr m¨ achtige Anfragem¨oglichkeit zu sein, so hat zum Beispiel Larsson [2008] auf Basis der Schnittstelle effiziente Implementierungen einer Vielzahl von Graphalgorithmen entwickelt. Solche Graphalgorithmen, beispielsweise Zentralit¨atsmaße, sind - wie eingangs erl¨ autert - auch f¨ ur Proteininteraktionsnetze interessant.

6.2.2. HyperGraphDB HyperGraphDB [Iordanov, 2010] ist ebenfalls in Java geschrieben, nutzt aber als zugrunde liegenden Datenspeicher Oracles BerkeleyDB via JNI. Daher sind bei der Paketierung der Datenbank zusammen mit der nutzenden Software neben den JAR-Archiven des

5

Neo4j ist zu finden unter http://www.neo4j.org. Neo4j 1.3 Milestone 4, lib-Folder des ZIP-Archivs, Stand 17. M¨ arz 2011 7 Richtung meint hier, ob mit den Kantenrichtungen, den Kantenrichtungen entgegen oder unbeachtet der Kantenrichtungen traversiert wird. 6

27

Datenbankmanagementsystems auch die nativen BerkeleyDB-Bibliotheken f¨ ur alle unterst¨ utzten Zielsysteme einzuschließen – f¨ ur Windows, Linux und Mac OS umfassen diese zusammen circa 15,2 MB8 . Auch HyperGraphDB l¨auft eingebettet innerhalb der selben JVM wie das zugreifende Programm und ist prinzipiell auf allen Plattformen lauff¨ahig, auf denen auch Oracles BerkeleyDB sowie eine JVM verf¨ ugbar sind. Dies sind insbesondere Windows, Linux, MacOS und viele Unix-Systeme. HypergraphDB liegt das Datenmodell eines gerichteten Hypergraphen mit zwei Besonderheiten zugrunde: Hyperkanten und Knoten werden unter dem Begriff Atome zusammengefasst. Hyperkanten k¨ onnen nicht nur auf Knoten, sondern auch auf Atome verweisen. Des Weiteren kann jedem Atom ein Wert und ein f¨ ur den Wert zu erzwingender Datentyp zugewiesen werden. Das Typenmodell ist erweiterbar und bildet mittels Subsumptions- und Kompositionsbeziehungen wieder einen Hypergraphen. Es unterst¨ utzt somit, im Gegensatz zum Typenmodell von beispielsweise Neo4j, nicht nur primitive Java-Datentypen. HyperGraphDB hat einen mit Neo4j vergleichbaren Traversierungsmechanismus. Er unterst¨ utzt ebenfalls Breiten- und Tiefensuchen, allerdings wird hier auf einen vom Nutzer geschriebenen Adjazenzlistengenerator zur¨ uckgegriffen. Dieser generiert f¨ ur ein gegebenes Atom eine Liste weiterer Atome, die traversiert werden sollen. Nicht unterst¨ utzt wird eine Selektion der zur¨ uckzugebenden Atome. Als Anfragesprache steht hier ein propriet¨arer Ansatz zur Verf¨ ugung.

6.2.3. InfoGrid InfoGrid [Ernst, 2010] ist ein in Java geschriebenes Datenbankmanagementsystem, welches aber zur Speicherung der Daten auf andere Datenbankmanagementsysteme (sogenannte Stores) zur¨ uckgreift. Dies k¨ onnen beispielsweise PostgreSQL oder MySQL sein, aber auch das Hadoop-Dateisystem oder das Dateisystem des Betriebsystems. In Form von JAR-Archiven packetiert umfasst InfoGrid circa 1,5 MB9 . Auch InfoGrid l¨auft, sofern f¨ ur den Store kein seperater Prozess ben¨otigt wird (wie beispielsweise im Falle einer MySQL-Datenbank), eingebettet in die aufrufende JVM und ist auf allen Plattformen lauff¨ahig, f¨ ur die eine solche zur Verf¨ ugung steht. Das zugrunde liegende Datenmodell ist ein gerichteter Graph. Knoten und Kanten k¨onnen eine beliebige Anzahl von Typen haben. Einem Knoten kann dar¨ uber hinaus eine Attributmenge zugeordnet werden. Die Anzahl der erlaubten Attribute, deren Schl¨ ussel und deren jeweiliger Wertetyp wird durch die Typen eines Knotens bestimmt. Das Schema, welches die Menge der m¨ oglichen Typen spezifiziert, wird in Form einer XML-Datei abgelegt. Aus dieser werden dann mittels eines Code-Generators Java-Klassen generiert. 8

Rechnerischer Wert, ermittelt f¨ ur HyperGraphDB 1.1 durch Addition der Gr¨ oßen aller JAR-Archive der Windows-Distribution und der Gr¨ oßen der native“-Verzeichnisse aller Betriebssystemspezifischen ” Distributionen. Stand 17. M¨ arz 2011 9 InfoGrid 2.9.4; Gr¨ oße der JAR-Archive ig-graphdb, ig-stores, ig-utils, ig-vendors; Stand 20. M¨ arz 2011

28

Es muss somit bereits dem Compiler zur Verf¨ ugung stehen. Als Anfragem¨oglichkeit steht lediglich das Traversieren des Graphen zur Verf¨ ugung, wobei hier ein ¨ahnlicher adjazenzlistenbasierter Ansatz wie bei HyperGraphDB genutzt wird.

6.3. Vergleich der Datenbankmanagementsysteme Die in Abschnitt 5.2 definierten Anforderungen werden im Wesentlichen von allen evaluierten Datenbankmanagementsystemen erf¨ ullt, allerdings in unterschiedlichem Umfang. Unter den relationalen Datenbankmanagementsystemen scheint MySQL Community Server aufgrund seiner deutlich u ¨ berdurchschnittlichen Gr¨oße eher ungeeignet. Auch l¨asst die Tatsache, dass f¨ ur alle unterst¨ utzten Systeme Bin¨ardateien mitgeliefert werden m¨ ussen, bef¨ urchten, dass hier Inkompatibilit¨aten durch sehr heterogene Zielsysteme, beispielsweise bez¨ uglich Systembibliotheken und anderen installierte Anwendungen, auftreten k¨onnen. Auch rekursive Anfragen, wie sie beispielsweise f¨ ur eine Breitensuche im Graphen vorteilhaft sind, unterst¨ utzt MySQL Community Server nicht. Viel kleiner ist SQLite, allerdings bleiben auch hier die Risiken bez¨ uglich inkompatibler Zielsysteme und die fehlende Unterst¨ utzung rekursiver Anfragen. Das letzte Release des Java-Wrappers SQLiteJDBC ist nunmehr fast zwei Jahre alt und auch auf der zugeh¨origen Mailingliste10 ist keine nennenswerte Aktivit¨at zu verzeichnen. Dies l¨asst an der Zukunft dieser Java-Anbindung zweifeln. Die beiden verbleibenden relationalen Datenbankmanagementsysteme, H2 Database System und Apache Derby, bieten hingegen eine hervorragende Einbindung in die JavaUmgebung und damit weitreichende Portabilit¨at. Beide haben eine sehr kleine Dateigr¨oße und stehen unter sehr freien Lizenzen, namentlich der Apache License 2.0 [Apache Software Foundation, 2004] bei Apache Derby und der Eclipse Public License [Eclipse Foundation, 2004] sowie einer modifizierten Mozilla Public License [H2 Group, 2011b] beim H2 Database System. Alle drei erlauben es auch, Software, welche die Datenbankmanagementsysteme lediglich als Bibliothek nutzt, sie aber nicht ver¨andert, unter einer anderen, auch unfreien Lizenz zu ver¨offentlichen. Aufgrund seiner wenn auch nur experimentellen Unterst¨ utzung rekursiver SQL-Abfragen schien das H2 Database System unter diesen beiden relationalen Datenbankmanagementsystemen die bevorzugte Wahl zu sein. Betrachtet man die untersuchten Graphdatenbankmanagementsysteme, so f¨allt die durchgehend gute Integration in die Java-Umgebung auf. Lediglich HyperGraphDB l¨asst hier durch den R¨ uckgriff auf BerkeleyDB ¨ahnliche Bef¨ urchtungen bez¨ uglich der Kompatibilit¨at aufkommen wie zuvor der MySQL Community Server und SQLite. Bez¨ uglich des Graphenmodells bieten alle drei untersuchten Systeme unterschiedliche Vorteile. HyperGraphDB hat das im Vergleich zu den anderen beiden Systemen ausdrucksst¨arkste Datenmodell, da Kanten sowohl auf mehrere Knoten als auch auf andere Kanten f¨ uhren k¨onnen. Dies 10

Zu finden unter https://lists.hcoop.net/pipermail/sqlitejdbc/, abgerufen am 21. M¨ arz 2011.

29

ist aber auch komplexer, was die Bef¨ urchtung entstehen l¨asst, dass die Daten schwieriger zu verstehen, auszuwerten und zu bearbeiten sind. InfoGrid bietet dagegen ein deutlich einfacheres Modell kombiniert mit statischer Typisierung, welche Softwarefehler fr¨ uhzeitig sichtbar macht, aber mit der Notwendigkeit einer Code-Generierung zur Compile-Zeit einhergeht. Neo4j verzichtet vollst¨ andig auf Hyperkanten und Typisierung und erscheint dadurch deutlich weniger komplex. Eine Gruppe der Universitat Polit`ecnica de Catalunya, an der auch das Graphdatenbankmanagementsystem DEX 11 entwickelt wurde, hat in [Dominguez-Sal et al., 2010] einen Geschwindigkeitsvergleich mehrerer Graphdatenbanken dokumentiert. Neben ihrem eigenen Datenbankmanagementsystem waren auch HyperGraphDB und Neo4j einbezogen. Hierbei bildeten DEX und Neo4j die Spitzengruppe. HyperGraphDB war als einziges Datenbankmanagementsystem nicht in der Lage, 1 Million Knoten innerhalb von 24 Stunden in die Datenbank zu schreiben und wurde daher im weiteren Benchmark nicht mehr ber¨ ucksichtigt. Aber auch bei kleineren Datenmengen von 1.000 Knoten war HyperGraphDB beim Traversieren des kompletten Graphen um etwa den Faktor 2, 4, bei allen anderen Benchmarks noch um ein vielfaches dessen langsamer als Neo4j. Dies scheint angesichts der großen Menge an Originaldaten (vgl. Abschnitt 1) nicht akzeptabel. Aufgrund der Einfachheit des Graphenmodells und der Tatsache, das bei Neo4j im Gegensatz zu InfoGrid keine Schemagenerierung notwendig ist, f¨allt meine Wahl unter den Graphdatenbankmanagementsystemen auf Neo4j. Vergleicht man Neo4j mit dem H2 Database System, so erscheint die Speicherung eines Proteininteraktionsgraphen in einer Graphdatenbank intuitiver. Auch sind die f¨ ur Graphanfragen sinnvollen rekursiven Abfragen im H2 Database System noch im experimentellen Stadium. Neo4j hingegen bietet vielf¨altige Graphabfragem¨oglichkeiten, welche, wie von Larsson [2008] gezeigt, praxistauglich zu sein scheinen. Auch die Geschwindigkeit von Neo4J scheint, wie von Dominguez-Sal et al. [2010] beschrieben, selbst f¨ ur die hier vorliegenden Datenmengen akzeptabel zu sein, w¨ahrend ich f¨ ur die rekursiven Anfragen des H2 Database Systems kein belastbares Zahlenmaterial finden konnte. Die Tatsache, dass Graphdatenbanken insbesondere auf das voraussichtlich intensiv genutzte Traversieren von Kanten optimiert sind, l¨asst vermuten, dass Neo4j hier eine bessere Geschwindigkeit bieten k¨ onnte. Vor diesem Hintergrund scheint Neo4j f¨ ur das beschriebene Anwendungsgebiet geeigneter zu sein.

6.4. Abschließende Auswahl eines DBMS Um diese These zu pr¨ ufen, wurden sowohl eine H2-Datenbank als auch eine Neo4jDatenbank mit dem kompletten Datensatz bef¨ ullt und je eine Beispielanfrage gegen beide Datenbanken ausgef¨ uhrt. Das f¨ ur die Bef¨ ullung verwendete Verfahren war ¨ahnlich dem 11

DEX [Mart´ınez-Bazan et al., 2007] wurde im Rahmen dieser Evaluation nicht ber¨ ucksichtigt, da es die urheberrechtlichen Anforderungen nicht erf¨ ullte.

30

Abbildung 6.1.: Evaluation der H2 Database Engine: ER-Modell des Schemas

Abbildung 6.2.: Evaluation von Neo4j: Ausschnitt aus der Datenbank im nachfolgenden Kapitel 7.2 beschriebenen. Die Neo4j-Datenbank wurde mit Hilfe des Neo4j-BatchInserters bef¨ ullt, f¨ ur die H2 Database Engine existiert kein solcher, aber auf den dazugeh¨ origen Websiten finden sich Optimierungsschalter, die f¨ ur den Import großer Datenmengen empfohlen sind und hier genutzt wurden. Die Datenbankschemata nutzten Proteine und Interaktionsfundstellen als prim¨are Entit¨aten, wobei Proteine durch ihren Namen, wie er im Text gefunden wurde, identifiziert wurden. Das Schema f¨ ur die H2-Datenbank habe ist als ER-Diagramm in Abbildung 6.1, das verwendete Schema12 der Neo4j-Datenbank als Ausschnitt aus der Datenbank in Abbildung 6.2 dargestellt. Die Beispielanfrage zielte darauf ab, ausgehend von 10 Proteinen einen Nachbarschaftsgraphen beliebiger Tiefe zu selektieren. Dabei sollten nur menschliche Proteine sowie Interaktionen, welche mit einem Konfidenzwert u ¨ber 2, 0 in einem Dokument aus PubMed mit einer ID unter 1.000.00013 gefunden wurden, traversiert werden. 12

Wenn im Folgenden von Graphschemata die Rede ist, so meint dies kein striktes, vom DBMS erzwungenes Schema, wie dies bei relationalen Datenbanken der Fall ist. Es handelt sich viel mehr um eine bei der Bef¨ ullung der Datenbank entstehendes Grundstruktur des Graphen. Es existitieren eine Menge von Knoten- und Kantentypen, wobei Knoten bestimmter Typen u ¨blicherweise mit anderen Knoten u upft sind. Zu einem Typ geh¨ ort eine Menge von Attributen, ¨ ber Kanten bestimmter Typen verkn¨ welche bei diesem Typ u ¨blicherweise gesetzt sind. 13 Die Tatsache, dass ein Abstract relativ alt ist, wurde der Einfachheit halber mit einer relativ niedrigen ID modelliert.

31

Die Anfrage wurde f¨ ur Neo4j unter Nutzung der Traversal API umgesetzt. Hierbei wurde eine Breitensuche durchgef¨ uhrt, welche allen FIRST IN INTERACTION- und SECOND IN INTERACTION-Kanten folgt und die genannten Kriterien evaluiert. F¨ ur die H2 Datenbank wurde ein iterativer Algorithmus implementiert, da die rekursiven Anfragen bei H2 ihrem Status experimentell“ alle Ehre bereiteten: Sie funktionierten selten14 ” und eine zwischenzeitlich gefundene funktionierende Anfrage konnte ich nicht reproduzieren. Der Algorithmus basiert auf drei Mengen, namentlich einer initial leeren Menge von bereits verarbeiteten Proteinen, einer initial leeren Interaktionsergebnismenge und einer Menge der noch zu verarbeitenden Proteine, welche mit den 10 Ausgangsproteinen initialisiert ist. Daraufhin werden • alle Interaktionen, welche den zuvor definierten Kriterien entsprechen und an denen eines der zu verarbeitenden Proteine beteiligt ist, selektiert und zur Ergebnismenge hinzugef¨ ugt, • hieraus die Menge aller beteiligten Proteine extrahiert, • die soeben verarbeiteten Proteine zu einer Menge der bereits abgefragten Proteine hinzugef¨ ugt, • aus den extrahierten Proteinnamen die Elemente entfernt, die sich auch in der Menge der bereits abgefragten Proteine befinden und • die verbleibende Menge als neue Menge der zu verarbeitenden Proteine f¨ ur die n¨ achste Iteration gesetzt. F¨ ur das Bef¨ ullen der Datenbanken brauchte die H2 Datenbank bis zu 5 mal so lange wie Neo4j, jedoch stets unter 3 Stunden. Da man diesen Schritt nur h¨ochst selten ausf¨ uhren muss, ist dies ein akzeptabler Rahmen. F¨ ur die Beispielanfrage ergab sich kein klarer Geschwindigkeitsvorsprung f¨ ur eines der beiden Datenbankmanagementsysteme. In einigen Messungen lag Neo4j vor, in anderen hinter der H2 Datenbank. Die Anfragezeiten betrugen hierbei zwischen 7 und 10 Minuten. Die von Dominguez-Sal et al. [2010] beschriebene schlechte Einf¨ ugeperformance von Neo4j kann ich auf diesem Datenbestand nicht best¨ atigen. Deutlich u ¨berlegen zeigt sich Neo4j bei seiner Programmierschnittstelle: Bereits bei der hier umgesetzten Breitensuche im Graphen war die SQL-Schnittstelle kaum unterst¨ utzend, die Datenbank fungierte letztlich lediglich als Datenspeicher. Die eigentliche Anfragebearbeitung, also die Verkn¨ upfung der Daten und die Berechnung der Ergebnismenge, erfolgte weitestgehend im aufrufenden Java-Programm. Hinzu kommt, dass die hier vorliegende Anfrage mit fest vordefinierten Selektionskriterien geschrieben wurde. F¨ ur die Umsetzung der zu entwickelnden Java API m¨ usste also auch noch eine automatische Generierung von validem SQL-Code aus frei w¨ ahlbaren, vom Aufrufer gegebenen Selektionskriterien implementiert werden. Auch die anderen in Abschnitt 5.1 beschriebenen Anfragemodi m¨ ussten wohl in Java implementiert werden. 14

Die Anfragen endeten meist mit einer ArrayIndexOutOfBoundsException, wohl, weil H2 intern versuchte, auf den Index 0 einer leeren ArrayList zuzugreifen.

32

Die Neo4j-Datenbank hingegen bietet echte Graphanfrageverarbeitung: Es mussten lediglich ein Selektions- und ein Abbruchbedingung angegeben werden. Die vollst¨andige Berechnung des sich daraus ergebenden Teilgraphen lag daraufhin in der Verantwortung des Datenbankmanagementsystems. Auch das Problem der SQL-Code-Generierung entf¨allt, da es sich bei den Selektions- und Abbruchbedingungen um normale JavaFunktionen handelt. Der hier gegebene Use-Case schien sich daher mit Hilfe von Neo4j deutlich einfacher implementieren zu lassen, weshalb ich mich f¨ ur die Nutzung von Neo4j entschieden habe.

33

7. Implementierung Nachdem die grundlegenden Anforderungen an die drei Komponenten dargestellt sind, werden im Folgenden die Ergebnisse der Entwicklung sowie die grundlegenden Verfahren und Designentscheidungen dargestellt. Nach der Erstellung geeigneten Datenbankschemas wird der implementierte ETL-Prozess vorgestellt, der zur Bef¨ ullung und Packetierung der Embedded-Datenbank eingesetzt wird. Abschließend wird die Java API und das Cytoscape-Plugin vorgestellt.

7.1. Das Datenbankschema Betrachtet man die im Rahmen dieser Arbeit entwickelte PPI-Datenbank, so l¨asst diese sich nicht unmittelbar in eines der beiden in Abschnitt 4.4 beschriebenen Nutzungsmuster einordnen. So sind zwar auf der einen Seite viele Merkmale einer OLAP-Datenbank erf¨ ullt: Der Nutzungsschwerpunkt liegt auf nicht konkurrierenden Zugriffen, es sind mehrdimensionale Zugriffe geplant und Schreibzugriffe finden lediglich einmalig zum Bef¨ ullen statt. Andere Aspekte sind eher f¨ ur OLTP-Systeme typisch: So sollen die Daten in ihrem urspr¨ unglichen Detailgrad vorliegen, eine Pr¨aaggregation soll nicht stattfinden und auch f¨ ur die Abfragen sind keine – f¨ ur OLAP-Systeme eigentlich pr¨agende – Aggregationen vorgesehen. Ein Großteil der Daten ist nicht numerisch, weshalb typische Aggregationsfunktionen wie Summen- oder Mittelwertbildung kaum anwendbar sind. Die Daten haben außerdem eine nicht unerhebliche Fehlerquote, so dass sich die Fehler, je nach Aggregationsfunktion, bei der Aggregation summieren oder sogar potenzieren. Es scheint vor diesem Hintergrund angebracht, nicht blindlings ein existierendes Konzept f¨ ur die Struktur von Datenbankschemata f¨ ur einen der beiden Systemtypen anzuwenden.

7.1.1. Das Quellschema Ausgangspunkt meiner Arbeit sind die in einer MySQL-Datenbank vorliegenden PPIDaten. Sie stammen aus zwei Korpora, den Abstracts aus der PubMed-Datenbank und den Volltexten aus der Datenbank PubMed Central. Das Schema der Quelldatenbank ist in Abbildung 7.1 dargestellt. Kernelemente des Schemas sind die Tabellen entity“ und ” pair“. ”

34

Abbildung 7.1.: Das Quellschema der vorliegenden Daten Die Entit¨ atstabelle entity“ beinhaltet Proteinfundstellen, also Proteinnamen zusammen ” mit Informationen u ¨ber das Korpus, das Dokument, den Satz und den Zeichenindex innerhalb des Satzes, in dem ein Proteinname vorkam. Außerdem sind jeder Proteinfundstelle ein oder mehrere Paare von Protein-Ids aus EntrezGene und Taxon-Ids aus der NCBI Taxonomy Database zugeordnet. Insgesamt liegen hier 16,2 Millionen Proteinfundstellen in 6 Millionen S¨ atzen vor. Zu jeder Entrez-Id existiert dabei genau eine Taxon-Id. In den Quelldaten liegen die zum Protein geh¨origen Entrez-Ids und Taxon-Ids in einem nicht normalisierten Format vor: Sie sind als String gespeichert. Existiert nur eine Entrez-Id und eine Taxon-Id, so sind diese durch ein @“ getrennt. Sind mehrere Paare von Entrez” und Taxon-Id zugeordnet, so werden diese als |“-separierte Liste von @“-separierten ” ” Paaren gespeichert: 282691@9913|3146@9606|15289@10090“. ” Die Paartabelle verkn¨ upft je zwei solcher Fundstellen, speichert also zwei Referenzen auf Eintr¨age in der Entit¨ atstabelle. Insgesamt liegen 21,4 Millionen Fundstellenpaare vor. Erg¨anzend hierzu existieren vier weitere Tabellen. Die Tabelle predict“ ordnet jedem ” Paar Konfidenzwerte zu. Ein Eintrag umfasst eine Referenz auf das Paar, die Angabe, ob die Klassifikation des Paars positiv (die Fundstellen beschreiben eine Interaktion) oder negativ war, den Konfidenzwert selbst und die Bezeichnung der verwendeten Methode. Momentan existieren nur Eintr¨ age, die mit Hilfe des Tools jSRE – java Simple Relation ” Extraction1 “ [Giuliano et al., 2006] erstellt wurden, so dass zu jedem Eintrag der pair“” Tabelle maximal ein Eintrag in der predict“-Tabelle existiert. 3,3 Millionen Paare haben ” keinen Eintrag in der predict“-Tabelle. 13,4 Millionen Paare sind negativ klassifiziert ” worden, 4,7 Millionen Paare positiv. Die Tabelle sentence“ beschreibt die S¨atze, aus denen die Fundstellen stammen. Ein ” Eintrag besteht neben dem Volltext des Satzes aus einer Referenz auf das beinhaltende 1

jSRE ist zu finden unter http://hlt.fbk.eu/en/technology/jSRE.

35

Proteinfundstellen pro annotiertem Satz Interagierende Proteinfundst. pro ebensolche Annotierte S¨ atze pro Dokument Annotierte S¨ atze pro Dokument (PubMed) Annotierte S¨ atze pro Dokument (PMC)

Min 2 1 1 1 1

Max 576 566 2811 22 2811

AVG 2,7 2,1 4,2 2,6 27,0

Median 2 1 2 2 11

Tabelle 7.1.: Statistik bez¨ uglich der Quelltabellen Dokument und der Angabe, um den wievielten Satz innerhalb des Dokumentes es sich handelt. Insgesamt enth¨ alt die Tabelle 6 Millionen S¨atze. Die Tabelle doc“ beschreibt Dokumente und enth¨alt neben einer Referenz auf das ” Korpus, aus dem diese stammen, die Original-Id des Dokumentes in jenem Korpus. Hier liegen etwa 2,5 Millionen Dokumente vor, wovon etwa 2,4 Millionen PubMed-Abstracts und etwa 125.000 PubMed-Central-Volltexte sind. Die Tabelle geneInfo“ schließlich ordnet jedem Paar von entrezId und TaxonId einen ” kanonischen Namen zu, basierend auf HUGO.

7.1.2. Das Zielschema Wie in 5.1 beschrieben wird der Schwerpunkt der Datenbankanfragen auf Proteinen und ihren Interaktionen liegen. Die Fundstellen sind eher nebens¨achlich und haben lediglich als Selektionskriterium und zur Anzeige eine Bedeutung. Das Quellschema hingegen legt einen starken Fokus auf Fundstellen in Texten. M¨ochte man beispielsweise wissen, mit welchen Proteinen albumin“ interagiert, so ist daf¨ ur folgende Anfrage n¨otig: ”   SELECT DISTINCT e1 . e n t i t y T e x t , e2 . e n t i t y T e x t FROM pair p JOIN e n t i t y e1 ON ( e1 . e n t i t y L a b e l = p . e n t i t y 1 ) JOIN e n t i t y e2 ON ( e2 . e n t i t y L a b e l = p . e n t i t y 2 ) WHERE e1 . e n t i t y T e x t= ’ albumin ’ OR e2 . e n t i t y T e x t= ’ albumin ’





Listing 7.1: SQL-Code zur Abfrage interagierender Proteine (Quellschema) M¨ochte man zus¨ atzlich nur in verh¨altnism¨aßig neuen Dokumenten2 suchen, so erweitert sich die Abfrage auf:

2

Die Tatsache, dass ein Abstract relativ neu ist, ist der Einfachheit halber mit einer relativ hohen ID im Originalkorpus modelliert.

36





SELECT DISTINCT e1 . e n t i t y T e x t , e2 . e n t i t y T e x t FROM pair p JOIN e n t i t y e1 ON ( e1 . e n t i t y L a b e l = p . e n t i t y 1 ) JOIN e n t i t y e2 ON ( e2 . e n t i t y L a b e l = p . e n t i t y 2 ) JOIN s e n t e n c e s ON ( e1 . s e n t e n c e = s . l a b e l ) JOIN doc d ON ( s . doc = d . d oc L ab e l ) WHERE ( e1 . e n t i t y T e x t= ’ albumin ’ OR e2 . e n t i t y T e x t= ’ albumin ’ ) AND d . o r i g I d > 1 2 3 4 5 6 7 ;



Listing 7.2: SQL-Code zur gefilterten Abfrage interagierender Proteine (Quellschema) Durch den Schwerpunkt auf konkreten Fundstellen entsteht f¨ ur den hier beschriebenen Anwendungsfall also schon in der Quelldatenbank ein hoher Join-Aufwand, was wohl bei einem entsprechenden Graphdatenbankschema3 zu einer sehr großen Menge an zu traversierenden Kanten f¨ uhren w¨ urde. Dies legt nahe, dass es hier sinnvollere Ans¨atze der Schemagestaltung geben d¨ urfte. Desweiteren sind noch einige Aspekte des Originalschemas anzumerken: Obwohl Interaktionen auf Satzebene gesucht werden, also die beiden Komponenten eines Paares zwangsl¨ aufig immer im selben Satz stehen, ist der Verweis auf den beinhaltenden Satz in der Entit¨ atstabelle, und damit zwei mal f¨ ur jedes Paar, gespeichert. Die durch die Ausgliederung der Konfidenzwerte in die predict“-Tabelle entstandene ” M¨oglichkeit, mehrere Klassifikationen f¨ ur ein Paar zu haben, scheint f¨ ur den hier betrachteten Anwendungsfall eher irrelevant zu sein. So wird es f¨ ur den Nutzer der hier entwickelten API kaum einen Mehrwert haben, nach Konfidenzwerten verschiedener Tools selektieren zu k¨ onnen. Dies w¨ urde zum Einen voraussetzen, dass dem Nutzer die Besonderheiten verschiedener Verfahren bewusst sind, so dass er eine qualifizierte Entscheidung treffen kann. Zum Anderen m¨ usste er die Klassifikationsqualit¨at und die Geeignetheit des Tools bez¨ uglich des hier gegebenen Korpus kennen. So scheint es sinnvoll, sollte hier einmal mehr als nur ein Klassifikationsmechanismus genutzt werden, sich f¨ ur die API einen davon auszuw¨ ahlen. Abschließend f¨ allt noch auf, dass die Normalisierung der Satz-Dokument-Korpus-Beziehung auf drei Tabellen f¨ ur unseren Anwendungsfall ebenfalls kaum Mehrwert zu bieten scheint. Im Gegenteil steigert die Normalisierung die Komplexit¨at der Anfragen und ihrer Auswertung. In der Graphdatenbank werden diese daher, analog zur in OLAP-Systemen 3

Gemeint ist ein Graphdatenbank, welches f¨ ur jedes Element jeder Relation einen Knoten und f¨ ur jede Fremdschl¨ usselbeziehung zwischen zwei Elementen eine Kante beinhaltet.

37



Abbildung 7.2.: ER-Modell des entwickelten Zielschemas bewusst genutzten Denormalisierung zur Anfrageoptimierung in einen einzigen Knotentyp – den Satzknoten – zusammengefasst. TODO: Wie definiert sich ein Schema auf Graphen? Vor dem Hintergrund der in Abschnitt 5.1 beschriebenen Anfragen erscheint es sinnvoll, f¨ ur das Zielschema zwei Grundentit¨aten zu definieren: Zum einen Proteine, zum anderen deren Interaktionen. Proteine haben Attribute, beispielsweise ihre Entrez-Id, das Taxon, in welchem Sie vorkommen oder die Namen, unter denen sie im Text gefunden wurden. Zur Interaktion geh¨ oren deren Fundstellendetails, also wo sie mit welcher Konfidenz und wie oft sie insgesamt gefunden wurde. Einen Teil dessen ist in Abbildung 7.2 dargestellt. Doppelt eingekreiste Attribute sind hierbei mehrwertig, unterstrichene Attributnamen weisen auf ein Schl¨ usselattribut hin. Hier dargestellt sind aber nur ein kleiner Ausschnitt der denkbaren Attribute. So ist, wie eingangs erl¨ autert, beispielsweise auch eine Selektion nach Metadaten des Dokumentes, des Proteins, beeinflussten Krankheiten oder beeinflussenden Wirkstoffen denkbar. Aber es scheint, dass man auch diese stets entweder einem Protein oder einer Interaktion als mehrwertiges Attribut zuordnen kann.

7.2. Datenextraktion, Schematransformation, Bef¨ ullung der Datenbank Auch wenn es sich hier nicht um ein klassisches OLAP-System handelt, so ist ist dennoch ein ETL-Prozess anwendbar: Es gilt, aus einem Quellsystem Daten zu extrahieren, zu transformieren und in ein Zielsystem einzuspeisen. F¨ ur die hier entwickelte Anwendung wurden die Datenextraktion und ein Teil der Schematransformation im Quellsystem implementiert. Die Schematransformation erfolgt bereits dort, da das relationale Datenbanksystem aufgrund seiner mengenorientierten Datenzugriffsmechanismen (SQL) solche Massendatenverarbeitungen deutlich vereinfacht. Die Bef¨ ullung der Neo4j Zieldatenbank erfolgt durch ein selbst entwickeltes Java-Programm.

38

Abbildung 7.3.: Datenfluss w¨ahrend des ETL-Prozesses

7.2.1. Datenextraktion und Schematransformation F¨ ur die Datenextraktion und Schematransformation wurde in der Quell-MySQL-Datenbank ein eigenes Schema als Staging Area angelegt. Der darauf folgende Prozess ist in Abbildung 7.3 dargestellt: Sie stellt dar, welche Tabellen als Datenquellen anderer Tabellen dienen, wobei die Quelltabellen stets oberhalb der zu bef¨ ullenden Tabellen angeordnet sind. Der Prozess beginnt mit der Extraktion und Transformation der Proteinfundstellendaten des Quellschemas aus der entity“-Tabelle. Da die Entrez-Id unser Schl¨ usselattribut f¨ ur ” die Proteine sein soll, gilt es, dieses aus dem oben beschriebenen eigenwillig formatierten String herauszul¨ osen. Hierf¨ ur werden zuerst die Quelldaten aus der entity“-Tabelle ” in eine neue Tabelle entities staging“ kopiert. In dieser Tabelle wird dann sukzessive ” das jeweils erste Paar aus dem String entfernt und als neue Zeile eingef¨ ugt. Danach

39

entityLabel PMC.dPMC1104.e101

Tabelle entities“ ” origin 282691@9913|3146@9606|15289@10090

entityText HMG1

entityLabel PMC.dPMC1104.e101 PMC.dPMC1104.e101 PMC.dPMC1104.e101

Tabelle entities staging ” origin 282691@9913 15289@10090 3146@9606

proteinName HMG1 HMG1 HMG1

entityLabel PMC.dPMC1104.e101 PMC.dPMC1104.e101 PMC.dPMC1104.e101

Tabelle entities staging splitted“ ” entrezId taxonId 282691 9913 15289 10090 3146 9606

proteinName HMG1 HMG1 HMG1

entrezId 282691 15289 3146

Tabelle proteins“ ” taxonId proteinNames 9913 HMG-1#HMG1#. . . 10090 HMG1#HMGB1#. . . 9606 HMGB-1#HMGB1#. . .

canonicalName HMGB1 Hmgb1 HMGB1

Tabelle 7.2.: Veranschaulichung der Protein-Daten im Laufe des ETL-Prozesses wird die Tabelle entities staging splitted mit den so gewonnenen Daten bef¨ ullt, wobei ” die Paare noch am @“ aufgespalten werden. Zuletzt werden die Daten nach Entrez-Id ” gruppiert, mittels eines Joins die kanonischen Namen zu diesen EntrezIds zugeordnet und eventuell vorhandene unterschiedliche Schreibweisen eines Proteinnamens mittels der GROUP CONCAT()-Aggregationsfunktion mit einem #“-Zeichen konkateniert. ” Die Zusammenfassung auf eine Tabellenzeile pro EntrezId erleichtert sp¨ater geringf¨ ugig den Datenimport in die Zieldatenbank. Das #“-Zeichen ist in keinem Proteinnamen ” enthalten. Einen kurzen Ausschnitt aus den Daten und deren Ver¨anderung im Laufe des ETL-Prozesses ist in Tabelle 7.2 dargestellt. Es folgt die Extraktion der Interaktionsdaten. Hierbei werden zun¨achst s¨amliche zu einem Eintrag in der pair“-Tabelle geh¨ origen Fremdschl¨ usselbeziehungen aufgel¨ost, so dass zu ” jeder Interaktionsfundstelle die beteiligten Proteinfundstellen, die Quelleninformationen sowie der Konfidenzwert in einer Tabellenzeile zusammengefasst sind. Diese Daten werden in die Tabelle interactions staging“ gespeichert. Den so gewonnenen Daten ” liegen allerdings noch die Entit¨ atsdefinitionen des Quellschemas zugrunde: Ein Eintrag

40

dieser Tabelle bezieht sich auf je zwei, eine Interaktion beschreibende Proteinfundstellen, wobei jeder Fundstelle mehrere Entrez-Ids zugeordnet sein k¨onnen. Ziel ist es jedoch, die Interaktionen zwischen einzelnen Entrez-Ids zu finden. Daher werden in einem n¨ achsten Schritt diese Daten mit den Daten der entities staging ” splitted“-Tabelle verkn¨ upft, welche die Zuordnung zwischen Proteinfundstellen und deren Entrez-Ids beinhaltet. In diesem Schritt erfolgt außerdem ein Richten des Graphen: Fachlich gesehen ist der Interaktionsbegriff ungerichtet. Interagiert Protein A mit Protein B, so interagiert auch Protein B mit Protein A. Die Repr¨asentation in einer SQL-Tabelle hingegen ist stets gerichtet: Gibt es die Spalten protein1“ und protein2“, so folgt aus der ” ” Existenz des Eintrags (A,B) nicht zwingend die Existenz des Eintrags (B,A). Um dennoch im Folgenden eine einfache Duplikaterkennung zu erm¨oglichen, werden die beiden EntrezIds in diesem Schritt dergestalt getauscht, dass stets die numerisch kleinere in der ersten Spalte steht. Die resultierende Tabelle heißt daher interactions staging directed“. ” Was im Rahmen dieses ETL-Prozesses nicht mit extrahiert wurde, ist die genaue Position einer Proteinfundstelle innerhalb des Satzes. Da pro Satz mehrere Fundstellen des selben Proteinnamens vorkommen k¨onnen (was in ca. 3,4 Millionen S¨atzen der Fall ist), enth¨alt die interactions staging directed“-Tabelle mehrere Eintr¨age mit verschiedenen ” Konfidenzwerten f¨ ur ein und denselben Satz. Zur Vereinfachung der im weiteren Verlauf der Arbeit entwickelten Suchmechanismen galt es nun, dies auf genau einen Konfidenzwert zu reduzieren. Ausgehend von der Annahme, dass Suchende die Frage interessiert, in welchem Satz eine Interaktion gefunden wurde, und nicht, in welchem Satz eine Interaktion nicht gefunden wurde, liegt es nahe, den jeweils gr¨oßten der gefundenen Werte zu u ¨ bernehmen. Das Ergebnis dieses Schrittes wird dann in die Tabelle interactions“ ” eingef¨ ugt. Zuletzt wird f¨ ur jede gefundene Interaktion zwischen zwei Entrez-Ids berechnet, in wie vielen S¨atzen sie gefunden wurde, und das Ergebnis in der Tabelle statistics“ gespeichert. ” Diese Anzahl der Fundstellen wird dann in der entwickelten Java API ein m¨ogliches Selektionskriterium f¨ ur Interaktionen sein. Im Rahmen des beschriebenen Prozesses galt es an mehreren Stellen, etwaige doppelte Eintr¨age in den Tabellen zu vermeiden. Hierf¨ ur wurde dem Schema eine Standardsortierreihenfolge zugewiesen, welche nicht nach Groß- und Kleinschreibung unterscheidet. ¨ MySQL zieht diese auch f¨ ur die Bestimmung der Gleichheit bei der Uberpr¨ ufung von Unique-Constraints heran. Somit ließ sich mittels eines Prim¨arschl¨ ussels, der alle Spalten einer Tabelle umfasst, sicherstellen, dass in diese Tabelle keine Duplikate – auch nicht in verschiedenen Schreibweisen4 – eingef¨ ugt werden k¨onnen. F¨ ugt man Daten mit dem Befehl INSERT IGNORE INTO“ ein, so verwirft MySQL beim Einf¨ ugen etwaige Du” plikatszeilen stillschweigend. Dies erwies sich in der Regel als deutlich schneller als eine vorgelagerte Duplikatsbereinigung, beispielsweise mittels SELECT DISTINCT“. ”

4

Verschiedene Schreibweisen“ bezieht sich hier auf Groß- und Kleinschreibung. ”

41

7.2.2. Das Bef¨ ullen der Zieldatenbank Die Trennung der drei Schritte – Datenextraktion, Schematransformation und Bef¨ ullung – erweist sich bei der Bef¨ ullung der Zieldatenbanken als besonders n¨ utzlich, da hier anfangs zur Evaluation auch die H2 Datenbank parallel bef¨ ullt wurde. Zu diesem Zweck wurde ein Java-Programm geschrieben, welches je 1.000.000 Interaktionen (respektive deren Fundstellen) zusammen mit den beteiligten Proteinen und den Statistik-Daten (per Join verkn¨ upft) aus der Quelldatenbank abfragt. Diese 1.000.000 Interaktionen werden dann in die jeweiligen Datenbanken geschrieben. In der Neo4J-Datenbank werden 3 Knotentypen und 3 Kantentypen genutzt: Alle Knotentypen haben ein type“-Attribut, welches einen der folgenden Werte annehmen kann: ” protein“, interaction“, sentence“. Satzknoten haben als Attribute ihren Volltext so” ” ” wie ihre Quellenangaben (Korpus, Dokumenten-Id, Satznummer). Proteinknoten haben ihren kanonischen Namen, die Namen, unter denen sie im Text vorkamen, sowie ihre Entrez- und Taxon-Id als Attribute. Das einzige Attribut der Interaktionsknoten ist die Anzahl ihrer Fundstellen. Proteine sind mit Interaktionsknoten u ¨ ber Kanten der Typen FIRST IN INTERACTION“ und SECOND IN INTERACTION“ verbunden, ” ” Interaktionsknoten mit S¨ atzen durch FOUND IN“-Kanten. Letztere haben den dazu” geh¨origen Konfidenzwert als Attribut. Das sich daraus ergebende Netz ist in Abbildung 7.4 als Ausschnitt aus der Datenbank visualisiert. Da Neo4j auch mehrwertige Attribute unterst¨ utzt, k¨ onnen auch die Namen, unter denen ein Protein im Text gefunden wurde, ohne weitere Anpassungen direkt als einzelne Knotenattribute eingef¨ ugt werden. Um sp¨ ater die Ausgangsproteine f¨ ur die Nachbarschafts- und Kleine-Welt-Graphen effizient finden zu k¨ onnen, wird außerdem ein Lucene-Volltextindex bef¨ ullt. Hierin werden die gefundenen Namen, der kanonische Name, die Entrez-Id und die Taxon-Id jedes Proteins indiziert. Der gesamte ETL-Prozess zum Aufsetzen einer Neo4j-Instanz dauert etwa eine halbe Stunde.

7.3. Implementierung der Java API Die Java API setzt die in Abschnitt 5.1 genannten Anfragearten um und bietet somit Zugriff auf die Interaktionsdaten. Im Folgenden werden die grundlegenden Designentscheidungen kurz skizziert, die Schnittstelle vorgestellt und auf verwendete Entwurfsmuster eingegangen. Nachbarschaftsgraphen lassen sich durch eine Tiefen- oder Breitensuche bis zur Tiefe n im Graphen generieren, ausgehend von den gegebenen Startproteinen, wobei jede traversierte Kante im Ergebnisgraph enthalten ist. Kleine-Welt-Graphen lassen sich ebenfalls durch eine Tiefen- oder Breitensuche bis zur gegebenen Tiefe generieren, ausgehend von den gegebenen Startproteinen, wobei die Menge der Pfade den Graph bildet, welche wieder

42

Abbildung 7.4.: Neo4j: fiktiver Ausschnitt aus der Datenbank

43

an einem der Startproteine endet. Die Traversal API von Neo4j unterst¨ utzt Tiefen- und Breitensuchen mit frei definierbaren Abbruchbedingungen und erm¨oglicht wahlweise die R¨ uckgabe von Pfaden, Kanten oder Knoten, ist also f¨ ur die beschriebenen Anfragen geeignet. Die API wurde als interne dom¨ anenspezifische Sprache entwickelt. Hiermit gehen zwar einige Nachteile einher, insbesondere die gr¨oßere Komplexit¨at der Implementierung durch die st¨arkere Abstraktion, allerdings sehe ich die Vorteile als u ¨ berwiegend an: Da die Ausf¨ uhrung der Anfragen an die Traversal API delegiert werden kann, l¨asst sich die Java API als sehr leichtgewichtige Schicht u ¨ber der Neo4j-Datenbank implementieren. Dies relativiert das Argument, interne DSLs w¨ urden zu gesteigerter Softwarekomplexit¨at f¨ uhren. Auch eine Verschleierung von Fehlerquellen und erschwerte Fehlersuche durch die Abstraktion konnte ich w¨ ahrend der Entwicklung nicht feststellen. Die Verbesserungen in der Lesbarkeit des Codes aus Sicht des API-Konsumenten sowie die Vereinfachung der Kommunikation zwischen Softwareentwicklern und biomedizinischen Dom¨anenexperten scheinen daher die deutlich gewichtigeren Argumente zu sein. F¨ ur die Entwicklung einer externen DSL hingegen, die mit erheblichem Mehraufwand, beispielsweise f¨ ur die Parserentwicklung, einhergegangen w¨are, fanden sich keine hinreichenden Argumente. Zentraler Einstiegspunkt der API ist das Interface InteractionRepository, implementiert durch die Klasse GraphDatabaseInteractionRepository. Das Interface InteractionRepository stellt eine abstrakte Sammlung von Interaktionsdaten und Zugriffsmustern zur Verf¨ ugung und kapselt so die eigentliche Datenbank, das Wissen u ¨ ber ihr Schema und ihre Anfragesprachen hinter einer abstrakten Schnittstelle. Das InteractionRepository implementiert java .lang. Iterable , man kann also mittels eines Iterators alle vorhandenen Interaktionen abfragen:



InteractionRepository repository = new G r a p h D a t a b a s e I n t e r a c t i o n R e p o s i t o r y ( ” / pfad / z u r / datenbank ” ) ; for ( I n t e r a c t i o n i n t e r a c t i o n : r e p o s i t o r y ) { System . out . p r i n t l n ( i n t e r a c t i o n ) ; }



Listing 7.3: Abfrage aller Interaktionen u ¨ber die Java API Das Interaction-Interface ist die Grundentit¨at der API. Desweiteren existieren Interfaces namens Protein und Citation. Ersteres repr¨asentiert ein Protein, identifiziert durch seine Entrez-Id. Es stellt außerdem Informationen u ¨ ber das Taxon, den kanonischen Namen sowie diejenigen Namen zur Verf¨ ugung, unter denen das Protein im Korpus gefunden wurde. Letzteres repr¨ asentiert eine Interaktionsfundstelle. Es stellt Informationen u ¨ ber Korpus, Dokumenten-ID und Satzindex zur Verf¨ ugung. Außerdem l¨asst sich hier¨ uber abfragen, welcher Konfidenzwert der Fundstelle zugeordnet wurde, also ob und mit

44





welcher Sicherheit die Fundstelle tats¨achlich eine Interaktion beschreibt. Das InteractionInterface stellt Methoden bereit, um die beteiligten Protein-Instanzen sowie einen Iterator beteiligter Citation-Instanzen abzufragen. M¨ochte man nicht den kompletten Graphen, sondern lediglich Teilgraphen abfragen, so ist dies mit Hilfe des InteractionQuery-Interfaces m¨oglich. Eine Instanz erh¨alt man mittels interactionRepository.query(). Es handelt sich hierbei um ein sogenanntes Fluent ” Interface“, das heißt: Methoden dieses Interfaces geben in der Regel eine Instanz dieses Interfaces zur¨ uck. Somit lassen sich mehrere Methodenaufrufe miteinander verketten (Fowler und Parsons [2011, Kapitel 35] nennen dies Method Chaining“). Da auch ” das InteractionQuery-Interface java .lang. Iterable implementiert, kann man mittels der iterator () -Methode bzw. for ( Interaction ppi : query) {} u ¨ ber die Anfrageergebnisse iterieren. Das InteractionQuery-Interface bildet zusammen mit den Klassen ProteinSelectors und InteractionFilters die interne DSL. Listing 7.4 zeigt zwei Beispiele m¨ogliche Anfragen:





r e p o s i t o r y . query ( ) . smallWorldGraph ( ) . asInducedSubGraph ( ) . crawlUpToRadius ( 3 ) . startingWithProteinsMatching ( canonicalName ( ”BRCA1” ) ) ; r e p o s i t o r y . query ( ) . startingWithProteinsMatching ( entrezId (123)) . crawlOnlyInteractionsCited ( allOf ( inCorpus ( ”PMID” ) , withConfidenceGreaterThan ( 0 ) ) ) ;



Listing 7.4: Beispielanfragen gegen die API Der Standardanfragemodus eines InteractionQuerys ist die Abfrage eines Nachbarschaftsgraphen der Tiefe 1, was mittels query.smallWorldGraph() ge¨andert werden kann. F¨ ur beide Anfragemodi l¨ asst sich per query.asInducedSubGraph() eine Nachverarbeitungsstufe zuschalten, welche aus den in der Ergebnismenge der Anfrage enthaltenen Proteinen einen induzierten Subgraphen des vollst¨andigen Graphen generiert. Mittels query.crawlUpToRadius(long n) l¨ asst sich f¨ ur beide Anfragevarianten die Tiefe auf einen beliebigen positiven Wert setzen. Die gezeigten, kursiv gedruckten Funktionen entstammen den Klassen ProteinSelectors und InteractionFilters . Die Klasse ProteinSelectors gibt Nutzern die M¨oglichkeit, Selektionskriterien f¨ ur Proteine anhand ihrer Attribute zu spezifizieren. Dies sind ihre Entrez-ID, ihre Taxon-ID, ihr kanonischer Name und die Namen, unter denen sie im Korpus gefunden wurden. Außerdem stellt sie einen allOf(ProteinSelector ...) - und einen oneOf(ProteinSelector.. .) -Selektor, welcher nur solche Proteine selektiert, bei denen alle bzw. mindestens einer der Subselektoren erfolgreich ist. Die Funktionen der Klasse InteractionFilters geben entsprechend Instanzen des Interfaces InteractionFilter zur¨ uck.

45



Auch hier werden allOf( InteractionFilter ...) - und oneOf(InteractionFilter ...) -Filter angeboten. Dar¨ uber hinaus stehen Filterm¨oglichkeiten nach Korpus, Dokumenten-ID, Konfidenzwert und Anzahl der Fundstellen zur Verf¨ ugung. Letztere beiden Attribute k¨onnen auch mittels ≤, und ≥ gefiltert werden. Es handelt sich hierbei um statische Funktionen, welche Instanzen des Interfaces ProteinSelector bzw. InteractionFilter zur¨ uckgeben und mit Hilfe der seit Java 5 vorhandenen Schl¨ usselw¨ orter static import“ so verf¨ ugbar gemacht werden k¨onnen, als seien sie ” lokal definiert. Somit lassen sich mit verschachtelten Funktionen boolsche Ausdr¨ ucke in Pr¨afixnotation schreiben. Die ProteinSelectors-Methoden sind jeweils sog. statische Factory-Methoden. Die generierten ProteinSelector-Instanzen haben mit getIndexQuery() genau eine Methode, welche ein Lucene-Anfrageobjekt zur¨ uckgibt. Die Methoden des Interfaces InteractionFilters sind ebenfalls statische Factory-Methoden. Die generierten InteractionFilter -Instanzen haben ebenfalls genau eine Methode. Diese heißt match(Node node) und gibt true zur¨ uck, wenn die Kante weiterverfolgt werden soll sowie false, falls nicht. Das InteractionQuery-Interface wird implementiert durch die Klasse GraphDatabaseInteractionQuery. Die in Listing 7.4 gezeigten Methoden setzen beim Aufruf lediglich bestimmte Werte innerhalb des Objektes, analog zu setXY()-Methoden in CommandQuery-APIs. Zusammen mit den Instanzen von ProteinSelector und InteractionFilter bildet eine Instanz der Klasse GraphDatabaseInteractionQuery das sogenannte semantische Modell der Anfrage. Sie enth¨ alt alle Informationen (Anfragemodi, Selektionskriterien, etc.), die notwendig sind, um eine solche Anfrage auszuf¨ uhren (vgl. hierzu Fowler und Parsons [2011, Kapitel 11]). Im Sinne eines Rich-Domain-Models h¨alt die Klasse GraphDatabaseInteractionQuery nicht nur Informationen und stellt Methoden zu ihrer Modifikation bereit, vielmehr ist sie durch ihre iterator ()-Methode auch Einstiegspunkt in die Anfrageverarbeitung. Hierf¨ ur greift sie auf mehrere Komponenten zur¨ uck: Neben dem schon erw¨ahnten Lucene-Index, welcher auf Basis der Attributwerte eine Menge von Proteinen generiert, sind hier die Klassen DepthBasedGraphGenerator f¨ ur die Abfrage von Nachbarschaftsgraphen, SmallWorldGraphGenerator f¨ ur die Abfrage von Kleine-Welt-Graphen und InducedSubGraphGenerator f¨ ur das anschließende, optionale Abfragen von induzierten Teilgraphen anhand von Proteinlisten zu nennen. Die GraphDatabaseInteractionQueryKlasse l¨asst von der ProteinSelector-Instanz einen Lucene-Query generieren, fragt damit die Liste der Start-Proteine ab und delegiert die Anfragebearbeitung dann die entsprechenden Graphgeneratoren. Diese delegieren dann wiederum auf die Traversal API von Neo4j, wie bereits zuvor beschrieben. Neo4j berechnet dabei nicht, wie viele relationale Datenbankmanagementsysteme, die komplette Ergebnismenge sofort. Stattdessen wird das n¨achste Ergebniselement erst in dem Moment berechnet, indem es ben¨otigt wird. Dies spart auch Arbeitsspeicher, da stets nur das aktuelle Ergebnis in selbigem gehalten werden muss. Außerdem entstehen dadurch kurze Reaktionszeiten f¨ ur den Nutzer, der nicht erst lange auf die Berechnung

46

des kompletten Ergebnisses warten muss. Diesen Vorteil gibt die API mittels des Iterators an den Nutzer weiter. Die Ergebnisknoten des Graphen werden hinter einer Implementierung des Interaction¨ Interfaces gekapselt. Hierbei kommt die strukturelle Ahnlichkeit zwischen dem Objektmodell, welches Java nutzt, und dem Graphenmodell von Neo4j zugute: Bei der Nutzung von relationalen Datenbankmanagementsystemen steht man stets vor dem Problem, Objektgraphen auf das relationale Datenmodell abbilden zu m¨ ussen, das sogenannte Objekt-Relationale Mapping. Bei einer Graphdatenbank ist das einfach: Objekte lassen sich auf Knoten abbilden, Beziehungen zwischen Objekten auf Relationen zwischen Knoten, Variablen von Objekten auf Attribute des zugrundeliegenden Knotens. Die Implementierung des Interaction-Interfaces, die GraphDatabaseInteraction, erh¨alt daher den Interaktionsknoten des Graphen als Konstruktorparameter, speichert diesen und delegiert in seinen Methoden nur noch an ihn. Selbiges gilt f¨ ur die Protein- und Citation-Klassen. Ein gek¨ urztes Beispiel sieht folgendermaßen aus:





c l a s s GraphDatabaseProtein implements P r o t e i n { private f i n a l Node p r o t e i n N o d e ; GraphDatabaseProtein ( Node p r o t e i n N o d e ) { this . proteinNode = notNull ( proteinNode ) ; } @Override public int g e t E n t r e z I d ( ) { return ( I n t e g e r ) p r o t e i n N o d e . g e t P r o p e r t y ( P r o t e i n C o n s t a n t s . ENTREZ ID ) ; } @Override public S t r i n g getCanonicalName ( ) { return ( S t r i n g ) p r o t e i n N o d e . g e t P r o p e r t y ( P r o t e i n C o n s t a n t s .CANONICAL NAME) ; } [...] }





Listing 7.5: Ausschnitt aus der Klasse GraphDatabaseProtein Die Node-Instanz von Neo4j stellt hierbei nur eine Referenz auf den physischen Knoten dar. Dass das GraphDatabaseProtein eine Instanz der Node-Klasse h¨alt, bedeutet somit nicht, dass sich der physische Node tats¨ achlich im Arbeitsspeicher befindet. Neo4j verwaltet hinter diesem Interface nahezu unbemerkt das Caching, das Memory-Management und das tats¨achliche Laden der Knoten, Attribute und Relationen.

47

Abbildung 7.5.: Grafische Schnittstelle zum Erstellen von Suchanfragen gegen die API

7.4. Entwicklung eines Plugins f¨ ur Cytoscape Ein Nutzer der Java API ist ein Plugin f¨ ur Cytoscape. Das Plugin tr¨agt den Namen 5 HUBerlinPPIs“ und bietet eine grafische Schnittstelle (Abbildung 7.5) zur Erstellung ” von InteractionQuery-Instanzen. Der Anfragemodus kann hierbei am unteren Rand des Fensters mittels zweier Checkboxen gew¨ahlt werden: Auch hier wird standardm¨aßig der uninduzierte Nachbarschaftsgraph abgefragt. Jedoch l¨asst sich sowohl die Abfrage des Kleine-Welt-Graphen als auch die Abfrage von induzierten Teilgraphen dort aktivieren. Zus¨atzlich kann die Suchtiefe eingestellt werden. Im oberen Teil des Fensters k¨onnen die Selektoren f¨ ur die Ausgangsproteine und die Filter f¨ ur die zu traversierenden Interaktionen eingestellt werden. Diese werden hier in Form ihres abstrakten Syntaxbaums angezeigt. Man kann einzelnen Knoten dieses Baumes neue Unterknoten hinzuf¨ ugen und so beliebig 5

Pluginnamen in Cytoscape d¨ urfen keine Leerzeichen enthalten, daher der etwas kryptische Name.

48

Abbildung 7.6.: Ein Anfrageergebnis mit selektierten Proteinen und deren Attributen komplexe Anfragen zusammenstellen, wie es in besagter Abbildung ansatzweise f¨ ur den OneOf-Selector gezeigt ist. Nach einem Klick auf Search“ wird eine Suche u ¨ber die API gestartet. Die Interaktionen ” werden abgefragt und einem neu angelegten Cytoscape-Netz hinzugef¨ ugt. An dieser Stelle zeigt sich ein Vorteil der Just-In-Time-Anfragebearbeitung von Neo4j: Da das n¨achste Suchergebnis erst berechnet wird, wenn es per iterator .next() abgefragt wird, l¨asst sich die Anfragebearbeitung jederzeit abbrechen. Die bis dahin abgerufene Ergebnismenge l¨asst sich dann dennoch anzeigen. Es ist auch m¨oglich, sich das Netz bereits w¨ahrend der Anfragebearbeitung anzeigen zu lassen, um beispielsweise einen ersten Eindruck zu erhalten, ob die Anfrage den eigenen Bed¨ urfnissen entspricht. Gefundene Proteine und Interaktionen werden dem Graphen dann hinzugef¨ ugt, sobald sie gefunden wurden. Die Literaturfundstellen (Korpus, Dokumenten-ID, Satzindex, Volltext, Konfidenzwert) werden hierbei als mehrwertiges Kantenattribut in Cytoscape dargestellt. Der aus der Anfrage in Abbildung 7.5 resultierende Interaktionsgraph ist in Abbildung 7.6 zu sehen.

49

8. Auswertung Abschließend m¨ ochte ich einen kurzen Ausblick auf weitere Entwicklungsm¨oglichkeiten der hier implementierten Komponenten geben und die wesentlichen getroffenen Entscheidungen kurz bewerten. Voraussetzung f¨ ur die Eignung der DBMSe war, dass eine Weitergabe der Daten an Dritte m¨ oglich sein soll. Ob dies m¨ oglich sein wird, ist allerdings aus urheberrechtlichen Gr¨ unden fraglich: Die zu Grunde liegenden Texte, aus denen die Daten extrahiert wurden, stellen eventuell gesch¨ utzte Werke dar. Zwar denke ich, dass es unproblematisch ist, zu speichern und zu ver¨ offentlichen, dass im f¨ unften Satz des Dokuments mit der PubMedId x eine Interaktion zwischen BRCA1 und BRCA2 beschrieben ist. Problematisch hingegen wird es, wenn die Volltexte der S¨atze gespeichert und ver¨offentlicht werden. Dies ist insbesondere schwierig, da hier die Urheberrechts- und Copyright-Regelungen verschiedener Jurisdiktionen beteiligt sein k¨onnten, namentlich die deutsche, da die Erstellung und Ver¨ offentlichung der Datenbank hier stattfindet, diejenige der USA, da dort die zugrunde liegenden Korpora PubMed Central und Medline/PubMed gepflegt und erstellt wurden, die des Staates, in dem der publizierende Verlag der jeweiligen Texte seinen Sitz hat sowie die, auf deren Hoheitsgebiet die jeweiligen Texte entstanden sind. Eine M¨ oglichkeit, diese Probleme zu umgehen, k¨onnte sein, die Volltexte nicht in der Datenbank zu speichern, allerdings ginge damit eventuell auch ein nicht unerheblicher Teil der N¨ utzlichkeit der Schnittstelle verloren. Eine Pr¨ ufung der urheberrechtlichen Implikationen w¨ urde allerdings den Rahmen dieser Arbeit sprengen. Bei den Anfragem¨ oglichkeiten an die API bietet sich noch Erweiterungspotential. Denkbar w¨are hier beispielsweise, neben den Interaktionsfiltern auch Proteinfilter zuzulassen, also nicht nur initiale Proteine, sondern auch die beim Traversieren des Graphen zu ber¨ ucksichtigenden Proteine einzuschr¨anken. Dies w¨ urde es beispielsweise erm¨oglichen, lediglich einen Teilgraphen aus menschlichen Proteinen abzufragen. Auch das Verhalten der Interaktionsfilter ist momentan eher unintuitiv: So wird die Anfrage allOf(Corpus: PMID‘; Document-ID: 12345‘)“ nicht ausgewertet als die ” ’ ’ ” Interaktion wurde in einem Dokument mit der ID 12345‘ im Korpus PMID‘ gefunden“, ’ ’ sondern als die Interaktion wurde in einem Dokument mit der ID 12345‘ und in ” ’ einem Dokument aus dem Korpus PMID‘ gefunden“. Ersteres w¨are wohl die sinnvollere ’ Anfragesemantik. Auch die M¨ oglichkeit zur Abfrage aller Interaktionen k¨onnte noch erweitert werden: Gibt sie momentan schlicht alle vorhandenen Interaktionen zur¨ uck, so k¨onnte sie zuk¨ unftig beispielsweise auch Interaktionsfilter auswerten. Auch die Auswertung von Proteinfiltern

50

w¨are denkbar, wobei eine Interaktion nur zur¨ uckgegeben w¨ urde, wenn der Proteinfilter auf beide beteiligten Proteine zutrifft. Nicht nur die Anfragemechanismen, sondern auch die Daten selbst bieten einen Erweiterungspunkt. So erscheint es sinnvoll, weitere Attribute zu den Interaktionsdaten hinzuzuf¨ ugen. So w¨ aren bei den Literaturfundstellen beispielsweise das Ver¨offentlichungsdatum, die Namen der Autoren oder das publizierende Journal interessant. Bei den Interaktionen k¨onnte man assoziierte Krankheiten und Erstver¨offentlichungsdaten annotieren, bei den Proteinen assoziierte Gene. Neben der Erweiterung bestehender Daten um neue Attribute ließen sich auch zus¨ atzliche Korpora hinzuf¨ ugen oder gar Interaktionsdatenbanken aus anderen Projekten, die eventuell auch mittels anderer Verfahren gewonnen wurden, integrieren. Die Tatsache, dass Neo4j graphenbasiert ist, pr¨adestiniert die Datenbank auch zur Integration anderer Graphen, wie beispielsweise Ontologien. Nimmt man diese als gerichtete Graphen an, so kann man sie erg¨ anzend in die Datenbank speichern. F¨ ugt man Kanten zwischen einzelnen Proteinen bzw. Interaktionen zu den Ontologieknoten hinzu, so kann man die Ontologie auch als Indexstruktur f¨ ur den Datenzugriff auf die Interaktionsdaten nutzen. Das Cytoscape Plugin ist noch ausbauf¨ahig, insbesondere der Bereich der Software-Ergonomie wurde hier etwas vernachl¨ assigt. Das Zusammenstellen der Filter- und Selektorenausdr¨ ucke beispielsweise ließe sich sicherlich deutlich benutzerfreundlicher gestalten. Zu denken w¨ are hier an: ein Editieren von Blattwerten nach dem Einf¨ ugen, das Einf¨ ugen und L¨oschen von Baumelementen per Kontextmen¨ u, eine Validierung, welche u ¨ ber das Nichtreagieren auf invalide Tastendr¨ ucke hinausgeht und dem Nutzer mehr Feedback ob seines Fehler gibt, etc. Nach dem Laden des Teilgraphen w¨are es sch¨on, wenn man Daten nachladen k¨ onnte, beispielsweise u ¨ber eine Option Lade die Interaktionen dieses ” Proteins“ im Kontextmen¨ u eines ebensolchen. Zweifelhaft erscheint im Nachhinein, ob die Eingliederung der Graphalgorithmenschnittstelle in die Java API sinnvoll war, da es bisher keinen einzigen nennenswerten Algorithmus gibt, der u ¨ber diese Schnittstelle ansprechbar w¨are. Vor diesem Hintergrund ist es ungenutzter Code, der im Weiteren Wartungsaufwand mit sich bringen kann und keinerlei Nutzen bietet. Da es noch keinen nennenswerten Algorithmus gibt, ist auch nicht klar, ob sich u ¨berhaupt Algorithmen sinnvoll in diese Schnittstelle einbetten lassen. Bloch [2007, 0:17:24] empfiehlt f¨ ur Service Provider Interfaces mindestens 3 Algorithmen tats¨achlich zu implementieren, um valide Aussagen u ¨ ber die Tauglichkeit der Schnittstelle machen zu k¨onnen. Vor diesem Hintergrund w¨are es wohl sinnvoller gewesen, diese Schnittstelle iterativ auf Basis reeller algorithmischer Anforderungen zu entwickeln. Bew¨ahrt hat sich die Wahl des Datenbankmanagementsystems. Das Datenmodel von HyperGraphDB h¨ atte zwar eine einfachere Abbildung des Interaktionsgraphen erlaubt – durch die M¨ oglichkeit, Kanten (hier Zitierungen) auf andere Kanten (hier Interaktionen) zeigen zu lassen, w¨ are kein seperater Interaktionsknoten n¨otig gewesen – allerdings ließ sich der Graph auch im Datenmodell von Neo4j hervorragend darstellen. Die auf

51

Graphanfragen spezialisierte Traversal API vermeidet viel Aufwand, der sonst f¨ ur die Implementierung der Graphanfragemechanismen mit einer relationalen Datenbank notwendig geworden w¨ are. Dadurch wurde es m¨oglich, das semantische Modell der Anfrage mit nur wenigen Zeilen Programmcode auf eine Neo4j-Anfrage abzubilden. Auch die Abbildung von Neo4j-Eintr¨ agen auf Java-Objekte war durch die beschriebene N¨ahe zwischen dem Datenmodell von Neo4j und einem Java-Objektgraphen einfach und leichtgewichtig. Die Entscheidung f¨ ur eine interne DSL als Grundstruktur der API f¨ uhrt zu einfach lesbaren Anfragen. Diese d¨ urften in der Folge auch uneingeweihten Nutzern mit einem grundlegenden Dom¨ anenwissen die Intention des Autors der Anfrage z¨ ugig vermitteln. Die API entwickelt einen gewissen Sprach- und Lesefluss und ist mit Ausnahme der Algorithmenschnittstelle auf die wesentlichen Funktionen beschr¨ankt, was den Einarbeitungsaufwand f¨ ur neue Nutzer minimieren sollte. Die korrekte Syntax der Anfragen wird bei der Nutzung bereits durch den Compiler gepr¨ uft. Dies macht es auch f¨ ur neue Nutzer fast unm¨oglich, ung¨ ultige Anfragen zu formulieren. Durch die statische Typisierung von Java sind auch IDEs sehr gut in der Lage, beim Erstellen der Anfragen eine Liste m¨oglicher Funktionen zur Verf¨ ugung zu stellen und den Nutzer so bei der Erstellung einer Anfrage zu unterst¨ utzen. Bloch [2006] stellt an gute APIs die Anforderung: APIs should be easy to use and hard to misuse.“ ” Die vorliegende API d¨ urfte diese Anforderungen weitgehend erf¨ ullen.

52

A. Literaturverzeichnis Altman, R. B., Lauderdale, K., Hunter, L., und Klein, T. E. (Hrsg.) (1999). Pacific Symposium on Biocomputing 2000: Honolulu, Hawaii, USA 4-9 January 2000. World Scientific. Online, http://psb.stanford.edu/psb-online/proceedings/psb00/, abgerufen am 18. Februar 2011. Angles, R. und Gutierrez, C. (2008). Survey of graph database models. ACM Computing Surveys, 40(1). Apache Software Foundation (2004). Apache license, version 2.0. Online, http://www. apache.org/licenses/LICENSE-2.0.html, abgerufen am 22. M¨arz 2011. Apache Software Foundation (2010). Apache Derby. Online, http://db.apache.org/ derby/, abgerufen am 13. M¨ arz 2011. Assenova, Y., Ram´ırez, F., Schelhorn, S.-E., Lengauer, T., und Albrecht, M. (2008). Computing topological parameters of biological networks. Bioinformatics, 24(2):282– 284. Blaschke, C., Andrade, M. A., Ouzounis, C., und Valencia, A. (1999). Automatic extraction of biological information from scientific text: protein-protein-interactions. In Lengauer, T., Schneider, R., Bork, P., Brutlag, D., Glasgow, J., Mewes, H.-W., und Zimmer, R. (Hrsg.), Proceedings of the seventh international conference on intelligent systems for molecular biology, Seiten 60–67. International Society for Computational Biology, AAAI Press. Bloch (2007). How to design a good api and why it matters. Vortrag im Rahmen eines Google Tech Talks. Video, Online, www.youtube.com/watch?v=aAb7hSCtvGw, abgerufen am 22. Dezember 2011. Bloch, J. (2006). How to design a good API and why it matters. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, Seiten 506–507, New York, NY, USA. ACM. B¨ornke, F. (2008). Protein interaction networks. In Junker und Schreiber [2008], Kapitel 9, Seiten 207–232. Brosy, F. (2010). Rekonstruktion biologischer Pathways aus sehr großen Korpora. Diplomarbeit an der Humboldt-Universit¨at zu Berlin.

53

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6):377–378. Crawshaw, D. (2009). SqliteJDBC. Online, http://www.zentus.com/sqlitejdbc/, abgerufen am 8. M¨ arz 2011. Dominguez-Sal, D., Urb´ on-Bayes, P., Gim´enez-Va˜ no´, A., G´omez-Villamor, S., Mart´ınezBaz´an, N., und Larriba-Pay, J. (2010). Survey of graph database performance on the HPC scalable graph analysis benchmark. In Shen et al. [2010], Seiten 37–48. Eclipse Foundation (2004). Eclipse public license – v 1.0. Online, http://www.eclipse. org/legal/epl-v10.html, abgerufen am 22. M¨arz 2011. Ernst, J. (2010). Infogrid – the web graph database. Online, http://infogrid.org, abgerufen am 20. M¨ arz 2011. Federhen, S. (2011). The ncbi taxonomy database. Nucleic Acids Research. Epub ahead ” of print“, Online, http://www.ncbi.nlm.nih.gov/pubmed/22139910, abgerufen am 14. Dezember 2011. Fischer, T. B., Paczkowski, M., Zettel, M. F., und Tsai, J. (2005). A guide to protein interaction databases. In Walker, J. M. (Hrsg.), The Proteomics Protocols Handbook, Kapitel 64, Seiten 753–799. Humana Press. Fowler, M. (2007). Mocks aren’t stubs. Online, http://martinfowler.com/articles/ mocksArentStubs.html, abgerufen am 02. Dezember 2011. Fowler, M. und Parsons, R. (2011). Domain-Specific Languages. The Addison-Wesley Signature Series. Addison-Wesley, 1 Ausgabe. Giuliano, C., Lavelli, A., und Romano, L. (2006). Exploiting shallow linguistic information for relation extraction from biomedical literature. In 11th Conference of the European Chapter of the Association for Computational Linguistics – Proceedings of the Conference, Seiten 401–408. Association for Computational Linguistics. H2 Group (2011a). H2 Advanced. Online, http://www.mysql.com/support/ supportedplatforms/database.html, abgerufen am 13. M¨arz 2011. H2 Group (2011b). H2 license – version 1.0. Online, http://www.h2database.com/ html/license.html#h2_license, abgerufen am 22. M¨arz 2011. He, X., Li, Y., Khetani, R., Sanders, B., Lu, Y., Ling, X., Zhai, C., und Schatz, B. (2010). BSQA: integrated text mining using entity relation semantics extracted from biological literature of insects. Nucleic Acids Research, 38(Supplement 2):W175–W181. Hipp, Wyrick & Company, Inc (2011). Most widely deployed sql database engine. Online, http://www.sqlite.org/mostdeployed.html, abgerufen am 8. M¨arz 2011.

54

Hoffmann, R., Krallinger, M., Andres, E., Tamames, J., Blaschke, C., und Valencia, A. (2005). Text mining for metabolic pathways, signaling cascades, and protein networks. Science’s STKE, 2005(283). pe21. Hoffmann, R. und Valencia, A. (2005). Implementing the iHOP concept for navigation of biomedical literature. Bioinformatics, 21(Supplement 2):ii252–ii258. ECCB/JBI’05 proceedings. Fourth European Conference on Computational Biology/Sixth Meeting of the Spanish Bioinformatics Network (Jornadas de BioInform´atica), Palacio de Congresos, Madrid, Spain, September 28-October 1, 2005. Iordanov, B. (2010). HyperGraphDB: A Generalized Graph Database. In Shen et al. [2010], Seiten 25–36. Jeong, H., Mason, S. P., Barab´asi, A.-L., und Oltva, Z. N. (2001). Lethality and centrality in protein networks. Nature, 411(6833):41–42. Junker, B. H. (2008). Networks in biology. In Junker und Schreiber [2008], Kapitel 1, Seiten 3–14. Junker, B. H. und Schreiber, F. (Hrsg.) (2008). Analysis of biological networks. Wiley Series on Bioinformatics: Computational Techniques and Engineering. John Wiley & Sons, Inc. Kim, S., Shin, S.-Y., Lee, I.-H., Kim, S.-J., Sriram, R., und Zhang, B.-T. (2008). PIE: an online prediction system for protein–protein interactions from text. Nucleic Acids Research, 36(Supplement 2):W411–W415. Larsson, P. (2008). Analyzing and adapting graph algorithms for large persistent graphs. Master’s thesis, Filosofiska fakulteten, Link¨opings universitet, Tekniska h¨ogskolan, Institutionen f¨ or datavetenskap. ISRN: LIU-IDA/LITH-EX-A–08/048–SE, Online, http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-15422, abgerufen am 17. M¨ arz 2011. Maglott, D., Ostell, J., Pruitt, K. D., und Tatusova, T. (2011). Entrez Gene: gene-centered information at NCBI. Nucleic Acids Research, 39(Supplement 1):D52–D57. Malinowski, E. und Zim´anyi, E. (2008). Advanced Data Warehouse Design – From Conventional to Spatial and Temporal Applications. Data-Centric Systems and Applications. Springer-Verlag Berlin-Heidelberg. Mart´ınez-Bazan, N., Nin, J., Munt´es-Mulero, V., S´ anchez-Mart´ınez, M.-A., G´omezVillamor, S., und Larriba-Pey, J.-L. (2007). DEX: High-performance exploration on large graphs for information retrieval. In CIKM ’07: Proceedings of the sixteenth ACM conference on information and knowledge management, New York, NY, USA. ACM. Milgram, S. (1967). The small-world problem. Psychology Today, 1(1):61–67. Neo Technology (2011). The Neo4j Manual. v1.6.M01, Online, docs.neo4j.org/ chunked/1.6.M01/.

55

Oracle (2009). MySQL 5.0 Reference Manual – MySQL Connector/MXJ. Online, http:// dev.mysql.com/doc/refman/5.0/en/connector-mxj.html, abgerufen am 13. M¨arz 2011. Oracle (2011). Supported platforms: MySQL database. Online, http://www.mysql.com/ support/supportedplatforms/database.html, abgerufen am 13. M¨arz 2011. Razick, S., Mora, A., Michalickova, K., Boddie1, P., und Donaldson, I. M. (2011). iRefScape. a Cytoscape plug-in for visualization and data mining of protein interaction data from irefindex. BMC Bioinformatics, 12(388). Rindflesch, T. C., Tanabe, L., Weinstein, J. N., und Hunter, L. (1999). EDGAR: Extraction of drugs, genes and relations from the biomedical literature. In Altman et al. [1999], Seiten 514–525. Online, http://psb.stanford.edu/psb-online/ proceedings/psb00/, abgerufen am 18. Februar 2011. Rodriguez, M. A. (2011a). Gremlin. Online, http://gremlin.tinkerpop.com, abgerufen am 14. Dezember 2011. Rodriguez, M. A. (2011b). The pathology of graph databases. Vortrag auf der WindyCityDB Conference. Video, Online, http://windycitydb.org/videos2011/#1, abgerufen am 7. Dezember 2011. Seal, R. L., Gordon, S. M., Lush, M. J., Wright, M. W., und Bruford, E. A. (2011). genenames.org: the HGNC resources in 2011. Nucleic Acids Research, 39(Supplement 1):D514–D519. Shannon, P., Markiel, A., Ozier, O., Baliga, N. S., Wang, J. T., Ramage, D., Amin, N., Schwikowski, B., und Ideker, T. (2003). Cytoscape: A software environment for integrated models of biomolecular interaction networks. Genome Research, 13:2498– 2504. ¨ Shen, H. T., Pei, J., Ozsu, M. T., Zou, L., Lu, J., Ling, T.-W., Yu, G., Zhuang, Y., und Shao, J. (Hrsg.) (2010). Web-Age Information Management. WAIM 2010 Workshops, volume 6185 of Lecture Notes In Computer Science. Springer-Verlag Berlin-Heidelberg. SQL (1999). ANSI/ISO/IEC 9075-2-1999: for Information Technology – Database Languages – SQL – Part 2: Foundation (SQL/Foundation). ANSI/ISO/IEC. Stapley, B. J. und Benoit, G. (1999). Biobibliometrics: Information Retrieval and Visualization from Co-Occurrences of Gene Names in Medline Abstracts. In Altman et al. [1999], Seiten 526–537. Online, http://psb.stanford.edu/psb-online/ proceedings/psb00/, abgerufen am 18. Februar 2011. Stark, C., Breitkreutz, B.-J., Chatr-aryamontri, A., Boucher, L., Oughtred, R., Livstone, M. S., Nixon, J., Auken, K. V., Wang, X., Shi, X., Reguly, T., Rust, J. M., Winter, A., Dolinski, K., und Tyers, M. (2011). The BioGRID interaction database: 2011 update. Nucleic Acids Research, 39:D698–D704.

56

Temkin, J. M. und Gilder, M. R. (2003). Extraction of protein interaction information from unstructured text using a context-free grammar. Bioinformatics, 19(16):2046– 2053. W3C (2008). SPARQL query language for RDF. W3C Recommendation, Online, http://www.w3.org/TR/rdf-sparql-query, abgerufen am 14. Dezember 2011. ¨ ur, A., Vu, T., Erkan, G., und Radev, D. R. (2008). Identifying gene-disease associaOzg¨ tions using centrality on a literature mined gene-interaction network. Bioinformatics, 24(13):i277–i285. ISMB 2008 conference proceedings 19-23 July 2008, Toronto.

57

B. Die Schnittstellen der Java-API  package info.gehrels.ppi.api;



/∗∗ ∗ An algorithm processing protein−protein−@link{Interaction}s provided as parameter to ∗ {@link #calculateFor(Iterable )}. Since {@link InteractionQuery} implements {@link ∗ Iterable }, one can execute an Algorithm using a {@link InteractionQuery} as parameter, ∗ thus executing the Algorithm on the results of the {@link InteractionQuery} results ∗ ∗ @param The type of the result the algorithm calculates. ∗/ public interface Algorithm { T calculateFor( Iterable interactions); } 



Listing B.1: info.gehrels.ppi.api.Algorithm  package info.gehrels.ppi.api;



/∗∗ ∗ A collection of interaction processing algorithms. ∗/ public interface Algorithms { /∗∗ ∗ @return an @link{Algorithm} counting the number of Interactions found in a given ∗ @link{ Iterable } ∗/ Algorithm numberOfInteractions(); } 



Listing B.2: info.gehrels.ppi.api.Algorithms  package info.gehrels.ppi.api;



/∗∗ ∗ Represents a citation of an {@link Interaction} between to proteins . It provides ∗ information about the document, the {@link Interaction} has been described in, the full ∗ text of the sentence it has been described in and a confidence value. ∗/ public interface Citation {

58

/∗∗ ∗ @return An identifier of the corpus, the {@link Interaction} has ben found in. An ∗ example could be ”PMC” for PubMed Central. ∗/ String getCorpusId(); /∗∗ ∗ @return the ID of the Document, the {@link Interaction} has been found in. It is ∗ given by the creator of the corpus and only unique inside that corpus. ∗/ long getDocumentId(); /∗∗ ∗ @return a confidence value. Confidence values are generated by an automatic ∗ classification system used to determine, if a sentence really describes an {@link ∗ Interaction} between two proteins. If the result is positive , the sentence is ∗ expected to describe an {@link Interaction}. If the result is negative , it is ∗ expected not to describe an {@link Interaction}. If the values ( positive or negative) ∗ are larger , the probability of this expectation to be true should be higher. ∗/ double getConfidence(); /∗∗ ∗ @return the index of the sentence the {@link Interaction} has been found in. It is ∗ relative to the beginning of the document, starting with 0 for the first sentence. ∗/ long getSentenceIndexInDocument(); /∗∗ ∗ @return the text of the sentence, the {@link Interaction} has been found in. ∗/ String getSentenceText(); } 



Listing B.3: info.gehrels.ppi.api.Citation 

 package info.gehrels.ppi.api; import java.util. Iterator ; /∗∗ ∗ Represents an interaction between to {@link Protein}s. It provides the names of the ∗ interacting proteins and a list of {@link Citation}s. Interactions are undirected , that ∗ is , it makes no difference if a proteinName is the first or ∗ the second one. ∗/ public interface Interaction { long getId(); Protein getFirstProtein ();

59

Protein getSecondProtein(); /∗∗ ∗ @return an Interator of {@link Citation}s of Documents, this Interaction has been ∗ described in. ∗/ Iterator getCitations(); long getNumberOfCitations(); } 



Listing B.4: info.gehrels.ppi.api.Interaction 

 package info.gehrels.ppi.api; import org.neo4j.graphdb.Node; /∗∗ ∗ A InteractionFilter can be used define criterias to select a small set of {@link ∗ Interaction}s from a bigger set . Selectors should be used as Parameters of an {@link ∗ InteractionQuery}. ∗ ∗ @see info. gehrels .ppi.api.graphImpl. selectors . interaction . InteractionFilters ∗/ public interface InteractionFilter { /∗∗ ∗ For internal use only ∗/ boolean match(Node node); } 



Listing B.5: info.gehrels.ppi.api.InteractionFilter  package info.gehrels.ppi.api.graphImpl.selectors . interaction ; import info.gehrels.ppi.api. InteractionFilter ; import org.neo4j.graphdb.Node; /∗∗ ∗ Provides static factory methods to retrieve different instances of {@link info. gehrels ∗ .ppi.api. InteractionFilter }. Selectors may be combined using {@link #allOf(info.gehrels ∗ .ppi.api. InteractionFilter ...)} and {@link #oneOf(info.gehrels.ppi.api ∗ . InteractionFilter ...)}. ∗ ∗ There are two kinds of selectors : ∗ Citation based selectors and interaction based selectors . ∗ ∗ Citation based selectors will , if combined using {@link #allOf(info.gehrels.ppi.api

60



∗ . InteractionFilter ...)} evaluated together for each citation of an interaction and will ∗ match, if at least one of the citations matches all of the selectors . That means, allOf( ∗ corpus(PMC), documentId(123)) will match those interactions found in document ∗ PMC:123, not those interactions found at least once in corpus PMC and at least once in a ∗ document with id 123. ∗ ∗ Interaction based selectors will be evaluated independent of the citations per ∗ interaction . If combined with citation based selectors using {@link #allOf(info.gehrels ∗ .ppi.api. InteractionFilter ...)}, the interaction based selectors and the citation based ∗ selectors will be evaluated separately . The {@link #allOf(info.gehrels.ppi.api ∗ . InteractionFilter ...)} selector will match, if both selector groups match. ∗/ public class InteractionFilters { private InteractionFilters () { }

/∗∗ ∗ @return a selector matching only interactions , that match all of the given sub ∗ selectors . Please see the class comment for further details . ∗/ public static InteractionFilter allOf( InteractionFilter ... subFilters ) { return new AllOfInteractionFilter(subFilters); }

/∗∗ ∗ @return a selector matching only interactions , that match one or more of the given ∗ sub selectors ∗/ public static InteractionFilter oneOf(InteractionFilter ... subFilters ) { return new OneOfInteractionFilter(subFilters); } /∗∗ ∗ @return a citation based selector matching only interactions cited in the corpus with ∗ the given canonicalName. ∗ ∗ @see #inDocument(String, long) ∗/ public static InteractionFilter inCorpus(String name) { return new CitedInCorpusInteractionFilter(name); } /∗∗ ∗ @return a citation based selector matching only interactions cited in a document ∗ with the given id ∗

61

∗ @see #inDocument(String, long) ∗/ public static InteractionFilter inDocument(long documentId) { return new CitedInDocumentInteractionFilter(documentId); } /∗∗ ∗ @return a citation based selector matching only interactions cited in the document ∗ with the given id in the given corpus. ∗/ public static InteractionFilter inDocument(String corpus, long documentId) { return allOf(inCorpus(corpus), inDocument(documentId)); } /∗∗ ∗ @return a citation based selector matching only interactions cited at least once with ∗ a confidence value less than the given one. ∗/ public static InteractionFilter withConfidenceLessThan(double confidence) { return new CitedWithConfidenceInteractionFilter(confidence, true, false); } /∗∗ ∗ @return a citation based selector matching only interactions cited at least once with ∗ a confidence value less or equal to the given one. ∗/ public static InteractionFilter withConfidenceLessOrEqualTo(double confidence) { return new CitedWithConfidenceInteractionFilter(confidence, true, true); } /∗∗ ∗ @return a citation based selector matching only interactions cited at least once with ∗ the given value. ∗/ public static InteractionFilter withConfidence(double confidence) { return new CitedWithConfidenceInteractionFilter(confidence); } /∗∗ ∗ @return a citation based selector matching only interactions cited at least once with ∗ a confidence value greater or equal to the given one. ∗/ public static InteractionFilter withConfidenceGreaterOrEqualTo(double confidence) { return new CitedWithConfidenceInteractionFilter(confidence, false, true); } /∗∗ ∗ @return a citation based selector matching only interactions cited at least once with ∗ a confidence value greater than the given one.

62

∗/ public static InteractionFilter withConfidenceGreaterThan(double confidence) { return new CitedWithConfidenceInteractionFilter(confidence, false, false); } /∗∗ ∗ @return an interaction based selector matching only interactions cited less than the ∗ given number of times. ∗/ public static InteractionFilter lessThanNumberOfTimes(long numberOfTimes) { return new CitatedANumberOfTimesFilter(numberOfTimes, true, false); } /∗∗ ∗ @return an interaction based selector matching only interactions cited at most the ∗ given number of times. ∗/ public static InteractionFilter atMostNumberOfTimes(long numberOfTimes) { return new CitatedANumberOfTimesFilter(numberOfTimes, true, true); } /∗∗ ∗ @return an interaction based selector matching only interactions cited exactly the ∗ given number of times. ∗/ public static InteractionFilter numberOfTimes(long numberOfTimes) { return new CitatedANumberOfTimesFilter(numberOfTimes); } /∗∗ ∗ @return an interaction based selector matching only interactions cited at least the ∗ given number of times. ∗/ public static InteractionFilter atLeastNumberOfTimes(long numberOfTimes) { return new CitatedANumberOfTimesFilter(numberOfTimes, false, true); } /∗∗ ∗ @return an interaction based selector matching only interactions cited more than the ∗ given number of times. ∗/ public static InteractionFilter moreThanNumberOfTimes(long numberOfTimes) { return new CitatedANumberOfTimesFilter(numberOfTimes, false, false); } /∗∗ ∗ @return an interaction base selector matching everything ∗/ public static InteractionFilter returnAll() {

63

return new InteractionFilter() { @Override public boolean match(Node node) { return true; } }; } } 



Listing B.6: info.gehrels.ppi.api.graphImpl.selectors.interaction.InteractionFilters  package info.gehrels.ppi.api;



/∗∗ ∗ An InteractionQuery can be used to construct complex queries using fluent interfaces . ∗ Together with the {@link ∗ info . gehrels .ppi.api.graphImpl. selectors . protein . ProteinSelectors} and {@link info ∗ . gehrels .ppi.api.graphImpl. selectors . interaction . InteractionFilters } it forms some kind ∗ of domain specific language for querying protein−protein interactions . ∗

∗ The results of an InteractionQuery can be retrieved by calling {@link #iterator()}. They ∗ will be computed by crawling the interaction network, starting with the proteins matching ∗ the {@link ProteinSelector} defined by calling {@link #startingWithProteinsMatching( ∗ ProteinSelector )}. ∗

∗ There are currently two primary search modes: The default one returns all {@link ∗ Interaction}s being part of a path starting at one of the start proteins . The second ∗ mode, activated by calling {@link #smallWorldGraph()} returns all {@link Interaction}s ∗ being part of a path between a pair of start proteins . In both search modes, only paths ∗ with a length up to the one defined by calling {@link #crawlUpToRadius(long)} will form ∗ the result . ∗

∗ In addition, there is an optional postprocessing stage . It may be activated by calling ∗ {@link #asInducedSubGraph()}. If used, the query will return not only the interactions ∗ computed by the primary search mode, but also all other interactions between two proteins ∗ in the computed subgraph. ∗

∗ An unmodified InteractionQuery will, if executed, compute an empty result as long as ∗ {@link #startingWithProteinsMatching(ProteinSelector)} has not been called. ∗

∗ You can retrieve an InteractionQuery via {@link info. gehrels .ppi.api ∗ . InteractionRepository#query()}. Calling {@link #iterator()} multiple times will start a ∗ new, independent search every time. ∗

∗ A sample Query can look like {@code interactionRepository.query().crawlUpToRadius(2) ∗ .startingWithProteinsMatching(allOf(entrezId(5732), taxonId(9606));} where allOf(), ∗ taxonId() and entrezId() are static factory methods found in {@link info. gehrels .ppi.api ∗ .graphImpl. selectors . protein . ProteinSelectors }. ∗

∗ The results of an InteractionQuery will form a graph consisting of one or more connected

64

∗ sub graphs, each of them containing at least one of the start proteins . Each {@link ∗ Interaction} will be returned at most once. ∗/ public interface InteractionQuery extends Iterable { /∗∗ ∗ Calling this results in the query returning a so called small world graph, a graph ∗ containing only Interactions that are part of a path between two of the start nodes. ∗ The maximum length of this path may be defined by calling {@link #crawlUpToRadius( ∗ long)} ∗ ∗ @return a reference to the instance this method has been called on. Useful for ∗ chained method calls. ∗/ InteractionQuery smallWorldGraph(); /∗∗ ∗ Calling this results in the query returning a so called induced subgraph. In a first ∗ step , the query will be evaluated as if this method has not been called . In a second ∗ step , all those interactions will be added to the resulting graph, that connect two ∗ proteins from the first steps result . ∗ ∗ @return a reference to the instance this method has been called on. Useful for ∗ chained method calls. ∗/ InteractionQuery asInducedSubGraph(); /∗∗ ∗ Define a matcher used to filter interactions while crawling the network. Interactions ∗ not matching the given {@link InteractionFilter } will not be returned by the query ∗ and Crawling will not continue behind this interaction . ∗ ∗ @return a reference to the instance this method has been called on. Useful for ∗ chained method calls. ∗/ InteractionQuery crawlOnlyInteractionsCited(InteractionFilter interactionFilter ); /∗∗ ∗ Define the the number of connected Interactions, including the one the crawling has ∗ started with, up to which the query crawls through the network. ∗ ∗ @param newRadius The radius. Must be grater or equal to 1. Defaults to 1. ∗ @return a reference to the instance this method has been called on. Useful for ∗ chained method calls. ∗/ InteractionQuery crawlUpToRadius(long newRadius);

/∗∗

65

∗ Define a matcher used to select the proteins acting as start nodes for crawling ∗ through the network. If not called . ∗ ∗ @return a reference to the instance this method has been called on. Useful for ∗ chained method calls. ∗/ InteractionQuery startingWithProteinsMatching(ProteinSelector proteinSelector); } 



Listing B.7: info.gehrels.ppi.api.InteractionQuery  package info.gehrels.ppi.api;



import java.util. Iterator ; /∗∗ ∗ An InteractionRepository is the basic entry point of this API. It can be used to retrieve ∗ information about {@link Interaction}s between proteins forming an undirected graph. ∗ {@link Interaction}s can be queried by different criterias , for example a canonicalName ∗ of a protein taking part in the {@link Interaction}. ∗

∗ To query the repository , call the {@link #query()} method to retrieve a {@link ∗ InteractionQuery} object. See the documentation of {@link InteractionQuery} for further ∗ details . ∗

∗ To retrieve all {@link Interaction}s stored by the repository , call {@link #iterator()}. ∗

∗ Every InteractionRepository has to be closed before stopping the JVM. ∗/ public interface InteractionRepository extends Iterable { /∗∗ ∗ Closes and frees all resources being held by this InteractionRepository . This method ∗ has to be called before shutting down the JVM, otherwise it is not guaranteed, that ∗ the Interaction repository will still be usable the next time an ∗ InteractionRepository gets instantiated . ∗ ∗ An instance of this Interface must not be used after close has been called . ∗/ void close (); /∗∗ ∗ Initializes and returns an {@link InteractionQuery}. If executed, an unmodified ∗ {@link InteractionQuery} will return an empty result. An {@link InteractionQuery} ∗ can be used to construct complex queries using fluent interfaces , thus providing some ∗ kind of domain specific language for querying protein−protein interactions . ∗ ∗ @return a new {@link InteractionQuery} returning an empty result, if called .

66

∗/ InteractionQuery query(); /∗∗ ∗ This method can be used to retrieve all {@link Interaction}s contained by this ∗ InteractionRepository . ∗ ∗ @return An {@link Iterator} of {@link Interaction}s ∗/ @Override Iterator iterator (); /∗∗ ∗ Provides access to various interaction network processing algorithms. ∗/ Algorithms algorithms(); } 



Listing B.8: info.gehrels.ppi.api.InteractionRepository  package info.gehrels.ppi.api;



import java.util.Set; /∗∗ ∗ Represents a {@link Protein}s. A Protein is uniquely identified by its Entrez Id. It ∗ provides the names of the interacting proteins and a list of {@link Citation}s. ∗ Interactions are undirected , that is , it makes no difference if a proteinName is the ∗ first or the second one. ∗/ public interface Protein { int getEntrezId(); /∗∗ ∗ @return the id of a member class in the NCBI taxonomy associated with this protein. ∗/ int getTaxonId(); /∗∗ ∗ @return The canonical name of the protein as defined by the HUGO Gene ∗ Nomenclature Committee. May be null, if no name has been defined. ∗/ String getCanonicalName(); /∗∗ ∗ @return The names of the protein, exactly as the have been found in the corpus. ∗/ Set getNames(); }

67





Listing B.9: info.gehrels.ppi.api.Protein  package info.gehrels.ppi.api;



import org.apache.lucene.search.Query; /∗∗ ∗ A Selector can be used define criterias to select a small set of Proteins from a bigger ∗ set . ProteinSelectors should be used as Parameters of an {@link InteractionQuery}. ∗ ∗ @see info. gehrels .ppi.api.graphImpl. selectors . protein . ProteinSelectors ∗ @see InteractionQuery#startingWithProteinsMatching(ProteinSelector) ∗/ public interface ProteinSelector { /∗∗ ∗ For internal use only ∗ @return a Query ∗/ Query getIndexQuery(); } 



Listing B.10: info.gehrels.ppi.api.ProteinSelector  package info.gehrels.ppi.api.graphImpl.selectors . protein ; import info.gehrels.ppi.api. ProteinSelector ; /∗∗ ∗ Provides static factory methods to retrieve different instances of {@link ∗ ProteinSelector }. ∗/ public class ProteinSelectors { private ProteinSelectors() { } /∗∗ ∗ @return a selector matching only proteins having exactly the given canonicalName ∗/ public static ProteinSelector canonicalName(String proteinName) { return new ByCanonicalNameProteinSelector(proteinName); } /∗∗ ∗ @return a selector matching only proteins having exactly the given canonicalName ∗/ public static ProteinSelector name(String proteinName) { return new ByNameProteinSelector(proteinName); }

68



/∗∗ ∗ @return a selector matching only proteins of the given taxonId ∗/ public static ProteinSelector taxonId(int taxonId) { return new ByTaxonIdProteinSelector(taxonId); } /∗∗ ∗ @return a selector matching only proteins having the given entrezId ∗/ public static ProteinSelector entrezId(int entrezId) { return new ByEntrezIdProteinSelector(entrezId); } /∗∗ ∗ @return a selector matching only proteins, that match all of the given sub selectors ∗/ public static ProteinSelector allOf(ProteinSelector ... proteinSelectors ) { return new AllOfProteinSelector(proteinSelectors); } /∗∗ ∗ @return a selector matching only proteins, that match one or more of the given sub ∗ selectors ∗/ public static ProteinSelector oneOf(ProteinSelector ... proteinSelectors ) { return new OneOfProteinSelector(proteinSelectors); } /∗∗ ∗ @return a selector matching no proteins ∗/ public static ProteinSelector nothing() { return new EmptyResultProteinSelector(); } } 



Listing B.11: info.gehrels.ppi.api.graphImpl.selectors.protein.ProteinSelectors

69

C. Abschließendes Ich erkl¨are, die vorliegende Arbeit selbstst¨andig und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt zu haben. Ein ganz herzlicher Dank gilt Prof. Dr. Ulf Leser, Philippe Thomas und Andr´e Koschmieder f¨ ur die hervorragende Betreuung sowie Anja Kunkel f¨ ur ihr unerm¨ udliches Finden verdrehter Buchstaben, verdrehter Formulierungen und vergessener Kommata sowie die immer wiederkehrende Motivation.

Berlin, der 27. M¨ arz 2012 Benjamin Gehrels

70