Introduction
This deliverable presents the design of the mapping tool as a part of the ontology management environment DOME. This document is based on the requirements eclicited in the deliverable D7.1 we have designed the achitechture of the mapping tool. This repose on three components. The basic functionality of the tool is to give the user the possibility of expressing mappings between ontologies. It is in that scope important to have a formalism to express them, we call it mapping language. We have designed such a language and present it in section 2. From this language we will build mapping patterns section 3. They assist the user in finding the relevant constructs for specific mapping tasks. Once available the support to express the mappings, the should assist the user in this task. The main two way of giving the user assistance is first to provide a Graphical Interface that creates a graphical layer between the user and the mapping representation language. This Graphical Interface is designed in Java. We will see in section 3 the way we have designed it. The higher refinement in tool assistance to the user is to provide automation facilities so the mappings are (semi-)automatically found. we based this automation proces on an interface that allows to plug different algorithms that are coping with the different problems to solve in order to automatically find similarities between ontologies. Section 4 will present this interface.
Ontology Mapping Specification Language
Introduction
We present in this section the language developped on the basis of the requirements elicited in the deliverable D7.1. The language specification is given together with explenation about the role of the different constructs, in section 2.2 we give the core specification of the language that allow to express simple entity to entity mappings. In section 2.3 we extend this specification, allowing to map between many to many entities between the source and target ontologies. A set of operator is introduced to link together those entities. Section 2.4introduce constructs to condition the validity of the mappings and section 2.5 introduce the specification of instance transformations as a set of services. A full specification of the language in EBNF style is available at here. For tools and examples of this language, please consult the deliverable D7.3.
Simple mappings
We present here the mapping language developped to express corespondences between ontologies. This language is being developed as a joint effort in the WSMO and OMWG working groups, and the Sekt and Dip european projects (see the Acknowledgements).
We present the abstract syntax of the language written in EBNF, similar to the WSML (http://www.wsmo.org/wsml/wsml-syntax) abstract syntax. Any element between square brackets ‘[’ and ‘]’ is optional. Any element between curly brackets ‘{’ and ‘}’ can have multiple occurrences.
Each element of an ontology on the Semantic Web, whether it is a class, attribute, instance, or relation, is identified using a IRI which is an extension of the URI format. In the abstract syntax, a IRI is denoted with the name IRIReference. We define the following identifiers:
We allow concrete data values. The abstract syntax for data values is taken from the OWL abstract syntax:
The lexical form is a sequence of unicode characters in normal form C, as in RDF.
The language tag is an XML language tag, as in RDF.
First of all, the mapping document itself is declared, along with the ontologies participating.
A mapping consists of a number of annotations, corresponding to non-functional properties in WSMO (http://www.wsmo.org/), and a number of mapping rules. The creator of the mapping is advised to include a version identifier in the non-functional properties as well as other indications about the nature of the mappings.
The Alignment format is proposed in [Euzenat2004] and accessible at http://co4.inrialpes.fr/align/format.html. It is designed to express mappings resulting from matching algorithms. To comply with this format we introduce a special annotation. The measure gives an indication about the level of confidence of a mapping rule, it is given as a real number in [0,1]. This field is mainly used when the mappings are the results of a matching algorithm. It may also be proposed to a user in a graphical tool, if the mapping is complex and the user is not certain about his current modeling. The alignment format contains other field that compatible with the mapping language format. The relation gives the kind of relation standing between the two mapped expression. This information is given in the mapping language by the directionality field (see below).
A mapping can be either uni- or bidirectional. A unidirectional mapping from a source to a target means that the source expression is subsumed by the target one. This corresponds to the inclusion in the alignment format relation field. A bidirectional mapping means the source and the target expressions are equivalent. This corresponds to the equality in the alignment format relation field.
Expressions are either class mappings, relation mappings, instance mappings or arbitrary logical expressions. The syntax for the logical expressions is not specified; it depends on the actual logical language to which the language is grounded. A special kind of relation mappings are attribute mappings. Attributes are binary relations with a defined domain and are thus associated with a particular class. In the mapping itself the attribute can be either associated with the domain defined in the (source or target) ontology or with a subclass of this domain. In order to distinguish these kinds of mappings, we introduce two different keywords for class, relation and attribute mappings, namely ‘unidirectional’ and ‘bidirectional’. Individual mappings are always bidirectional.
It is possible, although not required, to nest attribute mappings inside class mappings. Furthermore, it is possible to write an axiom, in the form of a class condition, which defines general conditions over the mapping, possibly involving terms of both source and target ontologies. Notice that this class condition is a general precondition for the mapping and thus is applied in both directions if the class mapping is a bidirectional mapping. Notice that we allow arbitrary axioms in the form of a logical expression. The form of such a logical expression depends on the logical language being used for the mappings and is thus not further specified here.
There is a distinction between attributes mapping in the context of a class and attributes mapped outside the context of a particular class. Because attributes are defined locally for a specific class, we expect the attribute mappings to occur mostly inside class mappings. The keywords for the mappings are the same. However, attribute mappings outside of the context of a class mappings need to be preceded with the class identifier, followed by a dot ’.’.
Simple mapping expressions are expressed by replacing the class, attribute and relation expressions with corresponding identifiers of the respective class attribute or relation. We see in the next section how to expand these simple mappings, going deeper in the definition of the class, relation and attribute expressions.
More complex mappings
We here introduce more constructucts to express complex mappings. These constructs allow us to express mappings at the level 1 and 2 as defined in [Euzenat2004].
For class expressions we allow basic boolean algebra. This corresponds loosely with Wiederhold’s ontology algebra [Wiederhold2001]. Wiederhold included the basic intersection and union, which correspond with our and and or operators. Wiederhold’s difference operator corresponds with a conjunction of two class expressions, where one is negated, i.e. for two class expressions C and D, the different C¡D corresponds with and(C,not(D)).
The join expression is a specific kind of disjunction, namely a disjunction with an additional logical expression which contains the precondition for instances to be included in the join.
Attribute expressions are defined as such, allowing for inverse, transitive close, symmetric closure and reflexive closure, where inverse(A) stands for the inverse of A, symmetric(A) stands for the symmetric closure of A , reflexive(A) stands for the reflexive closure of A and trans(A) stands for the transitive closure of A. Especially when mapping several source ontologies into one target ontology, different classes and relations need to be joined. Although apparently similar, a join mapping is fundamentally different from an intersection mapping.
Relation expressions are defined similar to class expressions, with the difference that the arity of the relations may be precised.
We now introduce the conditions that may be applied to the mappings. a mapping is valid if the condition is satisfied. Conditions may apply on attributes in class or attribute mappings.
Instance transformation functions
As presented in the requirements (D7.1) there is a need to specify transformations of instances in the mappings definition. We will in this section give a set of transformation functions expliciting the instance transformations between the two ontologies to be mediated. We propose two way of specifying the transformations. In a first approach, we will propose an extensible library of functions to be included in the pattern library for storage and retrieval. These functions should cover most of the cases presented in the hierarchy of transformation functions in the deliverable D7.1. the only aspect not covered by this library is the dynamicity some transformations require. We cope with this aspect in the second way we propose to handle instance transformation, namely by specifying a web service.
The set of functions is specified in the implementation deliverable D7.3. The web service protocol is to be chosen at the implementation level, we however recommend to use a semantic based web services framework like the Web Service Modelling Ontology, WSMO [WSMO2005]
RDF Syntax
We give in this section the rdf translation of the mapping language abstract syntax. The implementation of the mapping language will support import/export from this format as well.
Here is the list of keywords. We use 'map' as a prefix. The URI corresponding to this prefix is the URI of the current document: https://www.omwg.org/TR/d7/d7.2.
| Keyword |
Comment |
| map#mappingDocument |
used to define a mapping document |
| map#classMapping |
mapping between two class expressions |
| map#attributeMapping |
Mapping between two attribute expressions |
| map#relationMapping |
mapping between two relation expressions |
| map#individualMapping |
mapping between two instances |
| map#classAttributeMapping |
mapping between a class expression and an attribute expression |
| map#classRelationMapping |
mapping between a class expression and a relation expression |
| map#classInstanceMapping |
mapping between a class expression and an instance |
| map#onto1 |
first ontology |
| map#onto2 |
second ontology |
| map#directionality |
indicates the directionality of a mapping rule |
| map#measure |
indicates the confidence given to a mapping rule |
| map#operator |
indicates the operator in a complex class,attribute or relation expression |
| map#condition |
specify a condition |
| map#hasSource |
source expression of a mapping rule |
| map#hasTarget |
target expression of a mapping rule |
| map#hasExpression |
source or target expression of a mapping rule. Can also be a sub-expression of an expression |
| map#logicalExpression |
kind of expression, represented as a string |
the remainder of this section present the translation from the abstract syntax to the rdf syntax. We use the existing rdf constructs to limit the number of introduced keywords. In particular, the documentid is mapped to dc#title, the annotation is mapped to rdf#description.
A,B,C represent identifiers, DVi stands for an integer value, DVd stands for a decimal, and DVs stands for a string data value, and n is an integer number.
| Abstract Syntax |
RDF Triples |
Comments |
| T(
MappingDocument(
A
source_exp
target_exp
annotation1 ... annotationn
expression)
) |
A rdf#type map#mappingDocument
T(source_exp,A)
T(target_exp,A)
T(annotation1,A) ... T(annotationn,A)
T(expression
, A) |
A is the IRI represesenting the mapping document given as an id. The source and target expressions are ontologies |
| T(
source(B)
, A) |
A map#onto1 B |
|
| T(
target(B)
, A) |
A map#onto2 B |
|
| T(
annotation(
C D)
, A) |
A B T(propertyValue) |
annotations are used to indicate informations about the document and the rule, the propertyid B is a dublin core property and then may be used here as an RDF predicate. |
| T(
classMapping(
annotation1 ... annotationn
directionality
classExpr
classExpr
classCondition1 ... classConditionn
logicalExpression)
, A) |
A map#classMapping _:X
T(annotation1, _:X)
...
T(annotationn, _:X)
T(directionality, _:X)
_:X map#hasSource _:Y
_:X map#hasTarget _:Z
T(classExpr, _:Y) T(classExpr, _:Z)
T(classCondition1, _:X)
...
T(classConditionn, _:X)
T(logicalExpression, _:X) |
The blank identifier _:X denotes a helper node to bind the mapping rule to the mapping document |
| T(
attributeMapping(
annotation1 ... annotationn
directionality
attributeExpr attributeExpr
attributeCondition1 ... attributeConditionn
logicalExpression)
, A) |
A map#attributeMapping _:X
T(annotation1, _:X)
...
T(annotationn, _:X)
T(directionality, _:X)
_:X map#hasSource _:Y
_:X map#hasTarget _:Z
T(attributeExpr, _:Y)
T(attributeExpr, _:Z)
T(attributeCondition1, _:X)
...
T(attributeConditionn, _:X)
T(logicalExpression, _:X) |
The blank identifier_:X denotes a helper node to bind the mapping rule to the mapping document |
| T(
relationMapping(
annotation1 ... annotationn
directionality
relationExpr relationExpr
relationCondition1 ... relationConditionn
logicalExpression)
, A) |
A map#relationMapping _:X
T(annotation1, _:X)
...
T(annotationn, _:X)
T(directionality, _:X)
_:X map#hasSource _:Y
_:X map#hasTarget _:Z
T(relationExpr, _:Y) T(relationExpr, _:Z)
T(relationCondition1, _:X)
...
T(relationConditionn, _:X)
T(logicalExpression, _:X) |
The blank identifier_:X denotes a helper node to bind the mapping rule to the mapping document |
| T(
instanceMapping(
annotation1 ... annotationn
instance1
instance2
, A) |
A map#individualMapping _:X
T(annotation1, _:X)
...
T(annotationn, _:X)
_:X map:hasSource instance1
_:X map:hasTarget instance2 |
The blank identifier_:X denotes a helper node to bind the mapping rule to the mapping document |
| T(
logicalExpression
, A) |
A map#logicalExpression DVs^^xsd:string |
|
| T(
classid
, A) |
A map#hasExpression classid |
|
| T(
and( classExpr1 ...
classExprn , A) |
A map#operator map#and
A map#hasExpression _:X1
T(classExpr1, _:X1)
...
A map#hasExpression _:Xn
T(classExprn, _:Xn) |
Identical for the 'or' and 'join' operators, just change to map#or and map#join |
| T(
attributeid
, A) |
A map#hasExpression attributeid |
|
| T(
and( attributeExpr1 ...
attributeExprn
, A) |
A map#operator map#and
A map#hasExpression _:X1
T(attributeExpr1, _:X1)
...
A map#hasExpression _:Xn
T(attributeExprn, _:Xn) |
Identical for the other operators, just change to map#_operator where _operator is the corresponding operator. See the attribute operators list. |
| T(
relationid
, A) |
A map#hasExpression relationid |
|
| T(
and( relationExpr1 ...
relationExprn , A) |
A map#operator map#and
A map#hasExpression _:X1
T(relationExpr1, _:X1)
...
A map#hasExpression _:Xn
T(relationExprn, _:Xn) |
Identical for the other operators, just change to map#_operator where operator is the corresponding operator. See the relation operators list. |
Conclusion
We have in this section presented an ontology mapping language coming with an abstract syntax.
Mapping patterns library
See Sekt Del 4.5.1.
Graphical Mapping tool
We will develop a graphical tool to realize mappings on top of the language. This tool is part of the general ontology management system and will be tightly integrate with the ontology editing and browsing tool (see del. d8.2)
Acknowledgement
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.
The authors would like to thank to all the members of the OMWG working group for their advices and inputs to this document.
Annex 1. BNF style grammar
iri