Ontology Mapping with SPARQL CONSTRUCT
Ontology mapping is regarded as one of the key technologies for data integration, for example to mediate between databases that have different but similar schemas. A lot of papers have been published on the topic (see a State of the Art paper from 2005).
I am not an expert in this topic, but most approaches that I have seen so far seem to employ specialized mapping ontologies that define bridges, for example to map a property "name" in a source ontology into property "lastName" in a target ontology. Mapping engines are then needed to interpret the mapping rules. I think a lot of research prototypes exist, but I don't think the Semantic Web community has reached any conclusive standard mapping ontology or implementations beyond prototypes yet.
We are running some very promising experiments with using SPARQL for ontology mapping. SPARQL is best known as the upcoming W3C standard query language for RDF, but few people notice that beside its SELECT command, SPARQL also defines a CONSTRUCT keyword. The input of a CONSTRUCT query is a WHERE clause describing a pattern in a source model, including variable definitions. The output is an RDF graph that inserts all matching variable bindings into a target graph template.
Here is an example screenshot from TopBraid Composer's new SPARQL visualization (click for a larger image). In this example, a SPARQL query is used to convert instances of a source:Person class into target:Persons. To make this example more interesting, the string values of source:car are converted into instances of a class target:Car (that's why the query looks so scary).
For example, if you have a set of source instances Bob and Alice
then the output is a new subgraph in the target model, but with the cars as objects instead of strings:
The trick is that CONSTRUCT generates new triples, and these triples can be treated as "inferences" and added to the target model. TopBraid's SPARQL window displays what happens under the hood (the screenshot actually shows a different version of the query from above):
As I said I am not an expert on ontology mapping and therefore don't want to comment whether this approach is better than other ontology mapping tools. However, it seems to me that the popularity of SPARQL and the large number of tools that support SPARQL make this a very promising idea. We may assume that in the near future most Semantic Web developers will know SPARQL and therefore don't need to learn any other "mapping ontology". Also, SPARQL is supported by optimized query engines, and SPARQL is fairly expressive with regards to query filters etc. And if the default expressivity is not enough, you still have property functions.
I guess a lot of more research can go into this idea, and lots of new papers could be written, for example on typical design patterns (such as a "property bridge" pattern), how to edit SPARQL visually and how to shape future editions of the SPARQL standard to meet the ontology mapping use case best. For example, it appears to be impossible to create new URIs for the resources in the target ontology - only bnodes can be created on the fly. We therefore added a simple post-processor that uses the rdfs:label to create suitable URIs.
Given the fact that CONSTRUCT queries can create or infer new triples, it may also be worth investigating whether SPARQL could serve as a rule language, similar to SWRL.
As a side effect of these new features (and its existing support to import relational databases, UML, XML Schema and Excel, and to operate on Jena, Oracle and Sesame databases), TopBraid Composer is increasingly becoming a data and knowledge integration platform and is no longer "just" an ontology editor.