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 overcome 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.
Linkkeys can be defined for expressing conditions under
which, instances of the aligned entities should be considered equivalent.
The buttons below can be used to show or hide the available syntaxes.
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.
Support
EDOAL is supported in the following way by the Alignment API:
API: A full EDOAL API is implemented allowing to manipulate EDOAL alignments.
Parser: EDOAL Alignments can be properly parsed and expressed in
the API through the AlignmentParser (and more precisely the RDFParser).
Server: the Alignment server can manipulate EDOAL alignments and,
in particular, can store them in the datatabe. It can only partially
render them in the interface (see HTML below).
Renderer: EDOAL can be rendered in RDF, JSON or OWL. It can only be
partially rendered in other formats, in particular, SPARQL and HTML.
In addition, it is possible to convert alignments from one format to
EDOAL in Java. So far, this is not possible in the command-line
interface.
This is achieved through the static
method EDOALAlignment.toEDOALAlignment( al );
such that al is a BasicAlignment. For this to be possible, the API should be able to access
the ontologies concerned by the alignment.
An example can be found in the EDOALExport test file.
Alignment and cells
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.
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). EDOAL vocabulary is dereferenceable (see below).
Alignment format
An EDOAL alignment is an alignment as specified by the Alignment format.
It is identified by its level which must be "2EDOAL".
This tells tools that the alignment is on level 2, i.e., correspondences are across constructed entities, and that the corresponding entities are specified according to the expressive language.
This ensures the compatibility with other extensions of the format.
The alignment moreover specifies the two aligned ontologies, and as
exemplified in the code below.
As the example shows, the EDOAL vocabulary only appears within the
"entity" properties and very specificaly in
the edoal:transformation and edoal:linkkey
properties.
The correspondence between the two entities could have been expressed
in the simple Alignment format because these have named entities
identified by a URI. However, the correspondence provides more
information because it tells that these entities are Classes.
The strength of EDOAL is to express more complex entities which are
described below.
Entities
A quick overview of the implemented EDOAL API is provided here (abstract
classes are in bold and interfaces in italics):
The Id interface is implemented by expressions identified by
an URI: these are the named entities of ontologies that may be used in
basic URIAlignments. The ValueExpression is implemented by
expressions that identify in context a particular value or instance.
This can be an instance or a literal as well as a path expression that
leads to that value in the context of an instance.
Hence, the entities that can be found in cells are:
Below are the syntactic declaration of these entities.
Class expressions
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 also be identified by using its URI or defined through a
restriction. There are four types of class restrictions:
AttributeDomainRestriction which restricts the values of
relations to be in a particular class;
AttributeTypeRestriction which restricts the values of
properties to be in a particular type;
AttributeValueRestriction which restricts the value of
properties or relations to a particular value;
AttributeOccurenceRestriction which constrains the
cardinality of a property or relation;
These four types of restrictions restrict the scope of a class expression by applying a restriction to the value, type or cardinality of a particular property or relation.
Restrictions are defined by giving an path expression (relation or property), a comparator defining the relation to a value.
This grammar relies on base values described in the following
table:
onatt ::= <onAttribute> attexpr </onAttribute>
typerest ::= <datatype> type </datatype>
type ::= <Datatype rdf:about=" URI " />
classrest ::= <class> classexpr </class>
comp ::= <comparator rdf:resource=" URI "/>
Comparators have to be defined as specific URI, usually in the edoal
namespace. They are currently described by: edoal:equals,
edoal:lower-than, edoal:greater-than, the latter morally corresponding to the
op:numeric-less-than and op:numeric-greater-than from
the XQuery 1.0 and
XPath 2.0 Functions and Operators recommendation.
Hence, a class expression may be an identified class:
vin:Acidite a edoal:Class .
vin:Amertume a edoal:Class .
vin:Astreingence a edoal:Class .
[] a edoal:Class ;
edoal:or ( vin:Acidite vin:Astreingence vin:Amertume ) .
Thanks to paths and restrictions, it is possible to restrict a correspondence to ``Wines whose producing region is located in Aquitaine'' using the following restriction:
xsd:integer a edoal:Datatype .
[] a edoal:PropertyTypeRestriction ;
edoal:datatype xsd:integer .
Relation expressions
Relations correspond to object properties in OWL. Relation expressions can be constructed using one of the operators and, or,
not and compose as well as "closure" operator inverse,
symmetric, transitive and reflexive:
and denotes the conjunction of several relations, i.e.,
the set of pairs of individuals which are in all the relations,
or denotes the disjunction of several relations, i.e.,
the set of pairs of individuals which are in one of the relations,
not denotes the complement of a relation, i.e., the set of
pairs of individuals which are not in the relation,
compose denotes the
inverse denotes the converse of a relation,
symmetric denotes the symmetric closure of a relation
(this is equivalent to or( p inverse( p ) ),
transitive denotes the transitive closure of a relation,
reflexive denotes the reflexive closure of a relation.
A relation can also be identified by using its URI or defined through
a restriction. There are two classes of relation restrictions:
wine:Wine a edoal:Class .
wine:locatedIn a edoal:Relation .
vin:hasTerroir a edoal:Relation .
[] a align:Cell ;
align:entity1 [ a edoal:Relation ;
edoal:and ( wine:locatedIn
[ a edoal:Relation ;
edoal:domainRestriction wine:Wine ] ) ] ;
align:entity2 vin:hasTerroir ;
align:measure "1.0"^^xsd:float ;
align:relation "<" .
An example of occurrence restriction would be the wines produced in a region with no adjacent region, such as an island. For instance Moscatel Madeira wine is produced on the island of Madeira.
wine:Wine a edoal:Class .
wine:adjacentRegion a edoal:Relation .
wine:hasTerroir a edoal:Relation .
vin:Madere a edoal:Class .
[] a align:Cell ;
align:entity1 [ a edoal:Class ;
edoal:and ( wine:Wine [ a edoal:AttributeOccurrenceRestriction ;
edoal:onAttribute [ a edoal:Relation ;
edoal:compose ( wine:hasTerroir wine:adjacentRegion ) ] ;
edoal:comparator edoal:greater-than ;
edoal:value [ a edoal:Literal ;
edoal:string "0" ;
edoal:type "http://www.w3.org/2001/XMLSchema#integer" ] ] ) ] ;
align:entity2 vin:Madere ;
align:measure "1.0"^^xsd:float ;
align:relation ">" .
Another example
uses a path to state that a locally grown wine is a wine whose owner (propriétaire) is the same person as the first seller (négociant) for this wine.
wine:LocallyGrownWine a edoal:Class .
vin:Vin a edoal:Class .
vin:négotiant a edoal:Relation .
vin:propriétaire a edoal:Relation .
[] a align:Cell ;
align:entity1 wine:LocallyGrownWine> ;
align:entity2 [ a edoal:Class ;
edoal:and ( vin:Vin
[ a edoal:AttributeValueRestriction ;
edoal:onAttribute vin:propriétaire ;
edoal:comparator edoal:equals ;
edoal:value vin:négotiant ] ) ] ;
align:measure "1.0"^^xsd:float ;
align:relation ">" .
Note that compose may take no
argument in case of relations. This may be useful in some
circumstances.
<compose rdf:parseType="Collection"/> is equivalent to
the identity relation, hence when applied to an object has for
unique value the object itself (it is the equivalent self
or this in some languages).
Value expressions
A value expression may be used in alignments for denoting an
individual things (not a class, a property or a relations). These
values may be:
a litteral value;
an individual instance;
a value reachable to a property or relation;
a value computable by a function from arguments which are values.
They obey the following grammar:
val ::= <value> value </value>
value ::= <Literal {edoal:type=" URI "} {edoal:lang=" LANG "} edoal:string=" STRING " />
| instexpr
| attrexpr
| <Apply edoal:operator=" URI "> <arguments rdf:parseType="Collection">value*</arguments> </Apply>
| <Aggregate edoal:operator=" URI "> <arguments rdf:parseType="Collection">value*</arguments> </Aggregate>
instexpr ::= <Instance rdf:about=" URI "/>
O1:component a edoal:Property .
O2:weight a edoal:Property .
[] a edoal:Aggregate ;
edoal:operator "http://www.w3.org/2005/xpath-functions#sum" ;
edoal:arguments ( [ a edoal:Property ;
edoal:compose ( O1:component O1:weight ) ] ) .
The actual implementation of the edoal:operator values is out of the
scope of EDOAL. URIs to use as the operator attribute of Apply (and
Aggregate) are not
specified. Depending on the use of the alignments, operators may be
implemented in various way. In order to provide a useful and portable way to
express operations, EDOAL promotes the use of the following conventions:
XPath functions (fn:name, op:name and xs:type)
Operators from
the XQuery and
XPath Functions and Operators (3.1) recommendation.
This is the recommended way to identify functions because they have
URIs and the XPath library is already quite large.
(fn: prefix used
for http://www.w3.org/2005/xpath-functions and op
prefix used as a convention and does not corresponds to a URI
prefix! In addition, the xs: prefix for http://www.w3.org/2001/XMLSchema is used for type
coercion as with the "as" operation)
SPIN function (sp:name)
It would be convenient to use standard SPIN functions as
well. However, SPIN functions are usually declared in another
namespace, e.g., qodtspin, so they may not be usable here
(sp: prefix used
for http://spinrdf.org/sp? spin for http://spinrdf.org/spin#?)
Web service (http://service prefix)
It should be possible to call a web service (but for this to work
parameters should be named and not just listed)
Java (static) method (java:fully qualified class name#method name)
The fully qualified name of a
Java method, e.g., java.net.URI#toString, may be used referring to
a Java implementation (it can be from any namespace).
Otherwise (uri)
Any URI is possible but its interpretation is undefined.
EDOAL could have come with yet another standard set of built-in
functions, but we decided to refrain from introducing it and prefer to
rely on more standard efforts.
Transformations
Transformations are expressed in the cell itself. Transformations do
not express constraints on the classes or properties, but constraints
on instances that should match.
transformation ::= <Transformation edoal:direction=" STRING ">
<entity1> value </entity1>
<entity2> value </entity2>
</Transformation>
withSTRING ::= 'o-' | '-o'
Transformations can be invoked, for example for dynamic transformations like currency conversions (see examples).
The following correspondence shows an example of the use of data transformation:
stating that whatever an instance of the class c has the same
values for
properties p1,... pn as an
instance of class d has for
properties q1,... qn and
that their values for respectively p'1,... p'm
and q'1,... q'm instersect pairwise, then
these two are the same entity.
Such keys are slightly more complex than in databases because in RDF
properties are not necessarily functional (they may have several
values) and their values may be other objects. For this reason, it is
necessary to indicate if it is required that all values must be the same
(Equals) or if some of them must instersect (Intersects).
Linkkeys are primarily used for identifying identical objects.
For instance, it may be that a instance of the Livre class is
equivalent to an instance of the Novel class as soon as their
properties auteur and titre on the one side
and creator and title on the other side have the same values.
This is expressed in the following example:
O1:Livre a edoal:Class .
O1:auteur a edoal:Relation .
O1:titre a edoal:Property .
O2:Novel a edoal:Class .
O2:creator a edoal:Relation .
O2:title a edoal:Property .
edoal:cell-with-linkkey a align:Cell ;
align:entity1 O1:Livre ;
align:entity2 O2:Novel ;
align:relation "=" ;
edoal:linkkey [ a edoal:Linkkey ;
lk:type "plain" ;
edoal:binding [ a edoal:Intersects ;
edoal:property1 O1:auteur ;
edoal:property2 O2:creator ],
[ a edoal:Equals ;
edoal:property1 O1:titre ;
edoal:property2 O2:title ] ] .
It is then possible to identify duplicates or to
generate owl:sameAs links.
EDOAL Patterns
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 documented at a later stage.
Contact us if you need such a language or have an idea of what it should do.
The following correspondence pattern uses 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".
: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:onAttribute :var3.
].
].
align:entity2 :var2.
Graph
Longer examples
Various examples are in the alignment files found in the
"examples/omwg" directory of the Alignment API release zip.
The following examples illustrate various kids of usage of the vocabulary.
Class partition
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.
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:onAttribute 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:onAttribute 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:onAttribute O1:hasColor;
edoal:comparator function:equals;
edoal:value O1:Green.
];
edoal:and O1:LED.
align:entity2 O2:GreenLED.
Graph
Class equivalence by restricting values
This example expresses that any INSEE Département (French
administrative circunscription) is a NUTS region of level 2
situated in France (note the use of composition for reaching FR).
nuts:FR a edoal:Instance .
nuts:Region a edoal:Class .
nuts:level a edoal:Property .
nuts:hasParentRegion a edoal:Relation .
insee:Département a edoal:Class .
[] a align:Cell ;
align:entity1 insee:Département ;
align:entity2 [ a edoal:Class ;
edoal:and ( nuts:Region
[ a edoal:AttributeValueRestriction ;
edoal:comparator edoal:equals ;
edoal:onAttribute [ a edoal:Relation ;
edoal:compose ( nuts:hasParentRegion nuts:hasParentRegion ) ] ;
edoal:value nuts:FR ]
[ a edoal:AttributeValueRestriction ;
edoal:comparator edoal:equals ;
edoal:onAttribute nuts:level ;
edoal:value [ a edoal:Literal ;
edoal:string "2" ;
edoal:type "http://www.w3.org/2001/XMLSchema#int" ] ] ) ] ;
align:relation "=" .
Equivalence between a relation and a class
In this example, instances of the class "Connection" are equivalent
to the relation "connectedWith". The definition of the correspondence
allows to transform immediately one into the other and vice-verse
because the first part is defined as a relation.
O1:Connection a edoal:Class .
O1:sourceComponent a edoal:Relation .
O1:targetComponent a edoal:Relation .
O2:connectedWith a edoal:Relation .
edoal:M6 a align:Cell ;
align:entity1 [ a edoal:Relation ;
edoal:compose (
[ a edoal:Relation ;
edoal:inverse O1:sourceComponent ]
[ a edoal:Relation ;
edoal:and ( O1:targetComponent
[ a edoal:RelationDomainRestriction ;
edoal:class O1:Connection ] ) ] ) ] ;
align:entity2 O2:connectedWith ;
align:measure "1.0"^^xsd:float ;
align:relation "=" .
Extensive use of data transformations
This example shows two classes which are trivially equivalent but
which needs a lot of transformations to convert one instance into
another.
The value of hasLeader is obtained by applying regular
expression substitution on the full name of the leader;
The firstname and lastname of the leader is obtained by
manipulating the value of hasLeader (in the first case through XPath
function, in the second case through an imaginary non portable Java
function. Note that these operations go in the opposite directions
as the former one and allows for complementary transformations;
The duration is obtained by subtracting start date from end date
(unsing a standard XPath operation);
The load is obtained by summing the manpower required by each subtask;
The cost is obtained by calling an external service providing
currency convertion.
This example illustrates the conversion between two currencies. A transformation service is specified.
Due to popular demand, here is the derefenceable version of the RDF
vocabulary used in the format. Official URI is http://ns.inria.org/edoal/1.0/.
Beware, that EDOAL has been designed as
a format and an API rather than a generic RDF vocabulary. A natural
ontology would be closer to the API but would give a more verbose
EDOAL format. The EDOAL format is in RDF and compact. In consequence,
not any RDF graph using the EDOAL vocabulary is a well-defined EDOAL
alignment. In particular, RDF can express incomplete knowledge while
the EDOAL API requires complete knowledge of the alignment.
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.
The linkkey idea has been promoted by Jérôme Euzenat, further refined with Jérôme David and Manuel Atencia and finally implemented in the Alignment API (version 4.7) by Nicolas Guillouet.