Transparent mediation-based access to multiple yeast data sources using an ontology driven interface

Abstract

Background: Saccharomyces cerevisiae is recognized as a model system representing a simple eukaryote whose genome can be easily manipulated. Information solicited by scientists on its biological entities (Proteins, Genes, RNAs...) is scattered within several data sources like SGD, Yeastract, CYGD-MIPS, BioGrid, PhosphoGrid, etc. Because of the heterogeneity of these sources, querying them separately and then manually combining the returned results is a complex and time-consuming task for biologists most of whom are not bioinformatics expert. It also reduces and limits the use that can be made on the available data.

Results: To provide transparent and simultaneous access to yeast sources, we have developed YeastMed: an XML and mediator-based system. In this paper, we present our approach in developing this system which takes advantage of SB-KOM to perform the query transformation needed and a set of Data Services to reach the integrated data sources. The system is composed of a set of modules that depend heavily on XML and Semantic Web technologies. User queries are expressed in terms of a domain ontology through a simple form-based web interface.

Conclusions: YeastMed is the first mediation-based system specific for integrating yeast data sources. It was conceived mainly to help biologists to find simultaneously relevant data from multiple data sources. It has a biologist-friendly interface easy to use. The system is available at http://www.khaos.uma.es/yeastmed/.

Figure 1

General architecture of YeastMed system. It shows how the different components of YeastMed System are structured and interact between them.

Figure 2

The ontology-based search interface of YeastMed. It shows how is captured the example sketched in this section.

Figure 3

A fragment of the yeastract schema. It is used in YeastMed as a model describing data and their organisation in data source and defines a structure under which results will be returned by the Yeastract web service.

Figure 4

Architecture of the web services in YeastMed system. Services receive Xqueries through the different methods of the API and transmit them to the wrapper. The output is an XML document.

Figure 5

A fragment of the YeastMed ontology. It shows the semantic encapsulation of the concepts related to DNA sequences in YeastMed. For example the concept GeneSequence which represents the set of gene sequences is a child of the concept DNASequence which represents all type of DNA sequences. DNASequence is in turn a child of NASequence which represents the set of nucleic acid sequences.

Figure 6

A schematic representation of the example sketched in this section. It shows four biological concepts (ellipses) linked by four object properties (red arrows) and two parent-child relationships (blue arrows), and two datatype properties (green arrows) linking two concepts to values of type String (rectangles).

Figure 7

The fragment of the ontology invoked to formulate the query example. Classes are shown in green and Properties in blue. The mappings between the ontology and the source schemas are present above the ontology element (in red).

Figure 8

The plan tree generated from the conjunctive query. The plan tree is a binary tree where nodes are represented by variables of the predicate arguments in the conjunctive query and the edges are predicates containing the two variables of the nodes they are linking.

Figure 9

The information presented by the node P in the plan tree. The node P contains the location of the YeastMed ontology and the web service to call, in addition to the mapping resources and the xquery to send to the web service.

Figure 10

SUS scores of YeastMed in function of the frequencies of using biological database. The graph shows that the evolution of the mean SUS scores increases progressively when the frequency of using biological databases of biologists increases.

Figure 11

Run times performed by YeastMed to answer a query. The figure shows how run times of the three main stages required to answer queries behave when the number of the implied sources increases.