Towards a visual query interface for phylogenetic databases

Towards a Visual Query Interface forPhylogenetic Databases

Hasan M. Jamil Giovanni A. Modica Maria A. TeranDepartment of Computer Science Department of Computer Science

Mississippi State UniversityDepartment of Computer Science

Mississippi State University Mississippi State University

[email protected] [email protected] [email protected]

ABSTRACTQuerying and visualization of phylogenetic databases remaina great challenge due to their complex tree type semi struc-tured nature. Naturally, successful phylogenetic databasessuch as the ‘I& of Life database at the University of Ari-zona are implemented as Web documents in HTML. WhileWeb implementation of such databases facilitate the repre-sentation, and in part, visualization of their contents, query-ing remains an issue. The interoperability of Web-basedphylogenetic databases with other similar databases such asTreeBase and RDB which are implemented using traditionaldatabase management systems, has not been possible due tothe impedance mismatch between the underlying query anddata representation framework. In this paper, we present anovel approach to phylogentic database management usingexisting database technologies without compromising poten-tial opportunities for visualization and interoperability. Wepresent a Web-based tool for the creation, querying and vi-sualization of phylogenetic databases. We demonstrate thefunctional capabilities and strengths of our system by recre-ating the Dee of LZje database in our system and perform-ing queries that are not possible in the original Tree of Lifedatabase.

KeywordsPhylogenies, tree and semi structured data, visualization,query language, information retrieval, relational database,w e b

1. INTRODUCTIONResearch into genomics is producing an unprecedented

amount of data. Consequently, we are witnessing a prolifer-ation of databases or data repositories all around the world.These databases allow the researchers to access and analyzedata with the tools they support. New, more accurate, andmore efficient tools and techniques are being developed toanalyze, interpret and investigate these data. In order to be

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.CIKM’OI, November 5-10,2001, Atlanta, Georgia, USA.Copyright 2001 ACM l-581 13-436-3/01/0011...$5.00.

useful, these data must be indexed and stored, which leads tothe issue of effective data analysis and abstraction that stillposes a formidable challenge. From this point of view, thecreation and development of advanced database technolo-gies for storage, curation, retrieval and analysis of biomedi-cal data has become extremely important in all biomedicaldisciplines. As genomics and biology become more of a datadriven science rather than the traditional workbench andtest tube based discipline, new developments will both gen-erate and require volumes of data far more vast than whatthese fields are currently prepared to utilize and assimilate.Thus, it behooves us to prepare for envisioned challenges bypreparing a technological base which is equipped to handlesuch rich and new data with their own unique requirementsand limitations.

