How to Integrate Ontologies and Rules?

ONTOR UL E

Ontologies meet Business Rules

How to Integrate Ontologies and Rules?

Adeline Nazarenko Luis Polo Thomas Eiter Jos de Bruijn Antonia
Schwichtenberg Stijn Heymans
(Paris13, CTIC, TU Vienna, ontoprise)

12 July 2010 — AAAI 2010 Tutorial Forum

ONTOR UL E
Aim of this Tutorial

You will understand:
1. How NLP can help to extract business knowledge from policy
documents
2. What type of business knowledge is typically modeled as an
ontology and what knowledge as rules (both logical and production
rules)
3. Which approaches to combining ontologies and rules are currently
available; which ones are implemented
4. How to choose the appropriate combination paradigm for your goals;
5. How to model a combination of ontologies and rules using mature
commercial tools

(2/221) c ONTORULE Consortium, all rights reserved

ONTOR UL E
Contents of the Tutorial

1. From Business Policy Documents to a Business Model (1 hour 10
minutes)

2. Integrating Ontologies and Rules (2 hours 15 minutes)
2.1 OWL 2 ontologies (45 minutes)
2.2 Logic Programming and Production Rules (25 minutes)
2.3 Integration (50 minutes)
2.4 Demo (15 minutes)


ONTOR UL E
Acknowledgements

The ONTORULE project consortium: ILOG (an IBM Company),
ontoprise, Free University of Bolzano, Vienna University of
Technology, PNA, Université Paris 13, Fundación CTIC, Audi and
ArcelorMittal
http://ontorule-project.eu

This tutorial is co-funded by the European Union (FP7)


ONTOR UL E
Business Vocabulary


ONTOR UL E
Business Scenario

Business knowledge

Ship to customer

Production process

Decision
(assignment)

Coil Repair

Scrap


Part I

From Business Policy Documents to a
Business Model


ONTOR UL E
Overview of Part I

Building business models from written policies
State of the art
Ontology design
Ontology population
Information extraction
Corpus design
Ontology acquisition
Terminological analysis
Term normalization
Conceptualization
Relation identiﬁcation
Business rule acquisition
Semantic Business Vocabulary and Rules

ONTOR UL E
Outline


State of the art

Corpus design





ONTOR UL E
Why starting from texts?

An alternative source of information
Expert knowledge is difﬁcult to make explicit
Experts are seldom available for intensive interviews
Large amount of written information is available

A challenge for knowledge management
Business models must be documented (for traceability)
The source documents must be maintained together with the
business models


ONTOR UL E
What can be extracted from texts?

Although
Documents do not contain all the relevant information
Domain knowledge is seldom explicit
Texts are precious source of information
Documents often express factual knowledge about the domain
entities, their properties, their evolution and their relations.
Documents also reﬂect the underlying domain knowledge : what are
the relevant concepts? how do they relate to each other?
Policy documents express the business rules that are relevant for
the domain.


ONTOR UL E
Example of text

Domain concept? Domain entity? Business rule? Domaine relation?


ONTOR UL E
Outline


State of the art
Ontology design
Ontology population

Corpus design




ONTOR UL E
Building a hierarchy of concepts

Two main approaches

A distributional approach for "learning" ontologies
A terminological approach for assisting the conceptualization task


ONTOR UL E
Distributional approach

Words with similar meanings tend to appear in similar contexts [Harris et
al., 1989].
Example
mechanical properties
mechanical strength
mechanical process
mechanical behaviour

Semantic classes of words can be built out of a distributional
analysis
They are supposed to represent domain concepts
The results are noisy and difﬁcult to exploit
[Hindle, 1990][Dagan et al., 1993][Faure and Nédellec, 1999][Maedche and
Staab, 2001][Cimiano and Völker, 2005]

ONTOR UL E
Terminological approach

Definition (Terms)
Words and compounds that form the domain vocabulary

Example
mechanical properties coil yield point elongation strength

The terms extracted from a text reflect the conceptual vocabulary
A lot of manual work is necessary for filtering, structuring, modeling

[Aussenac-Gilles et al., 2000] [Aussenac-Gilles et al., 2008] [Szulman et al.,
2009a]


ONTOR UL E
Ontology population

Deﬁnition (Named entities)
Textual units that are similar to proper names whose meaning is built
through the operation of reference.

Example
STRIP BH2 2% Nitrogen

Given a conceptual model (ontological T-Box), named entity recognition
tools can be used to extract the concept and relation instances and thus
enrich the ontological A-Box.
[Magnini et al., 2006] [Giuliano and Gliozzo, 2008]


ONTOR UL E

Deﬁnition (Information extraction)
A set of techniques for automatically extracting structured information
from unstructured textual documents (e.g. Who gives a conference,
when and where?)
[Sundheim, 1992][Grishman and Sundheim, 1996]

Goals
Extracting relations between entities
Discovering concepts properties and relations
[Hearst, 1992] [Aussenac-Gilles and Jacques, 2008]
Extracting business rules


ONTOR UL E
Information extraction method

Information extraction relies on extraction patterns that must be carefully
designed to achieve good precision and recall.

Example
noun1 , noun2 , ... and other noun3 → noun1 < noun3
Hospitals, schools and other public buildings → school < public building

