There is increasing interest in the development of computational methods to analyze fluorescent microscopy images and enable automated large-scale analysis of the subcellular localization of proteins. Determining the subcellular localization is an integral part of identifying a protein's function, and the application of bioinformatics to this problem provides a valuable tool for the annotation of proteomes. Training and validating algorithms used in image analysis research typically rely on large sets of image data, and would benefit from a large, well-annotated and highly-available database of images and associated metadata.The Yeast Resource Center Public Image Repository (YRC PIR) is a large database of images depicting the subcellular localization and colocalization of proteins. Designed especially for computational biologists who need large numbers of images, the YRC PIR contains 532,182 TIFF images from nearly 85,000 separate experiments and their associated experimental data. All images and associated data are searchable, and the results browsable, through an intuitive web interface. Search results, experiments, individual images or the entire dataset may be downloaded as standards-compliant OME-TIFF data.http://images.yeastrc.org/.The YRC PIR is a powerful resource for researchers to find, view, and download many images and associated metadata depicting the subcellular localization and colocalization of proteins, or classes of proteins, in a standards-compliant format. The YRC PIR is freely available at  Understanding a protein's subcellular localization is critical to understanding a protein's role in the cell. The physical location of a protein limits its possible interaction partners and suggests possible biological functions for the protein . The subProtein-protein interactions may be assessed via fluorescence microscopy by observing the relative subcellular localization of separate proteins simultaneously tagged with different fluorescent proteins. Proteins with strongly overlapping patterns of subcellular localization are said to colocalize; and this colocalization may indicate similar biological function or possible protein-protein interaction. Interactions may be further characterized by exploiting fluorescence energy transfer (FRET) -4, wherede novo prediction of subcellular localization for proteins based on sequence or other criteria.The data from fluorescence microscopy experiments are typically captured using digital imaging systems attached to fluorescence microscopes and stored as images on disk. Developing computational techniques to automate the analysis of these images is an area of active research ,7 with dS. cerevisiae proteins. YPL.db2 [S. cerevisiae proteins. The Saccharomyces cerevisiae Morphological Database (SCMD) [Researchers developing computational algorithms that analyze fluorescence microscopy images typically require large datasets of images for training and validation of their method. Databases of fluorescence microscopy images have been previously developed, which may aid in this research. The Yeast GFP Fusion Localization Database  is a sta YPL.db2  (Yeast Pe (SCMD)  presentsThe YRC PIR is unique among these database because it is primarily an image database and not a protein annotation database. Where localization databases typically focus on annotating proteins in terms of their subcellular localization by providing chosen examples of images depicting that localization, the YRC PIR aims to provide a large number of images and their associated metadata for many proteins across multiple organisms. Although the YRC PIR may be used to find images depicting the subcellular localization of a particular protein, it is well suited to researchers interested in searching for and downloading large sets of images depicting the localization of particular proteins or categories of proteins.http://images.yeastrc.org/.The YRC PIR expands on existing databases by also offering an intuitive interface to a very large (and growing) database of high-quality and well-annotated images that may be downloaded, along with their associated metadata, as user-defined downloads using standards-compliant formats. In addition to standard subcellular localization data, the YRC PIR contains many images from colocalization and FRET experiments. As the YRC PIR expands, it will grow to include images from many organisms and will accept submissions from researchers wishing to disseminate their data to the public. The YRC PIR should be a valuable tool for researchers developing image analysis and pattern recognition techniques, as well as biologists interested in viewing the subcellular localization for specific proteins or examples of certain subcellular localization patterns. The YRC PIR is freely available at http://www.mysql.com/.The YRC PIR was designed to store and disseminate experimental data generated by disparate microscopy data pipelines. Accordingly, a relational database schema Figure  was deveThe database was initially populated with experimental data from two sources: YRC microscopy data and the Yeast GFP Fusion Localization Database.4). The XML was transferred to the YRC PIR database server and processed by a custom-written Java program that read the XML input and saved the data to the relational database schema.These data existed as proprietary-format binary files generated by the Deltavision microscopy system and resided on multiple servers within the YRC microscopy group. A custom-written Java program was run on a computer with access to the YRC microscopy network that processed these data files and extracted image data, image metadata and experimental metadata and saved the data as XML. The image data existed as raw 12-bit grayscale pixel values, and were converted into uncompressed 16-bit grayscale TIFFs via simple multiplication of pixel values by 16  and DAPI  channel images existed as 16-bit grayscale PNG files. The GFP and RFP channel images existed as 48-bit color PNG files, with fluorescence depicted in the green and red channels, respectively. In order to preserve data consistency in the YRC PIR database, all PNG files were converted to 16-bit grayscale TIFF images using the ImageMagick Saccharomyces cerevisiae. The data include protein subcellular localization and colocalization images.The MySQL database and resulting TIFF images were processed and inserted into the YRC PIR relational database schema by a custom-written Java program. These data comprise 14,526 images from 4,842 experiments. The data depict 4,176 proteins, all from A web interface for searching and downloading the data was written in Java and JSP using the Apache Struts web application framework running on the Apache Tomcat servlet container and Apache httpd web servers.All images downloaded via any of the methods for downloading "raw" data from the YRC PIR are formatted as OME-TIFF files. The Open Microscopy Environment (OME) defined OME-TIFF such that it is fully compatible with standard TIFFs and, consequently, software that is able to read and write TIFFs. OME-TIFF files include experimental and image metadata by incorporating OME-XML into oneThe YRC PIR's design is focused on searching, viewing results, refining searches and downloading or viewing pertinent raw data Figure . An exteA web interface was constructed for searching microscopy experiments Figure . From thThe search results consist of a synopsis of the search parameters and a table of microscopy experiments that match the search parameters Figure . Each roThe search may be constrained by most of the values present in these search results by clicking on the value in the table. For example, clicking on the name of a strain from one of the listed experiments will re-search the database with the added constraint of that strain name. Clicking the value for fluorescent tag used , image size and species will also constrain the current search. Hovering the mouse cursor over protein names, GO terms, or whether or not FRET was used in the experiment will produce a "pop up" tool tip that provides a description of that value (such as a description for that GO term) and provides links for adding that constraint to your search or learning more about that protein or GO term by visiting the YRC Public Data Repository (YRC PDR) . The YRCFrom this search results page, the user may refine their search (by clicking "Refine Search"), download all data that matches the current search (by clicking "Save as Bulk Download") or view the images and metadata associated with any experiment (by clicking the "View Experiment" link associated with the desired experiment). The "Save as Bulk Download" option prompts the YRC PIR system to create an archive of all images and metadata that match the current search and then notify the user (at the email address specified) that their data is ready to be downloaded. The organization of this file is described extensively in the User Guide available at the YRC PIR web site.The "View Experiment" link takes the user to a page listing all experimental metadata and all images (and their associated metadata) associated with the experiment Figure . From heBelow the metadata, the images associated with the experiment are shown as thumbnails along with accompanying metadata. By default, the images have their intensity values scaled so that the fluorescence is easier to observe in the web site. This effect may be disabled by clicking "Turn scaling OFF," just above the images. Also by default, a scale bar is present in each image that depicts the physical scale of objects in the image. This may also be disabled by clicking "HIDE scale bars." Very simple image statistics may be displayed by clicking "SHOW image statistics". These statistics include minimum, maximum and mean pixel values in each image, along with a histogram depicting the distribution of pixel values.The displayed thumbnails are in PNG format, and are converted and resized on-the-fly from 16-bit grayscale TIFFs stored in the database. Clicking on a thumbnail will cause a full-size version of the image to appear in a pop up window, also in PNG format. Clicking on the full-size image will trigger a download of a "raw" version of that image. As with all image data that is available for download from the YRC PIR, the "raw" version will be an unmodified  and uncompressed OME-TIFF file.Metadata are displayed for each image in the experiment. These include the name of the tagged protein and the name of the covalently-bound fluorescent protein that are visible in the image. The pattern of fluorescence in these images indicates the location of the tagged protein in the cell, and the strength of the signal is proportional to the amount of tagged protein present. For images of FRET channels, the name of the donor and acceptor proteins and their associated fluorescent proteins are displayed instead. The fluorescent protein bound to the donor protein has been excited and fluorescence from the acceptor protein is visible in the image. In these images, the intensity of this signal is a measure of the potential distance between the two fluorescent proteins and, by extension, between the donor and acceptor proteins. For images taken using differential interference contrast (DIC), whole cells are shown using transmitted light and no data describing the localization of a protein are shown.Additional metadata include the excitation and emission wavelengths of light used to excite and detect fluorescence from the fluorescent proteins in the image. (Except in the case of DIC images where the excitation and emission wavelengths are not meaningful.) The filter channel categorizes images as DIC, FRET or standard color channels. The photosensor is the measured brightness of the lamp. Exposure describes how long the shutter was open. NDFilter describes the level of neutral density filter applied to the image. More descriptions of the metadata are available in the FAQ available at the YRC PIR web site.Further work on the YRC PIR will include analysis tools to be available on the experimental view page, such as creating RGB merged-color images of the different channels in the experiment, the ability to perform FRET analysis and co-localization analysis, and other analysis tools common to fluorescence microscopy studies. Additionally, a web interface will be developed for users in the general community to upload data from their own experiments into the YRC PIR. The YRC PIR will be a platform for data sharing, suitable for collaboration and distributing data associated with microscopy publications.To our knowledge, the YRC PIR is the largest public database of fluorescence microscopy images currently available. To make this large dataset manageable to users, an emphasis was placed on search options and intuitive data view pages that lead to multiple options for downloading raw data. This makes the YRC PIR a valuable tool for computational biologists interested in defining and downloading datasets specific to their research and to cellular and molecular biologists interested in viewing the subcellular localization of particular proteins or viewing examples of subcellular localization patterns.http://images.yeastrc.org/.The YRC PIR is freely available to all at YRC PIR: Yeast Resource Center Public Image Repository; GFP: Green Fluorescent Protein; FRET: Fluorescence Resonance Energy Transfer; DIC: Differential Interference Contrast; RFP: Red Fluorescent Protein; OME: Open Microscopy Environment; GO: Gene Ontology; CFP: Cyan Fluorescent Protein; YFP: Yellow Fluorescent Protein.MR drafted the manuscript and developed the data parsing software, designed and implemented the database, and designed and implemented the web site. TND provided input during all phases of development and participated in drafting and revising the manuscript. All authors have read and approved the manuscript.


