Copyright © 2004 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
this document is available as a non normative PDF version
This deliverable presents the design of the mapping tool as a part of the ontology management system. This tool is built on top of an ontology mapping specification language, and a mappings patterns library that helps the user to identify mappings. We then present the first steps made towards a graphical mapping tool.
We will here present the mapping language developped to express the mappings. This language is being developed as a joint effort in the WSMO and OMWG working groups, and the Sekt and Dip european projects.
We present this language in the form of the abstract syntax. The abstract syntax
is written in the form of EBNF, similar to the OWL 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 URI. In the abstract syntax, a
URI is denoted with the name URIReference. We define the following identifiers:
mappingDocumentId ::= URIReference ontologyId::= URIReference classId::= URIReference propertyId::= URIReference attributeId::= URIReference relationId::= URIReference individualId::= URIReference |
We allow concrete data values. The abstract syntax for data values is taken
from the
OWL abstract syntax:
dataLiteral ::= typedLiteral|plainLiteral |
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.
mappingSet ::= ’MappingSet(’ [ mappingSetId ] |
A mapping consists of a number of annotations, corresponding to non-functional properties in WSMO [30], and a number of mapping rules. The creator of the mapping is advised to include a version identifier in the non-functional properties.
annotation ::= ’Annotation(’ propertyID URIReference ’)’ |
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.
A mapping can be either uni- or bidirectional. In the case of a class mapping,
this corresponds with class equivalence and class subsumption, respectively.
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.
Unidirectional and bidirectional mappings are differentiated with the use of
a switch. The use of this switch is required.
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.
expression ::= ’classMapping(’
’unidirectional’|’bidirectional’
{ annotation }
classExpr classExpr
{ classAttributeMapping }
{ classCondition }
|
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 ’.’.
expression ::= ’attributeMapping(’
’unidirectional’|’bidirectional’
attributeExpr attributeExpr
|
expression ::= ’relationMapping(’
’unidirectional’|’bidirectional’
|
expression ::= ’instanceMapping(’ individualID individualID ’)’ |
expression ::= ’classAttributeMapping(’
’unidirectional’|’bidirectional’
classExpr attributeExpr
|
expression ::= ’classRelationMapping(’
’unidirectional’|’bidirectional’
classExpr relationExpr
|
expression ::= ’classInstanceMapping(
’unidirectional’|’bidirectional’
classExpr individualId
[ ’{’ logicalExpression ’}’ ] ’)’
|
expression ::= ’{’ logicalExpression ’}’
|
For class expressions we allow basic boolean algebra. This corresponds loosely
with
Wiederhold’s ontology algebra [37]. 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.
classExpr ::= classId |
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:
attributeExpr ::= attributeId |
Relation expressions are defined similar to class expressions:
relationExpr ::= relationId |
classCondition ::= ’attributeValueCondition(’
attributeId
( individualID | dataLiteral )
’)’
classCondition ::= ’attributeTypeCondition(’
attributeID
classExpr
’)’
classCondition ::= ’attributeOccurrenceCondition(’
attributeID
’)’
|
attributeCondition ::= ’valueCondition(’
(individualID
| dataLiteral)
’)’
attributeCondition ::= ’typeCondition(’
classExpression
’)’
|
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.
We developped an API to deal with the mapping language.
Here is the big picture of the language API's object model.
See Sekt Del 4.5.1.
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)
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.
$Date: 2004/10/22 16:12:55 $