Difﬁculties
Extraction patterns are often corpus dependent
Manual design is tedious and error prone
Machine learning can help but requires large amount of annotated
data to extract relational information
[Califf M. E., 1998] [Brin, 1999]


ONTOR UL E
Building business models from texts

Goal Combining state-of-the-art approaches
Bootstrapping and help business modeling
Enabling business experts to understand and author
business models
Anchoring business models in policies
Strategy Three major steps
Designing an acquisition corpus
Acquiring the domain conceptual model (ontology)
Modeling business rules


ONTOR UL E
Outline


State of the art

Corpus design





ONTOR UL E
Corpus design

Designing an acquisition corpus is a complex task [Atkins et al., 1992]
An acquisition corpus is application dependent
Identifying relevant documents is challenging in many organizations
The sources are heterogeneous (size, types, technicality, target
audience)
There may be missing or redundant pieces of knowledge
Some documents may be conﬁdential
How to achieve a good representativity of the domain to model?


ONTOR UL E
In practice

There is no stable methodology or acknowledged good practice to
design acquisition corpus: all use cases are different.
Knowledge engineers inventory the available documentation and
extract the most useful pieces.

Example (ArcelorMittal use case)

Extract from the product catalogue (10 pages, 3,500 words)
Use case description (2,000 words)
Description of the order Assignment at galvanization Line (1,000
words)
Email discussion with experts


ONTOR UL E
Outline


State of the art

Corpus design

Terminological analysis
Term normalization
Conceptualization
Relation identiﬁcation



ONTOR UL E
Ontology design

The TERMINAE approach to ontology acquisition
[Aussenac-Gilles et al., 2008][Szulman et al., 2009b]
An interactive approach
A terminological approach

