[Alignment format] [API]

# EDOAL: Expressive and Declarative Ontology Alignment Language

The Expressive and Declarative Ontology Alignment Language (EDOAL) allows for representing correspondences between the entities of different ontologies. Unlike other formats, the alignment vocabulary allows to represent complex correspondences allowing to precisely describe the relation between the entities. The alignment vocabulary extends the alignment format.

## Purpose

Representing ontology alignments is the general purpose of this vocabulary. Particularly, it extends the ontology alignment format in order to enable the representation of complex correspondences.

This format can be used for cases where expressing equivalence or subsumption between terms is not sufficient, when more precise relations need to be expressed. While term equivalence or subsumption might be enough for exchanging documents, more precise relations are needed to exchange and integrate data.

This vocabulary was originally designed with the goal of representing patterns of correspondence between ontologies. It was since then both simplified and extended to obtain a minimal vocabulary on top of the alignment format, able to express all possible kinds of ontology alignments.

## Features

The alignment vocabulary has the following features:

- Construction of entities from other entities can be expressed through algebraic operators. Constructed entities allows to supply the shallowness of some ontologies.
- Restrictions can be expressed on entities in order to narrow their scope. Narrowing the scope of an entity makes possible to better align this entity with the one corresponding in the other ontology.
- Transformations of property values can be specified. Property values using different encoding or units can be aligned using transformations. The current version of Edoal only supports a limited kind of transformations. This will be improved soon.

## Vocabulary

In the alignment format, an alignment is a set of cells, each cell being a correspondence between two entities. The alignment vocabulary extend this scheme by allowing cells to contain compound entity descriptions. Each entity can be typed according to one of the following category: Class, Instance, Relation, Property. A relation corresponds to an object property in OWL, a property to a datatype property. Each entity can then be restricted, and transformation can be specified on propery values.

The diagram below shows the vocabulary classes ???

While Alignment and Cell are described by the alignment format, we will focus here on the remaining classes.

### Headers

#### Namespaces

The namespace for the Alignment format is still `http://knowledgeweb.semanticweb.org/heterogeneity/alignment#` (usual prefix: align).

EDOAL's own namespace is `http://ns.inria.org/edoal/1.0/` (usual prefix: edoal).

Comparators are taken from the W3C XPath functions recommendation: `http://www.w3.org/2005/xpath-functions` (usual prefix: functions).

#### Alignment

As specified by the alignment format, an alignment contains a set of correspondences (cells). Each cell can be linked to an alignment using the map property. The alignment moreover specifies the two aligned ontologies, and as exemplified in the code below.

    <?xml version='1.0' encoding='utf-8' standalone='no'?>
    <rdf:RDF xmlns='http://knowledgeweb.semanticweb.org/heterogeneity/alignment#'
             xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
             xmlns:xsd='http://www.w3.org/2001/XMLSchema#'
             xmlns:align='http://knowledgeweb.semanticweb.org/heterogeneity/alignment#'>
    <Alignment>
      <xml>yes</xml>
      <level>0</level>
      <type>**</type>
      <align:method>fr.inrialpes.exmo.align.impl.method.StringDistAlignment</align:method>
      <align:time>7</align:time>
      <onto1>
        <Ontology rdf:about="http://www.example.org/ontology1">
          <location>file:examples/rdf/onto1.owl</location>
          <formalism>
            <Formalism align:name="OWL1.0" align:uri="http://www.w3.org/2002/07/owl#"/>
          </formalism>
        </Ontology>
      </onto1>
      <onto2>
        <Ontology rdf:about="http://www.example.org/ontology2">
          <location>file:examples/rdf/onto2.owl</location>
          <formalism>
            <Formalism align:name="OWL1.0" align:uri="http://www.w3.org/2002/07/owl#"/>
          </formalism>
        </Ontology>
      </onto2>
    ...

Details on each property are available on the alignment format page.

### Entities

#### Classes

Class entities can be constructed using one of the three operators and, or, not.

- and represents the interesection of the classes in the expression
- or represents the union of the classes in the expression
- not represents the negation of a given class.

