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.
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.
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.
While Alignment and Cell are described by the alignment format, we will focus here on the remaining classes.
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).
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.
A quick overview of the implemented EDOAL API is provided here (abstract classes are in bold and interfaces in italics):
EDOALAlignment extends BasicAlignment EDOALCell extends BasicCell Expression implements Clonable |- ClassExpression | |- ClassId implements Id | |- ClassConstruction | |- ClassRestriction | |- ClassDomainRestriction | |- ClassOccurenceRestriction | |- ClassTypeRestriction | |- ClassValueRestriction |- PathExpression implements ValueExpression | |- PropertyExpression | | |- PropertyId implements Id | | |- PropertyConstruction | | |- PropertyRestriction | | |- PropertyDomainRestriction | | |- PropertyTypeRestriction | | |- PropertyValueRestriction | |- RelationExpression | |- RelationId implements Id | |- RelationConstruction | |- RelationRestriction | |- RelationCoDomainRestriction | |- RelationDomainRestriction |- InstanceExpression |- InstanceId implements Id Value implements ValueExpression Apply implements ValueExpression Transformation TransfService implements Clonable Variable Comparator Datatype
Class entities can be constructed using one of the three operators and, or, not.
classexpr ::= <Class rdf:about=" URI "/> | <Class> classconst </Class> | <AttributeOccurenceRestriction> onatt comp INTEGER </AttributeOccurenceRestriction> | <AttributeDomainRestriction> onatt classrest </AttributeDomainRestriction> | <AttributeTypeRestriction> onatt typerest </AttributeTypeRestriction> | <AttributeValueRestriction> onatt comp (<value>instexpr</value>|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> typerest ::= <type> type </type> type ::= <Datatype rdf:about=" URI " /> classrest ::= <all> classexpr </all> | <exists> classexpr </exists> | <class> classexpre </class> comp ::= <comparator rdf:resource=" URI "/> value ::= <Literal {type=" URI "} string=" STRING " /> | instepr | attrexpr | <Apply operator=" URI "> <arguments rdf:parseType="Collection">value*</arguments> </Apply>
Comparators are taken from the XPath function specification [1].
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> </PropertyDomainRestriction> | <PropertyTypeRestriction> typerest </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>
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 are always single entities refering to an individual through its URI.
instance ::= <Instance rdf:about=" URI "/>
The best examples are the alignment files found in the "examples/omwg" directory of the Alignment API release zip.
The following exmples illustrate various kids of usage of the vocabulary.
In case of conflict, the RDF/XML syntax is the authoritative one. This is also the one for which we have developed parsers and renderers. However, we are glad that you report errors in the other syntaxes as well.
This example shows how to express a correspondence between a class 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.
<align:Cell rdf:about="#cell1"> <align:entity1> <edoal:Class> <edoal:and rdf:parseType="Collection"> <edoal:Class rdf:about="&O1;LED" /> <edoal:AttributeValueRestriction> <edoal:onAttribute> <edoal:Relation rdf:about="&O1;hasColor" /> </edoal:onAttribute> <edoal:comparator rdf:resource="&xsd;equals" /> <edoal:value><edoal:Instance rdf:about="&O1;Blue"/></edoal:value> </edoal:AttributeValueRestriction> </edoal:and> </edoal:Class> </align:entity1> <align:entity2><edoal:Class rdf:about="&O2;BlueLED" /></align:entity2> <align:relation>=</align:relation> </align:Cell> <align:Cell rdf:about="#cell2"> <align:entity1> <edoal:Class> <edoal:and rdf:parseType="Collection"> <edoal:Class rdf:about="&O1;LED" /> <edoal:AttributeValueRestriction> <edoal:onAttribute> <edoal:Relation rdf:about="&O1;hasColor" /> </edoal:onAttribute> <edoal:comparator rdf:resource="&xsd;equals" /> <edoal:value><edoal:Instance rdf:about="&O1;Red"/></edoal:value> </edoal:AttributeValueRestriction> </edoal:and> </edoal:Class> </align:entity1> <align:entity2><edoal:Class rdf:about="&O2;RedLED" /></align:entity2> <align:relation>=</align:relation> </align:Cell> <align:Cell rdf:about="#cell3"> <align:entity1> <edoal:Class> <edoal:and rdf:parseType="Collection"> <edoal:Class rdf:about="&O1;LED" /> <edoal:AttributeValueRestriction> <edoal:onAttribute> <edoal:Relation rdf:about="&O1;hasColor" /> </edoal:onAttribute> <edoal:comparator rdf:resource="&xsd;equals" /> <edoal:value><edoal:Instance rdf:about="&O1;Green"/></edoal:value> </edoal:AttributeValueRestriction> </edoal:and> </edoal:Class> </align:entity1> <align:entity2><edoal:Class rdf:about="&O2;GreenLED" /></align:entity2> <align:relation>=</align:relation> </align:Cell>
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.
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.
We give two valid version of this correspondence depending on if the correspondence apply to the two properties (version 1) or the bearer of the transformed properties (version 2).
<align:Cell rdf:about="#cell"> <align:entity1><edoal:Property rdf:about="&O1;hasWeight" /></align:entity1> <align:entity2><edoal:Property rdf:about="&O2;weight" /></align:entity2> <align:relation>=</align:relation> <edoal:transformation> <edoal:Transformation edoal:type="o-"> <edoal:entity1> <edoal:Property><edoal:compose rdf:parseType="Collection"/></edoal:Property> </edoal:entity1> <edoal:entity2> <edoal:Apply edoal:operator="&fn;safe-divide"> <edoal:arguments rdf:parseType="Collection"> <edoal:Property><edoal:compose rdf:parseType="Collection"/></edoal:Property> <edoal:Literal edoal:type="&xsd;float" edoal:string="2.679229" /> </edoal:arguments> </edoal:Apply> </edoal:entity2> </edoal:Transformation> </edoal:transformation> </align:Cell>
<align:Cell rdf:about="#cell"> <align:entity1><edoal:Class rdf:about="&O1;Person" /></align:entity1> <align:entity2><edoal:Class rdf:about="&O2;Patient" /></align:entity2> <align:relation>=</align:relation> <edoal:transformation> <edoal:Transformation edoal:type="o-"> <edoal:entity1><edoal:Property rdf:about="&O1;hasWeight" /></edoal:entity1> <edoal:entity2> <edoal:Apply edoal:operator="&fn;safe-divide"> <edoal:arguments rdf:parseType="Collection"> <edoal:Property rdf:about="&O2;weight" /> <edoal:Literal edoal:type="&xsd;float" edoal:string="2.679229" /> </edoal:arguments> </edoal:Apply> </edoal:entity2> </edoal:Transformation> </edoal:transformation> </align:Cell>
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. ]. ].
This example illustrates the conversion between two currencies. A transformation service is specified.
<align:Cell> <align:entity1><edoal:Property rdf:about="&O1;price" /></align:entity1> <align:entity2><edoal:Property rdf:about="&O2;hasPrice" /></align:entity2> <align:relation>=</align:relation> <edoal:transformation> <edoal:Transformation edoal:type="o-"> <edoal:entity1> <edoal:Property><edoal:compose rdf:parseType="Collection"/></edoal:Property> </edoal:entity1> <edoal:entity2> <edoal:Apply edoal:operator="http://www.google.com/finance/converter"> <edoal:arguments rdf:parseType="Collection"> <edoal:Property><edoal:compose rdf:parseType="Collection"/></edoal:Property> <edoal:Literal edoal:value="EUR" /> <edoal:Literal edoal:value="CNY" /> </edoal:arguments> </edoal:Apply> </edoal:entity2> </edoal:Transformation> </edoal:transformation> </align:Cell>
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.
This alignment pattern makes use of three variables. Var3 is a property variable representing a property having in its domain the class identified by the variable Var1. Moreover, the property Var3 has an integer 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".
<align:Cell rdf:about="#Cell1"> <align:entity1> <edoal:Class> <edoal:and rdf:parseType="Collection"> <edoal:Class edoal:var="#var1" /> <edoal:AttributeTypeRestriction> <edoal:onProperty> <edoal:PropertyDomainRestriction edoal:var="#var3"> <edoal:class> <edoal:Class edoal:var="#var1" /> </edoal:class> </edoal:PropertyDomainRestriction> </edoal:onProperty> <edoal:type><edoal:Datatype rdf:about="&xsd;integer" /></edoal:type> </edoal:AttributeTypeRestriction> </edoal:and> </edoal:Class> </align:entity1> <align:entity2> <edoal:Class edoal:var="#var2" /> </align:entity2> <align:relation>=</align:relation> </align:Cell>
: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.
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 which are already present in the previous example).
It will be released at a later stage. Ask François Scharffe for a more complete description of the EDOAL Pattern language.
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.
Thanks to Jonathan Snook and Robert Nyman for the syntax toggling scripts borrowed from the OWL Recommendation web page. http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/.