Currently, in the Semantic Web in Healthcare and Life Sciences large ontologies representing a “consensus” world-view are selected, then data relevant to those ontologies is manually located and aggregated prior to reasoning. This approach presents challenges in addition to the real-world limitations of reasoning over such large-scale data: data critical to discovery in the life sciences must often be generated dynamically by analytical algorithms. Here we describe a prototype system - SHARE - that consumes ontologies and queries and automatically discovers, retrieves, and reasons over information relevant to that ontological world view by locating and executing Web Services. The SHARE system exhibits what we believe are crucial characteristics of the Semantic Web vision: relevant information is dynamically discovered and/or generated from distributed resources, and is interpreted, updated, or reinterpreted as the over-laid local ontology changes.
As Semantic Web technologies become more pervasive in bioinformatics, we must
urgently define scalable ways to discover, analyse, and organize biological data in
ways that encourage scientific exploration, discourse and disagreement, and in a
manner compliant with the proposed Semantic Web “stack”[
SHARE (the Semantic Health and Research Environment) is a mediator system
that enables simultaneous querying of databases and analytical programs distributed
across the Web, where resources are exposed as Services using the SADI (Semantic
Automated Discovery and Integration) Semantic Web Service framework[
In contrast to typical SPARQL query engines, SHARE does not search an existing RDF dataset for a sub-graph with a specified triple-pattern structure. Instead, SHARE utilizes SADI by matching individual triple-patterns in the SPARQL query against SADI Service interface descriptions (in OWL) to discover services capable of generating those triple patterns; thus the RDF data required to answer any given SPARQL query is dynamically generated in response to the query being posed. Note that while distributed SPARQL endpoints may provide some of the query-relevant data, data may also be dynamically generated through execution of an application or algorithm since all resources are exposed as Web Services, thus making the nature of the underlying data resource opaque to the client.
We first introduce the methodology by which SHARE converts SPARQL queries into Web Service workflows. We then show how formal OWL Class definitions can similarly be converted into workflows, thus making it possible to dynamically discover OWL Individuals, compiled from globally distributed data resources, that are compliant with the OWL Classes in a given local or remote ontology. 2
SHARE utilizes properties in a SPARQL query (the predicates in the triple-patterns) as keys in a query against the SADI registry. Thus the process of discovery for any given query is relatively straightforward.: for each triple pattern (s,p,o) SHARE searches for services that have p, or the OWL inverse of p, as one of their generated properties. Consequently, at each step there are two cases:
Case 1: s is a concrete node (URI or literal), or a variable that is already bound to a set of candidate nodes. In this case, the triple pattern is resolved in the forward direction. First, the SADI registry is queried to find Services that are capable of generating the predicate in the triple pattern. For each Service discovered, the candidate nodes of s are compared, using an OWL reasoner, to the axioms in the input OWL Class definition for the discovered service. Matching nodes become rdf:typed according to the Service input class and are submitted for processing. (Optionally, SHARE itself can be used to dynamically resolve OWL Class membership as defined in §2.2 below.) If o has not been bound to any candidate nodes, the set of retrieved values for property p become the candidates of o.
Case 2: s has no candidate nodes and o is a concrete node (URI or literal) or a variable bound to a set of candidate nodes. In this case, the triple pattern is resolved as above, but in the reverse direction: instead of p, the OWL inverse of p is used to find Services. The retrieved values for inverse(p) become the bindings of s.
Between these two cases, it is frequently possible to automatically synthesize a Web Service workflow that collects all query-relevant data prior to SPARQL query resolution. It is currently not possible with SHARE to resolve triple patterns where both s and o are unbound, but SHARE attempts to order the query to avoid this case. We are experimenting to determine the optimal behaviour when p, the predicate itself, is unbound, but s and/or o are bound.
When OWL Class definitions extend beyond mere declaration of a Class and include axioms that must be fulfilled in order to achieve class membership, those axioms can be used to drive Web Service discovery in a manner similar to that described above for SPARQL queries. SHARE decomposes the definition of the Class to determine what properties are required for Class membership and these properties (p) are used as keys in a SADI service look-up. For each discovered Service, candidate individuals matching the Service‟s input OWL Class are submitted for processing. Further, if a candidate individual does not conform to a Service‟s Input Class definition, the OWL axioms of that input Class are similarly decomposed and used for further Web Service discovery until all required data elements are present.
Clearly, this iterative process must halt, and these stop-points are either nonaxiomatic Class definitions or axioms with strict value requirements. In bioinformatics both cases often involve database identifiers, so SHARE requires all database record URIs to be explicitly rdf:typed according to their source database. At present, SHARE is coded to recognize identifiers from the LSRN and bio2rdf database record naming schemes; URIs that adhere to either scheme will be automatically rdf:typed by SHARE and can be used for Web Service matchmaking, allowing most simple queries to be performed with no initial data whatsoever.
The example query below demonstrates SADI+SHARE functionality. This query can
be executed at the CardioSHARE client website[
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX patients: <http://biordf.net/cardioSHARE/patients.owl#> PREFIX bmi: <http://sadiframework.org/examples/bmi.owl#> SELECT ?patient ?bmi FROM <http://biordf.net/cardioSHARE/patients.rdf> WHERE { ?patient rdf:type patients:AtRiskPatient .
?patient bmi:BMI ?bmi }
The Service performs the BMI calculation based on the patient‟s height and
weight, the output RDF is stored in a transient triple store and a reasoner classifies the
appropriate URIs as instances of AtRiskPatient. Finally, the SPARQL query is
executed over the transient triple store. A more detailed walkthrough of the example
query[
We believe that this is the first time relevant, distributed data has been dynamically discovered, generated and assembled in response to the assertion of an ontological class. Formally classifying data in terms of its properties allows the consequences of a particular definition to be easily explored. Further, the ontological classes thus created provide a means to share domain knowledge among researchers. The SADI+SHARE approach, we believe, gives significant impetus to begin defining “personal ontologies” – ontologies that reflect an individual rather than a shared world view, which can then be resolved over global data and analytical resources. The first step towards a personalized Semantic Web! Acknowledgments. Heart + Stroke Foundation of BC and Yukon, Microsoft Research, The Canadian Institutes for Health Research, The Natural Sciences and Engineering Research Council of Canada, and CANARIE.