BioMOBY successfully integrates distributed heterogeneous bioinformatics Web Services. The PlaNet exemplar case

Abstract

The burden of non-interoperability between on-line genomic resources is increasingly the rate-limiting step in large-scale genomic analysis. BioMOBY is a biological Web Service interoperability initiative that began as a retreat of representatives from the model organism database community in September, 2001. Its long-term goal is to provide a simple, extensible platform through which the myriad of on-line biological databases and analytical tools can offer their information and analytical services in a fully automated and interoperable way. Of the two branches of the larger BioMOBY project, the Web Services branch (MOBY-S) has now been deployed over several dozen data sources worldwide, revealing some significant observations about the nature of the integrative biology problem; in particular, that Web Service interoperability in the domain of bioinformatics is, unexpectedly, largely a syntactic rather than a semantic problem. That is to say, interoperability between bioinformatics Web Services can be largely achieved simply by specifying the data structures being passed between the services (syntax) even without rich specification of what those data structures mean (semantics). Thus, one barrier of the integrative problem has been overcome with a surprisingly simple solution. Here, we present a non-technical overview of the critical components that give rise to the interoperable behaviors seen in MOBY-S and discuss an exemplar case, the PlaNet consortium, where MOBY-S has been deployed to integrate the on-line plant genome databases and analytical services provided by a European consortium of databases and data service providers.

Figure 1.

Schematic representation of the participants, the architecture, and the messaging processes in the MOBY-S Web Service brokering system. A, First, service providers (s) each register themselves in a centralized registry (b) indicating their input, output, and the type of data service they provide. B, Data consumers (c) then query the registry looking for service providers capable of executing the desired data retrieval or transformation service, the registry responds by providing a machine-readable description of the service interface. C, The data consumer is now able to automate the execution of the desired service to acquire the output data.

Figure 2.

A, The MOBY Triple representing a DNASequence object containing the AGI Locus At5g20240. B, The XML serialization of the same object, derived from an interpretation of the object ontology (Fig. 3). C, The same data entity now represented as a FASTA object, as defined by the object ontology (Fig. 3).

Figure 3.

A small portion of the MOBY-S object ontology. The ontology has object classes at the nodes, and these are connected by two types of edges representing subclass (“ISA”; solid arrows) and container relationships (dashed arrows). The graph above would be interpreted using the following statements: “A string is a type of object. An integer is a type of object. A virtual sequence is a type of object that also contains an integer. A DNA sequence is a type of virtual sequence that also contains a string. Formatted text is a type of string. FASTA is a type of formatted text.” The full object ontology can be obtained as an RDF-XML document from http://biomoby.org/RESOURCES/MOBY-S/Objects.

Figure 4.

Architecture of the PlaNet federated database. The user interface and Web display provide a single point of access to data and analysis tools provided by the distributed partners. To this end, all databases are linked via a connectivity layer developed by PlaNet in collaboration with the BioMOBY project. The component databases make their data available as BioMOBY Web Services (the connectivity layer) and interactions between individual services, and between services and the user interface, are orchestrated by the BioMOBY registry system (BioMOBY layer). Integration tools can be developed that use the connectivity layer to compare data in different databases and thus ensure data consistency. Besides data sources, BioMOBY also provides for the integration of analysis tools and applications.

Figure 5.

Examples of data flow made possible by the PlaNet BioMOBY connectivity layer. Services (not all shown here) are represented as arrows linking input and output data objects in this graph. For example: A, starting from a keyword all corresponding AGI locus codes can be found. B, The AGI locus codes can then be used to retrieve the NASC codes (http://www.arabidopsis.info). C, With the NASC code in hand, a third service can be queried to find the Arabidopsis phenotypes for them. This example combines three services that operate on data from two different service providers (MIPS/Neuherberg, represented as solid arrows, and NASC/Nottingham, represented as dashed arrows), previously requiring two separate Web query forms. The workflow just described could also be automated in an application. Complex queries can be realized through pipelining services and filters in a workflow where the output of one service is the input of another service. The services are accessible through a simple, Web-based query client prototype at http://www.eu-plant-genome.net.

Figure 6.

A sample AGI locus report Web page dynamically generated by querying the MOBY Central registry at MIPS. The AGI locus report gives links to the Web interfaces of partner databases (left) as well as all MOBY-S services (right) on the same results page. The list of services is not static, and will grow as PlaNet partners register new relevant services in MOBY Central. The end-user, however, simply chooses the data that they are interested in retrieving, and the transaction is automatically carried out for them, regardless of which partner(s) host the requested data. Thus, the AGI locus report page acts as a dynamic portal through which all information known about a locus can be retrieved.