A class can be defined using its URI or a restriction. Restrictions are defined by giving an attribute (relation or property), a comparator defining the relation to a value.

    classexpr ::= <Class rdf:about=" URI "/>
                | <Class> classconst </Class>
                | <AttributeOccurenceRestriction> onatt comp INTEGER </AttributeOccurenceRestriction>
                | <AttributeDomainConstraint> onatt (classexpr|type) </AttributeDomainConstraint>
                | <AttributeValueRestriction> onatt comp (instexpr|val) </AttributeValueRestriction>

    classconst ::= <and rdf:parseType="Collection"> classexpr+</and>
                 | <or rdf:parseType="Collection"> classexpr+ </or>
                 | <not> classexpr </not>

This grammar relies on base values described in the following table:

    entity ::= instexpr | classexpr | attexpr

    attexpr ::= propexpr | relexpr

    onatt ::= <onAttribute> attexpr </onAttribute>

    val ::= <value> value </value>

    datatype ::= <type> value </type>

    comp ::= <comparator rdf:resource=" URI "/>

    value ::= <Literal string=" STRING " /> | instepr | attrexpr
            | <Apply operator=" URI "> <arguments rdf:parseType="Collection">value*</arguments> </Apply>

Comparators are taken from the XPath function specification [1].

#### Properties

Properties entities can be constructed using one of the operators and, or, not and compose. Property values can be transformed by applying a Transformation function.

    propexpr ::= <Property rdf:about=" URI "/>
               | <Property> propconst+ </Property>
               | <PropertyDomainRestriction> <class> classexpr </class> </PropertyDomainRestrict
               | <PropertyTypeRestriction> datatype </PropertyTypeRestriction>
               | <PropertyValueRestriction> comp val </PropertyValueRestriction>

    propconst ::= <and rdf:parseType="Collection"> propexpr+ </and>
                | <or rdf:parseType="Collection"> propexpr+ </or>
                | <not> propexpr </not>
                | <compose> relexpr* propexpr </compose>

Transformations are of two kinds, either XPath transformation functions can be used, or other transformation services can be invoked, for example for dynamic transformations like currency conversions (see examples).

#### Relations

Relations correspond to object properties in OWL. Relation entities can be constructed using the operators and, or, not, compose, but also inverse, transitive, reflexive, and symmetric. Like properties they can also be composed in a path of relations using first and next. Relations domain and range can be restricted.

    relexpr ::= <Relation rdf:about=" URI "/>
             | <Relation> relconst+ </Relation>
             | <RelationDomainRestriction> <class> classexpr </class> </RelationDomainRestriction
             | <RelationCoDomainRestriction> <class> classexpr </class> </RelationCoDomainRestriction

    relconst ::= <and rdf:parseType="Collection"> relexpr+ </and>
               | <or rdf:parseType="Collection"> relexpr+ </or>
               | <not> relexpr </not>
               | <compose> relexpr+ </compose>
               | <inverse> relexpr </inverse>
               | <symmetric> relexpr </symmetric>
               | <transitive> relexpr </transitive>
               | <reflexive> relexpr </reflexive>

#### Instances

Instances are always single entities refering to an individual through its URI.

    instance ::= <Instance rdf:about=" URI "/>

## Examples

The following exmples illustrate various kids of usage of the vocabulary.

### Class partition

This example shows how to express a correspondence between a classes in one ontology corresponding to a set of classes in the other ontology. In order to graps the precise correspondence, the one class is partitioned according to the value of one of its attributes. In this example one ontology has a class LED which has a property color, while the other ontology has three classes RedLED, BlueLED, and GreenLED. The LED class is aligned with the three corresponding classes by specifying a restriction of its scope to the corresponding value of the color attribute.

