Alignment API: Implementation

This page describes the different classes available in the Alignment API implementation. For instructions how to use them, the reader is refered to the tutorial pages.

Basic alignment structures

A (default) implementation of this API can be found in the fr.inrialpes.exmo.align.impl package. It implements the API by providing the simple basic classes: BasicAlignment, BasicCell, BasicRelation and BasicEvaluator. These classes provide all the necessary implementation for the API but the algorithm specific methods (Alignment.align() and Evaluator.eval()). It also provides an RDF/XML parser that can parse the format into an Alignment object.

It is thus advised to extend these basic implementations instead of reimplementing everything (of course, there may be good reasons for doing otherwise).

Along with these basic classes the default implementation provides a library of other classes, mentioned below.

URI-based implementation

The URI-based implementation is a first concrete implementation of the Alignment API in which entities in correspondences are URI. It defines classes URIAlignment and URICell.

Object implementation

The Object implementation is an implementation of the Alignment API in which entities are OWL entities (classes, object properties, data properties, instances). It defines classes ObjectAlignment and ObjectCell. It is built on top of the abstract ontology layer Ontowrap which is extensible. This layer allows to use different ontology APIs within the Alignment API. This implementation is useful for implementing matching algorithms which needs to have access to the actual ontologies.

It is possible to transform instances of these classes through two primitives:

toURIAlignment()

in ObjectAlignment transforms an ObjectAlignment into and URIAlignment;

static ObjectAlignment.toObjectAlignment(Alignment)

which transforms an URIAlignment into an ObjectAlignment provided that it is possible to load the two ontologies

static EDOALAlignment.toEDOALAlignment(Alignment)

which transforms an URIAlignment or ObjectAlignment into an EDOALAlignment provided that it is possible to load the two ontologies and dereference their URIs.

Useful abstract classes such as DistanceAlignment are built on top of this implementation as well as the old OWLAPIAlignment which has been maintained for compatibility purposes.

EDOAL alignments

The EDOAL language is implemented as an extension of the Alignment API. It defines classes EDOALAlignment and EDOALCell.

Trimming

In general, alignment structures can be manipuled algebraically. This is described in more details in the dedicated page. We only discuss trimming here.

If neither ontology needs to be completely covered by the alignment, a threshold-based filtering would allows for retaining only the highest confidence entity pairs. Triming, for most of its actions, requires that the set M supporting confidence measures be a totally ordered set. Without the injectivity constraint, the pairs scoring above the threshold represent a sensible alignment.

The easier way to proceed consists of selecting correspondences over a particular threshold. However, we implemented several methods. They are identified in the cut method by a following string switches:

hard

retains all the correspondences above or equal to threshold n;

span

retains all the correspondences which are above or equal to the best value minus n;

prop

retains all the correspondences which are above or equal to n% of the best value;

perc

retains the n% best values (beware, ex-aequos are drawn at random).

The method is invoked by:

Parsing

This API implementation does provide support for manipulating alignments. It offers a number of services for manipulating the API. The following primitives are available:

parsing

an alignment from a file in RDF/XML (AlignmentParser.parse());

The method is invoked by:

Rendering

The obtained alignment can, of course, be generated in the RDF serialisation form of the Alignment format. However, there are other formats available.

The method is invoked by:

The API provides the notion of a visitor of the alignment cells. These visitors are used in the implementation for rendering the alignments. So far, the implementation is provided with seven such visitors (in parenthesis is the minimal class from which renderer works):

RDFRendererVisitor

displays the alignment in the RDF format as well as EDOAL. An XSLT stylesheet is available for displaying the alignments in HTML from the RDF/XML format.

OWLAxiomsRendererVisitor (ObjectAlignment)

generates an ontology merging both aligned ontologies and comprising OWL axioms for expressing the subsumption, equivalence and exclusivity relations.

XSLTRendererVisitor

generates an XSLT stylesheet for transforming data expressed in the first ontology in data expressed in the second ontology;

COWLMappingRendererVisitor (ObjectAlignment)

generates a C-OWL mapping, i.e., a set of relations expressed between elements (in fact classes) of two ontologies.