Discovering that drug entities already approved for one disease are effective treatments for other distinct diseases can be highly beneficial and cost effective. To do this predictively, our conjecture is that a semantic infrastructure linking mechanistic relationships between pharmacologic entities and multidimensional knowledge of biological systems and disease processes will be highly enabling.Disease-Drug Correlation Ontology (DDCO), formalized in OWL, that integrates multiple ontologies, controlled vocabularies, and data schemas and interlinks these with diverse datasets extracted from pharmacological and biological domains. Using the complex disease Systemic Lupus Erythematosus (SLE) as an example, a high-dimensional pharmacome-diseasome graph network was generated as RDF XML, and subjected to graph-theoretic proximity and connectivity analytic approaches to rank drugs versus the compendium of SLE-associated genes, pathways, and clinical features. Tamoxifen, a current candidate therapeutic for SLE, was the highest ranked drug.To develop a knowledge framework capable of modeling and interconnecting drug actions and disease mechanisms across diverse biological systems contexts, we designed a This early stage demonstration highlights critical directions to follow that will enable translational pharmacotherapeutic research. The uniform application of Semantic Web methodology to problems in data integration, knowledge representation, and analysis provides an efficient and potentially powerful means to allow mining of drug action and disease mechanism relationships. Further improvements in semantic representation of mechanistic relationships will provide a fertile basis for accelerated drug repositioning, reasoning, and discovery across the spectrum of human disease. The requirements for such an approach are to generate a comprehensive knowledge base that must both broadly and deeply represent factual knowledge and correlated phenomena from across pharmacological and biological domains. Doing this would, ideally, allow researchers, and subsequently, care providers, to distill insightful hypotheses and derive the best decisions. Computational approaches exist to allow the integration of heterogeneous data, such as by schema merging, federating databases, or by unifying data models. Notably, while great efforts have been made in connecting the biological and chemical domains, including PharmGKB [Lamb et al group designed a promising "connectivity map" approach which associates small molecules, genes, and diseases through genomics profiling connections [Drug repositioning – the use of established drugs for new indications – represents a promising avenue for the development of therapeutics based on its relatively low cost and ready availability of extensive data and knowledge from prior research and development efforts . DespitePharmGKB , KEGG [3PharmGKB , these dnections . This ap and Resource Description Framework (RDF) , as well as progress in corresponding database and knowledge representation technologies provide promising platforms for comprehensively integrating, analyzing, and visualizing heterogeneous high dimensional data using semantics and complexity of knowledge interoperability. The information layer of OWL defines domain knowledge using structured vocabulary and provides a mechanism for formalizing components for an ontology, such as classes, instances, and their relationships, therefore provides a computationally processable conceptual representation of our understanding of the domain knowledge. Based on the semantic definition in OWL, information resources can be denoted in RDF, a language represented in a simple statement form of triples (<subject verb object>). A set of RDF statements can be represented in directed acyclic graph-like data network. We argue that by associating comprehensive biomedical information and prior knowledge around pharmacological entities  systematically and semantically using Semantic Web principles and technologies can facilitate knowledge discovery such as novel indications for known or novel drugs. To achieve this, a knowledge framework with adequate formalism that encapsulates broad and interdisciplinary range of concepts across pharmacological, biological, and clinical domains is needed. Conceivably, any single domain-specific ontology will not serve this purpose. The existing multi-domain ontologies or terminologies, such as UMLS [Advancements in the development of Semantic Web (SW)  standard as UMLS , though Disease-Drug Correlation Ontology (DDCO), using OWL representation formalism. The DDCO is a result of manual curation and integration of relevant components from multiple existing ontologies, vocabularies, and database schemas. We used the constructed DDCO framework to support the integrated data representation needs of a set of prior knowledge sources, including data from DrugBank, EntrezGene, GO, OMIM, KEGG, BioCarta, Reactome, UMLS, and GEO. The data was semantically integrated into an RDF network as a pharmacome-diseasome knowledge base containing instance data represented as a web-like structure. Thereafter, we demonstrate how this integrated Semantic Web infrastructure supports knowledge mining and inference by presenting an application scenario that requires finding implicit associations between a compendium of drugs and the disease Systemic Lupus Erythematosus (SLE). Our goal in constructing and analyzing such a knowledge base is to learn essential elements that would provide critical power to the entire spectrum of drug R&D applications: to support new hypothesis generation, particularly for drug repositioning; as well as for novel target identification by establishing mechanism-based connectivity of drugs, diseases, genes, pathways, and continuously emerging biological systems knowledge.In this work, we devised a knowledge framework, Pharmacologic_Substance" has only a single child term (e.g. "Antibiotic") whereas "Molecular Mechanisms of Pharmacologic Action", "Pharmacologic Actions", and "Chemical Actions and Uses", are concept instances that are not represented as semantic types. They belong to a semantic type called "Natural Phenomenon or Process" which is not however semantically related to either the semantic type of "Clinical_Drug" or "Pharmacologic_Substance". Thus, at least one of the challenges in linking these terms in an ontology to enable reasoning is to provide connector relationships that facilitates domain representation, in this case principles of drug action. In this work, we have designed three key subdomains in the DDCO and created relevant knowledge components in each subdomain: 1) Pharmacological subdomain: focusing on defining concepts around drug and compound with classes such as Mechanism_of_Action, Chemical_Substance, Manufactured_Object, Therapeutic_Category, Structure_ Classification, Pharmacologic_Property, etc. 2) Phenomical subdomain: focusing on defining concepts and relations for disease and its associated clinical features and including classes such as Disease_or_Syndrome, Clinical_Property, Clinical_Finding, Phenotype_Trait, Diagnosis, Etiology, etc. 3) Biological subdomain: focusing on defining biological entities, events, and mechanisms, including key components such as BioEntity, Molecular_Basis, BioProcess, Molecular_Interaction, and BioEvent, etc. Among these domains, components from biological subdomain, such as pathway, gene, molecular phenotype and function, serve as key bridge for connecting components from other two subdomains  : the Nat• NCI Thesaurus : an onto• ATC System : The Ana• KEGG Drug Category: A chemical structure based information resource for approved therapeutics with classifications for drugs• Common Terminology Criteria for Adverse Event (CTCAE) : A descr• Gene Ontology : Control• SNOMED CT : clinicaDrug class. The "Chemicals and Drugs" in MeSH covers a mixture of information in a loosely-structured manner for drugs ranging from chemical structure, pharmaceutical preparation, and pharmacological actions. The "Pharmacological Substance" in NCI Thesaurus, however, is focused on therapeutic classifications of cancer drugs. KEGG Drug Category is also focused on therapeutic classification but is better organized to cover both application- and target-driven categories which fit general class of drug concepts including non-cancer drugs. To maximize the value of these relevant components, we chose to extract the "Pharmacological_Action" from MeSH and mapped it as a subclass of Drug class in the DDCO. By using ontology-merging and aligning techniques (see Methods), we populated "Therapeutic_Category" using knowledge components from both NCI Thesaurus and KEGG Drug Category. The target-based and structural-based categorizations from KEGG and NCI Thesaurus were also extracted and created as subclasses to represent Drug entity from respective aspect. In addition, we also integrated the ATC classification, a broadly accepted system for annotating approved drugs with classifications at main anatomy group, pharmacological property, chemical, and substance levels. To establish the relations between different drug classifications in the DDCO and adopted ATC system, explicit OWL class definitions were created to formally record the equivalence (or difference) among these classes.Some of these ontologies or vocabularies are independent and ready for direct integration (such as Gene Ontology), yet many resources contain overlapping and intertwining classes. For example, MeSH, KEGG Drug Category, and NCI Thesaurus all contain hierarchical and categorized terminologies which may represent e.g. areas lacking high quality knowledge representation or missing standards) that could serve data integration needs. For example, we created hierarchical classes of Pharmacokinetics with descriptions of both ADME and toxicity features. We also generated classes to unify drug administration properties, such as preparation, drug type, and dosing and regimen . Figure Drug class as well as the key entities associated with it by defined relations. While efforts to expand and refine the conceptualization are continuing, the current DDCO contains 2046 classes (excluding GO which was imported directly), with average sibling number of 17 (maximum 35 and minimum 1) per class.In order to comprehensively represent key entities and relations in DDCO, we defined classes that attempted to fill in knowledge gaps  with our curation of concept restrictions including necessary and sufficient restrictions. OWL-DL was used to define each relevant class and their associations. As shown in Figure Clinical_Drug is a subclass of Manufactured_Object. As an instance of the Clinical_Drug class, a drug may treat Diseases or Syndromes. It can be categorized into Therapeutic Category which includes custom defined classification or ATC_Classification system. In addition, one of the obligatory criteria to define a Clinical_Drug entity is that it needs to have at least one active ingredient. With the robust expression power of OWL, the complex relationships for such ontological descriptions were defined in an explicit and self-descriptive manner.One key to realize the inference power of semantic infrastructure is to have accurate and meticulous definitions of properties as well as proper restrictions (e.g. domain and range definition). We have thoroughly examined the class relationships and defined detailed properties for the classes required for our project purpose. The DDCO contains total of 221 properties, with 99 properties domain-specified, 69 range-specified and 36 inverse-specified. Among these, 106 properties were mapped to the UMLS semantic network relations, 40 mapped to SNOMED attributes, and 75 were custom-defined properties for constraint specification. In addition, we developed 67 restrictions related to data to be integrated in the semantic knowledge base, including 7 existential, 36 universal, and 25 cardinality constraints. Figure A key benefit of the Semantic Web is the ability to integrate relevant data from different origins and in incompatible formats. We have used the DDCO as the knowledge framework to integrate a diverse collection of data sources across multiple domains to create an integrated pharmacome- and diseasome- network.Drug-associated information was compiled from DrugBank, a database containing drug data with comprehensive target information. The dataset contains 4,763 drug entries. We parsed the information of over 1,400 FDA-approved drugs for integration in our knowledge base. Besides the information of pharmacological entity, we parsed the drug annotation and mapped the drug and drug target to associated pathways, which would allow for semantic integration with other data sources such as KEGG pathway (via mapped drug ID) and NCBI EntrezGene (via mapped gene ID). In addition, we have extracted the mapping associations between FDA-approved drugs and their indications using data from UMLS metathesaurus (see Methods). These associations, along with other entities, such as gene, pathway, drug, disease, and other molecular connectivity, were used as key linkage points to connect pharmacome and diseasome subnetworks. To generate the pharmacome network, RDF models were created in compliance with the logic and semantic definitions in the DDCO and the pharmacome data instances extracted were converted into RDF triples with designated unique name spaces. Figure The diseasome network was constructed using Online Mendelian Inheritance in Man (OMIM)  records.has_target" and "has_indication" properties. Similarly, we constructed the gene-interaction RDF graph for all human genes associated with their interacting genes in the integrated RDF store. The resulting interactome network consists of over 44,000 associations for 21,143 human genes. By refining pattern matching criteria in the RDF query, we further extracted and constructed two gene-interaction subnetworks for disease genes  and drug target genes (consisting of 749 drug target genes in the current knowledge base).To further understand the topological features of our integrated RDF network, we performed degree centrality analysis on the drug-centric and gene-interaction subnetworks. Degree centrality is a network centrality measure that takes account of the degree of a node, which is the number of nodes that a given node is connected to . To consP(k) ∞ Kr-, with P(k) denotes the degree distribution of nodes with degree k. Specifically, the degree distributions of the drug-target and drug-indication subnetworks are power law with exponents of 1.32 ± 0.05 and 1.20 ± 0.03, respectively. The interactome subnetworks for disease genes and drug target genes have similar exponent values of 2.64 ± 0.10 and 2.76 ± 0.12, respectively. These values are much greater than the exponent for the overall human interactome network (1.23 ± 0.09) , a chronic immuno-inflammatory disease that exhibits strong gender bias and the tendency to affect multiple organ systems including heart, skin, joints, kidney and nervous systems. At the current stage, there is no cure for SLE and treatments are largely limited to the relief of symptoms and limited ability to protect organs from inflammation or autoimmune activities in the body by using drugs such as nonsteroidal anti-inflammatory agents or corticosteroids.Subjects and Objects as nodes  and lines labeled with Verbs. This readily allowed us to perform systemic network analyses using centrality algorithms and graph-based approaches. By applying betweenness and closeness centrality ranking metrics on the resultant subnetwork, we found Tamoxifen was consistently ranked 1st using both ranking approaches  the primary genes associated with SLE as well as all the associated annotations for these primary genes including pathway, gene ontology association, interacting entity, and drug targeting on these genes; 2) the secondary genes interacting with or participating in the sharing pathway and biological process with above primary genes as well as associated annotations  for these secondary genes. With the semantic representation of multi-source biomedical data in our knowledge base, the entities are encoded according to S-V-O (subject-verb-object) triples with in silico approach would await results from extensive animal model testing and human clinical studies. However, by extending the semantic mining and ranking techniques, possible mechanisms with supporting evidences can be inferred to facilitate hypothesis generation and guide further study design. While the pathogenesis of SLE is very complex and remains unclear, we attempted to test whether our integrated RDF semantic knowledge base would be able to uncover the implicit links between Tamoxifen and SLE. First, we issued RDF queries to retrieve Tamoxifen and SLE RDF subgraph respectively:Undoubtedly, solid validation of specific drug-disease associations predicted using Retrieve all genes and their annotation  that are associated with Tamoxifen by acting as its drug target(s) or indication(s)• For Tamoxifen: Retrieve disease genes, or genes interacting with or sharing pathways with SLE disease gene as well as their annotation• For SLE: GO_0006915) and T cell receptor signaling pathway (KEGG: hsa04660) that are traversed by two genes: PDCD1  that is associated with SLE via property of "associates_with", and gene AKT1  that is found to be associated with known indication of Tamoxifen  and AR (androgen receptor). In fact, accumulating evidence from prior studies has suggested a functional crosstalk between immune and endocrine mechanisms in modulating immunity responses [et al has shown that estrogen level alteration in SLE patients appears to affect the development and severity of SLE [As described above, since RDF triples are naturally represented in graph, we sought to use applied graph centrality analysis algorithm and approach  to identesponses ,30. Receesponses ,32. Ridey of SLE ,34. ESR1y of SLE -37. Basey of SLE ,34,38-40et al [et al [Next-generation decision support to optimize the yield of discoveries and benefits from biomedical research, translational medicine, and clinical care will critically depend on our intelligent use of assembled information from multiple sources of facts, knowledge and data. An outstanding opportunity to refine approaches to this next-generation challenge for computational medicine is represented by the search to find drug repositioning opportunities and to develop new understanding of mechanisms that underlie disease. In this study, we have created a comprehensive pharmacome-diseasome infrastructure using Semantic Web-based technology to integrate multiple knowledge sources. By using a specific scenario involved in drug development, we have provided anecdotal evidence for the benefit of such semantic knowledge integration and representation in identifying and ranking drug candidates associated with SLE based on their centrality in the RDF graph. There have been multiple prior efforts to build semantically integrated databases, such as YeastHub , FungalWet al ,44 and Sl [et al . Our appOur hypothesis is that the drugs or genes that are central in the disease-specific RDF subnetwork are likely to be related to the disease. Our results provide supporting evidence for the hypothesis. As shown in the result, ESR1 has been identified as one of the key genes in the SLE-Tamoxifen data network based on the centrality measurements. Estrogen receptor signaling has been shown to regulate differentiation and maturation of immunity cells and impact the immunity modulation by cross talking other pathways . At moleThe knowledge model and approach in data mining and ranking demonstrated in this study can be generalized to more complex diseases and to additional information sources. The DDCO constructed in this work has provided a formalized ontology for integrating biological and pharmacological knowledge domains. It is designed with flexibility and extendability in mind by providing well-structured upper-level schema scaffold readily for integrating additional knowledge components to accommodate new type of data instances. Further, the equivalence specifications defined in the DDCO can assist with uniting data if different identifiers were initially used. With the continuous enrichment of functional annotations in biomedical areas including disease, gene, pathway, and molecule properties, we envisage a proportional increase of the usefulness and performance of such semantic infrastructure. Nevertheless, how the platform efficiently collects and transforms large amount of new data from heterogeneous biological sources and appropriately mapping ontology content in an efficient manner remains an issue to be solved. While some of the major data sources become available in RDF/XML format, such as UniProt, GO, NCBI Taxonomy, an improved and consistent data conversion/distribution mechanism and system, such as Bio2RDF project under development for making biological data available in RDF document , will beusefulness of nodes) like many other centrality measures. We recognized other centrality measures, such as eigenvector-based centrality, may provide additional power in refining entity ranking. Indeed, we have applied PageRank, a modified eigenvector centrality algorithm underlying the popular search engine Google [Our approach however has some limitations. First, in this work, the centrality measures of closeness and betweenness were chosen to rank the biologically significant entities since they don't require to pre-assign weight values to entities  and Protégé [We used a manual construction and import approach to provide broad coverage across the breadth of disease and drug knowledge. The ontology editor Protégé  was usedProtégé . In addiFor knowledge domains lacking high quality ontology or mature standards, we sought to build our own ontology by applying approach analogous to CRISP-DM methodology  and as d. Data from UMLS knowledge source was downloaded from . Gene Ontology was downloaded from Gene Ontology website .DrugBank is a freely available public resource and the data used for this work was downloaded in flat file format from . Pathway annotation was compiled from KEGG , BioCarta , BioCyc , and Reactome download site . Online Mendelian Inheritance in Man (OMIM) records in XML format and the corresponding gene associations to OMIM disease were extracted from "mim2gene" file in NCBI ftp site.Corresponding human gene and GO annotation were downloaded from NCBI Entrez site "may_treat" and "may_be_treated_by", which represent both directions for a relationship . To further refine the extraction and eliminate false positive mapping, the semantic type "Chemicals & Drugs" and "Disorders" were used to constrain the returned association concepts , which is the primary Metathesaurus relationship file defining intra-source relationships in UMLS, to map FDA-approved drugs to the UMLS concepts, each with a unique Concept Unique Identifier (CUI). The table MRREL.RRF, the primary file providing the intra-source relationships of non-synonymous concepts, was used to extract the associated indications for these drug CUI concepts. There are total of 266 distinct relations represented in the MRREL.RRF table, with one row for each relationship between concepts or atoms of UMLS. To extract the drug-indication relationship pairs, we used the relations of , a java-based framework for building semantic web applications and supporting RDF(S)/OWL, was used to generate triples required for RDF in compliance with the definitions by the DDCO model. The data includes drug information , genomic data  and disease information . The RDF triples from extracting above mentioned pharmacome and diseasome data sources were further converted into N-Triple format using Oracle RDF loader and then loaded to the Oracle 10g release 2 RDF data store [JENA API ta store .We used SPARQL and SPARQL-like RDF query syntax such as SDO_RDF_MATCH table function that is required by the Oracle RDF data model to query the data in our RDF data network. The query attributes consists of given RDF graph to be searched, i.e. SDO_RDF_MODELS created in Oracle database, and query which is a SPARQL-like graph pattern containing a set of variables. Each query returns a set of variable bindings matching to the query parameters and the results produces a graph formed from the triples meeting query criteria. To construct RDF subnetwork for each query result, for example, SLE-centric data, the query form of "CONSTRUCT" from SPARQL was used to extract the associated graph for each query result. We generated the inference rules in our rulebase to support RDF inferencing query following below definitions :IF <A is_a B> AND <B is_a C>, THEN <A is_a C>• IF <A is_a B> AND <B part_of C>, THEN <A part_of C>• IF <A part_of B> AND <B is_a C>, THEN <A part_of C>• IF <A part_of B> AND <B part_of C>, THEN <A part_of C>• Oracle 10g store supports RDFS and custom developed inference rules. We implemented the rulebases for inferencing and created rule indexes enabling pre-computed triples to be inferred from the models built in Oracle 10g.i of node i is calculated as follow:Degree centrality was used to examine the general topological properties of the integrated RDF network. In a network, the degree of a node is one of the measurements of the centrality of a node. It's defined as the number of lines connecting to the nodes . The degAij = 1 if there is an edge between node i and j and Aij = 0 if there is not edge connecting i and j.where The mean degree (K) of nodes in a network is computed by:ki(Gn) is the degree of node i in graph G consisting of n nodes.where The degree centrality of a network is associated measure of centralization for the entire network, which expresses the extent to which a network has a center. It is calculated by the variation in the degrees of nodes divided by the maximum degree variation which is possible in a network of the same size .nodes and L is the set of lines , the two parameters is computed as below. [The importance of the entities in the network is evaluated using closeness and betweenness centrality algorithms and analyses. Closeness evaluation emphasizes the distance of one entity to all others in the network, i.e. the smaller the total distance of a node to other nodes, the higher its closeness is. Betweenness centrality calculation balances the importance ranking by weighing in the global importance of an entity that assesses the proportion of the shortest paths between all entity pairs in the network that pass through the entity of interest, i.e., an entity is ranked high of importance if more entity pairs in the network are connected dependent on this entity. The average of the two calculations is used for final ranking. For a graph G = , where V is the set of s below. dist denotes the length of a shortest path between the nodes v and w in the set of nodes V [-  nodes V σst is the number of shortest paths from node s to t and σst(v) is the number of shortest paths from s to t that pass through the node v.-DDCO: Disease-Drug Correlation Ontology; SLE: Systemic Lupus Erythematosus; SW: Semantic Web; OWL: Web Ontology Language; RDF: Resource Description Framework; GO: Gene Ontology; UMLS: Unified Medical Language System; W3C: World Wide Web Consortium; XML: eXtensible Markup Language; SERM: Selective Estrogen Receptor Modulator; ADME: absorption, distribution, metabolism, excretionThe authors declare that they have no competing interests.AXQ conceived and implemented the use scenario in this research work and is the primary author for drafting the manuscript. AXQ and RCG carried the semantic infrastructure design and implementation. EKN participated in the design and discussion of the research and helped to draft the manuscript. BJA directed and designed the research project and contributed to writing the manuscript. All authors read and approved and final manuscript.Supplement Table: Top 10 Ranked Drugs Associated with SLE by Closeness and Betweenness Centrality Measurements.Click here for file


Identifying relevant research in an ever-growing body of published literature is becoming increasingly difficult. Establishing domain-specific knowledge bases may be a more effective and efficient way to manage and query information within specific biomedical fields. Adopting controlled vocabulary is a critical step toward data integration and interoperability in any information system. We present an open source infrastructure that provides a powerful capacity for managing and mining data within a domain-specific knowledge base. As a practical application of our infrastructure, we presented two applications – Literature Finder and Investigator Browser – as well as a tool set for automating the data curating process for the human genome published literature database. The design of this infrastructure makes the system potentially extensible to other data sources.Information retrieval and usability tests demonstrated that the system had high rates of recall and precision, 90% and 93% respectively. The system was easy to learn, easy to use, reasonably speedy and effective.The open source system infrastructure presented in this paper provides a novel approach to managing and querying information and knowledge from domain-specific PubMed data. Using the controlled vocabulary UMLS enhanced data integration and interoperability and the extensibility of the system. In addition, by using MVC-based design and Java as a platform-independent programming language, this system provides a potential infrastructure for any domain-specific knowledge base in the biomedical field. Published literature databases are a major information source for generating scientific hypotheses and conducting evidence-based reviews . PubMed/The human genome epidemiology literature database  is a domWe present an open source infrastructure for managing and querying domain-specific data (Literature Finder) and investigator information (Investigator Browser) available in PubMed abstracts, along with a data management and curating tool set. We illustrate these functions using a knowledge base system called HuGE Navigator  which waThe Web-based infrastructure for this system was designed to manage a local collection of PubMed literature and generate investigator profiles based on authorship and affiliation information. The main objectives of the design were data standardization, automatic capacity for data manipulation, modularity and scalability of the system, and a user-friendly Web interface.The UMLS  containsTo increase the granularity of relationships among the millions of unique concepts collected in UMLS, we used the Medical Subject Headings (MeSH) hierarchy tree to establish parent-child relationships. MeSH  indexed We enriched the gene information in the UMLS metathesaurus by incorporating data downloaded from Entrez Gene records , substitTo improve the performance of the system, we designed a dynamic data subset-creating process for the external datasets. The 6 million records in the UMLS concept-lookup table could create performance issues if queried directly. Even after removing non-English and retired terms, the table contained 3 million records. Because of the multidisciplinary nature of HuGE research, we could not further subset the UMLS metathesaurus by semantic type. Since not all 3 million UMLS terms will be used in literature indexing, we developed a UMLS concept subset-creating script as part of the curating utilities. This script populates the subset table automatically and dynamically by adding any newly encountered terms into the UMLS subset table in the database when PubMed records are uploaded or updated (see Curating utility implementation section). Applying this process dramatically reduced the size of the UMLS subset table to about 23,000 records, significantly improving performance. The same mechanism was applied to the MeSH hierarchy data, creating subsets that are used to retrieve children terms for the query.The user interface was designed to be simple and intuitive, so that the system could be used with minimal instructions. Searches are performed using free text with Boolean operators (or/and) Figures , 2. The A spelling check feature, equipped with the ESpell  NCBI E-UThe filtering feature allows further stratification of returned results based on user preference Figure , 5. The Gene-centered information and UMLS concept information can be retrieved from a central page that contains relevant links to general information, genetic association, gene variation/prevalence, and pathway and microarray data Figure . UMLS inThe simple search using the Search Text box returns all available articles that meet the query specification, which can be displayed with 25, 50, or 200 records on a page. The PubMed It feature opens a PubMed page with the returned articles. The user can then search with features provided by PubMed or upload the list of PubMed abstracts into reference software such as Endnote and Reference Manager Figure .The Query Detail page Figure  providesSeven classifiers  are available for the filtering feature in the HuGE Literature Finder Figure .A list of investigators with their corresponding number of publications is returned based on the user's query in the text search box Figure . The useAn investigator's profile may be retrieved by clicking on the author's name. If data are available in PubMed, the investigator profile may include the full address, institutional affiliation, country and email address, and the number of publications in the local database as first/last author or any author, and total publications in PubMed Figure .The filtering feature in the Investigator Browser includes two classifiers: Country and Institute Figure .A number of tools were developed to curate the database automatically. These consist of the following:The PubMed literature loader automatically uploads records from the PubMed database into the local database using NCBI E-Utilities [tilities  based onThe MeSH index loader automatically uploads MeSH terms provided in the PubMed record into the database when these terms are available.The MeSH-UMLS converter converts and maps MeSH terms to the corresponding UMLS CUI.The UMLS/Entrez Gene subset-generator automatically creates a UMLS/Entrez Gene table with subsets based on terms used in the database.The MeSH Tree subset-generator automatically creates MeSH Tree table with subsets based on the terms used in the database.The affiliation parser automatically parses the author affiliation string into full mail address, institution, country and email address, and populates the database with the parsed information. The detailed methodology has been reported [reported .The system was designed using one of the most accepted Web application architectures, the model-view-controller (MVC) pattern ,21. ThisThe whole infrastructure can be divided into three discrete modules that are loosely coupled. The data module contains all data in the database; the accessory utility module is responsible for a series of data transactions and manipulations; and the application module includes all the applications in the system. To avoid version control problems, we allow data entities from external data sources  to be updated as needed without an overhaul of the entire system. Each application was built on this model, allowing for seamless navigation and easy plug-in of new applications.A relational database was created based on the requirements of the system. The database design contained the document, investigator, indexing and classifier, and external data modules Figure .To test the system's information retrieval performance, we first populated it with 500 randomly selected articles from the human genome epidemiology literature database (HuGE Literature Finder). Independently, two of us  assessed all 500 abstracts for relevance to any of the five diseases or the five genes that appear with greatest frequency in the database . All diswhere TP, FP and FN represent the number of true positives, false positives and false negatives respectively.We recruited 26 participants to perform a usability test. The participants had diverse backgrounds and included epidemiologists, geneticists, web developers, and graduate students. After a brief introduction and demonstration of the system, each participant used the HuGE Literature Finder to search for the answer to a multiple-choice question. All participants responded to eight statements about usability on a five-point Likert scale. The mode for each statement was calculated to measure central tendency, in keeping with the ordinal nature of Likert scales . Most paWith advances in Web technology, online searching has become one of the most preferred methods for obtaining information in the health science setting . AlthougThere have been many initiatives in the goal of improving the PubMed data retrieval, such as SLIM  that enhModularity and scalability in the MCV-based design of the infrastructure will allow the system to expand easily as needed. Any individual application with specific business logic and requirements can be plugged into the system. We have experimented with this idea by adding supplementary applications, such as other components of HuGE Navigator . A critiThe open source system infrastructure presented in this paper provides a novel approach to managing and querying information and knowledge from domain-specific PubMed data. To ensure data integration, interoperability, and system extensibility, we have developed a novel approach to generate dynamically a controlled vocabulary for a specific biomedical domain. A performance evaluation of the system demonstrated high recall and precision. Results of usability testing showed that the Web interface was easy to learn and queries to be completed queries quickly and effectively. The ability to generate a dynamic controlled vocabulary, the MVC-based design, and Java as a platform-independent programming language allow this infrastructure to be used for other domain-specific knowledge bases in the biomedical field.Project home page: The system built upon this open source infrastructure: Operating systems: Windows and Linux/UnixDatabase: MS SQL server and MySQLProgramming language: JavaSoftware packages: J2EE 1.4, Hibernate 3.0 and Strut 1.2.9License: GNU General Public License. This license allows the source code to be redistributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation. The source code for the application is available at no charge.Any restrictions to use by non-academics: NoneCUI: Concept Unique IdentifierHuGE: Human Genome EpidemiologyHUGO: The Human Genome OrganizationMeSH: Medical Subject HeadingMVC: Model-View-ControlOMIM: Online Mendelian Inheritance in ManUMLS: Unified Medical Language SystemWY designed and implemented the infrastructure, wrote the source codes, and drafted the manuscript. AY was involved in the system design and the data analysis and helped in manuscript preparation. AW participated in design of the system evaluation, data collection and analysis. JQ was involved in the system design and configuration, and data management. MG provided advice on the project and revised the draft manuscript. MJK oversaw the project and revised the draft manuscript. All authors read and approved the final document.


In computer science, database systems are based on the relational model founded by Edgar Codd in 1970. On the other hand, in the area of biology the word 'database' often refers to loosely formatted, very large text files. Although such bio-databases may describe conflicts or ambiguities  in a positive sense, the flexibility of the data format sacrifices a systematic query mechanism equivalent to the widely used SQL.To overcome this disadvantage, we propose embeddable string-search commands on a Wiki-based system and designed a half-formatted database. As proof of principle, a database of flavonoid with 6902 molecular structures from over 1687 plant species was implemented on MediaWiki, the background system of Wikipedia. Registered users can describe any information in an arbitrary format. Structured part is subject to text-string searches to realize relational operations. The system was written in PHP language as the extension of MediaWiki. All modifications are open-source and publicly available.This scheme benefits from both the free-formatted Wiki style and the concise and structured relational-database style. MediaWiki supports multi-user environments for document management, and the cost for database maintenance is alleviated. In many research fields, building or maintaining a database system is not a sought-after task and researchers tend to avoid the chore because: 1) the inputting and checking of data are routine and tedious, 2) novel findings are rarely based on a collection of old data, 3) database developers often do not receive deserved credit especially when data are distributed for free, and 4) it is difficult to evaluate the quality and value of data. However, most bioinformatics research requires high-quality databases. Their significance is clear from the success of major data-servicing institutes such as the National Center for Biotechnology Information  or the European Bioinformatics Institute . Without doubt, data collection and management are important activities in scientific research.How can we promote the development and maintenance of high-quality databases? The key processes in data handling are the input, management, and query of data. The effort required for the first two activities can be significantly reduced by introducing a Wiki-based system. The Wikipedia, a web-based free encyclopaedia, for example, continues its rapid growth despite criticism by experts of 'lack of quality control' and 'vulnerability to website vandals' . Its EngIn the rapidly evolving frontiers of biology research, the development of flexible and systematic query mechanisms has not been pursued actively. Biological data and their formats often co-evolve; the definition of data type in a repository requires frequent, major updates. This is not compatible with the relational model proposed by E. Codd . It has .This paper is organized as follows. The basic function and flexibility of MediaWiki are introduced in Methods section from a computer-science perspective. Using functionality, we introduce the implementation of the flavonoid database in Results section. The advantages of our approach and differences from other approaches are reviewed in Discussions. Readers are encouraged to access our website at Flavonoid is a class of plant secondary metabolites with a C6-C3-C6 skeleton derived from the phenylpropanoid-acetate pathway . This clpage, is separated into its title and body and stored in a single table in the background RDB . Second, MediaWiki supports user-defined functions called extension. A system administrator can add extension programs written in PHP language and enhance MediaWiki functionality. By overwriting the source code, any modification can be applied through this option. For example, the if-then control command of a programming language has been implemented in MediaWiki as an extension [template. The template mechanism itself is implemented as a special page that can be pasted into any other page by calling its page title. A template page can accept arguments; its function is similar to a function call of programming languages. Lastly, MediaWiki provides a classification scheme for pages called namespace. Each page belongs to a certain namespace which is displayed as a prefix of the page title. In the background RDB, each namespace is translated into an integer value assigned to each data tuple in the relation table. One major custom namespace is Category. Pages in this space are used to describe the semantic hierarchy, and all pages linking to a Category page are automatically sorted for display in the page. These functions are fully exercised in our database design. Hereafter, the words extension, template, and namespace carry the meaning described above.In most Contents Management Systems, page contents are stored in a file system and their edit history is automatically maintained to manage version differences or to restore past edits. MediaWiki excels such systems in the following four characteristics. First, the entire system is built on a Relational Database (RDB). Each article, called a xtension . Third, Text data managed by Wiki-based systems are inherently free-formatted. The fundamental operation for realizing any query is the full-text search. In our implementation, for efficiency, information for systematic searches must be described in tabular form with a special separator, "&&", at the head of each table element. Tabular data are searched and organized with the following new commands implemented as an extension on MediaWiki.• {{#SearchTitle:arg1|arg2}}: The command lists all page titles that match the regular expression arg1 in namespace arg2. The returned titles are separated by &&.• {{#SearchLine:arg1|arg2|arg3}}: The command lists all page lines that match the regular expression arg1 in the namespace arg2. An optional argument arg3 specifies a particular page title in the namespace. A page title is attached at the head of every detected line with a separator &&.• {{#repeat:arg1|arg2|arg3}} The command repeats the application of the template titled arg1 that requires arg2 arguments (arg2 must be a positive integer) for the list of arguments arg3 separated by &&.These commands are used to emulate two fundamental operators in the relational model: selection (extraction of rows from a relation table) and projection (extraction of columns from a relation table). Note that search results are labeled with page titles, which serve as the identifier of the relation table being searched. A join operation (merging two relation tables by associating a particular column common to both) is theoretically possible by repeating searches for all table elements; however, the computational cost is too high. In our implementation, such costly operations, including set operations, are delegated to the Lua embeddable programming language . Lua is All newly implemented Wiki commands  are summarized on our website . Their sThe page contents of the database can be converted to XML data in MediaWiki; the initial construction and major modification of the contents, including data integration from multiple data sources, were operated in the XML format. In our initial database construction, a sample page for a single flavonoid compound was created and verified its XML format by serializing the page. Then other data were reformatted in the same XML style and were bulk input accordingly. Page update is possible either through a web browser or the OpenOffice Project, which recently announced the function to export Microsoft Office documents to MediaWiki .Our basic concept is to describe tabulated data in Wiki pages and to let all other operations such as formatting for visualization, obtaining statistics, or applying relational operators be done by the template mechanism and text-string searches. Information on pages is intended to be least redundant to maintain data integrity and to reduce input and update tasks. The translation scheme between the relational model and Wiki pages is shown in Figure reference namespace and necessary information is dynamically integrated by using string-search commands in the compound and species namespaces.Different from traditional metabolite databases , we prepared three relation tables that provide compounds, plant species, and references on an equal footing rather than assigning a compound ID as the sole primary key for all information Figure . The thrspecies pages. The page title is a genus name from which the taxonomic hierarchy is derived. Such derivation is performed either by templates or by the embedded Lua programming language.For example, a page for a compound displays information on plant species and references that is derived automatically from other pages or external resources. Using the 12-digit ID, each compound page is associated with a MOL-format (molecular structure) file from which structural information such as formula, exact mass, and average mass is obtained. The same is true for the The data page of catechin only includes the page title 12-digit ID), English names, and link information for other databases , and we conservatively estimate 100,000 pages as the limit to run the database on the current DELL PowerEdge server .As a natural extension of page dependency, we can let the system generate fully dependent pages. Pages for statistics, indexes, or search summaries belong to this category. Traditional Wiki systems do not support such pages unless specially designed as built-in pages because they are devoid of original contents or titles. We prepared two types of fully dependent pages: those that are not necessarily saved, and those that should be saved and subject to page (or internet) searches. Examples of the former are different display styles of an identical page or volatile information that needs not be searched for. Examples of the latter are the index pages. To support both functionalities, the namespace "volatile" and "persist" were newly introduced.volatile namespace describe not data contents but function to process data. This resembles, but is clearly different from, the template mechanism. Whereas a template page is called from inside normal Wiki texts and its output is embedded where the template is called, a volatile page is linked from other pages with arguments and the processed output is shown as if it were the page contents of the called volatile page. Therefore, the page view may change for each access depending on the given arguments. Its function is the same as the widely used parameter passing mechanism through the http protocol , except that any user can design such a page through Wiki.Pages in the volatile namespace. It accepts an author's name as a sole argument and generates statistics for the author's publications from all reference pages.From more than 4500 article information, author statistics can be generated: for example the number of compounds reported by the author and the annual publication trend. Since the data are fully dependent on reference pages, the page for the author summary was placed in the persist namespace initially contain nothing and the page contents are fully projected from other pages. While a page in volatile namespace offers function as its page body and receives arguments to be processed, a page in persist namespace receives both arguments and function body from other pages. Each time the contents are projected, the corresponding persist page retains the projected information so that the data are cashed and subjected to web searches.On the other hand, pages in the volatile namespace, such a list cannot be utilized for further full-text searches because the list is not materialized as the page body. Therefore, the persist namespace is required to realize such fully dependent pages whose page sources list data rather than functions to generate lists. In our implementation, indexes of the exact mass, average mass, molecular name, and chemical formulas were prepared in the persist namespace.Indexes of molecular names, molecular weights, or chemical formulas are indispensable information for large-scale data collections. Index pages are fully dependent on other pages and should be automatically updated when molecules are added or deleted. Although a list of molecules may be displayed using the #SearchLine function (see Methods section) in Traditional HTML-based systems including Wiki provide a collection of independent pages only. Therefore, it is difficult to obtain page summaries or identify discrepancies on pages even inside the same website. To acquire statistics, for example, users must rely on search engines, or administrators must prepare CGI-based functions to provide user-dependent views.The installation of embeddable query commands alleviates, at least in part, these difficulties. It yields (fully) dependent pages; page statistics or indexes can be easily designed and maintained, provided that data pages are written in a uniform format. On Wiki-based systems, moreover, not only administrators but also users have the right to create such pages.The introduction of embedded queries thus changes the way Wiki-based systems are used. It accelerates the exchange of information and reduces the cost of maintaining data integrity through appropriately designed, dependent pages. However, creating dependent pages requires understanding of MediaWiki system and additional programming skill (interested readers are encouraged to view page sources of our website). Thus, our contribution rather benefits advanced users that can write dependent (i.e. programmed) pages than the majority of end users.interdependent web pages. There have been attempts to utilize Wiki-based systems for gene annotation or for the management of biological information [n-nary relationships among pages to manage ontology data [Our implementation on MediaWiki for flavonoid data is a novel, though small-sized, prototype for ormation -14. Howeogy data . In termogy data . In bothMediaWiki supports streamlined page formatting through the so-called template mechanism. A tabulated list of data can be transformed into a uniform style by using this mechanism. Our implementation also extensively utilizes the function, but we additionally exploit the #repeat command so that the system can handle an arbitrary number of data records (see Methods section). In the original MediaWiki, only a fixed number of arguments are allowed for each template (or command) and there is no mechanism to handle data of unknown size. Under this restriction, processing search results is impossible because the number of returned items is unpredictable. Thus, the introduction of loop- or control structures is the fundamental difference from MediaWiki and other Wiki-based systems. In other words, we allow users to write small computer programs inside Wiki pages, i.e., to realize document computing.template namespace is called by the original data and the result is embedded where the template name appears. Case (2) is a page in the volatile namespace; it resembles the http-based parameter passing in CGI in which users input arguments to show user-dependent views. Case (3) is a page in the persist namespace; it resembles the Resource description framework Site Summary (RSS) concept in which data-crawling software, called a feed reader, scans registered news-sites or web logs to obtain real-time news. Retrieved information may be cast as an independent web page elsewhere. A well-known example is Google News [persist page is updated at the time of browsing, and its contents persist as if it were an independent page until the next update.The existence of dependent pages raises the problem of data placement. In general, when page contents are generated from original data applied to a function, the result can be placed at the location of 1) the original data, (2) the function, or (3) elsewhere (Table  the origgle News . The difThe embedding of the Lua programming language on MediaWiki made it possible to implement any program code (see Methods section). It was too powerful a function to suppress server attacks. To avoid denial-of-service (DOS) or other attacks through Lua, we closed its I/O function and restricted its running time to 10 seconds. A page-size quota was also set. Therefore, it became impossible to handle truly large-scale data (e.g. one million pages) on our system. However, this limitation is due to our system maintenance and is not a theoretical limitation (provided that we can use a high-performance computer as our server).volatile and persist pages, which are updated only by visiting these pages. Although both types are fully dependent and can be easily reconstructed, vandalized persist pages may be cached by external web search engines (e.g. Google). To prevent this, in our current implementation all pages are password-protected, and persist pages are updated only through accesses by registered users.Since all pages are accessed through the http protocol, all pages are subject to web vandalism. Although the original MediaWiki supports a password-based edit restriction, this does not work for We proposed the introduction of embedded string-search commands on MediaWiki, and realized a half-formatted database system that can handle relational operations. The introduction of embedded string-searches created the notion of page dependency and document computing. Dependent pages are categorized into three types, each corresponding to standard Wiki pages, http-based parameter passing in CGI, and RSS-like pages. Thus, page dependency sorts out seemingly irrelevant web functionalities in a streamlined manner. The advantage is that any (registered) user can create such pages through a web browser.Using these functionalities, a database of around 7,000 flavonoid molecules was implemented. On our system, the task of data input and maintenance was rendered easier and systematic queries became possible through a tabulated data format.The introduction of embeddable search commands is theoretically possible for standard HTML with Java script. If searching against external servers were to be realized, the concept will change how we manage information on the web. Imagine a world where every user obtains a power to design and construct statistics pages as is done by Google: a world where construction of 'meta' knowledge becomes much easier. To accelerate information exchanges and to improve data integrity on the web, what is anticipated is a framework like our system for the entire internet.The authors declare that they have no competing interests.MA incepted and conducted the research and wrote the manuscript. KS helped with implementation. Both authors read and approved the final manuscript.


Many complementary solutions are available for the identifier mapping problem. This creates an opportunity for bioinformatics tool developers. Tools can be made to flexibly support multiple mapping services or mapping services could be combined to get broader coverage. This approach requires an interface layer between tools and mapping services.Here we present BridgeDb, a software framework for gene, protein and metabolite identifier mapping. This framework provides a standardized interface layer through which bioinformatics tools can be connected to different identifier mapping services. This approach makes it easier for tool developers to support identifier mapping. Mapping services can be combined or merged to support multi-omics experiments or to integrate custom microarray annotations. BridgeDb provides its own ready-to-go mapping services, both in webservice and local database forms. However, the framework is intended for customization and adaptation to any identifier mapping service. BridgeDb has already been integrated into several bioinformatics applications.http://www.bridgedb.org.By uncoupling bioinformatics tools from mapping services, BridgeDb improves capability and flexibility of those tools. All described software is open source and available at  Many interesting problems in bioinformatics require the integration of experimental data from different sources. Examples include merging two independently created protein-protein interaction networks in Cytoscape and visuThis problem of identifier mapping has been recognized, and a number of resources have been developed to solve it, including DICT, CRONOS, MatchMiThe key to both challenges is to create a standard interface between tools and mapping services. Here we present BridgeDb, a framework that provides such a standard interface. BridgeDb is a software library intended to be used by bioinformatics tool developers. The overall architecture is described in Figure data source to describe a database of biological entities, indexed by unique identifiers. Usually, these identifiers are assigned and maintained internally by an independent organization. Examples of data sources include Ensembl, UniProt, ChEBI, and the Gene Ontology.To explain the features of the BridgeDb framework, it is necessary to define some concepts. We use the term internal identifier is an identifier that is valid within the namespace of a data source. A good identifier must be unique, stable, and preferably free of semantic information. An internal identifier is not necessarily globally unique because a given identifier may be valid for two different data sources .An symbol for a string that is a human readable representation of a biological entity. Symbols are not necessarily guaranteed to be unique or stable over time. A symbol can be a gene name such as INSR or TP53 for example. A biological entity might have several synonymous symbols or aliases. Since these symbols have a biological meaning, they are not semantic-free and do not serve as good identifiers. Semantics should be avoided because the information can be found to be "wrong" by new evidence. For example, the Caenorhabditis elegans gene symbol rad-5 (implying radiation sensitivity) was replaced by clk-2  after additional experimental evidence was collected and reinterpreted [In contrast with identifiers, we use the term erpreted .global identifier is a globally unique identifier based on the combination of data source and internal identifier. Importantly, for the exchange of data, global identifiers must be standardized. For the representation of global identifiers, BridgeDb relies on the MIRIAM URI standard [A standard . MIRIAM mapping service to describe a resource for mapping information among identifiers from two or more data sources. This broad definition could include simple tables in a text file as well as complete relational databases or online web services such as Ensembl BioMart and PICR.We use the term BridgeDb allows stacking, or combining, of different mapping sources both in transitive and non-transitive modes. Transitivity means the inference of second- or even third-degree mappings from direct mappings. Transitivity becomes an important issue especially when combining mapping services in a stack. In general it is preferable to make use of global resources such as Ensembl BioMart for annotation of microarray data, but this is not possible for custom microarrays that are not distributed widely. In those cases, custom annotation files must be used. A custom annotation file can be produced to map custom identifiers to all other biological identifiers that one might wish to consider. But BridgeDb allows an alternative approach, where one only needs a very simple mapping of custom identifiers to one gene identifier, and can rely on Ensembl BioMart to provide the rest. For example, if the custom annotation file defines relations between custom identifiers and Entrez Gene, and Ensembl BioMart provides mapping between Ensembl and Entrez Gene, then mappings between the custom identifier and Ensembl can be inferred. In this way, the task of creating custom annotations is much simpler, while at the same time enabling broader coverage of data sources. This process is depicted in Figure The implementation of BridgeDb is described here for each of the three layers of Figure The Application Programming Interface (API) of BridgeDb takes two different forms. The first form is based on Java and is suitable for Java applications. The other is based on Representational State Transfer (REST) and is suitable for all other programming languages.The structure of the Java API is represented in Figure http://localhost/Human/search/ENSG00000122375 includes the following query parameters: 'search' specifies the type of query, 'Human' is the organism database being searched, and 'ENSG00000122375' is the query input. In this example, a list of identifiers and data sources corresponding to the query would be returned in the form of tab-delimited plain-text. Developer documentation for BridgeREST is also available on the BridgeDb website [In addition to the Java API, we provide a REST-based interface. The required software can run in the background and can be embedded in non-Java applications. Each function is accessed by a URL that specifies the address of the service and query parameters. For example,  website .The mapping services supported by BridgeDb can be broadly categorized in three groups: flat files, relational databases, and online web services. Flat text files are great for custom annotations. Local relational databases provide the fastest access. They are stable and make long-running analyses repeatable. Web services are not as fast as local databases but potentially provide the broadest range of data and if well maintained, are more up-to-date.In addition to supporting a number of third-party mapping services, BridgeDb also provides its own mapping services, in the form of BridgeDerby databases for efficient mapping of genes, proteins and metabolites, and in the form of a webservice named BridgeWebservice. Thus, BridgeDb can be used as a complete identifier mapping solution out-of-the-box for common bioinformatics applications. See Table The BridgeDerby mapping service is based on the Derby relationWe create database files per species for genes and proteins. We also created a database file for metabolites, which is species-independent. Using the stacking mechanism, the metabolite database and a species-specific gene and protein database can easily be combined to form a complete database for biological entities of a given species. The procedures for creating these two types of database files are described below in more detail.The database files for genes and proteins are based on Ensembl. RelevanThe same information as contained in the Derby databases is also stored in MySQL databases, using the same schema. This form of the data is maintained for web service accessibility. Practical limitations on the size of the distributed Derby databases are not an issue for MySQL. Thus, additional identifier systems, annotations and cross-references can be stored in the MySQL databases. Furthermore, with greater capacity, this system will be able to support additional types of information such as exon, transcript, and protein domain alignments, polymorphisms, and homology, which are also available from Ensembl.Currently, the database files for metabolites are based on HMDB Metabocards, becauseBroadly speaking, BridgeDb can be useful whenever an application needs to make use of multiple mapping services or wants to enable the user to choose among different services. To demonstrate this, we have integrated BridgeDb into a number of bioinformatics tools. These implementations are described below illustrating four different occurrences of the identifier mapping problem.WikiPathways is a collection of biological pathways open to community curation[ curation. PathwayNetwork Merge plugin for Cytoscape[The Cytoscape can aligPathVisio[PathVisio is a patCyThesaurus plugin for Cytoscape can perform large-scale identifier translation on biological entities in Cytoscape networks using BridgeDb. The plugin can be used for different purposes. For example, when multiple identifier sources are used in the networks of interest, this plugin can be used to translate different types of identifiers to a common identifier type so that identities of the biological entities in the networks will be unified. Alternatively, to export Cytoscape networks for use in other tools that require different identity types, one can utilize CyThesaurus plugin to translate the identifiers into identifier types that other tools can understand.The Once BridgeDb has been incorporated in a bioinformatics tool, it will be possible to choose a suitable identifier mapping solution for the job at hand. There are a few considerations when choosing the right service. First, when should two identifiers map to one another? What is the basis for a mapping? An identifier is a reference to a database record about a biological entity. If two databases describe the exact same biological entity, then certainly the identifiers should map to each other. But most applications require a broader definition of identifier mapping. When aligning microarray data with a pathway model based on genes, for example, there is a need for mapping microarray reporters to genes and gene products even though these are different biological entities.The facile switching of mapping services makes it easy to compare them programatically. In a simple test we found that most web services integrated in BridgeDb are in agreement to a high degree. Four different webservices were able to map successfully more than 80% of a set of 1000 random Affymetrix probeset identifiers. For 72% of the total set, the result was identical for each webservice. For a given set of 100 Ensembl gene identifiers, each webservice was able to map over 91%, and the identical subset was 86%  from the end-user.Theoretically, it would be good to do away with the multiplicity of biological databases and designate a single universal identifier for each biological entity. However, this would not eliminate the need for identifier mapping, as there would still be a need to relate different biological entities such as transcripts and reporters. That fact, combined with the current situation of multiple gene databases, means that we have to deal with the identifier mapping problem in the best possible way. We believe that standardizing on a framework used by several programs in unison provides a robust and extensible solution.Importantly, identifier mapping should be performed as late as possible in a given workflow or annotation scheme. Gene databases change over time as more information becomes available. Experimental datasets, on the other hand, are fixed once the experiment is done. The experimental data should be annotated as closely as possible to the experimental conditions. Consider for example microarray data. Perez-Iratxeta et al.  have fouSeveral mapping services supported by BridgeDb are provided by us Table . We consThe BridgeDb concept derived from our experience as developers of different bioinformatics tools. The Application Programming Interface (API) was designed to be used by multiple tools and has proven its usability for a combination of applications with different uses.We believe that it is better to build identifier mapping into a tool rather than requiring users to perform identifier mapping manually or with separate tools. Burdening the researcher to perform identifier mapping ignores the problem and dramatically limits the usability of the tool. Relying on external solutions also introduces unknown factors into the workflow that can lead to unreliable analysis results. By integrating a mapping service directly in the bioinformatics software tools, error-prone data preparation steps are avoided.Different software packages solve the identifier mapping problem in different ways. We propose to modularize the identifier mapping problem into a single library. This has several advantages. Using a shared library means that developers can pool efforts, rather than investing considerable effort into maintaining isolated solutions. Tools that currently do not implement identifier mapping could do so with very little effort by just adding a module to the project.BridgeDb frees bioinformatics tools from compromising on solutions to the identifier mapping problem. By providing a standardized layer through which different mapping services can be used, BridgeDb makes it easy for tool developers to support and switch between multiple services. BridgeDb can also be used to combine or merge mapping services to support multi-omics experiments or integrate custom resources.Project name: BridgeDb.Project home page: http://www.bridgedb.org.Operating systems: platform independentProgramming language: implemented in Java, compatible with any programming language.Other requirements: Java Runtime Environment version 1.5 or higher.License: Apache 2.0 License. Source can be found at http://svn.bigcat.unimaas.nl/bridgedb. A snapshot of the code is available as additional file Any restrictions to use by non-academics: none.MI drafted the paper. TK developed the first derby databases. AP developed the Ensembl ETL process for MySQL and derby database production. MI and JG designed the BridgeDb API. IH improved the Ensembl ETL process and developed the REST web service. JG developed both Cytoscape plugins. AP and KH contributed to the original GenMAPP identifier mapping strategy. CE and BC provided valuable feedback and support. All authors have read and approved the final manuscript.BridgeDb example in Java. This is a simple example script that demonstrates how the BridgeDb library can be used to map an identifier using two different mapping services.Click here for fileCounter-example not using BridgeDb. This is a counter-example that does the same as additional file Click here for fileRaw results of the comparison of four different webservices. The script used to extract this data is included in additional file Click here for fileSource code of the BridgeDb java library version 0.9. For the latest version we recommend to use our subversion repository at http://svn.bigcat.unimaas.nl/bridgedb.Click here for file