Closely aligned to genomics, a relatively new discipline,phylogenetics (the science of studying structural and behav-ioral relationships of organisms), has been instrumental indiscovering new relationships and explaining unknown sci-ence, and is becoming increasingly popular as the study ofphylogenies often bear directly on basic understanding inmolecular biology or of human health issues. For exam-ple, phylogenetic techniques have been used to trace con-tact histories for infectious diseases [14, 51 and identify ge-ographic origins of new outbreaks, as in the case of WestNile Virws [15], and even the timing of new introductions[7], suggesting their broad explanatory power in epidemiol-ogy [l]. Phylogenetic trees depict the hierarchical pattern ofcommon ancestry of species, genes, sequences or other enti-ties (taxa). These trees capture information that are vitalin the analysis of molecular sequence variations. In order tostudy phylogenies and to explore their predictive properties,large-scale tree databases have been created using variousformats (e.g., fieeBnse [3], Tree of Life [8], RDB [9], GreenPlant Phylogeny Research Coord&ntion Group [4]). At thesame time, work is advancing on the synthesis of extremelylarge phylogenetic trees from these large scale databases ofsmaller trees. The quality of diagnostic predictions stronglydepends upon the completeness of a set of samples of a par-ticular group of organisms or genes, and the correctness ofthe connectivity information between the taxa. Therefore,precise navigation and querying tools to interact with thetree structures and the structure of relationships betweentrees is critical.

Past experiences with genomic and phylogenetic reposi-tories and the tools for accessing and analyzing the dataduring the last decade or so serve as important lessons forprofessionals working with these dynamic fields. In the light

57

of the observations and recommendations made in the doc-uments [13, 121, with a few not so notable exceptions, theexperiences can be portiolly summarized as follows:

. Accessing data through Web-based forms are limitingand often frustrating simply because they do not allowqueries outside the scope of the interface, and becausethey force the ose~s to follow too many predelined nav-igational steps or pointen.

l The lack of a suitable query language for genomic orphylogenetic databases acts as a barrier in extract-ing biomedical information from various databases ina flexible way.

. It is simply impossible to make databases interopwa-ble because developing the te&nologV (such as middlelayer, wrappers, mediators, etc.) are either too expen-sive or too complicated.

In this paper, we address the issoe of representing, qoery-ing and visualization of phylogenetic database using tra-ditional technologies. Specifically, we aim to answer thequestion if such databaes can be developed in conventionalways (perhaps with extensions) without compromising thevisualization and browsing aspects of their vast contents,features that biologists find useful and attractive. We an-swer positively by developing a mapping of the University ofArizona’s acclaimed ‘Dee of Life Web-based database to atraditional database and by developing a W&based graph-ical query interface that uses SQL and a relational databaseas underlying query and storage engines. The resulting syctern is more robust, and sopports enhanced visualization andimproved query capabilities. It also now m&x it possibleto interoperate other genomic and phylogenetic databaseswith our database exploiting existing techniques for inter-operability of relational databases.

1.1 Paper OrganizationThe remainder of the paper is organized as follows. In

section 2, we introduce of the Pee of Life database alongwith a discussion of its structure and properties that serveas the representation and querying requirements of OUT tar-get database. The mapping process is presented in section3 followed by a discussion on design issues and systems a-chitecture in section 4, and a description of the systems im-plementation in s&ion 5. We present some performancerealts related to the mapping of the ‘I% of Life databasein section 6 before we summarize our discussion in section7 .

2. THE TREE OF LIFE DATABASE‘Ike of Life (TOL) is one of several recently created phylo-

genetic databases at the University of Arizona for the studyof phylogenies and evolution of organisms. Unlike most ofits siblings, TOL is Web-based and thus, can be queriedonly by means of Web search engines. It also provides ahierarchical structure that a user or a crawler could navi-gate one node at a time. Rnearchers in various part.s ofthe world contribute to this database by remotely adding asub tree in the form of an HTML document. All nodes axreviewed by the peers for correctness and accuracy, and areconnected via byperlinks rooted at the TOL home page atthe University of Arizona.

Figure 1: !fke of Life database tree hierarchy andnode structure.

The TOL database structure is essentially a huge hierar-chical tree of hyperlink connected Web documents. Eachdocument in the hierarchy can be considered as a node ofthe tree that follows a loosely delined format. Every childnode is a sub group and a specialization of a living organismof the parent node. For example, the species Homo Sopt-ens is a child node of genus Homo, which is a child node ofthe family Hominidae, and so on. In other words, these areordered from kingdom to species with intermediate classes,namely, phylum, class, order, family and genus. However,the actual classification is more elaborate and often-timesdebated (because archaeological and genomic evidences of-ten suggest contradictory classifications). We will discusssome of the representation details and the influence of theclassification scheme on the representation shortly.

The nodes in the TOL structure are classified in the fol-lowing four categories as shown in figure I, i.e., trunks,bronehes, lichens, and leaves. The trunk and branch pagesare similar except that a branch page contains the leaf pages.Usually, a branch page contains information for a paticu-lax class of organism such as Metazoa, or Homo, etc., andmay have links to the sub tree rooted at that class. On theother hand, the trunk pages usually contain links to severalbranch pages. Lichen is a specialization of a class at anylevel that leads to a species that can be reached directlyfrom that page. In other words, a lichen page is a node thatdescribes a species of a given class.

Navigation through the entire structure is facilitated withseveral buttons in every page. Users can visit the nodes ofthe tree by clicking these buttons to reach the next taxon,the previous taxon and to dive down to the immediate lowernode in the classification (the down button) hierarchy or tothe parent class (the deep button). Note that there may beseveral intermediate nodes between a class and its parentclass.

3. MAPPING TOL STRUCTURES TO A RE-LATIONAL DATABASE

The HTML document format of every page and its con-tents provide enough information for the design of a map-ping function from TOL to a relational database. In general,every page contains pictures of species belonging to thatclass, the sub tree under that class (only one level deep),references to documents that are relevant for that class, dis-cussions, and other relevant information and links.

================================_2=========== porlfe:a (sponge

I ======~===============L_=T_=_========== Cnidarla (jellyf

I

I I =====================_==I= = ==== Ctenoohora (comb

I II I

node divisions=====I Xrthrcipcda (lnse

=== j ====e Qr.vchophnr,~ (“el

I I I I Iroot ======I , =====I) zz==== TardiQr& (wate

II IIII II ====== Ancelida (segmen

II II..<--=I 1 1 I

II IIII II

Figure 2: Textual representation of a tree in a page.

The mapping process is divided into several steps and in-volves a mixture of manual and automated activities. Inthe following sections, we discuss two major components ofthese steps.

3.1 Understanding TOL Page StructuresBefore we can proceed to map the TOL database into

a relational structure, it is necessary to recognize the pagestructure of every node and develop an accurate understand-ing so that a relational structure can be designed based onthe page template.

As mentioned previously, in addition to several descrip-tive information, each node page contains a textual diagramof the one level deep sub tree rooted at that node. An ex-ample of such a tree is shown in figure 2. Since these aretrees represented using text, it is difficult for any existingautomated agent to understand the structure. It is how-ever possible to identify important regularities in such treesand develop a specialized agent for automated mapping. Forexample, a root is denoted by the symbol ‘cc==‘, and its chil-dren are denoted by line drawn with symbols ’ I ’ that leadsto branches represented with lines drawn with the symbol‘=‘. Every branch is labeled (marked as leaf in figure 2) andpotentially is a hyperlink.

The structures represented in such trees have special sig-nificance that must be preserved, e.g. all the branches havethe same parent, but ‘closeness’ of branches are determinedby their position in the tree. Consider the sub tree shownbelow rooted at node X (node X not shown). In this treethere are four nodes (leaves) A, B, C and D, all children ofnode X. However, nodes B and C are at a lower level thanthe nodes A and D. Hence, the similarity between B and Care higher than that between A and B. This ‘closeness’ ismaintained in the tool, as we describe later.

The tree structure in each page is described using HTMLpre tags, thus it is identifiable. The algorithm we have de-veloped, presented below, plays a critical role in developinga complete and automated mapping process. Any identified

tree can be processed using this algorithm to construct anactual Java JTree tree structure.

Algorithm 1. Text2TreeConverterInput: text describing the tree to convertOutput: a JTree tree structure

JTree Text2TreeConverter(String text)I

matrix=buildMatrix(text);root=findRoot(matrix);tree=new JTreeO;buildTree(root,matrix,tree)return(tree);

JTree buildTree(root,matrix,tree)I

//identify all the branches of the rootbranches[l=findBranches(root,matrix)for(every branch in branches[I)tree.addChild(buildTree(branch,matrix,tree))

As the reader can see, to build a tree we fist need to createa matrix containing all the characters in the text. Usinga matrix, we can move around the tree using coordinateslike x and y, or columns and rows. The building of thematrix is straightforward, all the lines (separated by end-of-line characters) in the text are mapped to a separate rowin the matrix, and in order for the matrix to have the samenumber of columns for each line, we calculate the longestline and pad the others with spaces until the length of allthe lines reach the length of the longest one.

Now we can identify the root in the first column using thecharacter < (or = in the case of the root of all the trees).The root is expressed using coordinates (x, y). We startbuilding the tree recursively identifying the branches for theroot first and then treat each branch as a new root for asubtree. In general, is natural to use recursive algorithmswhen working with trees. We will see that in order to storea tree in a database we will also use a recursive algorithm,as explained later. To identify the branches we use the Icharacter and then we move along the vertical axis in thematrix trying to identify new nodes. The process ends whenwe reach a leaf (identified by a = character and then a space,as shown in figure 2).

3.2 Crawling the TOL StructureUsing the algorithm presented in the previous section as

a backbone, a Web crawler is developed to parse the TOLstructure and gather necessary information to construct therelational structure. As the structure is crawled, pertinentinformation is stored in a relational database with the struc-ture shown in Figure 3. In this figure, the primary keys areidentified using bold letters. The schema contains four ta-blespage1nformati.q page, pageReference, and treelode.The relationship cardinalities among these tables is shownbelow.

The description of the tables are as follows. The tabletreeNode in Table 1 represents a node of the tree. ThenodeID attribute is the primary key, the name represents thename of a group, the description is the example species ofthe organism that belongs to this node (class) and parentIDis a foreign key to the table treeNode itself that representsthe parent of this node. Hence, these relationships are re-cursive, since a parent of the node is another node in thetree.

5 9

Figure 3: ER Diagram for the relational structure.

Table 2 shows the scheme for the table page. This ta-ble has all the information pertaining to a page in the TOLdatabase. The pageID attribute is auto generated and iden-tifies the page as its primary key. The url attribute is theweb address where this page is located, title and subtitledescribe the name of the group and example organism, treeis a foreign key to the treeNode table and relates to the in-formation of the node, treeText stares the tree informationcontained in this page, pageText stores the characteristicsand information of the group and the about records infor-mation such as the page creation date, the creator of thepage, etc.

The page~nfomation scheme is shown in Table 3. Inthis table, information related to links that have additionalinformation about a specific class is recorded. The primarykey of this scheme is the attribute informationID. pageIDis a foreign key to the table page, and the informationattribute represents the title of the information content.

The scheme of the last table page%leference is shown inTable 4. This table contains the references contained ina page. A page may contain several references. In thistable, referenceID is the primary key while pageID is theforeign key to the table page where it has been cited. Finally,reference is the explicit reference text.

Once the information is stored in the database, a suit-able user interface can be developed for usem to query and

Table 2: Relational scheme of the page table.

about string I J

Table 3: Relational scheme of the pageInformationtable.

Name TYW CO”l”le”tinformationID l o n g i n t e g e r PKpagem long integer FK topage.pageIDinformation string

Table 4: Relational scheme of the pageReference ta-ble.

Name TYW CommentreferenceID long i n t e g e r PKpage10 long integer FKta page.pageIDreference string

visualize its contents. We will address this issue in a latersection.

4. SYSTEM ARCHITECTURE ANDDESIGN ISSUES

The architecture for our system is presented in Figure 4.The major components in our system are the modules Pmp-erty Identi~catwn Module and the Navigation Module. Theother two modules are Vtsaalizntion Module and DatabaseManager. We now present a brief discussion on each of themodules .

4.1 Navigation ModuleThe navigation module is composed of two agents reapon-

sible for the interaction between the system and the Inter-net. The first agent, the page retriever, is responsible farestablishing network connections for a given URL. The pageretriever is also responsible for building appropriate URLsbased on relative “RLs found in the pages, i.e., if a page hasa relative (local) URL as a link then the page retriever agentwill use the page information (base tags and page domain)to build an absolute URL. When a network canncction isestablished, the agent starts retrieving the HTML text fromthe page. The page retriever agent is also used to auto-matically navigate through the hierarchical structure of thepage to follow links to the internal pages in the web site pmvided by the eztemol link identi,5catdon agent. Because thenumber of links to crawl usually grows exponentially to thecrawling depth, the page retned agent must be limited onlyto crawling pages in the application domain using a prede-fined crawling (which is implemented as a system propertythat can be adjusted, if necessary, as shown in figure 5).

The second agent, the &mud link identijication agent,uses a DON (Document Object Model) structure to iden-tify external links to other pages in the application domain(identified by attributes in the HTML code). In general, allthe leaf nodes in a sub tree contain links to other sub trees(other pages) in the TOL structure. All these links are en-capsulated as a list of new pages that will be passed to thepage retriever so that the contents of the new pages can beretrieved and parsed.

4.2 Parsing ModuleOnce the page contents are retrieved, the parsing module

is activated. The parsing module contains an HTML parserthat is able to identify the different HTML tags and their

60

__------ l'-------Navigation Module 1 1 Parsing Module

HTMLP a r s e r

1

DOM TreeStrudure

I

Database Manager

Property Identification Modules Visualization Module-J L-------------J

Figure 4: System architecture.

contents, and to map the HTML page into a tree calledthe DOM (Document Object Model) tree. This tree struc-ture is described in W3C standard (21 and is used to de-scribe the structure of an HTML page. The use of DOMstructure and construct greatly simplifies the identificationof the elements in an HTML page. While there are severalHTML parsers available, most of them are designed to parseXHTML/XML documents and thus cannot be used to parsethe TOL database HTML pages since most of these docu-ments are not well formed, a critical requirement for thosetools to be effective [lo]. However, HTML Tidy, also a W3Cstandard [2] tool can ignore such discrepancies and is usedin our system. In addition to the parsing and creation ofa DOM structure, HTML Tidy is able to identify and fix mostof the common problems present in HTML pages such asomission of closing tags when required, etc. Another goodfeature of HTML Tidy is that it can use any parser as long asthe parser is able to produce a DOM structure that representsthe page (most of the parsers do).

Table 5: Submodules for identification of page prop-!I-

rE ties.

Module PropertyPage Title/Subtitle The title and optionally, a subti-

tle (e.g. title: Animals, subtitle:Metazoa)

Additional Info Every page has an “AdditionalInfo” section with external linksin the web

Tree Identification This submodule identifies thetext that describes the tree for

tion with information about the

section with references used by

4.3 Property Identification ModuleThe property ident$cataon module receives a DOM struc-

ture representing a specific page and identifies its attributes(title and references, metadata contained in the page, etc.)as well as page information such as description of the speciesrepresented in the page, family, descendents in the taxon-omy, etc. This module is comprised of specific submodules,each of which is responsible for the identification of a specificproperty in the page. The use of an array of sub modulessupports extensibility in case new properties that are notcurrently supported need to be recognized. Our system cur-rently supports five sub modules for the identification of thefollowing five properties listed in Table 5.

module, the query interface of our system. The primaryfunction of the visualization module is to provide the userwith a graphical representation of the pages and the illusionof the TOL structure. The query interface is shown in thefigure 6 in section 5.

The input to the sub modules is a DOM structure createdby the parsing module for a page. These sub modules usethe tag template presented in table 6 for the identificationof specific properties in the page.

There are basically two choices in mapping and query-ing the TOL database. In our application, we have usedour crawler to map the TOL database offline and store allthe information in the relational database for efficiency rea-sons. In this way, the querying of the relational databaseis extremely fast. The compromise is that the currency ofinformation is lost in the event of an update in the sourceTOL database, a common, albeit rare, practice. Our otheroption was to crawl the pages at query time and store theinformation as we crawl. In this way, the mapping could bedone at query time. As we need to map the entire databasein any event, an ofhine retrieval seemed logical.

4.4 Visualization Module 4.5 Database ManagerUsers interact with the system through the visualization The database manager module is responsible for inter-

61

Table 6: Template for property identif ication based0” HTML tags.

Property HTML TagTrEe <p-e>References <pm>Title <h2>Subtitle <h3>Section boundaries Between two <hr> tagsLinks < a >

acting with the data repository used to store the mappedinformation. The database manager makes use of the JDBCwrappers supported by Java to abstract the database op-erations from the type of database in use. The dotobasemonnger module has two sub modules: Stom/Rettieue tostore and retrieve the pages parsed, and the Query Men-ager to handle queries against the data repository using thequery forms in the query interface. The query mnnnyer isjust a general module that receives as input an SQL queryand returns the results using a multicolumn table that islater displayed by the tisual&ation module. The databasemanager uses the relational structure described in section 3as the database schema to store the page information.

5. SYSTEM IMPLEMENTATIONThis section addresses issuea related to the systems imple-

mentation. We present a brief discussion about the languageand platforms used to develop and deploy the tool, as wellas some details about the main two structures used by thetool: the DO” and the TreeOfLifePage structures. We alsoexplain same of the features presented in the tool like theconfiguration panel (to configure database accea and inher-ent addresses to the source of the information) and the querymanager (to perform queries against the data collected).

5.1 Language and PlatformThe tool was developed in Java for portability, abundant

predefined library and tool support, and because Java supports better abstraction capabilities. As an example, weused libraries such as the util library for container strut-tures like vectors and dynamic arrays, the BWT and Swing li-braries for GUI development, and JDBC library for databaseaccess, to name a few [ll]. The choice of Java was also mo-tivated by the fact that future versions of the system maynow include the same functionality in a Java Applet so thatwe can run the system from any Java-enabled web browserlike Netscape or Microsoft Internet Explorer.

5.2 Data StructuresThe two most important data structures used are the OOH

structure and the TreeOfLifePage structure, also identifiedin figure 4. As already mentioned in a previous section, theo0n structure is used by the parsing libraries to reprnent anHTML page as a hierarchical tree structure. The templatein table 6 is used in conjunction with the DOM structure toanalyze and understand a page according to its structure,and use its contents as needed.

The DON structure is based on a lode structure, repre-senting all the nodes in the hierarchy. HTML tags are rep-resented by Element structures (a subclass of Node). Thelibrary to manipulate DOH structures allows identifying all

Figure 5: Configuration options available to the“Ser.

the tags in the page by name, and for an Element to retrieveits children, or its attributes, as well as the text containedinside a tag (like in the case of the p tag) [lOI.

The second structure, the TreeOfLifePage structure isused to store all the parsed information relevant to a page. Itresembles the database structure presented in section 4. Thestructure contains data members for each property modeled,and in the case of multivalued attributes like references (apage can contain multiple references) and additional infor-mation, it contains dynamic arrays for storing these prop-erties. It is worth noting here that the TreeOflifePagestructure contains a reference to a TreeDfLifeNode strut-tare that represents the root node for the tree described inthe page. This node structure contains data fields to de-scribe each node in the tree, including the node name, adescription, and a URL (in case of leaf nodes that point toother pages in the TOL structure).

The TreeOfLifePage structure uses a set of utility meth-ods to maintain the structure. Methods like saveToDB andretrieve~romm are used by the database manager to storeand retrieve a page to/from a database while the meth-ods addInior,nation and removeInformation are used toadd/remove information found in the “Additional Informa-tion” section of each page. The methods addReference andremove~eference are used to add/remove references foundin the ‘“References” section of each page. The structure alsoprovides methods to retrieve the set of links present in thetree to be used as input to the navigation module to crawlthe tree.

5.3 System Configuration PanelIn order to make the system independent of the underlying

data structure and database management system, a set ofconfiguration options are supported that allows it to connectto ahnost any database manager that supports JDBC. If thedatabase is changed, all the usem need is to specify the newdatabase in the configuration options as shown in Figure 5.

For systems with support for ODBC drivers (such as in thecase of Microsoft Windows OS), the user only needs to spec-ify the ODBC driver configured for database access in theconnection string field, and the ODBC driver takes care ofthe details regarding security, type of connection, databaseserver, etc. Of COUISZ, the user can also specify these pa-ramete~~ as part of the connection in the appropriate fields.

For general options the user can specify the crawling depthused by the navigation module to retrieve new pages for

62

parsing. Due to the potential exponential growth of thetree structures on the Internet, including the in the Dee ofI,jJe datahwe, we suggest using of a low depth. Otherwise,depending on the type of connection, the process to buildthe complete tree can be extremely slow. The user can alsomodify the starting point (i.e. the root of the tree) allowingthe construction of partial trees. For example, to build onlyone branch of the tree of depth six, the user may first builda complete tree up to a depth of three (by specifying crawldepth to be three), selecting only the branchn at depththree that are of interest, and then building three more levelsfrom it.

5.4 Query ManagerOne of the main goals for this project is to provide the user

with extended query capabilities not present in the originalsource of the phylogenetic tree. The tool provides to theuser with query and browsing capabilities ar, explained inthis section. The user interface allows the user to performqueries using different attributes of the page. Currently, fourtypes of queries can be performed in this interface: selectionof pages using (i) the title of the page, (ii) the URL of thepage, (iii) my keyword in the page text, and (iv) the id ofthe page in the database. Queries of type (i) and (iii) usesubstring searches, and multiple strings are ANDed togetherto constrain the selection. If the query is saccezsful, i.e.at IeaSt one page meets the conditions specified, the querymanager constructs a list of page IDS identifying the pagesdisplayed as hot links. The user can browse the informationin each of these links by clicking the page ID needed. Whenthe user selects a page ID, a new TreeOflifePage structureis created, and its contents retrieved from the database usingthe database manager module. The page is then displayedin the user interface for the user just like a web document.

Additional information about the query capabilities forthis tool can be found in [I?], where a the framework for agraphical query language is defined to query tree databases(specifically, phylogenetic databases like the % e of Lifedatabase described in this paper).

5.5 User InterfaceThe interface is developed using entirely the Java Swing

UI library. As shown in figure 6, the interface is divided indifferent panels with multiple tabs to organize different in-formation to be presented to the user. Most of the elementspresent properties (e.g., nodes in the tree) that the user cansee using the properties panel. Figure 6 also depicts howthe information is stored in the database, how the queriescan be performed, and the how results are viewed. It is alsopossible to inspect/query the underlying database and itsmeta data. The ueer can also use the address bar to type ina “RI,, parse it, and inspect its structure, if needed.

6. SYSTEM VALIDATIONWe have tested our system on SUN Solaris and PC Win-

dows ZOOO/Millenium Edition. We were able to successfullyrun the system in both these platforms without any need forcompilation of either system. We have used three differenttypa of database management systems such as MicrosoftAccess, Microsoft SQL Server and Oracle 8i with this sys-tern without any complication.

As the graph in Figure i’ shows, the time required to parseand map the TOL structure increases quite dramatically

Figure 6: System/User Interface for TOL RelationalDatabase.

mmr~.0.m

Figure 7: Time VS. Depth (56K & Tl).

with the increase in crawl depth. The mapping performancefor a 56K and a Tl Internet connection on Microsoft AccessDBMS are shown for multiple crawl depth. The numberof pages parsed and mapped at each depth is also shown.Notice that the number of pagee parsed is a constant for agiven crawl depth.

I. SUMMARY AND FUTURE WORKWe have presented a system for mapping Web-based phy-

logenetic databases into regular relational databases so thatthey can be queried using improved database query capabil-ities, yet, can be visualized using graphical interfaces suchas the Web. We believe that the framework presented inthis paper can be generalized to map most such databasesfor the purpose of interoperability and scientific analysis.

Since XML is increasingly becoming a language of choicefor many applications, our current research is focused ondeveloping a mapping technique for phylogenetic databases

63

into XML. The main idea is as follows. We are working ondeveloping a simple DTD schema that will match the ERmodel presented in previous sections, enabling us to mapthe phylogenetic information in to XML structures:

<?xml version="i.O" encoding="UTF-8"?><!ELEMENT phylogeny (page)><!ATTLIST phylogenyname CDATA #REQUIREDurl CDATA #REQUIREDdescription CDATA #IMPLIED><!ELEMENT page (treeText, pageText?,about, reference*, information*, page*)>

<!ATTLIST pageurl CDATA #REQUIREDtitle CDATA #REQUIREDsubtitle CDATA #IMPLIEDdescription CDATA #IMPLIED><!ELEMENT treeText (tPCDATA)><!ELEMENT pageText (#PCDATA)><!ELEMENT about (#PCDATA)><!ELEMENT reference (tPCDATA)><!gLFmNT information (*PcDATA)>

As an illustration, we present below an XML fragmentthat encodes the first two levels of the Tree of Life database:

<?xml version="l.O" encoding="UTF-8"?><!DOCTYPE phylogeny SYSTEM "phylogeny.dtd"><phylogeny name="lhe Tree of Life"url="http://phylogeny.arizona.edu/tree/life.htm~'><pageurl="http://phylogeny.arizona.edu/tree/lifa.html"title="lhe Tree of Life Project Root Page">

<treeText>...</treeText><pageText/><about>David R. Maddison</about><page url="eubacteria.htm1"

title="Eubact.eria"description="'True bacteria", mitochondria...'><treaText>...</treeText><pagaText>...</pageText><about>Gary J. Ulsen</about>

</page><page url="archaea.html"title="Archaea (Archaebacteria)"description="Methanogens, Halophiles, . .."><treeText>...</treeText><pageText>...</pageText><about/>

</page><page url="eukaryotes.html"title="Eukaryotes (Eukaryota)"description="Protists, Plants, Fungi, Animals, etc."subtitle="Organisms with nucleated cells">CtreeText>...(/treeText><pageText>...</pageText><about>David J. Patterson</about>

</p=ge></page></phylogeny>

Once the phylogenetic tree is converted to XML, we willbe able to perform more advanced queries using XML querylanguages like XQL and XPath expressions, or even XSLtemplates for advanced display and formatting [2]. As an ex-ample, an XPath expression to retrieve nodes with title ‘An-imals’, at any level, would be: //pageCQname=‘Animals’l.We are also working on a API for advanced query capabili-ties, some of the API commands include the parent 0 andchild0 to query for direct hierarchy relationships in the

tree, as well as the predecessoro, succesor0 and root 0commands for indirect hierarchy relationships.

However, the system presented in this paper is a part ofa larger project at Mississippi State University that aimsat developing a framework for interoperability of genomicand phylogenetic databases. As a next step to this project,we plan to develop a language for phylogenetic databases,called the phylogenetic query language (PQL) to query treestructured data and their intricate properties. A preliminaryreport on this language may be found in [S].

8.PI

R E F E R E N C E S

PI

131

[41

[51

PI

[71

PI

S. N. e. a. C. Holmes, Paul Bollyky. New Uses for NewPhylogenies, chapter Using phylogenetic trees toreconstruct the history of infectious disease epidemics,pages 169-186. Oxford University Press, 1996.W. Consortium. Internet Address:http:://www.w3.org.B. P. et al. TreeBASE. Internet Address:http://herbaria.harvaxd.eclu/treebase.G. P. P. Ft. C. Group. Deep Green. Internet Address:http://ucjeps.berkeley.edu/bryolab/greenplantpage.html.D. M. Hillis and J. P. Huelsenbeck. Support for dentalHIV transmission. Nature, 369:24-25, 1994.G. M. Jamil Hasan and M. Teran. Queryingphylogenies visually. In Proceedings of the SecondIEEE BIBE Symposium, 2001.G. F. G. e. a. K. McGuire, E. C. Holmes. Tracing theorigins of Louping Ill virus by molecular phylogeneticanalysis. Journal of General V+ology, 79:981-988,1998.

PI

PO1

PI

WI

[I31

1141

P51

D. Maddison and W. P. Maddison. The Tree Of Life:A multi-authored, distributed internet projectcontaining information about phylogeny andbiodiversity. Internet address:http://phylogeny.arizona.edu/tree/phylogeny.html,1998.L. T. e. a. Maidak BL, Cole JR. The RDP-II(Ribosomal Database Project). Internet Address:http://rdp.cme.msu.edu/html/. Nucleic Acids Res2001 Jan 1;29(1):173-4.B. McLaughlin. Java and XML. O’Reilly andAssociates, Inc., Sebastopol, CA, 2000.P. Naughton and H. Schildt. The complete Javareference: Java 2. Osborne/McGraw-Hill, Berkeley,CA, 3rd ed. edition, 1999.W. G. on Biomedical Computing. The biomedicalinformation science and technology initiative.Technical report, National Institutes of Health, June1999.N.-U. D. W. on Phyloinformatics. Research needs inphyloinformatics (draft report). Technical report,National Science Foundation, October 2000.C. Y. Ou. Molecular epidemiology of HIV transmissionin a dental practice. Science, 256:1165-1171, 1992.V. D. e. a. R. S. Lanciotti, J. T. Roehrig. Origin ofthe West Nile virus responsible for an outbreak ofencephalitis in the northeastern united states. Science,286:2333-2337, 1999.

6 4