The alignment expressed in RDF/N3 is the following:

    O1:LED a edoal:Class;
    O1:hasColor a edoal:Relation.
    O1:Blue a edoal:Instance.
    O2:BlueLED a edoal:Class.
    :cell1 a align:Cell;
    	align:entity1 [
    		edoal:and [
    			edoal:onProperty O1:hasColor;
    			edoal:comparator function:equals;
    			edoal:value O1:Blue.
    		];
    		edoal:and O1:LED.
    	align:entity2 O2:BlueLED.
    O1:Red a edoal:Instance.
    O2:RedLED a edoal:Class.
    :cell2 a align:Cell;
    	align:entity1  [
    		edoal:and [
    			edoal:onProperty O1:hasColor;
    			edoal:comparator function:equals;
    			edoal:value O1:Red.
    		];
    		edoal:and O1:LED.
    	align:entity2 O2:RedLED.
    O1:Green a edoal:Instance.
    O2:GreenLED a edoal:Class.
    :cell3 a align:Cell;
    	align:entity1  [
    		edoal:and [
    			edoal:onProperty O1:hasColor;
    			edoal:comparator function:equals;
    			edoal:value O1:Green.
    		];
    		edoal:and O1:LED.
    	align:entity2 O2:GreenLED.

The corresponding graph:

### Property value transformation (XPath function)

This exemple shows how to use a transformation between property values. Two cases can be considered: static transformations such as unit conversion, and transformations which vary over time such as currency conversions. This example illustrates a static conversion from pounds to kilograms using a XPath function.

    01:hasWeight a edoal:Property.
    O2:weight a edoal:Property.
    :cell a align:Cell;
    	align:entity1 O1:hasWeight;
    	align:entity2 [
    		a Transformation;
    		fn:safe-divide [
    			a rdf:Seq;
    			rdf:li O2:weight;
    			rdf:li 2.679229.
    		].
    	].

The corresponding graph:

### Property value transformation (other service)

This example illustrates the conversion between two currencies. A transformation service is specified.

The alignment expressed in RDF/N3 is the following:

    O1:price a edoal:Property.
    O2:hasPrice a edoal:Property.
    :cell a align:Cell;
    	align:entity1 [
    			edoal:function <http://www.google.com/finance/converter?>;
    			edoal:parameters [ rdf:li O1:price;
    			  rdf:li "from=EUR";
    			  rdf:li "to=CNY".
    		   ].
    	];
    	align:entity2 O2:hasPrice.

The corresponding graph:

### Class with attribute value restriction

This alignment pattern makes use of three variables. Var3 is a property variable representing a property having in its domain the class of the class variable Var1. Morover, the property Var3 has an interger value. This pattern thus captures all correspondences between two classes, the scope of one class being restricted to only those instances having a specific value (not specified by the pattern) for one of its property whith datatype "integer".

    :var1 a edoal:Variable;
    	a edoal:Class.
    :var2 a edoal:Variable;
    	a edoal:Class;
    :var3 a edoal:Variable;
    	a edoal:Property;
    	edoal:and [
    		edoal:domainRestriction :var1.
    	].
    	edoal:and [
    		edoal:typeRestriction <http://www.w3.org/2001/XMLSchema#integer>.
    	].
    :Cell1 a align:Cell;
    	align:entity1 [
    		edoal:and :var1;
    		edoal:and [
    			a edoal:Restriction;
    			edoal:onProperty :var3.
    		].
    	].
    	align:entity2 :var2.

The corresponding graph:

## EDOAL Pattern

EDOAL also contains a pattern language with allows for expressing generalised correspondences in which entities can be abstract. This language is not very different from EDOAL (beside its introduction of variables).

It will be released at a later stage. Ask François Scharffe for a more complete description of the EDOAL Pattern language.

## History

This language has been first designed by François Scharffe as the SEKT Mapping language.

It then became the OMWG Ontology Mapping language developed under the Sourceforge mappingapi project (http://sourceforge.net/projects/mediation/). This language was further described by François Scharffe, Jérôme Euzenat and Antoine Zimmermann in Knowledge web deliverable 2.2.10, in particular through the semantics of the language. Its implementation was also reengineered as an extension of the alignment format so that it could be manipulated through the Alignment API tools (starting version 3.1).

It has now been redesigned and reimplemented under the name of EDOAL. It is a plain component of the Alignment API and is maintained together with it.