SWRLRendererVisitor (ObjectAlignment)

generates a set of SWRL rules for inferring from data expressed in the first ontology the corresponding data with regard of the second ontology.

SEKTMappingRendererVisitor (ObjectAlignment)

generates a mapping document as was defined in the SEKT document.

SKOSRendererVisitor

generates a SKOS mapping document.

Some of these methods, like XSLT or SWRL, take the first ontology in the alignment as the source ontology and the second one as the target ontology.

Generating axioms

OWL itself provides tools for expressing axioms corresponding to some relations that we are able to generate such as subsumption (subClassOf) or equivalence (equivalentClass). From an alignment, the OWLAxiomsRendererVisitor visitor generates an ontology that merges the previous ontologies and adds the bridging axioms corresponding to the cells of the alignment.

This returns:

<rdf:RDF
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

  <owl:Ontology rdf:about="">
    <rdfs:comment>Aligned ontollogies</rdfs:comment>
    <owl:imports rdf:resource="http://www.example.org/ontology1"/>
    <owl:imports rdf:resource="http://www.example.org/ontology2"/>
  </owl:Ontology>

  <owl:Class rdf:about="http://www.example.org/ontology1#reviewedarticle">
    <owl:equivalentClass rdf:resource="http://www.example.org/ontology2#article"/>
  </owl:Class>

  <owl:Class rdf:about="http://www.example.org/ontology1#journalarticle">
    <owl:equivalentClass rdf:resource="http://www.example.org/ontology2#journalarticle"/>
  </owl:Class>

</rdf:RDF>

Generating XSLT translations

Alignements may be used for translation as well as for merging. Such a transformation can be made on a very syntactic level. The most neutral solution seems to generate translators in XSLT. However, because it lacks deductive capabilities, this solution is only suited for transforming data (i.e., individual descriptions) appearing in a regular form.

The XSLTRendererVisitor generates transformations that recursively replace the names of classes and properties in individuals. The renderer produces stylesheets like:

Generating SWRL Rules

Finally, this transformation can be implemented as a set of rules which will ``interpret'' the correspondence. This is more adapted than XSLT stylesheets because, we can assume that a rule engine will work semantically (i.e., it achieves some degree of completeness with regard to the semantics) rather than purely syntactically.

The SWRLRendererVisitor transforms the matching into a set of SWRL rules. The result on the same example will be the following:

Of course, level 2 alignments would require specific renderers targeted at their particular languages.

Generating C-OWL mappings

The COWLMappingRendererVisitor transforms the alignment into a set of C-OWL mappings. The result on the same example will be the following:

Generating SEKT-ML mappings

The SEKTMappingRendererVisitor transforms the alignment into a SEKT mapping document. The result on the same example is the following:

Of course, level 2 alignments would require specific renderers targeted at their particular languages.

Generating SKOS

The SKOSRendererVisitor transforms the alignment into a SKOS mappings. The result on the same example is the following:

Sample matchers

DistanceAlignment class template

The API features a DistanceAlignment abstract class that can be specialised for creating a similarity or distance based matching method. This class offers a variety of methods for extracting alignments from distance matrix.

TO BE FURTHER DOCUMENTED

Collection of predefined algorithms

The implementation of the Alignment API offers a small library of basic matchers. These are simply here as examples of matchers. Several of these algorithms have been run to provide the alignments between the two considered ontologies:

NameEqAlignment

Simply compares the equality of local class and property names (once downcased) and align those objects with the same name;

EditDistNameAlignment

Uses an editing (or Levenstein) distance between (downcased) entity names. It thus has to build a distance matrix and to choose the alignment from the distance;

SubsDistNameAlignment

Computes a substring distance on the (downcased) entity name;

StrucSubsDistNameAlignment

Computes a substring distance on the (downcased) entity names and uses and aggregates this distance with the symmetric difference of properties in classes. This class is not available anymore within the API.

These simple algorithms should increase the accuracy of the matching results.

All these simple demonstration algorithms of the Alignment API, sould be rewritten with regard to the more generic DistanceAlignment and StringDistAlignment abstract classes.

Evaluating

Evaluators are described in a separate page.