TERMINAE tool (http://www-lipn.univ-paris13.fr/~szulman/logi/index.html)


ONTOR UL E
From texts to domain model

Texts reﬂect the underlying domain model . . .
Domain vocabulary: hardening element, iron crystal lattice
Controlled meaning: elements = chemical element
Situated communication (e.g. actors, locations, roles)
Explicit domain knowledge: The grain structure of steel inﬂuences
its mechanical behavior
Factual knowledge: Coil #13 is a coil, with length 670 meters,
currently located in Aviles factor.
But a partial and distorted view
Synonymy: defects = non-conformities
Polysemy: (lab test) results = result (of the assignment process)
Ellipses
Presuppositions

ONTOR UL E
From a corpus to an ontology

Sublanguage model Domain model 1. NLP extraction
(semantic network) (ontology)
2. Selection and
3 disambiguation of
core meanings
3. Formalisation
2
concepts,
terms & roles &
terminological properties
relations

1
Corpus
(text)

word and term occurrences
syntactic relations, sentences


ONTOR UL E
Overall approach

Terminological Termino-conceptual Conceptual
level level level (ontology)

Terms Termino-concepts Concepts

Acquisition
corpus

relations relations relations


ONTOR UL E
1st step: Terminological analysis



Acquisition
corpus



ONTOR UL E
Terminology extraction

Definition (Terminology)
The body of words or terms relating to a particular subject, field of activity
or branch of knowledge.

Definition (Term Extractor)
Tools that take a domain specific acquisition corpus as input and output a
list of specialized term candidates (e.g. YaTeA [Aubin and Hamon, 2006])

Underlying hypothesis
The relevant terms of a corpus reflect the domain concepts
Terminological analysis can bootstrap the ontology design


ONTOR UL E
Terminology extraction and tagging

Example
The Galvanization Line processes coils, long strips of steel, to provide
them a coating of zinc; this coating will give the product an improved
surface aspect as well as protection from corrosion. During the process
the mechanical properties, such as the yield strength, of the steel are
also changed due to the thermal cycle it goes through.


ONTOR UL E
2nd step: Term normalization



Acquisition
corpus



ONTOR UL E
Term normalization

To abstract from language peculiarities
Term ﬁltering and selection (noise)
Term variant clustering (synonymy)
Term disambiguation (polysemy)
Output
A semantic network of normalized terms and terminological relations
TERMINAE can export the result in SKOS1

1
(33/221) http://www.w3.org/2004/02/skos/ c ONTORULE Consortium, all rights reserved

ONTOR UL E
Term filtering and selection

Term extractors provide noisy results (candidate terms) that must be
further filtered [Nazarenko and Zargayouna, 2009]
Terminology creation is a social process: there is a consensus
within a given community to use a term t with a specific meaning
Termhood cannot be fully captured through linguistic and statistical
properties
Validation interfaces allow for filtering based on
Characters
Lexical items
Various types of ranking (e.g. frequency, tf.idf)


ONTOR UL E
Term variant clustering

In texts, a given term may appear under various forms. Each group of
(quasi-) synonymous terms must be clustered and associated to a single
termino-concept

Example
residual carbon precipitation thickness reduction rates
precipitation of residual carbon rate in thickness reduction
precipitations of residual carbon reduced thickness
carbon precipitations reduction rate of thickness


ONTOR UL E
Variant detection

Some variants can be identiﬁed automatically
Typographical normalization: colour vs color
Morphological analysis
singular vs. plural forms
verbs vs. nominalizations
Syntactic analysis based on equivalent syntactic patterns [Jacquemin
and Tzoukermann, 1999]
Noun Noun ⇔ Noun of Noun
Synonymy propagation [Hamon et al., 1998]
If Noun1 ⇔ Noun2 then Noun1 Noun ⇔ Noun2 Noun
Other variants often have to be manually identiﬁed
Irregular morphology: datum vs. data
Semantic variation: defect vs. non-conformities
"... sometimes there are defects, non-conformities with regard to the
allowed ranges... "

ONTOR UL E
Term disambiguation

Ambiguous terms must be disambiguated in such a way that each
relevant meaning be represented as a distinct termino-concept

Example (result)
result → lab test result = lab test data
result → assignment result = outcome of the assignment process

Method (for a given term)
Browse its occurrences
Identify its various meanings
For each relevant meaning, create a termino-concept
Assign the proper occurrences to each termino-concept


ONTOR UL E
Terminological forms (TERMINAE)


ONTOR UL E
3rd step: Conceptualization



Acquisition
corpus



ONTOR UL E
From termino-concepts to concepts

Once the relevant domain elements are identiﬁed, normalized and
disambiguated, the termino-conceptual level can be formalized into a
formal ontology.
At the conceptual level, the termino-concepts can be modeled as
concepts
instances of concepts
relations (object or data properties)
Those modeling choices depend on the domain and the aimed
application.
TERMINAE can export the ontological level in OWL.


ONTOR UL E
Traceability of concepts

When a conceptual element is built out of a termino-concept, it is linked
to that termino-concept, which is itself associated to one or several
synonymous terms and to text occurrences.
The termino-concept/concept links ensure the traceability of the
conceptual level which is grounded in the source document.


ONTOR UL E
4th step: Relation identiﬁcation



Acquisition
corpus



ONTOR UL E
Enriching the conceptual hierarchy with relations

Two complementary strategies
Text driven approach where terminological relations
are extracted from the acquisition corpus
are normalized into termino-conceptual relations
are formalized into ontological elements at the conceptual level
Ontology driven approach
The knowledge engineer looks for speciﬁc relations
Each relation is associated with a set of characteristic extraction
patterns
The matching text fragments are occurrences of the searched
relations.


ONTOR UL E
Looking for relations

Tools like TERMINAE propose facilities to design patterns and mine
texts
Frequent verbs are good clues
Co-occurring terms often bring relations into light

Example
Property isCharacterizedBy
Steel is characterized by the mechanical properties of products
sold. . .
Surface quality is characterized by surface topography, lubrication
and chemical treatment.
. . . the following parameters, which characterize the material: yield
stress, mechanical strength, fracture elongation. . .

ONTOR UL E
Ontology acquisition: conclusion

A text-based approach of ontology acquisition
Automatic natural language processing of acquisition corpus
Normalization of the terminological output into a disambiguated
semantic network of termino-concepts
Formalization of that network into an ontology
Future developments
Enriching the corpus analysis with named entities recognition
Automatically clustering terms (distributional analysis of terms)
Integrating bottom-up relation extraction methods


ONTOR UL E
Ontology acquisition: conclusion

TERMINAE , a tool to support that process
The modeling work is supported by speciﬁc interfaces (i.e.
terminological forms).
Linking concepts to termino-concepts and terms ensure the
traceability of the conceptual model to the source text.
The result is a complex knowledge base:
1. Ontology (OWL)
2. Associated normalized terminology (SKOS), which allows for the
recognition of new occurrences of conceptual elements
3. Ontology to text links, which allow for the visualization of the semantic
annotation of the source text


ONTOR UL E
Outline


State of the art

Corpus design





ONTOR UL E
Overall approach of rule acquisition

Structural Operative
1 rules rules

Documents
acquisition corpus

x
Ontology Index x
2 x
3
Documents
acquisition corpus
x
x
x
1 Rule extraction
2 Semantic annotation wrt. ontology 4
3 Extraction of relevant textual fragments Index
4 Rule editing and rephrasing R2
R1
R5 R4 R3

Business rule bases


ONTOR UL E
Fragment detection

Information extraction can help the identification of fragments of text
stating rules, although business rules cannot be fully automatically
extracted from written policies
Precise extraction patterns are difficult to design as they are highly
corpus dependant
Clues and combinations of clues can be used to filter out some
relevant fragments and bootstrap the rule acquisition process
Modal verbs
Linguistic markers
Domain specific action verbs


ONTOR UL E
Example of rule fragments

Example

Usually these targets are allowed to vary within a certain range,
speciﬁed in the order.
However, sometimes there are defects, non-conformities with
regard to the allowed ranges, that may make the coil unsuitable for
the order it is assigned to.
If a coil has a defect, mark it as ’defective’ scrap the coil and alert
the user of the defect.
When the line ﬁnishes the processing of each coil a decision must
be made regarding the assignment of the coil.
If nevertheless this is the result, the coil must be inspected by an
expert and the decision on the assignment be made manually.


ONTOR UL E
Fragment annotation

Deﬁnition (Semantic annotation)
Semantic annotation is an ontology-driven interpretation of the document
content. Textual units (e.g. words, phrases, sentences, paragraphs) are
annotated with ontological ones (concepts, instances, roles, properties
instances) [Ma et al., 2010].

Where do annotations come from?
The corpus that has been used for ontology acquisition has been
annotated during the acquisition process (ontology to text links
output by TERMINAE)
New corpus can be semantically annotated using the combined
ontological-terminological resource output from the acquisition
process (OWL and SKOS output from TERMINAE)


ONTOR UL E
Fragment annotation: example

Source document Ontology

The Galvanisation Line processes coils, long
strips of steel, to provide them a coating of zinc; SteelProduct
this coating will give the product an improved
surface aspect as well as protection from target yieldStrengh
corrosion. During the process the mechanical
Order hasLower Value Coil
properties, such as the yield strength, of the Extraction
steel are also changed due to the thermal cycle it of relevant hasUpper
goes through.
textual belongsTo
fragment

The actual yield strength of the coil should be within the tolerances indicated by the order the coil belongs to.

Semantic annotation wrt. ontology

The actual yield strength of the coil should be within the tolerances indicated by the order the coil belongs to.

The yield strength of the coil should be within the upper and lower values of the order the coil belongs to.

Rule editing

SBVR SE Rule
The yield strength of a coil that belongs to an order must be between the upper and lower
Statement
values of the order


ONTOR UL E
Fragment recomposition

A fragment often cannot be interpreted in isolation

Example
The actual yield strength of the coil should be within the tolerances
indicated by the order the coil belongs to.
The yield strength of a coil that belongs to an order must be within
the upper and lower values of that order .
... if at any point the yield strength is outside of this range there exists a
mechanical defect.
→ The yield strength is a property of a sampling point of a coil (= coil).
The yield strength of a sampling point of a coil that belongs to an
order must be within the upper and lower values of that order .


ONTOR UL E
Grounding rules in texts and in the ontology

Ontology

SteelProduct ChemicalComponent

target yieldStrengh isComposedOf
Order hasLower Value Coil
Steel Zinc
Rule base hasUpper

R3 belongsTo
R2
R1

The Galvanisation Line processes coils, long strips of steel, to provide them a coating of zinc; this coating
will give the product an improved surface aspect as well as protection from corrosion. During the process
the mechanical properties, such as the yield strength, of the steel are also changed due to the thermal
cycle it goes through.

The actual yield strength of the coil should be within the tolerances of the order the coil belongs to.


ONTOR UL E
Grounding rules in texts and in the ontology

Rich index structure
Text
Semantic model (ontology + rules)
3 types of links
Text ↔ Ontology
Ontology ↔ Rules
Rules ↔ Text
Beneﬁt
Explaining rules
Tracing inconsistencies
Updating policy documents


ONTOR UL E
Acquisition overall strategy

Acquisition Term list Network of Ontology
corpus termino-concepts
t1
t2 ONTOLOGY
ACQUISITION
t3 &
... AUTHORING
tn
Extraction Normalisation Formalisation

CR2 RULE
R2 ACQUISITION
CR3
R4 R3 &
CR4 AUTHORING
Relevant
Acquisition fragments
corpus texts Candidate rules Formal rules


ONTOR UL E
Ontology and rule acquisition

Two distinct processes
Rule updates are much more frequent than ontology revisions
The ontology and the business rule base might be authored by
different business people
Two interlinked processes
Rule editing relies on the ontological annotation of the acquisition
corpus
Rule editing might call for revision/extension of the underlying
ontology
The rule fragments can be exploited during the ontology acquisition
to focus on the rule vocabulary and the rule application


ONTOR UL E
Outline


State of the art

Corpus design





ONTOR UL E
SBVR1

Semantics of Business Vocabulary and Business Rules
OMG Request For Proposal issued by OMG in June 2003
An OMG standard since December 2007
Version 1.0 formally published in January 2008
Revision 1.1 underway

A business vocabulary contains all the specialized terms, names, and
fact type forms of concepts that a given organization or community uses
in their talking and writing in the course of doing business.

Business Rules form a set of explicit or understood regulations laws or
principles governing conduct or procedure within any business activity,
describing, or prescribing what is possible or allowable.

1
This section is based on the SBVR OMG speciﬁcation, v1.0 [OMG, 2008] and
some
(59/221) elements are borrowed from a presentation from J. Hall ONTORULE Consortium, all rights reserved
c (Model systems).

ONTOR UL E
Basics

Scope of an SBVR model
body of shared meanings of a semantic community
at least one vocabulary owned by a speech community within that
semantic community
Semantics of SBVR
A subset of SBVR can be expressed in 1st Order Logic
A small extension can only be expressed in modal logic
SBVR Structured English
SBVR proposes Structured English (SBVR SE) as one of possibly
many notations that can map to the SBVR Metamodel


ONTOR UL E
SBVR metamodel (1st part)

SBVR is a (abstract) language in which one can describe
Object types to classify things on the basis of their common
properties (= concepts, also called "noun concepts")
Concept definitions to define the meaning of all the terms at the
ABox and the TBox levels (= concept definition)
Fact types to define relations involving object types and their
instances (= n-ary predicates, also called "verb concepts")
Fact type forms to enable speech community specific
communications (= patterns or templates of expressions of a fact
type)


ONTOR UL E
Example

coil belongs to order
Synonymous form: order owns coil
Necessity: Each coil belongs to at most one order .
Note: If a coil fails to meet order targets it is de-assigned from the
order.
coil has been galvanised
unprocessed product
Definition: coil that belongs to an order and that has not been
galvanised
processed product
Definition: coil that belongs to an order and that has been galvanised
Concept Type: implicitly-understood concept
processed product has lab test
Necessity: Each lab test is of exactly one processed product .
lab-tested product
Definition: processed product that has had a lab test

ONTOR UL E
Terms and names

Individual concepts (noun concepts) have names
ArcelorMittal Galvanization Line Coil #13 Gijon factory
Concepts (general noun concepts)
May have formal, part-formal or informal deﬁnitions
May be adopted
May be ’implicitly understood’ (terms used in their everyday sense)
Width Thickness Weight


ONTOR UL E
Concept intensional deﬁnition

unprocessed product (deﬁned concept)
coil (more general concept)
that belongs to an order and that has not been galvanised (delimiting
characteristic)


ONTOR UL E
Fact types

Fact types deﬁne unary, binary or n-ary relations between concepts

coil has been galvanised
coil belongs to order

Concepts (general noun concepts) play roles in fact types
A role name may be:
an existing term: order
a speciﬁc role name
Coil is assigned to order
OrderAssignement
Fact symbols have meaning only in relation to the concept that play
the fact type roles
has has different meanings in Coil has Thickness and in
OrderTarget has LowerTolerance

ONTOR UL E
Constraints in fact types

Fact type

Coil belongs to order

By itself, the fact type means
’a coil can belong to any number of orders (including zero),
and vice versaa’
A fact type can be constrained (’necessity’ structural rule)
Necessity: Each coil belongs to at most one order .


ONTOR UL E
Fact type forms

Deﬁnition
representation of a fact type by a pattern
or template of expressions based on the fact type
A fact type may have multiple fact type forms
order has target yield strength (semantics in role name)
order targets yield strength (semantics in verb)
yield strength is target of order


ONTOR UL E
SBVR metamodel (2nd part)

SBVR is a (abstract) language in which one can describe
Integrity rules to restrict the contents of the ABox and the content
transitions to the ones considered useful
Derivation rules to generate new assertions of facts (at the ABox
level) from existing assertions of facts
Operative business rules to specify prescribed, suggested or
self-imposed rules (may be violated)


ONTOR UL E
Creating business rules

1. Select a base fact type
yield strength is between the upper and lower values of order
2. Apply a modal operator
’Necessity’ or ’Possibility’ for a structural rule
’Obligation’ or ’Permission’ for an operative rule.
It is obligatory that yield strength is between the upper and lower
values of order .
Alternatively: yield strength must be between the upper and lower
values order .
3. Use additional fact types to quantify and qualify the rule
The yield strength of a sampling point of a coil that belongs to an
order must be between the upper and lower values of the order .


ONTOR UL E
Level of enforcement

The level of enforcement describes how strictly a rule will be
enforced
Some operative rules cannot be automated (or the enterprise has
decided not to automate them).
They require an enforcement regime:
Level of enforcement (strict, pre-authorized, post-justiﬁed . . . ) =
business rules
Detection of violations
Remediation of unacceptable activity
(Possibly) application of sanctions to offenders
An enforcement regime often leads to additional IS requirements


ONTOR UL E
Beneﬁts of SBVR

Uniﬁed business model combining the conceptual model (ontology)
and the rules
Business oriented presentation
Documented business model
Verbalization of the business model understandable to business
people

SBVR, a way to specify the expected behaviour of the rule system.


Part II

Integrating Ontologies and Rules


ONTOR UL E
Overview of Part II

Modeling business knowledge using OWL2
Why use OWL for business knowledge?
OWL by example
Limitations
Conclusions
Rules: Logical and Production Rules
Logical Rules
Production Rules
Logical vs. Production
Rules vs. Ontologies
Integration of Rules and Ontologies
Integration of Logical Rules with Ontologies
Integration of Production Rules with Ontologies
Demo

ONTOR UL E
Outline

OWL by example
Limitations
Conclusions



Demo


ONTOR UL E
What is an ontology

An ontology is a shared model of some domain of the world:

... introducing some vocabulary
... deﬁning the meaning of the concepts
... relating the concepts using properties
... describing the individuals


ONTOR UL E
What is OWL

OWL is the W3C recommended language for web ontologies

Based on the Description Logic SROIQ

History: OWL1 (2004) and OWL2 (2009)

Several syntaxes: RDF/XML (normative), DL, functional, XML,
Manchester


ONTOR UL E
Description Logics

A Description Logic Knowledge Base consists of three parts:
1. TBox: the ontology axioms deﬁning the concepts
2. RBox: the ontology axioms deﬁning the properties
3. ABox: ground facts about the individuals, described using the
terminology

Description Logics is a subset of First Order Logic
Open World Assumption (OWA)
Not all statements about a domain can be formalized with a
Description Logic


ONTOR UL E
Why should I care about OWL

Even if it is not possible to produce a complete model for a business
domain, using OWL has a number advantages:

Understability and clarity of the model
Easy maintenance of the model
Reusability of a model


ONTOR UL E
OWL advantages: Understability and Clarity

OWL, as a Description Logic language, has an object-centered view.
It grasps the structure of the business domain:
Aggregation: “A steel product has a number of attributes: length,
weight, chemical composition”
Classiﬁcation: “Steel products can be ﬂat, long or stainless”
Generalization: “All steel products are produced in a steel factory ”

DL axioms are easier to understand than FOL formulas: “All coils are
steel products”
FOL: ∀x Coil(x) → SteelProduct(x)
DL: Coil SteelProduct


ONTOR UL E
OWL advantages: Easy Maintenance

Logical implications of each statement are intuitive

Formal validation of the business model. Automatic consistency
checking using dedicated tools (DL reasoners)
Not looking for completeness or integrity, but just for absence of
contradictions


ONTOR UL E
OWL advantages: Reusability

Ontologies capture the static knowledge of the domain
Changes are not frequent
Several applications can beneﬁt from it as a business data model

Being a standard means:
No vendor lock-in. Applications are interoperable
Ontologies can be published and found in the web. OWL is built on
top of the web stack (URIs, HTTP, etc.).The default exchanged
format is RDF.


ONTOR UL E
Outline

OWL by example
Limitations
Conclusions



Demo


ONTOR UL E
OWL in a nutshell

OWL vocabulary Properties
Concepts, Properties Subsumption and
and Individuals Equivalence
Concepts Disjointness
Domain and Range
Subsumption and
Inverse, Funct. and Inv.
Equivalence
Funct.
Disjointness
Symm., Asymm.,
Union, Intersection and
Reﬂex. and Irreﬂex.
Complement
Transitiveness and
Enumerations
Property Chains
Cardinality, Existential,
Universal and Other features
Individual restrictions


ONTOR UL E
Running Example

Business statements from the steel domain will be examined individually
Each sentence will introduce a new modeling feature of OWL
The following slides have the same pattern:
1. Business sentence in natural language
2. Sentence formalization (DL and/or Functional Syntaxes)
3. Comments and consequences


ONTOR UL E
Concepts

“There is a set of objects called coils”

Example
Coil

A new symbol (URI) is introduced in the ontology vocabulary for
each business concept
A DL concept represents a set of individuals of a business domain


ONTOR UL E
Concept Hierarchies

“Coils are ﬂat steel products which in turn are steel products”

Example
Coil FlatSteelProduct SteelProduct

Arbitrarily complex concept hierarchies can be deﬁned
Multiple inheritance is allowed


ONTOR UL E
Concept Equivalence

“Customer and product assignee are equivalent views of the
same concept”

Example
Customer ≡ ProductAssignee

The same set of objects are interpreted in two different points of
views (e.g. accounting and shipment)
Equivalence axioms may be used to align existing vocabularies


ONTOR UL E
Disjoint Concepts

“Chemical elements are either carbon elements or
non-carbon elements”

Example
CarbonElement NonCarbonElement ≡ ⊥

With this kind of axioms, it is possible to explicitly forbid the
classiﬁcation of a single domain object as an instance of two (or
more) incompatible concepts.


ONTOR UL E
Datatype Properties

“Length is a measurable property”

Example
length

Datatype properties express attributes of the domain objects
Their values are literals (numbers, strings, booleans, etc.)
Most datatypes are taken from XML Schema


ONTOR UL E
Object Properties

“Location is a property of physical objects”

Example
location

Object properties express relationships between domain objects


ONTOR UL E
Property Domain

“Length is a property of coils”

Example
∀length− .Coil

Domain axioms are not checks, but inference rules, i.e. “all objects
that have a length are inferred to be coils”
Note for OO programmers: Properties are deﬁned globally and
independently of concepts (classes). Domain declaration is
optional.


ONTOR UL E
Property Range

“Length is measured numerically”
“Objects in the steel domain are located in factories”

Example
∀length.xsd : double
∀locatedIn.Factory

Same notes that in the previous slide apply here


ONTOR UL E
Properties Hierarchy

“If a coil has been rejected by a QA team, then it has been
examined by that team”

Example
rejectedBy examinedBy

Arbitrarily complex property hierarchies can be deﬁned
Multiple inheritance is allowed
Note for OO programmers: this feature is usually not available in OO
programming languages.


ONTOR UL E
Property Equivalence

“The location property in system A is the same thing as the
place property in system B”

Example
location ≡ place

The same set of relationships are interpreted from two different
points of views (e.g. accounting and shipment)
Equivalence axioms may be used to align existing vocabularies


ONTOR UL E
Disjoint properties

“Regarding Quality Assurance, a coil cannot be produced and
veriﬁed by the same team”

Example
DisjointObjectProperties( producedBy veriﬁedBy )

With this kind of axioms, it is possible to explicitly forbid certain pairs
of relationships


ONTOR UL E
Individual Positive Assertions

“Coil #13 is a coil, with length 670 meters, currently located in
Aviles factory”

Example
Coil#13 ∈ Coil
(Coil#13, 670) ∈ length
(Coil#13, AvilesFactory) ∈ locatedIn

Individuals are classiﬁed in concepts using unary predicates
Values for properties of individuals are asserted using binary
predicates
Assertions about individuals populate the knowledge base (A-Box)


ONTOR UL E
Individual Negative Assertions

“Coil #13 does not contain chromium in its chemical
composition”

Example
(Coil#13, Chromium) ∈ contains
/

This kind of assertions are useful to detect inconsistencies in the
description of individuals
Negative assertions can be made about datatype and object
properties, but not about classiﬁcation


ONTOR UL E
Individual Equality and Inequality

“Coil #13 and product #7 are the same physical object”
“Aviles factory and Gijon factory are different places”

Example
Coil#13 = product#7
AvilesFactory = GijonFactory

Individual equality means logical equality. No uniﬁcation process is
involved
Be aware of OWA and the lack of Unique Name Assumption (UNA):
Gijon and Aviles factories are not different places unless you
explicitly declare them so


ONTOR UL E
Concept Intersection

“Coils are ready to be shipped whenever they have passed the
Quality Assurance process”

Example
ShippableCoil ≡ Coil QACertifiedProduct

Complex concepts can be created using set-intersection
This mechanism is similar to the definition of multiple inheritances
(eg. ShippableCoil Coil; ShippableCoil QACertifiedProduct)


ONTOR UL E
Concept Union

“Steel products can be ﬂat steel products, long steel products
or stainless steel products”

Example
SteelProduct ≡ FlatProduct LongProduct StainlessSteelProduct

Complex concepts can be created using set-union
This mechanism is often used in disjointness axioms:
FlatProduct LongProduct ≡ ⊥,
FlatProduct StainlessSteelProduct ≡ ⊥,
LongProduct StainlessSteelProduct ≡ ⊥


ONTOR UL E
Enumeration of Individuals

“Chemical elements involved in steel products are Iron, Carbon,
Manganese, Chromium, Vandium, Tungsten and Nickel”

Example
ChemicalElement ≡
{Iron, Carbon, Manganese, Chromium, Vandium, Tungsten, Nickel}

Concepts can be deﬁned extensionally, i.e. enumerating the set of
individuals


ONTOR UL E
Concept Complement

“Non-carbon elements are all except carbon and iron”

Example
NonCarbonElement ≡ ChemicalElement ¬{carbon, iron}

More details about negation in DLs will be addressed later in the
tutorial


ONTOR UL E
Cardinality Restrictions

“A coil can be shipped to a customer if it contains
at most 12 minor defects”

Example
ShippableCoil ≤ 12contains.MinorDefect

Restriction on the number of relationships can be qualiﬁed (to a
certain concept) and non-qualiﬁed (to any concept)
Operator can be at most (≤), at least (≥) or exactly (=)


ONTOR UL E
Existential Restrictions

“Alloy Steel is steel that contains non-carbon elements”

Example
AlloySteel ≡ Steel ∃contains.NonCarbonElement

Intensional concept definition based on the existence of
relationships between business objects
It is often used with subclassification axioms or to define new
concepts with equivalence axioms


ONTOR UL E
Universal Restriction on Property Expressions

“An order is fulfilled if all the coils are shippable”

Example
SatisfiedOrder ∀comprises.ShippableCoil

Intensional concept definition based on the universality of
relationships between business objects
It is often used with subclassification axioms or to define new
concepts with equivalence axioms
It can be used to restrict the range of a property in the context of a
particular concept


ONTOR UL E
Individual Value Restriction

“Maraging Steel is a kind of steel that contains nickel”

Example
MaragingSteel ≡ Steel ∃contains.{Nickel}

Intensional concept deﬁnition that relates business objects with a
single individual (eg. Nickel)
It is a particular case of the existential restrictions


ONTOR UL E
Inverse properties

“If a product has a defect, the defect must be located in the
product”

Example
hasDefect ≡ locatedIn−

Some properties can be modeled in both directions (eg. hasPart and
isPartOf ). Declaring them as inverse simpliﬁes the population of the
ontology, as it is possible to infer the other direction.


ONTOR UL E
Functional property

“A coil can be shipped to exactly one customer”
“A coil has just one length”

Example
FunctionalObjectProperty( shippedTo )
FunctionalDatatypeProperty( length )

Object equality may be inferred as a consequence of a functional
property having multiple values (eg. “If coil #12 has been shipped to
customer A and customer B, then both customers are the same”)


ONTOR UL E
Inverse functional property

“Two coils produced to meet the same order must be the same,
even if they are described by different systems”

Example
InverseFunctionalObjectProperty( hasOrder )

Object equality may be inferred as a consequence of an inverse
functional property having multiple values (eg. “If coil #12 and
inventory item #7 meet the same order #323, they are the same
object”)
Useful for integrating data coming from different knowledge bases


ONTOR UL E
Keys

“Each coil has a product ID which uniquely identiﬁes the coil”

Example
HasKey( Coil ( ) ( productId ) )

Similar to keys in databases
Compound keys (using both object and datatype properties) are
allowed
As inverse functional properties, keys are also useful to integrate
data coming from different sources


ONTOR UL E
Reflexive and Symmetrical Properties

“Several coils can be related because they come from the
same steel casting”

Example
ReflexiveObjectProperty( sameCastingAs )
SymmetricObjectProperty( sameCastingAs )

Reflexive properties relates a domain object with itself
Symmetric properties create “mirror” relationships


ONTOR UL E
Irreflexive and Asymmetrical Properties

“Steel production is arranged in a sequence of production steps
which follow each other”

Example
IrreflexiveObjectProperty( follows )
AsymmetricalObjectProperty( follows )

Irreflexive: objects can not be related with themselves
Asymmetrical: objects can be related just in one direction, but not in
the other one


ONTOR UL E
Transitive Property

“All metallurgical steps that follow a given one are considered
to be downstream in the processing chain”

Example
follows downstream
downstream∗ downstream

Transitivity is not inherited in the property hierarchy


ONTOR UL E
Property Chains

“If a shippable coil is assigned to an order, the coil is shipped to
the customer who placed the order”

Example
assignedTo ◦ placedBy shippedTo

Coil
placedBy Customer
assignedTo Order

shippedTo

Simple rules can be implemented using this mechanism. Chaining
can be arbitrarily long, but the properties are required to be chained:
range(pi ) dom(pi+1 ) = ⊥

ONTOR UL E
Metamodeling

“Coils and wire are entries in the company product catalog.
Coil #13 is a coil. ”

Example
Coil ∈ ProductCatalogEntry
Wire ∈ ProductCatalogEntry
Coil#13 ∈ Coil

Metamodeling introduces two levels of terminology description
Metamodeling is useful to provide additional domain information
about concepts
Be careful with metamodeling. Sometimes it is preferable to use an
alternative modeling or even annotations

ONTOR UL E
Datatype Restrictions and Definitions

“Order IDs in Aviles start with prefix 033 plus another 10 digits”

Example
Declaration( Datatype ( OrderId ) )
DatatypeDefinition( OrderId
DatatypeRestriction( xsd : string xsd : pattern ”033[0 − 9]{10}” ) )
DataPropertyRange( hasOrderID OrderId )

XML Schema provides the basic datatypes for OWL
User-defined datatypes are allowed
Some validation data rules can be implemented using restrictions
(eg. numerical ranges)


ONTOR UL E
Resource Annotations

“Spanish word for coil is bobina”

Example
AnnotationAssertion(rdfs : labelCoil”bobina”@es)

Annotations are not relevant for reasoning
A few annotation properties are predeﬁned in OWL
Multilingual capabilities are inherited from RDF
Annotation properties can have domain, range and hierarchies


ONTOR UL E
Outline

OWL by example
Limitations
Conclusions



Demo


ONTOR UL E
What is Open World Assumption

In OWA, no assumptions are made about the truth value of statements
that we do not know.
OWA ...
... assumes incomplete information by default
... is good for reusability. If we extend an ontology, all existing true
statements remain true (monotonic logic)
... does not make the Unique Name Assumption.


ONTOR UL E
Why should I care about OWA

Side effects of OWA (counterintuitive behavior):
If two individuals have different names (IDs), they can be inferred to
be the same resource
Data validation for incorrect or missing values (i.e. integrity) is not
possible
Sometimes it is mandatory to explicitly declare even silly business
statements (eg. People and Places are disjoint concepts)


ONTOR UL E
Integrity Constraints

“All coils must have a relation to the factory where they were
produced ”

Example
Coil ∃producedIn.Factory
Coil#12 ∈ Coil

This description is consistent even if we do not know where coil #12 was
produced. This is a side-effect of OWA.
Proposed solution:
Escalation to a Closed World Assumption (CWA) system,
implementing integrity constraints with either rules, query languages
or modal languages (K-operator)


ONTOR UL E
N-ary Predicates

“Coil #12 completed production step #7 at 2010/03/12 15:20
and completed production step #14 at 2010/03/12 18:57”

OWL lacks support for n-ary predicates.
Proposed solutions:
Reiﬁcation of the n-ary predicate
Change the modeling point of view

Consequences of using reiﬁcation (More details later in the tutorial):
Introducing non-intuitive, non-business concepts
Syntactic verbosity
Non-transparent for applications (eg., rules or query languages)


ONTOR UL E
Procedural Knowledge

“Shipment distance is the linear distance between the location
of the coil and the shipment destination. ”

Shipment distance is a calculated property, which value can not be
obtained from OWL reasoning.
Proposed solution:
Use a procedural language in combination with OWL, either an
imperative programming language such as JAVA or a declarative
one such as LP.


ONTOR UL E
Dynamic Knowledge

OWL ontologies describe a stateless picture of a given business
domain. Therefore it is difﬁcult to represent changes, business
processes, states, transitions, events, etc.

This limitation is shared with pure LP

Production rules ﬁt much better for this purpose


ONTOR UL E
Outline

OWL by example
Limitations
Conclusions



Demo


ONTOR UL E
OWL in practice

Mature authoring tools. Both commercial and open source

DL reasoners continously improving (eg.: performance)

Publicly available business ontologies are scarce (exception: Health
Science).
Internal usage of ontologies inside companies is difﬁcult to measure


ONTOR UL E
OWL2 Profiles

OWL 2 DL is a very expressive Description Logic (although
decidable).
However complexity of the reasoning algorithms (N2ExpTime)
hampers scalability
Subsets (profiles) of OWL 2 have been identified:
Still sufficiently expressive
Lower complexity (PTime/logspace)
Already available profiles:
EL profile, optimized for large terminologies
QL profile, optimized for queries
RL profile, can be implemented with rule systems


ONTOR UL E
OWL and SBVR

SBVR is a very expressive language to capture complete business
models using a controlled natural language

Some parts of the SBVR business model can be formalized using
OWL ontologies

Business experts can take advantage of formal reasoning
techniques to guarantee model consistency

Business experts can take advantage of web nature of OWL and
OWA assumption for reusability of business models in several
scenarios


ONTOR UL E
OWL and combinations with other languages

OWL is commonly used to build expressive, shared and reusable data
models. However OWL is not a language for writing applications.


How to Integrate Ontologies and Rules?

How to Integrate Ontologies and Rules?

Recommandé

Recommandé

Contenu connexe

Similaire à How to Integrate Ontologies and Rules?

Similaire à How to Integrate Ontologies and Rules? (20)

Dernier

Dernier (20)

How to Integrate Ontologies and Rules?