While the Grid and Web Services have helped us support heterogeneous resource access through the use of service oriented architectures, they have not addressed the issue of heterogeneous data representation. Since service providers often describe their service interfaces using different data models than those assumed by the client, it is common for additional processing to be required to compensate for the mismatch in data formats. By utilising technology from the Semantic Web, we are able to augment existing Web Service systems with middleware to automatically perform data harmonisation when a syntactic mismatch occurs. To achieve this, we have developed a mapping language which can be used to annotate XML data structures with OWL concepts and properties, a Mapping Language Engine to implement this language, and a Dynamic Web Service Invocation component to execute Web Services.
Web Services are software components designed to
support interoperable machine to machine interaction over a
network. By defining standard languages to present
software interfaces, such as WSDL [
The Semantic Web [
To focus our work, we examine a common service interaction from a bioinformatics Grid application. We identify where syntactic incompatibility occurs and why automated mediation is desirable. We then show the benefits of using ontologies to describe XML data structures and how this link can be specified using a mapping language. There follows a description of our mapping language and examples of how it can be used to annotate XML data structures. We then present our Mapping Language Engine which implements the mapping language and performs translations between XML data and OWL concepts. Finally, we show how our Mapping Language Engine can be incorporated with our Dynamic Web Service Invocation component to create a system that performs syntactic mediation between Web Services using different data representations.
This paper is organised as follows: Section 2 introduces our bioinformatics use case, Section 3 presents the theory behind using semantic annotations, and Section 4 describes our mapping language, the Mapping Language Engine and how it is combined with the Dynamic Web Service Invoker. Section 5 reviews related work before we conclude and show further work in Section 6. 2
Bioinformatics is the application of computational techniques to the management and analysis of biological information. With the collection and storage of large quantities of genomic and proteomic data, coupled with advanced computational analysis tools, a bioinformatician is able to perform experiments and test hypothesis without using conventional ‘wet bench’ equipment - a technique commonly referred to as in silico experimentation. To support this kind of science, a large collection of databases and tools has been developed to provide bioinformaticians with access to massive amounts of biological data and powerful computational software.
The MYGRID 1 project provides an open-source Grid
middleware that supports in silico biology. Using a
serviceoriented architecture based on Web Service standards such
as WSDL and UDDI [
For our use case, we examine a common bioinformatics task: retrieve sequence data from a database and pass it to an alignment tool to check for similarities with other known sequences. According to the service-oriented view of resource access adhered to by MYGRID, this interaction can be modelled as a simple workflow with each stage in the task being fulfilled by a Web Service.
Many Web Services are available to retrieve sequence data. For our example, we use one available at XEMBL http://www.ebi.ac.uk/xembl/
2http://taverna.sourceforge.net/docs/xscuflspecification.html 3http://sourceforge.net/projects/freefluo/ 4http://taverna.sourceforge.net/ Sequence
Data NCBI-Blast
Blast
Results XEMBL
DDBJ-XML
Get Sequence Data Sequence Alignment and another at DDBJ-XML http://xml.ddbj.nig.ac.jp/index.html. To obtain a record, an accession number is passed as input and an XML document is returned. These documents essentially contain the same data, namely the sequence data as a string (e.g. atgagtga...), references to publications, and features of the sequence (such as the protein translation). However, the format returned by each provider is different - XEMBL returns a BSML formatted document5 and DDBJ returns a document using to their own custom format6.
The next stage in the workflow is to pass the sequence data to an alignment service such as the BLAST service at NCBI7. This service can take a string of sequence data as input and return the result set in XML. We show this simple workflow in Figure 1.
Intuitively, a bioinformatician will view the two
sequence retrieval tasks as the same type of operation,
expecting both of them to be compatible with the NCBI Blast
service. However, when plugging the two components
together, additional information must be provided to specify
how data is extracted from one data structure and passed
into the next. This could be achieved using a data
transformation language such as XSLT [
6http://getentry.ddbj.nig.ac.jp/xml/DDBJXML.dtd 7http://www.ncbi.nlm.nih.gov/BLAST/ from all other compatible types would have to be specified. Finally, users are not interested in the details of the service interaction; they prefer them to be hidden so they can focus on the scientific problem.
We propose an architecture in Section 4 that utilises Semantic Web technology to enable the automated mediation of syntactic structure between Web Services. By annotating XML structures with ontology concepts and properties, described in Section 3, we are able to automatically integrate syntactically incompatible services. 3
In this section we show how an ontological definition of a data format can be used to integrate data structures passed between Web Services. We continue using the bioinformatics services presented in Section 2. This example is centred around the concept of some ‘sequence data’. We have devised a simple ontology to express this information, which is shown in Figure 2. The main concept, Sequence_Data , has the datatype property sequence (denoting the string of sequence data), description (a text annotation) and accession_id (unique id). Each sequence has a number of references which is represented by the has-reference object property type and a number of features, represented by the has-feature object property. There are a number of sequence features, we show two common ones in this example; feature_source (where and how the sequence was gathered), and feature_CDS (which shows the protein sequence translation and id). Since BSML format and DDBJ format also contain additional information on the sequence, we introduce subconcepts called BSML_Sequence_Data and DDBJ_Sequence_Data.
When examining the two services presented by XEMBL and DDBJ, we can consider their input and output to be similar; each take a sequence data accession id as input and both return some sequence data. To be more specific, the XEMBL service returns the concept BSML_Sequence_Data and the DDBJ service returns the concept DDBJ_Sequence_Data . The next service in the workflow, NCBI Blast, takes some sequence data as input, namely an individual of type Sequence_Data with the sequence property type specified. Given that the BSML_Sequence_Data and DDBJ_Sequence_Data concepts are both subsumed by the Sequence_Data concept, i.e. the Sequence_Data concept is considered more general, we say that the output from both of the sequence data retrieval services is semantically compatible with the input to the BLAST service. However, the services are not syntactically compatible since the output dataset cannot be passed directly as input to the BLAST service. Therefore, a stage of syntactic mediation is required to extract data from one dataset and transform it to create a new dataset.
To automate the process of syntactic mediation, we
require mappings from concrete XML structures to conceptual
ontology structures. To enable this specification, we have
developed a mapping language, presented in Section 4.1,
which can be used to specify mappings between XML and
OWL [
When using OWL concepts and properties to annotate an XML data structures, we do not require mappings between all compatible formats. Instead, each data format requires only one mapping to the ontological specification. With this approach, the number of mappings required for each compatible data format has a complexity of O(n) instead of the quadratic complexity discussed in Section 2. It is also more convenient when adding new formats to an existing system since only one mapping is required to achieve maximum interoperability.
8http://www.ecs.soton.ac.uk/˜mns03r/mapping/bsml mapping.mp and http://www.ecs.soton.ac.uk/˜mns03r/mapping/ddbj mapping.mp
Our mapping language can be used to specify two types of mapping: ontology concept instances to XML and XML to ontology concept instances. The grammar for the language is given in Figure 4 using standard BNF notation. A mapping is composed of a source type ({type}), source expression, a mapping symbol (<->), a destination type, a destination expression and set of using statements that map URLs to prefixes. An expression can be one of five kinds: helemi, hconstanti, hvari, hspliti or hconcati. An element expression corresponds to a concept or property type name for an ontology concept instance or the element name within XML document. The contents of an element, contained within parenthesis, is a sequence of further expressions delimited by a comma. These sub-expressions cor‚mappingÚ ::= {‚typeÚ} ‚expÚ ‚mapsymÚ {‚typeÚ} ‚expÚ ‚usingÚ | {‚typeÚ} ‚expÚ ‚mapsymÚ {‚typeÚ} ‚expÚ | ‚typeÚ ::= xml | owl ‚expÚ ::= ‚elemÚ [ ‚attr*Ú ]( ‚exp*Ú ) | ‚elemÚ ( ‚exp*Ú ) | ‚elemÚ [ ‚attr*Ú ]( ‚exp*Ú )‚elliÚ | ‚elemÚ ( ‚exp*Ú )‚elliÚ | ‚concatÚ ( ‚atom*Ú )| ‚concatÚ ( ‚atom*Ú )‚elliÚ| ‚splitÚ ( ‚atom*Ú )| ‚splitÚ ( ‚atom*Ú )‚elliÚ| ‚constantÚ | ‚varÚ ‚exp*Ú ::= ‚expÚ |
‚exp*Ú , ‚expÚ ‚attrÚ ::= ‚qnameÚ = ‚varÚ |
‚qnameÚ = "‚constantÚ" ‚attr*Ú ::= ‚attrÚ | ‚attr*Ú , ‚attrÚ ‚atomÚ ::= ‚constantÚ |
‚variableÚ ‚atom*Ú ::= ‚atomÚ |
‚atom*Ú , ‚atomÚ ‚elemÚ ::= ‚qnameÚ ‚qnameÚ ::= ‚charsÚ : ‚charsÚ |
‚charsÚ ‚constantÚ ::= "‚charsÚ"
‚varÚ ::= $‚charsÚ ‚mapsymÚ ::= <->
‚elliÚ ::= ... ‚concatÚ ::= concat ‚splitÚ ::= split ‚usingÚ ::= USING ‚binding*Ú ‚bindingÚ ::= ‚prefixÚ for < ‚urlÚ > ‚binding*Ú ::= ‚bindingÚ |
‚binding*Ú , ‚bindingÚ ‚prefixÚ ::= ‚charsÚ respond to child nodes of the parent element (for XML) or property types of the parent concept (for OWL). If the subexpression is a variable, this denotes that the text child of the parent is bound to the the variable (prefixed by a $ symbol). Hence, the value of a variable within the source expression is mapped to the corresponding variable value in the destination expression. Constants may be specified for elements in the destination expression to define element or concept constructions that are created independently of the inputs. A list of attributes may also be specified for an XML mapping by enclosing them within square brackets after the element name. An attribute expression may either assign a variable to an attribute value or specify the condition that an element must have an attribute with a specific value to be valid. An example of the variable assignment attribute construct can be found in Figure 3(a) where the accession id is extracted from an attribute named ic-acckey in the <bsml:Sequence> element.
The hspliti and hconcati expressions may be used in source and destination expressions respectively. The hspliti function takes three arguments; a variable, a constant and another variable. When applied to the text of an XML element or the value of an OWL datatype property, the string is split into two according to the delimiter specified in the second argument and assigned to the two variables specified. If more than one match is found, the string is broken at the first instance of the delimiter. The hconcati expression can be used in destination expressions to indicate the concatenation of constants or variables.
We include the hellii (ellipsis) construct to enable the processing of lists. This can be utilised when many instances of the same element within XML are to be mapped to many concept relations in the ontology (or vice versa). It is Mapping Language Engine
Parser
Executor Output Data owl xml
Data Model
also possible to use the hellii suffix with the hconcati
operator to indicate multiple element values that map to a single
element. In both cases, the ellipsis construct preserves the
order of list elements. The inspiration for the ellipsis
construct came from the Scheme [
Our Mapping Language Engine (MLE), pictured in Figure 5, is a JAVA component built on the Jena Framework9 and Dom4J10. To carry out a transformation, the MLE can be passed a mapping statement and a source data structure. A source data structure may be an XML document (using OWL serialisations for ontology concepts) or a reference to an individual within a Jena Ontology Model. The MLE parses the mapping expression and builds a list of variable bindings from the source expression. The destination expression is then evaluated and a new data structure is created. The result can be returned in either XML (again using OWL syntax for the serialisation of ontology concepts) or as a reference to a newly created individual within the Jena Ontology Model.
Because we use Jena to store our OWL models, we can take advantage of the in-built reasoning it provides, the most useful of which is subsumption. Subsumption, usually denoted as C v D, is the reasoning process through which the concept denoted by D (the subsumer) is checked to see if it is more general that the concept denoted by C (the subsumee). With Jena, this task is performed automatically when new concepts and individuals are introduced into the current Jena model. In our example, we see that the results from the first stage of the workflow (i.e. the sequence retreival services) can be BSML_Sequence_Data or DDBJ_Sequence_Data concepts. When the MLE creates a new individual to represent the service output from either of these services, it uses the approriate concept (ie.
10http://www.dom4j.org/ BSML or DDBJ sequence data). When inserted into the current model, Jena will automatically classify an individual of either concept as Sequence_Data too since it subsumes both concepts. Therefore, when creating the XML data set for input into the NCBI Blast service, either concept type is valid and the sequence data can be extracted. With this approach, users have the freedom to extend existing ontology definitions with their own more specific concepts without breaking compatibility with other more general data models. 4.3
To enable the execution of Web Services, we have created a Dynamic Web Service Invoker (DWSI). The DWSI takes an XML representation of the WSDL input and the service endpoint and invokes the service. The results of the service are returned in XML. In Figure 6, we show how the DWSI can be combined with the MLE to create a system that automatically mediates between different representations of the same data. This diagram shows one possible execution of our bioinformatics use case. In this instance, the XEMBL service is used to retrieve the sequence data after which it is passed to the NCBI Blast service for analysis. The first step is shown in the bottom left of the diagram where the accession id is passed to the XEMBL service. The result is a BSML formatted representation of the sequence data. This is then passed to the MLE, along with Mapping 1, where it is translated into a BSML_Sequence_Data concept and inserted into the Jena model. The uppermost box in Figure 6 shows a snapshot of the Jena model with the datatype properties holding example data. To enable the invocation of the NCBI Blast service, the MLE takes Mapping 2 and creates an XML representation of the sequence data that is compatible with the blast service. This XML is then passed to a new instance of the DWSI which invokes the service. Finally, the results of the blast service are returned by the DWSI.
We have tested the performance cost of our preliminary prototype against hard coded XSLT transformations. On average, an XSLT transformation takes 30ms where our MLE takes approximately 190ms - six time more processing time to perform the same translation. We consider this an acceptable cost considering the high level of interoperability our system supports. This cost is also a small fraction of the network time required in a Web Service invocation which is usually around 5000ms or more. 5
OWL-S [
The Web Services Modelling Ontology (WSMO) [
The SEEK project [
In this paper, we have used a bioinformatics Grid application to show the problem of data integration in open, service oriented architectures. We have identified a typical scenario where different syntactic structures are used by service providers, and how this effects the workflow process. After presenting the motivation behind a framework to support the automated mediation of syntactic structures, we describe our solution, which is based on the use of Semantic Web technology. By mapping XML data structures to OWL concepts and properties, we can describe service inputs and outputs according to their conceptual types. When services are then plugged together, as in our use case where sequence data is retrieved from a database and passed to an alignment service, we can automatically transform data structures between different formats.
In terms of our mapping language, it would be useful to incorporate regular expression support for string matching. Our current language only provides a simple split operator that can be used to break down atomic string values into separate components. With regular expression support, we could allow users to specify more complex string manipulation functions.
Our current architecture assumes that mappings are known, therefore, it would be beneficial to create a mapping repository which exposes a query interface allowing users to register new mappings, discovery new mappings and identify the semantic type of a given XML fragment.
Once such a registry has been implemented, we can integrate it with out MLE and DWSI so the appropriate mappings are retrieved automatically.
Finally, our last task is to formalise the link between syntactic type systems and the description logic models that underpin the OWL reasoning methods. We believe that a sound understanding of the problem will enable us to support a generic solution that is expressive enough to cope with a wide range of complex data structures.
This research is funded in part by EPSRC myGrid project (reference GR/R67743/01).