mapping guide mapping ontologies and data sets in rdf/rdfs/owl2 michel böhms

Mapping Guide

Mapping Ontologies and Data Sets in RDF/RDFS/OWL2

Michel Böhms

Michel BöhmsMapping Guide

2

Basic Assumptions

A “Mapping” is a set of one or more Mapping Rules relating two

ontologies and their data sets bi-directionally

These Mappings are just like the ontologies/data sets to be mapped,

“Mapping Ontologies” fully described using RDF/RDFS/OWL2 following

the same V-Con Modelling Guide

Not bound to a particular software tool

Not bound to a particular semantics/format (i.e. like MS Excel file

format)

Making full use of interoperable and well-defined RDF/RDFS/OWL2

semantics and Turtle syntax

Enabling inferred information from asserted information via standard

reasoners (instead of dedicated transformation software tools)

January 22, 2015


3

Relevant dimensions

Three key Meta concepts:

Classes (owl:Class)

Properties (owl:DatatypeProperty & owl:ObjectProperty)

Individuals (owl:NamedIndividual)

11 “Venn situations”

5 for classes, same 5 for properties, 1 other for individuals

Three Semantic levels (for classes)

Asserted versus Inferred information

January 22, 2015


4

Assume

2 ontologies: x and y

x, y prefixes for name space URIs

asserted or inferred

1 Class A in ontology x, x:A

1 Class B in ontology y, y:B

1 Property in ontology x: x:c

1 Property in ontology y: y:d

1 Individual in ontology x: x:a

1 Individual in ontology y: y:b

January 22, 2015


5

5 Venn situations for classes

The “default”, unconstrained.Independent classes, no mapping rule relevant

x:A rdfs:subClassOf y:B

y:B rdfs:subClassOf x:A

x:A rdfs:subClassOf y:B AND y:B rdfs:subClassOf x:ASame as: x:A owl:EquivalentClass y:B

[] rdf:type owl:AllDisjointClasses ; owl:members ( x:A y:B ) . No mapping rule relevant (only for ‘negative’ info)

1.

2.

3.

4.

5.

•• • •

• ••

••

••

•

•

••

••

•

•••

••••

••

January 22, 2015


6

5 Venn situations for properties

The “default”, unconstrained.Independent properties, no mapping rule

x:c rdfs:subPropertyOf y:d

y:d rdfs:subPropertyOf x:c

x:c owl:propertyDisjointWith y:dNo mapping rule relevant (only for ‘negative’ info)

1.

2.

3.

4.

5.

x:c rdfs:subPropertyOf y:d AND y:d rdfs:subPropertyOf x:cSame as: x:A owl:EquivalentProperty y:B

•• • •

• ••

••

••

•

•

••

••

•

•••

• •••

•

January 22, 2015


7

1 Venn situation for individuals

1. • • x:a owl:sameAs y:b

January 22, 2015


8

Types of Mapping Rules (#7)

x:A rdfs:subClassOf y:B

y:B rdfs:subClassOf x:A

x:A owl:EquivalentClass y:B

x:c rdfs:subPropertyOf y:d

y:d rdfs:subPropertyOf x:c

x:A owl:EquivalentProperty y:B

x:a owl:sameAs y:b

January 22, 2015


9

3 semantic levels for classes

L1: Classes without restrictions

L2: Classes with only “necessary” Restrictions

L3: Classes with “necessary & sufficient (n&s)” Restrictions

An ontology can have a mix of 1/2/3

An ontology can be “strong”, having only level 3 classes

January 22, 2015


10

Inference potential

Depending on the semantic level of the class more or less can be

inferred from asserted information

Standard OWL2 inferences (entailments regimes) like:

If (x:a rdf:type x:A AND x:A rdfs:subClassOf y:B)

THEN (x:a rdf:type y:B)

January 22, 2015


11

Example

x is some context ontology, y some common ontology following the V-

Con Modelling Guide

Ontology x asserts:

x:RedCar rdf:type owl:Class

x:colour rdf:type owl:DatatypeProperty

x:colour rdfs:range xsd:string

x:MyRedCar rdf:type x:RedCar

x:MyRedCar x:colour “Red”^^xsd:string

Ontology y asserts

y:Car rdf:type owl:Class

y:colour rdf:type owl:DatatypeProperty

(note not the same as x:colour!)

January 22, 2015


12

Venn situation here

Clearly the intended meaning of the mapping rules is:

x:RedCar rdfs:subClassOf y:Car•

x:colour owl:EquivalentProperty y:colour•

January 22, 2015


13

Semantic Level here (L1)

x:RedCar and y:Car have no n&s restrictions

Also both have no explicit restrictions at all: so we did not specify for instance that a

RedCar has the value “red” for x:colour explicitly

Note we could have never inferred “x:MyRedCar rdf:type x:RedCar” based on

“x:MyRedCar x:colour “red”^^xsd:string”)

i.e. No way to automatically classify

So we have to assert (as we did) “x:MyRedCar rdf:type x:RedCar”

Note we also cannot infer in any way that x:RedCar is a subclass of y:Car

i.e. No way to automatically subclass

So we have to assert “x:RedCar rdfs:subClassOf y:Car” as mapping rule

Doing that we CAN infer:

x:MyRedCar rdf:type y:Car

X:MyRedCar y:colour “red”^^xsd:string

And if we assert extra: y:MyCar rdf:type y:Car AND x:MyRedCar owl:sameAs y:MyCar

We can extra infer: y:MyCar x:colour “red”^^xsd:string and y:MyCar y:colour “red”^^xsd:string

Note that this had not been possible if he had not asserted x:MyRedCar x:colour

“red”^^xsd:string in the first place (it would have been implicit in the RedCar class only

January 22, 2015


14

In case semantic level 2

So: x:RedCar and y:Car have again no set of n&s restrictions but this

time we add an explicit restriction on the x:RedCar class:

x:RedCar a owl:Class ;

rdfs:subClassOf owl:Thing ;

rdfs:subClassOf [ a owl:Restriction ;

owl:hasValue "red"^^xsd:string ;

owl:onProperty x:colour

] .

January 22, 2015


15


Again, we can never infer that x:MyRedCar is of type x:RedCar

i.e. again no way to automatically classify, even if x:MyRedCar x:clour “red” was

asserted in the first place

So we again have to assert x:MyRedCar rdf:type x:RedCar

Again, we also cannot infer in any way that x:RedCar is a subclass of y:Car

i.e. again no way to automatically subclass

So we again have to assert x:RedCar rdfs:subClassOf y:Car

Now we CAN infer:

x:MyRedCar rdf:type y:Car (as before)

And if we assert: y:MyCar AND x:MyRedCar owl:sameAs y:MyCar (as before)

And x:MyRedCar x:colour “red” (because of the explicit restriction), no need to assert

anymore!

And even: y:MyCar x:colour “red” (as before)

And even: y:MyCar y:colour “red” (as before)

January 22, 2015


16


Now we add for both classes n&s restrictions like:

In x ontology:

x:RedCar owl:equivalentClass (…x:vehicleType=“car” and x:colour=“red”…)

In y ontology:

y:Car owl:equivalentClass (…y:vehicleType=“car” and y:colour=“red”

In mapping ontology

: “x:vehicleType owl:equivalentProperty y:vehicleType” AND

“x:colour owl:equivalentProperty y:colour”

which makes it possible to

Infer that “x:MyRedCar rdf:type x:MyCar” (automatic classification) in case

“x:MyRedCar x:colour “red”^^xsd:string” was asserted, but more important:

Infer that “x:RedCar rdfs:subClassOf y:Car” (automatic subclassing based on

the n&s class restrictions on both sides)

So no need for mapping rules for the classes at all!

Note: nice but unrealistic that all classes are defined on L3…

January 22, 2015


17

Bottom Lines

In general we have to specify mapping rules explicitly for classes since strong L3 definitions are not likelyWe always need mapping rules for propertiesWe need mapping rules for individuals to go beyond enrichment (and have all inferred data in both ontologies or in case such individuals are already asserted in both ontologies and actually refer to the same real world entityWe need as much as necessary restrictions to make knowledge explicit on class level and to avoid the need to provide all this data on individual level (for all individuals)If this info is not explicitly at class level and not available at individual level this info is not really there at all (only in the name of the class) so inference will obviously also not create it (more positively: no info is really lost, is was never their in the first place)

January 22, 2015


18

Issues

Other restriction types

So far we discussed Restrictions of the form “owl:hasValue”

Other types: hasRange (asphalt example)

Or even (?) owl:minCardinality, owl:maxCardinality,

owl:allValuesFrom, owl:someValuesFrom, ….

What happens now (when inferring)

Role of domain/range clauses for properties

Datypes and Lexical values

Do we also have to indicate that x:red = y:red or a bit more abstract

x:datatype is y:datatype if not the same (like xsd:string)

Do we also need rule x:c owl:differentFrom y:d ?

January 22, 2015


19

Simple CBNL Use Case /1

Ontology x (being CBNL) as entrance to ontology (and its individuals)

y

Where classes from y are equivalent or subclasses of classes in x

(only classes since properties are also modelled as classes in

CBNL)

No need to move data

Ontology y maybe not even an ontology, just connected via specific

api/web services etc.

January 22, 2015


20

Simple CBNL Use Case /2

2 ontologies: x (CBNL) and y (ETIM)

1 Individual in some ontology c classified as an item in CBNL: c:a

rdf:type x:A

A being an “object-class” in CBNL

1 Class B in ontology y (ETIM), y:B

In mapping rule:

y:B owl:equivalentClass x:A or

y:B rdfs:subClassOf x:A (being more realistic in case of specific

restrictions in y)

January 22, 2015


21

Simple CBNL Use Case /3 (flow)

You can now browse from c:a to x:A and search in all mapping

ontologies for y:B like classes being equivalent or subclass and

known more info on class level and existing individuals for y:B (here

2BA products)

January 22, 2015

mapping guide mapping ontologies and data sets in rdf/rdfs/owl2 michel böhms

Documents