how to integrate ontologies and rules?

Ontologies meet Business Rules

ONTOR UL E

How to Integrate Ontologies and Rules?

Adeline Nazarenko Luis Polo Thomas Eiter Jos de Bruijn AntoniaSchwichtenberg 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 policydocuments

2. What type of business knowledge is typically modeled as anontology and what knowledge as rules (both logical and productionrules)

3. Which approaches to combining ontologies and rules are currentlyavailable; 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 maturecommercial 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 10minutes)

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

I The ONTORULE project consortium: ILOG (an IBM Company),ontoprise, Free University of Bolzano, Vienna University ofTechnology, PNA, Université Paris 13, Fundación CTIC, Audi andArcelorMittal

http://ontorule-project.eu

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


http://ontorule-project.eu


ONTOR UL E

Business Vocabulary



ONTOR UL E

Business Scenario

Production process

Decision (assignment)

Ship to customer

Repair

Scrap

Coil

Business knowledge


Part I

From Business Policy Documents to aBusiness Model



ONTOR UL E

Overview of Part I

Building business models from written policies

State of the artOntology designOntology populationInformation extraction

Corpus design

Ontology acquisitionTerminological analysisTerm normalizationConceptualizationRelation identification

Business rule acquisition

Semantic Business Vocabulary and Rules



ONTOR UL E

Outline


State of the art

Corpus design

Ontology acquisition





ONTOR UL E

Why starting from texts?

An alternative source of informationI Expert knowledge is difficult to make explicitI Experts are seldom available for intensive interviewsI Large amount of written information is available

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

business models



ONTOR UL E

What can be extracted from texts?

AlthoughI Documents do not contain all the relevant informationI Domain knowledge is seldom explicit

Texts are precious source of informationI Documents often express factual knowledge about the domain

entities, their properties, their evolution and their relations.I Documents also reflect the underlying domain knowledge : what are

the relevant concepts? how do they relate to each other?I 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 artOntology designOntology populationInformation extraction

Corpus design



Semantic Business Vocabulary and Rules(13/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

Building a hierarchy of concepts

Two main approaches

I A distributional approach for "learning" ontologiesI A terminological approach for assisting the conceptualization task



ONTOR UL E

Distributional approach

Words with similar meanings tend to appear in similar contexts [Harris etal., 1989].

Examplemechanical propertiesmechanical strengthmechanical processmechanical behaviour

I Semantic classes of words can be built out of a distributionalanalysis

I They are supposed to represent domain conceptsI The results are noisy and difficult to exploit

[Hindle, 1990][Dagan et al., 1993][Faure and Nédellec, 1999][Maedche andStaab, 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

I The terms extracted from a text reflect the conceptual vocabularyI 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

Definition (Named entities)

Textual units that are similar to proper names whose meaning is builtthrough the operation of reference.

Example

STRIP BH2 2% Nitrogen

Given a conceptual model (ontological T-Box), named entity recognitiontools can be used to extract the concept and relation instances and thusenrich the ontological A-Box.

[Magnini et al., 2006] [Giuliano and Gliozzo, 2008]



ONTOR UL E

Information extraction

Definition (Information extraction)

A set of techniques for automatically extracting structured informationfrom unstructured textual documents (e.g. Who gives a conference,when and where?)

[Sundheim, 1992][Grishman and Sundheim, 1996]

GoalsI Extracting relations between entitiesI Discovering concepts properties and relations

[Hearst, 1992] [Aussenac-Gilles and Jacques, 2008]

I Extracting business rules



ONTOR UL E

Information extraction method

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

Example

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

DifficultiesI Extraction patterns are often corpus dependentI Manual design is tedious and error proneI 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 approachesI Bootstrapping and help business modelingI Enabling business experts to understand and author

business modelsI Anchoring business models in policies

Strategy Three major stepsI Designing an acquisition corpusI Acquiring the domain conceptual model (ontology)I 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]

I An acquisition corpus is application dependentI Identifying relevant documents is challenging in many organizationsI The sources are heterogeneous (size, types, technicality, target

audience)I There may be missing or redundant pieces of knowledgeI Some documents may be confidential

How to achieve a good representativity of the domain to model?



ONTOR UL E

In practice

I There is no stable methodology or acknowledged good practice todesign acquisition corpus: all use cases are different.

I Knowledge engineers inventory the available documentation andextract the most useful pieces.

Example (ArcelorMittal use case)

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

words)I Email discussion with experts



ONTOR UL E

Outline


State of the art

Corpus design

Ontology acquisitionTerminological analysisTerm normalizationConceptualizationRelation identification


Semantic Business Vocabulary and Rules(24/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

Ontology design

The TERMINAE approach to ontology acquisition

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

I An interactive approachI A terminological approach

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



ONTOR UL E

From texts to domain model

Texts reflect the underlying domain model . . .I Domain vocabulary: hardening element, iron crystal latticeI Controlled meaning: elements = chemical elementI Situated communication (e.g. actors, locations, roles)I Explicit domain knowledge: The grain structure of steel influences

its mechanical behaviorI Factual knowledge: Coil #13 is a coil, with length 670 meters,

currently located in Aviles factor.

But a partial and distorted viewI Synonymy: defects = non-conformitiesI Polysemy: (lab test) results 6= result (of the assignment process)I EllipsesI Presuppositions



ONTOR UL E

From a corpus to an ontology

Domain model(ontology)

word and term occurrencessyntactic relations, sentences

terms & terminological

relations

Corpus(text)

Sublanguage model(semantic network)

concepts, roles &

properties

2

3

1

1. NLP extraction2. Selection and disambiguation of core meanings3. Formalisation



ONTOR UL E

Overall approach

Acquisitioncorpus

Terms

Terminological relations

Termino-concepts

Termino-conceptual relations

Concepts

Conceptual relations

Terminologicallevel

Termino-conceptuallevel

Conceptuallevel (ontology)



ONTOR UL E

1st step: Terminological analysis

Acquisitioncorpus

Terms


Termino-concepts


Concepts


Terminologicallevel





ONTOR UL E

Terminology extraction

Definition (Terminology)

The body of words or terms relating to a particular subject, field of activityor branch of knowledge.

Definition (Term Extractor)

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

Underlying hypothesisI The relevant terms of a corpus reflect the domain conceptsI 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 providethem a coating of zinc; this coating will give the product an improvedsurface aspect as well as protection from corrosion. During the processthe mechanical properties, such as the yield strength, of the steel arealso changed due to the thermal cycle it goes through.



ONTOR UL E

2nd step: Term normalization

Acquisitioncorpus

Terms


Termino-concepts


Concepts


Terminologicallevel





ONTOR UL E

Term normalization

To abstract from language peculiaritiesI Term filtering and selection (noise)I Term variant clustering (synonymy)I Term disambiguation (polysemy)

OutputI A semantic network of normalized terms and terminological relationsI TERMINAE can export the result in SKOS1

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


ONTOR UL E

Term filtering and selection

Term extractors provide noisy results (candidate terms) that must befurther filtered [Nazarenko and Zargayouna, 2009]

I Terminology creation is a social process: there is a consensuswithin a given community to use a term t with a specific meaning

I Termhood cannot be fully captured through linguistic and statisticalproperties

Validation interfaces allow for filtering based onI CharactersI Lexical itemsI 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 singletermino-concept

Exampleresidual carbon precipitation thickness reduction ratesprecipitation of residual carbon rate in thickness reductionprecipitations of residual carbon reduced thicknesscarbon precipitations reduction rate of thickness



ONTOR UL E

Variant detection

Some variants can be identified automaticallyI Typographical normalization: colour vs colorI Morphological analysis

singular vs. plural formsverbs vs. nominalizations

I Syntactic analysis based on equivalent syntactic patterns [Jacqueminand Tzoukermann, 1999]Noun Noun⇔ Noun of Noun

I Synonymy propagation [Hamon et al., 1998]If Noun1 ⇔ Noun2 then Noun1 Noun⇔ Noun2 Noun

Other variants often have to be manually identifiedI Irregular morphology: datum vs. dataI Semantic variation: defect vs. non-conformities

"... sometimes there are defects, non-conformities with regard to theallowed ranges... "



ONTOR UL E

Term disambiguation

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

Example (result)

result→ lab test result = lab test dataresult→ assignment result = outcome of the assignment process

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



ONTOR UL E

Terminological forms (TERMINAE)



ONTOR UL E

3rd step: Conceptualization

Acquisitioncorpus

Terms


Termino-concepts


Concepts


Terminologicallevel





ONTOR UL E

From termino-concepts to concepts

Once the relevant domain elements are identified, normalized anddisambiguated, the termino-conceptual level can be formalized into aformal ontology.At the conceptual level, the termino-concepts can be modeled asI conceptsI instances of conceptsI relations (object or data properties)

Those modeling choices depend on the domain and the aimedapplication.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 linkedto that termino-concept, which is itself associated to one or severalsynonymous terms and to text occurrences.

The termino-concept/concept links ensure the traceability of theconceptual level which is grounded in the source document.



ONTOR UL E

4th step: Relation identification

Acquisitioncorpus

Terms


Termino-concepts


Concepts


Terminologicallevel





ONTOR UL E

Enriching the conceptual hierarchy with relations

Two complementary strategiesI Text driven approach where terminological relations

I are extracted from the acquisition corpusI are normalized into termino-conceptual relationsI are formalized into ontological elements at the conceptual level

I Ontology driven approachI The knowledge engineer looks for specific relationsI Each relation is associated with a set of characteristic extraction

patternsI The matching text fragments are occurrences of the searched

relations.



ONTOR UL E

Looking for relations

I Tools like TERMINAE propose facilities to design patterns and minetexts

I Frequent verbs are good cluesI Co-occurring terms often bring relations into light

Example

Property isCharacterizedByI Steel is characterized by the mechanical properties of products

sold. . .I Surface quality is characterized by surface topography, lubrication

and chemical treatment.I . . . 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 acquisitionI Automatic natural language processing of acquisition corpusI Normalization of the terminological output into a disambiguated

semantic network of termino-conceptsI Formalization of that network into an ontology

Future developmentsI Enriching the corpus analysis with named entities recognitionI Automatically clustering terms (distributional analysis of terms)I Integrating bottom-up relation extraction methods



ONTOR UL E

Ontology acquisition: conclusion

TERMINAE, a tool to support that processI The modeling work is supported by specific interfaces (i.e.

terminological forms).I Linking concepts to termino-concepts and terms ensure the

traceability of the conceptual model to the source text.I 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 elements3. 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

1 Rule extraction2 Semantic annotation wrt. ontology3 Extraction of relevant textual fragments4 Rule editing and rephrasing

1

Index

Documentsacquisition corpus

Structural rules

Operative rules

Documentsacquisition corpus

Ontologyxx

x

xx

x

2

R1R5 R4

R2R3

Business rule bases

Index

3

4



ONTOR UL E

Fragment detection

Information extraction can help the identification of fragments of textstating rules, although business rules cannot be fully automaticallyextracted from written policiesI Precise extraction patterns are difficult to design as they are highly

corpus dependantI Clues and combinations of clues can be used to filter out some

relevant fragments and bootstrap the rule acquisition processI Modal verbsI Linguistic markersI Domain specific action verbs



ONTOR UL E

Example of rule fragments

Example

I Usually these targets are allowed to vary within a certain range,specified in the order.

I However, sometimes there are defects, non-conformities withregard to the allowed ranges, that may make the coil unsuitable forthe order it is assigned to.

I If a coil has a defect, mark it as ’defective’ scrap the coil and alertthe user of the defect.

I When the line finishes the processing of each coil a decision mustbe made regarding the assignment of the coil.

I If nevertheless this is the result, the coil must be inspected by anexpert and the decision on the assignment be made manually.



ONTOR UL E

Fragment annotation

Definition (Semantic annotation)

Semantic annotation is an ontology-driven interpretation of the documentcontent. Textual units (e.g. words, phrases, sentences, paragraphs) areannotated with ontological ones (concepts, instances, roles, propertiesinstances) [Ma et al., 2010].

Where do annotations come from?I The corpus that has been used for ontology acquisition has been

annotated during the acquisition process (ontology to text linksoutput by TERMINAE)

I New corpus can be semantically annotated using the combinedontological-terminological resource output from the acquisitionprocess (OWL and SKOS output from TERMINAE)



ONTOR UL E

Fragment annotation: 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 the coil should be within the upper and lower values of the order the coil belongs to.

Source document

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 indicated by the order the coil belongs to.

Extraction of relevant textual fragment

Semantic annotation wrt. ontology

Rule editing

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

SBVR SE Rule Statement

CoilOrder

targethasLower

hasUpper

Value

SteelProduct

yieldStrengh

belongsTo

Ontology



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 tolerancesindicated by the order the coil belongs to.I 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 amechanical defect.→ The yield strength is a property of a sampling point of a coil (6= coil).

I The yield strength of a sampling point of a coil that belongs to anorder must be within the upper and lower values of that order .



ONTOR UL E

Grounding rules in texts and in the ontology

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.

CoilOrdertarget

hasLowerhasUpper

Value

SteelProduct

yieldStrengh

belongsTo

Ontology

ChemicalComponent

ZincSteel

isComposedOf

R1R2

R3

Rule base



ONTOR UL E

Grounding rules in texts and in the ontology

I Rich index structureI TextI Semantic model (ontology + rules)I 3 types of links

I Text↔ OntologyI Ontology↔ RulesI Rules↔ Text

I BenefitI Explaining rulesI Tracing inconsistenciesI Updating policy documents



ONTOR UL E

Acquisition overall strategy

OntologyAcquisition corpus

t1t2 t3...tn

Term list Network oftermino-concepts

Formal rules

Relevant fragments

texts Candidate rules

R4R2

R3CR4

CR2CR3

Acquisition corpus

Extraction Normalisation Formalisation

ONTOLOGYACQUISITION

&AUTHORING

RULEACQUISITION

&AUTHORING



ONTOR UL E

Ontology and rule acquisition

Two distinct processesI Rule updates are much more frequent than ontology revisionsI The ontology and the business rule base might be authored by

different business people

Two interlinked processesI Rule editing relies on the ontological annotation of the acquisition

corpusI Rule editing might call for revision/extension of the underlying

ontologyI 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 RulesI OMG Request For Proposal issued by OMG in June 2003I An OMG standard since December 2007I Version 1.0 formally published in January 2008I Revision 1.1 underway

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

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

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


ONTOR UL E

Basics

I Scope of an SBVR modelI body of shared meanings of a semantic communityI at least one vocabulary owned by a speech community within that

semantic communityI Semantics of SBVR

I A subset of SBVR can be expressed in 1st Order LogicI A small extension can only be expressed in modal logic

I SBVR Structured EnglishI 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 describeI Object types to classify things on the basis of their common

properties (= concepts, also called "noun concepts")I Concept definitions to define the meaning of all the terms at the

ABox and the TBox levels (= concept definition)I Fact types to define relations involving object types and their

instances (= n-ary predicates, also called "verb concepts")I Fact type forms to enable speech community specific

communications (= patterns or templates of expressions of a facttype)



ONTOR UL E

Example

coil belongs to orderSynonymous form: order owns coilNecessity: 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 galvanisedunprocessed product

Definition: coil that belongs to an order and that has not beengalvanisedprocessed product

Definition: coil that belongs to an order and that has been galvanisedConcept Type: implicitly-understood concept

processed product has lab testNecessity: Each lab test is of exactly one processed product .

lab-tested productDefinition: processed product that has had a lab test



ONTOR UL E

Terms and names

I Individual concepts (noun concepts) have names

ArcelorMittal Galvanization Line Coil #13 Gijon factoryI Concepts (general noun concepts)

I May have formal, part-formal or informal definitionsI May be adoptedI May be ’implicitly understood’ (terms used in their everyday sense)

Width Thickness Weight



ONTOR UL E

Concept intensional definition

unprocessed product (defined 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 define unary, binary or n-ary relations between concepts

coil has been galvanisedcoil belongs to order

I Concepts (general noun concepts) play roles in fact typesI A role name may be:

I an existing term: orderI a specific role name

Coil is assigned to orderOrderAssignement

I Fact symbols have meaning only in relation to the concept that playthe fact type roles

has has different meanings in Coil has Thickness and inOrderTarget has LowerTolerance



ONTOR UL E

Constraints in fact types

Fact type

Coil belongs to order

I By itself, the fact type means

’a coil can belong to any number of orders (including zero),and vice versaa’

I A fact type can be constrained (’necessity’ structural rule)

Necessity: Each coil belongs to at most one order .



ONTOR UL E

Fact type forms

I Definition

representation of a fact type by a patternor template of expressions based on the fact type

I 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 describeI Integrity rules to restrict the contents of the ABox and the content

transitions to the ones considered usefulI Derivation rules to generate new assertions of facts (at the ABox

level) from existing assertions of factsI 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 order2. Apply a modal operator

I ’Necessity’ or ’Possibility’ for a structural ruleI ’Obligation’ or ’Permission’ for an operative rule.

It is obligatory that yield strength is between the upper and lowervalues of order .

Alternatively: yield strength must be between the upper and lowervalues 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 anorder must be between the upper and lower values of the order .



ONTOR UL E

Level of enforcement

I The level of enforcement describes how strictly a rule will beenforced

I Some operative rules cannot be automated (or the enterprise hasdecided not to automate them).

I They require an enforcement regime:I Level of enforcement (strict, pre-authorized, post-justified . . . ) 6=

business rulesI Detection of violationsI Remediation of unacceptable activityI (Possibly) application of sanctions to offenders

I An enforcement regime often leads to additional IS requirements



ONTOR UL E

Benefits of SBVR

I Unified business model combining the conceptual model (ontology)and the rules

I Business oriented presentationI Documented business modelI 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 OWL2Why use OWL for business knowledge?OWL by exampleLimitationsConclusions

Rules: Logical and Production RulesLogical RulesProduction RulesLogical vs. ProductionRules vs. Ontologies

Integration of Rules and OntologiesIntegration of Logical Rules with OntologiesIntegration of Production Rules with Ontologies

Demo(73/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

Outline


Rules: Logical and Production Rules

Integration of Rules and Ontologies

Demo



ONTOR UL E

Outline




Demo



ONTOR UL E

What is an ontology

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

I ... introducing some vocabularyI ... defining the meaning of the conceptsI ... relating the concepts using propertiesI ... describing the individuals



ONTOR UL E

What is OWL

I OWL is the W3C recommended language for web ontologies

I Based on the Description Logic SROIQ

I History: OWL1 (2004) and OWL2 (2009)

I 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 defining the concepts

2. RBox: the ontology axioms defining the properties

3. ABox: ground facts about the individuals, described using theterminology

Description Logics is a subset of First Order LogicI Open World Assumption (OWA)I 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 businessdomain, using OWL has a number advantages:

I Understability and clarity of the modelI Easy maintenance of the modelI 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:I Aggregation: “A steel product has a number of attributes: length,

weight, chemical composition”I Classification: “Steel products can be flat, long or stainless”I Generalization: “All steel products are produced in a steel factory ”

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

I DL: Coil v SteelProduct



ONTOR UL E

OWL advantages: Easy Maintenance

I Logical implications of each statement are intuitive

I Formal validation of the business model. Automatic consistencychecking using dedicated tools (DL reasoners)

I Not looking for completeness or integrity, but just for absence ofcontradictions



ONTOR UL E

OWL advantages: Reusability

Ontologies capture the static knowledge of the domainI Changes are not frequentI Several applications can benefit from it as a business data model

Being a standard means:I No vendor lock-in. Applications are interoperableI Ontologies can be published and found in the web. OWL is built on

top of the web stack (URIs, HTTP, etc.).The default exchangedformat is RDF.



ONTOR UL E

Outline




Demo



ONTOR UL E

OWL in a nutshell

I OWL vocabularyI Concepts, Properties

and IndividualsI Concepts

I Subsumption andEquivalence

I DisjointnessI Union, Intersection and

ComplementI EnumerationsI Cardinality, Existential,

Universal andIndividual restrictions

I PropertiesI Subsumption and

EquivalenceI DisjointnessI Domain and RangeI Inverse, Funct. and Inv.

Funct.I Symm., Asymm.,

Reflex. and Irreflex.I Transitiveness and

Property Chains

I Other features



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

I A new symbol (URI) is introduced in the ontology vocabulary foreach business concept

I A DL concept represents a set of individuals of a business domain



ONTOR UL E

Concept Hierarchies

“Coils are flat steel products which in turn are steel products”

Example

Coil v FlatSteelProduct v SteelProduct

I Arbitrarily complex concept hierarchies can be definedI Multiple inheritance is allowed



ONTOR UL E

Concept Equivalence

“Customer and product assignee are equivalent views of thesame concept”

Example

Customer ≡ ProductAssignee

I The same set of objects are interpreted in two different points ofviews (e.g. accounting and shipment)

I Equivalence axioms may be used to align existing vocabularies



ONTOR UL E

Disjoint Concepts

“Chemical elements are either carbon elements ornon-carbon elements”

Example

CarbonElement u NonCarbonElement ≡ ⊥

I With this kind of axioms, it is possible to explicitly forbid theclassification of a single domain object as an instance of two (ormore) incompatible concepts.



ONTOR UL E

Datatype Properties

“Length is a measurable property”

Example

length

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



ONTOR UL E

Object Properties

“Location is a property of physical objects”

Example

location

I Object properties express relationships between domain objects



ONTOR UL E

Property Domain

“Length is a property of coils”

Example

> v ∀length−.Coil

I Domain axioms are not checks, but inference rules, i.e. “all objectsthat have a length are inferred to be coils”

I Note for OO programmers: Properties are defined globally andindependently of concepts (classes). Domain declaration isoptional.



ONTOR UL E

Property Range

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

Example

> v ∀length.xsd : double> v ∀locatedIn.Factory

I 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 beenexamined by that team”

Example

rejectedBy v examinedBy

I Arbitrarily complex property hierarchies can be definedI Multiple inheritance is allowedI 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 theplace property in system B”

Example

location ≡ place

I The same set of relationships are interpreted from two differentpoints of views (e.g. accounting and shipment)

I Equivalence axioms may be used to align existing vocabularies



ONTOR UL E

Disjoint properties

“Regarding Quality Assurance, a coil cannot be produced andverified by the same team”

Example

DisjointObjectProperties( producedBy verifiedBy )

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



ONTOR UL E

Individual Positive Assertions

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

Example

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

I Individuals are classified in concepts using unary predicatesI Values for properties of individuals are asserted using binary

predicatesI Assertions about individuals populate the knowledge base (A-Box)



ONTOR UL E

Individual Negative Assertions

“Coil #13 does not contain chromium in its chemicalcomposition”

Example

(Coil#13,Chromium) /∈ contains

I This kind of assertions are useful to detect inconsistencies in thedescription of individuals

I Negative assertions can be made about datatype and objectproperties, but not about classification



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#7AvilesFactory 6= GijonFactory

I Individual equality means logical equality. No unification process isinvolved

I Be aware of OWA and the lack of Unique Name Assumption (UNA):Gijon and Aviles factories are not different places unless youexplicitly declare them so



ONTOR UL E

Concept Intersection

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

Example

ShippableCoil ≡ Coil u QACertifiedProduct

I Complex concepts can be created using set-intersectionI This mechanism is similar to the definition of multiple inheritances

(eg. ShippableCoil v Coil; ShippableCoil v QACertifiedProduct)



ONTOR UL E

Concept Union

“Steel products can be flat steel products, long steel productsor stainless steel products”

Example

SteelProduct ≡ FlatProduct t LongProduct t StainlessSteelProduct

I Complex concepts can be created using set-unionI This mechanism is often used in disjointness axioms:

FlatProduct u LongProduct ≡ ⊥,FlatProduct u StainlessSteelProduct ≡ ⊥,LongProduct u 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}

I Concepts can be defined extensionally, i.e. enumerating the set ofindividuals



ONTOR UL E

Concept Complement

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

Example

NonCarbonElement ≡ ChemicalElement u ¬{carbon, iron}

I More details about negation in DLs will be addressed later in thetutorial



ONTOR UL E

Cardinality Restrictions

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

Example

ShippableCoil v ≤ 12contains.MinorDefect

I Restriction on the number of relationships can be qualified (to acertain concept) and non-qualified (to any concept)

I 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 u ∃contains.NonCarbonElement

I Intensional concept definition based on the existence ofrelationships between business objects

I It is often used with subclassification axioms or to define newconcepts with equivalence axioms



ONTOR UL E

Universal Restriction on Property Expressions

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

Example

SatisfiedOrder v ∀comprises.ShippableCoil

I Intensional concept definition based on the universality ofrelationships between business objects

I It is often used with subclassification axioms or to define newconcepts with equivalence axioms

I It can be used to restrict the range of a property in the context of aparticular concept



ONTOR UL E

Individual Value Restriction

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

Example

MaragingSteel ≡ Steel u ∃contains.{Nickel}

I Intensional concept definition that relates business objects with asingle individual (eg. Nickel)

I 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 theproduct”

Example

hasDefect ≡ locatedIn−

I Some properties can be modeled in both directions (eg. hasPart andisPartOf ). Declaring them as inverse simplifies the population of theontology, 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 )

I Object equality may be inferred as a consequence of a functionalproperty having multiple values (eg. “If coil #12 has been shipped tocustomer 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 )

I Object equality may be inferred as a consequence of an inversefunctional property having multiple values (eg. “If coil #12 andinventory item #7 meet the same order #323, they are the sameobject”)

I Useful for integrating data coming from different knowledge bases



ONTOR UL E

Keys

“Each coil has a product ID which uniquely identifies the coil”

Example

HasKey( Coil ( ) ( productId ) )

I Similar to keys in databasesI Compound keys (using both object and datatype properties) are

allowedI 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 thesame steel casting”

Example

ReflexiveObjectProperty( sameCastingAs )SymmetricObjectProperty( sameCastingAs )

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



ONTOR UL E

Irreflexive and Asymmetrical Properties

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

Example

IrreflexiveObjectProperty( follows )AsymmetricalObjectProperty( follows )

I Irreflexive: objects can not be related with themselvesI 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 consideredto be downstream in the processing chain”

Example

follows v downstreamdownstream∗ v downstream

I 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 tothe customer who placed the order”

Example

assignedTo ◦ placedBy v shippedTo

Order

CoilCustomerassignedTo placedBy

shippedTo

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



ONTOR UL E

Metamodeling

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

Example

Coil ∈ ProductCatalogEntryWire ∈ ProductCatalogEntryCoil#13 ∈ Coil

I Metamodeling introduces two levels of terminology descriptionI Metamodeling is useful to provide additional domain information

about conceptsI 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 )

I XML Schema provides the basic datatypes for OWLI User-defined datatypes are allowedI 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)

I Annotations are not relevant for reasoningI A few annotation properties are predefined in OWLI Multilingual capabilities are inherited from RDFI Annotation properties can have domain, range and hierarchies



ONTOR UL E

Outline




Demo



ONTOR UL E

What is Open World Assumption

In OWA, no assumptions are made about the truth value of statementsthat we do not know.

OWA ...I ... assumes incomplete information by defaultI ... is good for reusability. If we extend an ontology, all existing true

statements remain true (monotonic logic)I ... does not make the Unique Name Assumption.



ONTOR UL E

Why should I care about OWA

Side effects of OWA (counterintuitive behavior):I If two individuals have different names (IDs), they can be inferred to

be the same resourceI Data validation for incorrect or missing values (i.e. integrity) is not

possibleI 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 wereproduced ”

Example

Coil v ∃producedIn.FactoryCoil#12 ∈ Coil

This description is consistent even if we do not know where coil #12 wasproduced. This is a side-effect of OWA.

Proposed solution:I Escalation to a Closed World Assumption (CWA) system,

implementing integrity constraints with either rules, query languagesor modal languages (K-operator)



ONTOR UL E

N-ary Predicates

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

OWL lacks support for n-ary predicates.

Proposed solutions:

I Reification of the n-ary predicateI Change the modeling point of view

Consequences of using reification (More details later in the tutorial):

I Introducing non-intuitive, non-business conceptsI Syntactic verbosityI Non-transparent for applications (eg., rules or query languages)



ONTOR UL E

Procedural Knowledge

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

Shipment distance is a calculated property, which value can not beobtained from OWL reasoning.

Proposed solution:I Use a procedural language in combination with OWL, either an

imperative programming language such as JAVA or a declarativeone such as LP.



ONTOR UL E

Dynamic Knowledge

I OWL ontologies describe a stateless picture of a given businessdomain. Therefore it is difficult to represent changes, businessprocesses, states, transitions, events, etc.

I This limitation is shared with pure LP

I Production rules fit much better for this purpose



ONTOR UL E

Outline




Demo



ONTOR UL E

OWL in practice

I Mature authoring tools. Both commercial and open source

I DL reasoners continously improving (eg.: performance)

I Publicly available business ontologies are scarce (exception: HealthScience).

I Internal usage of ontologies inside companies is difficult to measure



ONTOR UL E

OWL2 Profiles

I OWL 2 DL is a very expressive Description Logic (althoughdecidable).

I However complexity of the reasoning algorithms (N2ExpTime)hampers scalability

I Subsets (profiles) of OWL 2 have been identified:I Still sufficiently expressiveI Lower complexity (PTime/logspace)

I Already available profiles:I EL profile, optimized for large terminologiesI QL profile, optimized for queriesI RL profile, can be implemented with rule systems



ONTOR UL E

OWL and SBVR

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

I Some parts of the SBVR business model can be formalized usingOWL ontologies

I Business experts can take advantage of formal reasoningtechniques to guarantee model consistency

I Business experts can take advantage of web nature of OWL andOWA assumption for reusability of business models in severalscenarios



ONTOR UL E

OWL and combinations with other languages

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

OWL must be combined!

I ... with programming languagesI ... with query languagesI ... with rule languages

And here comes the next part of the tutorial



ONTOR UL E

Outline

Modeling business knowledge using OWL2



Demo



ONTOR UL E

Outline




Demo



ONTOR UL E

Logic Programming – Prolog revisited

Kowalski (1979):

ALGORITHM = LOGIC + CONTROL

I Knowledge for problem solving (LOGIC)

I “Processing” of the knowledge (CONTROL)



ONTOR UL E

Prolog

Prolog = “Programming in Logic”

I Basic data structures: termsI Programs: rules and factsI Computing: Queries (goals)

I Proofs provide answersI SLD-resolutionI unification - basic mechanism to manipulate data structures

I Extensive use of recursion



ONTOR UL E

Desiderata

Relieve the programmer from several concerns: desirably,

I the order of program rules does not matter;

I the order of subgoals in a rule does not matter;

I termination is not subject to such order.

Exampler(X,Y)← s(X,Y)r(X,Y)← s(X,Z), r(Z,Y)

“Pure” declarative programming

I Prolog does not satisfy these desiderata

I Satisfied e.g. by the well-founded/ answer set semantics of logicprograms



ONTOR UL E

Positive Logic Programs

Definition (Positive Logic Program)

A positive logic program P is a finite set of clauses (rules) in the form

a← b1, . . . , bm , (1)

where a, b1, . . . , bm are atoms of a first-order language L.I a is the head of the ruleI b1, . . . , bm is the body of the rule.I If m = 0, the rule is a fact (written shortly a)

Roughly, (1) can be seen as material implication b1 ∧ · · · ∧ bm ⊃ a.

Semantics is based on Herbrand interpretations (terms are interpretedby themselves, no other elements).

Models are such interpretations where a is true whenever b1, . . . , bm are.(136/221) c© ONTORULE Consortium, all rights reserved

Example (Program P1)

p(f (X),Y,Z)← p(X,Y,Z′), h(X,Y), t(Z,Z′, r).

h(0, 0).

h(a, b)← h(a, b).

Which of the following (Herbrand) interpretations are models of P1?I I1 = ∅

no

I I2 = {p(t1, t2, t3), h(t1, t2), t(t1, t2, t3) | t1, t2, t3 ground terms }

yes

Note: due to the function symbol f , there are infinitely many groundterms ti (0, f (0), f (f (0)), . . . etc)

I I3 = {h(0, 0), t(a, b, r), p(0, 0, b)}

no




h(0, 0).

h(a, b)← h(a, b).

Which of the following (Herbrand) interpretations are models of P1?I I1 = ∅ no

I I2 = {p(t1, t2, t3), h(t1, t2), t(t1, t2, t3) | t1, t2, t3 ground terms }

yes


I I3 = {h(0, 0), t(a, b, r), p(0, 0, b)}

no




h(0, 0).

h(a, b)← h(a, b).


I I2 = {p(t1, t2, t3), h(t1, t2), t(t1, t2, t3) | t1, t2, t3 ground terms } yes


I I3 = {h(0, 0), t(a, b, r), p(0, 0, b)}

no




h(0, 0).

h(a, b)← h(a, b).


I I2 = {p(t1, t2, t3), h(t1, t2), t(t1, t2, t3) | t1, t2, t3 ground terms } yes


I I3 = {h(0, 0), t(a, b, r), p(0, 0, b)} no



ONTOR UL E

Minimal Model Semantics

I A logic program has multiple models in general.I Select one of these models as the canonical model.I Commonly accepted: truth of an atom in model I should be

“founded” by clauses.

Example

GivenP2 = {a← b. b← c. c},

truth of a in the model I = {a, b, c} is “founded.”

GivenP3 = {a← b. b← a. c},

truth of a in the model I = {a, b, c} is not founded.



ONTOR UL E

Minimal Model Semantics (cont’d)

Semantics: Prefer models with true-part as small as possible.

Definition

A model I of P is minimal, if there exists no model J of P such that J ⊂ I.

Example

I For P2 = { a← b. b← c. c }, we have LM(P2) = {a, b, c}.

I For P3 = { a← b. b← a. c }, we have LM(P3) = {c}.



ONTOR UL E

Negation in Logic Programs

Why negation?

I Natural linguistic concept

I Facilitates convenient, declarative descriptions (definitions)

E.g., "Men who are not husbands are singles.”

Definition

A normal logic program is a set of rules of the form

a← b1, . . . , bm, not c1, . . . , not cn (n,m ≥ 0) (2)

where a and all bi, cj are atoms in a first-order language L.

not is called “negation as failure”, “default negation”, or “weak negation”

Things get more complex!



ONTOR UL E

Negation in Logic Programs

Why negation?

I Natural linguistic concept

I Facilitates convenient, declarative descriptions (definitions)

E.g., "Men who are not husbands are singles.”

Definition

A normal logic program is a set of rules of the form

a← b1, . . . , bm, not c1, . . . , not cn (n,m ≥ 0) (2)

where a and all bi, cj are atoms in a first-order language L.

not is called “negation as failure”, “default negation”, or “weak negation”

Things get more complex!(140/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

Programs with Negation

Prolog: “not 〈X〉” means “Negation as Failure (to prove to 〈X〉)”

Different from negation in classical logic!


man(dilbert).

single(X)← man(X), not husband(X).

husband(X)← fail. % fail = "false" in Prolog

Query:?− single(X).

Answer:X = dilbert .


Example (cont’d)

Modifying the last rule of P4, we get P5:

man(dilbert).

single(X)← man(X), not husband(X).

husband(X)← man(X), not single(X).

Result in Prolog ????

Problem: not a single intuitive model!

Two intuitive Herbrand models:

M1 = {man(dilbert), single(dilbert)}, and

M2 = {man(dilbert), husband(dilbert)} .

Which one to choose?



ONTOR UL E

Semantics of Logic Programs With Negation

I “War of Semantics” in Logic Programming (1980/90ies):

Meaning of programs like the Dilbert example above

I Great Schism: Single model vs. multiple model semantics

I To date:I Well-Founded Semantics [Van Gelder et al., 1991]

Partial model: man(dilbert) is true,single(dilbert), husband(dilbert) are unknown

I Answer Set (alias Stable Model) Semantics by Gelfond and Lifschitz[1988,1991].

Alternative models: M1 = {man(dilbert), single(dilbert)},M2 = {man(dilbert), husband(dilbert)}.

I Agreement for so-called “stratified programs”

Different selection principles for non-stratified programs



ONTOR UL E

Semantics of Logic Programs With Negation

I “War of Semantics” in Logic Programming (1980/90ies):

Meaning of programs like the Dilbert example above

I Great Schism: Single model vs. multiple model semantics

I To date:I Well-Founded Semantics [Van Gelder et al., 1991]

Partial model: man(dilbert) is true,single(dilbert), husband(dilbert) are unknown

I Answer Set (alias Stable Model) Semantics by Gelfond and Lifschitz[1988,1991].

Alternative models: M1 = {man(dilbert), single(dilbert)},M2 = {man(dilbert), husband(dilbert)}.

I Agreement for so-called “stratified programs”

Different selection principles for non-stratified programs(143/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

F-Logic Programming

Examplerome : hubrome[link� cagliari]

X : connected ← Y : hub,Y[link� X]

I object-oriented:I rome : hub — Rome isa hub (type, hub(rome))

I rome[link� cagliari] — Rome has a link to Cagliari (attributes,link(rome, cagliari))

I higher-order: rome : X is like X(rome) (higher-order can be compiledaway)



ONTOR UL E

F-Logic Programming

Examplerome : hubrome[link� cagliari]

X : connected ← Y : hub,Y[link� X]

I object-oriented:I rome : hub — Rome isa hub (type, hub(rome))I rome[link� cagliari] — Rome has a link to Cagliari (attributes,

link(rome, cagliari))

I higher-order: rome : X is like X(rome) (higher-order can be compiledaway)



ONTOR UL E

Outline




Demo



ONTOR UL E

Production Rules

Production Rule

IF condition THEN action

Production System

I Set of production rulesI Working Memory: a set of ground atomic formulas (facts) that

evolves over timeI Rule Interpreter: a computer program

I Conflict resolution strategy



ONTOR UL E

Rule Execution

1. Building the conflict set: For each rule r, determine variablesubstitutions σ such that the condition of r is satisfied in WM. Theset of all such pairs (r, σ) is the conflict set.

2. Conflict resolution: following the conflict resolution strategy, therule interpreter picks one pair (r, σ) from the conflict set.

I Most strategies use rule priorities and avoid repeated application ofthe same pair (r, σ). No details given in this tutorial.

3. Application: the rule interpreter applies σ to the action part of r andexecutes the instantiated action.

I Built-in and user-defined functions are executedI Working Memory is updated



ONTOR UL E

Example Rules

Example

“If a coil has a defect, mark it as ‘defective’, scrap the coil, and alert the user ofthe defect.”

r1 : IF Coil(x) ∧ ∃y.hasDefect(x, y) THEN ADD(Defective(x)),

scrap(x), print(“defective coil”)I ADD(Defective(x)) adds a fact to the Working Memory

I scrap is a user-defined function that “scraps” a coil

I print is a built-in function that prints information on the standard output

“If a defective coil is allocated to a customer, remove the allocation.”

r2 : IF Coil(x) ∧ Defective(x) ∧ hasAllocation(x, y) THEN

REMOVE(hasAllocation(x, y))



ONTOR UL E

Example Execution

R r1, r2

WM0 {Coil(c1), hasDefect(c1, d1), hasDefect(c1, d2), hasAllocation(c1, cu1),

Coil(c2),Defective(c2), hasAllocation(c2, cu2)}

The conflict set is: {(r1, x 7→ c1), (r2, x 7→ c2, y 7→ cu2)}

1. If the interpreter picks (r1, x 7→ c1), the resulting working memory isWM1 = WM0 ∪ {Defective(c1)}The conflict set is: {(r1, x 7→ c1), (r2, x 7→ c2, y 7→ cu2), (r2, x 7→ c1, y 7→ cu1)}

2. If the interpreter picks (r2, x 7→ c2, y 7→ cu2), the result isWM2 = WM1\{hasAllocation(c2, cu2)} The conflict set is:{(r1, x 7→ c1), (r2, x 7→ c1, y 7→ cu1)}

3. If the interpreter picks (r2, x 7→ c1, y 7→ cu1), the result isWM3 ={Coil(c1), hasDefect(c1, d1), hasDefect(c1, d2),Coil(c2),Defective(c2),Defective(c1)}The conflict set is:{(r1, x 7→ c1)}

If interpreter picks no element of the conflict set, the production system terminates.



ONTOR UL E

Example Execution

R r1, r2

WM0 {Coil(c1), hasDefect(c1, d1), hasDefect(c1, d2), hasAllocation(c1, cu1),

Coil(c2),Defective(c2), hasAllocation(c2, cu2)}

The conflict set is: {(r1, x 7→ c1), (r2, x 7→ c2, y 7→ cu2)}1. If the interpreter picks (r1, x 7→ c1), the resulting working memory is

WM1 = WM0 ∪ {Defective(c1)}The conflict set is: {(r1, x 7→ c1), (r2, x 7→ c2, y 7→ cu2), (r2, x 7→ c1, y 7→ cu1)}

2. If the interpreter picks (r2, x 7→ c2, y 7→ cu2), the result isWM2 = WM1\{hasAllocation(c2, cu2)} The conflict set is:{(r1, x 7→ c1), (r2, x 7→ c1, y 7→ cu1)}

3. If the interpreter picks (r2, x 7→ c1, y 7→ cu1), the result isWM3 ={Coil(c1), hasDefect(c1, d1), hasDefect(c1, d2),Coil(c2),Defective(c2),Defective(c1)}The conflict set is:{(r1, x 7→ c1)}

If interpreter picks no element of the conflict set, the production system terminates.



ONTOR UL E

Production Rules: Key Features

I Conditions are (first-order/SQL) queries on working memoryI Closed-world negation: if a fact is not in the working memory, it is

falseI Working memory evolves as rules are executedI Rules can remove facts from the working memoryI RETE-networks [Forgy, 1982] are used to efficiently evaluate rule

conditionsI Network is updated as rules are executed



ONTOR UL E

Abstract view of Production Rules

Production Rule

r : IF φr THEN ADD ψaddr REMOVE ψremove

r

I φr is a (domain-independent) first-order formula (query) with freevariables

I ψaddr , ψremove

r are sets of atomic formulas with free variables

User-defined and built-in functions do not play a role in combinations withontologies

Rule Application

If a working memory WM satisfies σ(φr), then the result of applying rule rin WM using σ is WM′ = (WM ∪ σ(ψadd

r ))\σ(ψremover )

See: STRIPS, CLIPS, Jess



ONTOR UL E

Outline




Demo



ONTOR UL E

Logical vs. Production Rules (I)

Commonalities

I Both if....then.... rulesI Closed-world assumptionI Conditions look similar (Logical rules with first-order conditions can

be rewritten to sets of normal rules)



ONTOR UL E

Logical vs. Production Rules (II)

Differences

I Declarative vs. procedural semanticsI Logical rules have model-theoretic semantics; various algorithms may

be used for reasoningI The semantics of production rules is given in terms of an algorithm

(the rule interpreter)

I Production rules have side-effects (user-defined functions andbuilt-ins like print)

I Production rules can remove facts from the working memoryI Use:

I Logical rules are typically used for modeling domain knowledge andare associated with query answering

I Production rules are typically used in decision-support systems



ONTOR UL E

Semantics of Negation

Example

Consider the logical rulep← not p

The rule states “if p is false, p is necessarily true”; it has no stable models

Consider the corresponding production rule

IF ¬p THEN ADD p

This rule is applicable in a working memory that does not contain p, andp is included in the resulting working memory.



ONTOR UL E

Positive Programs

Correspondence

Consider a positive logic program P consisting of rules

h← b1, . . . , bn

and a corresponding set of production rules

IF b1 ∧ · · · ∧ bn THEN ADD h

Then, the minimal model of P is the same as the working memoryobtained by repeated application of the rules, until a fixpoint is reached



ONTOR UL E

Outline




Demo



ONTOR UL E

Rules and the SW

Question: Where do Rules fit in the “Layer Cake”?

Tim BL’s famous, layer cake, latest version (http://www.w3.org/2007/03/layerCake.png)


http://www.w3.org/2007/03/layerCake.png


ONTOR UL E

Rules and OWL

I What of OWL can be expressed directly in Rules?I What is different? Existentials, number restrictions, equality

reasoning, etc.



ONTOR UL E

What of OWL can be expressed directly in rules?

ABox factual knowledge about Class membership and property values and can betranslated to LP facts “as is”:

DL syntax Intuitive correspondence with LPrules/facts

paper1 ∈ Paper Paper(paper1)

(paper1, stHeymans) ∈ hasAuthor hasAuthor(paper1, stHeymans)

RBox/TBox: A subset of OWL can be straightforwardly translated to Rules, e.g.:

DL syntax Intuitive correspondence with LP rules/factsR v S (SubPropertyOf) S(X, Y)← R(X, Y)R+ v R (Transitive Property) R(X, Z)← R(X, Y),R(Y, Z)C1 u . . . u Cn v A A(X)← C1(X), . . . ,Cn(X)A v C1 u . . . u Cn C1(X)← A(X); . . . ;Cn(X)← A(X)∃R.C v A (SomeValuesFrom, lhs) A(X)← R(X, Y),C(Y)A v ∀R.C (AllValuesFrom, rhs) C(Y)← R(X, Y),A(X)C1 t . . . t Cn v A (UnionOf lhs) A(X)← C1(X); . . . ;A(X)← Cn(X)



ONTOR UL E

What of OWL cannot be expressed directly in Rules?

I Some OWL statements can only be approximated by a naive translation:

A ≡ {o1, . . . , on} (OneOf) A(o1), . . . ,A(on) does not work (what with A(b)?)A v ∃R.C (SomeValuesFrom rhs) Can only be approximated using function symbols

I Other OWL statements are even problematic to be approximated:

∀R.C v A (AllValuesFrom lhs) One might guess:A(X)← not noRC(X);noRC(X)← R(X, Y), not C(Y).

but doesn’t work :-(

cardinality restrictions, SameAs Need reasoning with equality, expensive to implement.

Recall: “=” and “!=” are not classical equality butbuiltin syntactic equality (UNA,CWA)!

. . . etc.



ONTOR UL E

Main differences OWL vs. Rules?

I not in rule paradigms is different from negation (e.g., ComplementOf) inOWL:

I ¬: Classical negation! Open world assumption! Monotonicity!I not: Different purpose! Closed world assumption! Non-monotonicity!

Publication v Paper¬Publication v Unpublishedpaper1 ∈ Paper.

in DL: 6|= paper1 ∈ Unpublished

Paper(X)← Publication(X)Unpublished(X)← not Publication(X)Paper(paper1)←

Does infer in LP: Unpublished(paper1).

I Also strong negation in LP (“−”, sometimes “¬”) is not completely thesame as classical negation in DLs, e.g.

Publication v PaperstHeymans ∈ ¬Paper.

in DL:|= stHeymans ∈ ¬Publication

Paper(X)← Publication(X)¬Paper(stHeymans)

Does not automatically infer in LP:¬Publication(stHeymans).



ONTOR UL E

Main differences OWL vs. Rules?

I LPs are strong in query answering, but subsumption checking as inDLs is infeasible (undecidable even for positive function-freeprograms).

I OWL DL allows complex statements in the “head” (rhs of v), whileuse of variables in LP rule bodies is more flexible

I DLs are stronger in type inference, while LPs are stronger in typechecking:

Person v ∃hasName.xs:stringjohn ∈ Person

is consistent in DL and infersjohn ∈ ∃hasName

← Person(X), not hasName(X, Y)Person(john)

is inconsistent, since there is noknown name for john



ONTOR UL E

Main differences summary

I CWA vs OWAI Existential quantificationI UNAI Negation as failure, strong negation vs. classical negationI Symmetry between “head” and “body” (DL) vs. more complex

bodies (LP)I Type inference (DL) vs. type checking (LP)



ONTOR UL E

Outline




Demo



ONTOR UL E

Combining Rules and Ontologies

I Major Issue: Combining rules and ontologies (logic framework)

I LP and ontology formalisms like RDF/s, OWL resp. DescriptionLogics have related yet different underlying settings

I This makes combination non-trivial

I At the heart, the difference is between LP and Classical logic



ONTOR UL E

Hybrid Approaches: Taxonomy

I hybrid KB KB = 〈T ,P〉:I T is a classical (first-order) theoryI P is a logic program (rules)

I Different approaches to a semantics for such a hybrid KB

I Strict semantic separation (loose coupling)

I Tight semantic integration

I Full integration

I Surveys:I ONTORULE D3.1 [de Bruijn et al., 2009]I KNOWLEDGEWEB [de Bruijn et al., 2007]I REWERSE [Antoniou et al., 2005], [Drabent et al., 2009]



ONTOR UL E

Loose Coupling

I Strict semantic separation between rules / ontology

RDFS

Ontologies (OWL)

Rules(RIF)

I View rule base P and FO theory T as separate, independentcomponents. ΣT and ΣP do (a priori) not share meaning.

I They are connected through a minimal “safe interface” for exchangingknowledge (formulas, usually ground atoms).

I Well-suited for implementation on top of LP & DL reasoners.

Examples

nonmonotonic dl-programs [Eiter et al., 2008], [Eiter et al., 2004];defeasible logic+DLs [Wang et al., 2004]



ONTOR UL E

Tight Semantic Integration

Rules(RIF)

Ontologies(OWL)

RDFS

I Integrate FOL statements and the logic program to a large extent,but keep predicates of ΣT and ΣP separate.

I Build an integrated model M as the “union” of a model Mo of the FOtheory T and a model Ml of P with the same domain.

I Ensure “safe interaction” between Mo and Ml.

Examples

CARIN [Levy and Rousset, 1998], DLP (OWL 2 RL) [Grosof et al., 2003],DL-safe rules [Motik et al., 2005], R-hybrid KBs [Rosati, 2005]DL+log [Rosati, 2006]



ONTOR UL E

Full Integration

RDFS

Ontologies(OWL)

Rules(RIF)

Unifiying Logic

I No principled separation between ΣT , ΣP (but special axioms)

Examples

I Hybrid MKNF knowledge bases [Motik and Rosati, 2007;Motik and Rosati, 2010]

I FO-Autoepistemic Logic [de Bruijn et al., 2007]



ONTOR UL E

Non-monotonic dl-Programs

I An extension of answer set programs with queries to DL knowledge bases(through dl-atoms) [Eiter et al., 2008]

I dl-atoms allow to query a DL knowledge base differently

bidirectional flow of information, with clean technical separation of DLengine and ASP solver (“loose coupling”)

DL EngineASP Solver ?

I Use dl-programs as “glue” for combining inferences on a DL base.

I System: DLVHEXhttp://www.kr.tuwien.ac.at/research/systems/dlvhex/


http://www.kr.tuwien.ac.at/research/systems/dlvhex/


ONTOR UL E

dl-atoms

Basic Idea:

I Query the DL base L using the query interface of the DL engine

Query Q may be concept/role instance C(X)/R(X,Y); subsumptiontest C v D; etc (extensions: conjunctive queries, SPARQL)

I Important: Possible to modify the extensional part (ABox) of L, byadding positive (]) or negative (−∪) assertions, before querying

I Q evaluates to true iff the modified L proves Q.



ONTOR UL E

dl-atoms: Examples

Wine ontology

owl:Thing

Wine Region

Red

Wine

White

Wine

locatedIn

WineDescriptor

WineTaste

WineFlavorhasFlavor

I DL[Wine](“ChiantiClassico”)

I DL[Wine](X)

I DL[DryWine ] dry; Wine](W)

add all assertions DryWine(c) to L, such that dry(c) holds.



ONTOR UL E

dl-Atoms: Syntax

dl-atom: form

DL[S1op1p1, . . . , Smopm pm; Q](t) , m ≥ 0,

where

I each Si is either a concept or a roleI opi ∈ {], −∪}, and pi is a unary resp. binary (input) predicate,I Q(t) is a DL query (t contains variables and/or constants).

Intuitively:

opi = ](−∪) increases (¬)Si by pi

DL query Q(t): in standard formalism, one of

(a) a (negated) concept inclusion axiom (¬)(C v D),

(b) (¬)C(t) for a concept C and term t, or

(c) R(t1, t2) or ¬R(t1, t2), for a role R and terms t1, t2.



ONTOR UL E

dl-Atoms: Syntax

dl-atom: form

DL[S1op1p1, . . . , Smopm pm; Q](t) , m ≥ 0,whereI each Si is either a concept or a role

I opi ∈ {], −∪}, and pi is a unary resp. binary (input) predicate,I Q(t) is a DL query (t contains variables and/or constants).

Intuitively:

opi = ](−∪) increases (¬)Si by pi







ONTOR UL E

dl-Atoms: Syntax

dl-atom: form

DL[S1op1p1, . . . , Smopm pm; Q](t) , m ≥ 0,whereI each Si is either a concept or a roleI opi ∈ {], −∪}, and pi is a unary resp. binary (input) predicate,

I Q(t) is a DL query (t contains variables and/or constants).

Intuitively: opi = ](−∪) increases (¬)Si by pi







ONTOR UL E

dl-Atoms: Syntax

dl-atom: form

DL[S1op1p1, . . . , Smopm pm; Q](t) , m ≥ 0,whereI each Si is either a concept or a roleI opi ∈ {], −∪}, and pi is a unary resp. binary (input) predicate,I Q(t) is a DL query (t contains variables and/or constants).








ONTOR UL E

dl-Atoms: Syntax

dl-atom: form

DL[S1op1p1, . . . , Smopm pm; Q](t) , m ≥ 0,whereI each Si is either a concept or a roleI opi ∈ {], −∪}, and pi is a unary resp. binary (input) predicate,I Q(t) is a DL query (t contains variables and/or constants).





(c) R(t1, t2) or ¬R(t1, t2), for a role R and terms t1, t2.(175/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

dl-Programs

I dl-programs are hybrid KBs with dl-atoms in rules

Definition (DL-Program)

A dl-program is a pair KB = 〈L,P〉 where

I L is a DL knowledge base (corresponding to a FO theory)

I P consists of dl-rules

a← b1, . . . , bk, not bk+1, . . . , not bm,

where m ≥ 0,I a is an atomic formula, andI b1, . . . , bm, m ≥ 0, are atomic formulas or dl-atoms (no function

symbols).



ONTOR UL E

Answer Sets

I HBΦP : Set of all ground atomic formulas with predicate symbol

in P and constants C from finite relational alphabet Φ.

I Constants C: those in P and (all) individuals in the ABox of L.

I Herbrand interpretation: subset I ⊆ HBΦP

Satisfaction

I I satisfies a ground atomic formula ` (I |=L `), iff ` ∈ I;

I I satisfies a ground dl-atom α = DL[S1op1p1, . . . , Smopm; Q](c(I |=L α) iff

L ∪ A1(I) ∪ · · · ∪ Am(I) |= Q(c), where

I Ai(I) = {Si(e) | pi(e) ∈ I}, for opi = ];I Ai(I) = {¬Si(e) | pi(e) ∈ I}, for opi = −∪.

I I is a model of KB = (L,P) if it satisfies all rules in grnd(P) as usual (wrt. L)



ONTOR UL E

Answer Sets

I HBΦP : Set of all ground atomic formulas with predicate symbol

in P and constants C from finite relational alphabet Φ.

I Constants C: those in P and (all) individuals in the ABox of L.

I Herbrand interpretation: subset I ⊆ HBΦP

Satisfaction

I I satisfies a ground atomic formula ` (I |=L `), iff ` ∈ I;

I I satisfies a ground dl-atom α = DL[S1op1p1, . . . , Smopm; Q](c(I |=L α) iff

L ∪ A1(I) ∪ · · · ∪ Am(I) |= Q(c), where

I Ai(I) = {Si(e) | pi(e) ∈ I}, for opi = ];I Ai(I) = {¬Si(e) | pi(e) ∈ I}, for opi = −∪.

I I is a model of KB = (L,P) if it satisfies all rules in grnd(P) as usual (wrt. L)(177/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

Examples

Let L be the wine ontology.

I Suppose I = {white(“siw”), not_dry(“siw”)}.Then I |=L DL[“WhiteWine” ] white, “DryWine”−∪not_dry; “Wine”](“siw”)

I Inconsistency of L is revealed with unsatisfiable DL queries:

inconsistent ← DL[“Wine” v ¬“Wine”]

I Consistency can be checked by

consistent ← not DL[“Wine” v ¬“Wine”]



ONTOR UL E

Answer Sets

I Use a reduct sPM akin to the Gelfond-Lifschitz reduct PM

In building PM, treat dl-atoms like ordinary atoms:

Strong reduct sPM

sPM contains all rules obtained from grnd(P) by removing

1. all rule instances

a← b1, . . . , bk, not bk+1, . . . , not bm

such that for some bj, where j ∈ {k + 1, . . . ,m}, it holds thatM |=L bj, and

2. all negation-as-failure literals not bj from the remaining rules.

Definition (Strong answer set)

M is a (strong) answer set of KB iff M is a minimal model of sPM.



ONTOR UL E

Use Case: Order Assignment at a Galvanization

Line

I Steel industry: Galvanization Line processes long strips of steel(coils) to coat with zinc

I The yield strength or yield point indicates stress at which steelbegins to deform irreversibly

I An order sets lower and upper tolerances for this yield strengthI Produced coils are part of a certain orderI A produced coil has an actual yield strength at a certain sampling

point on the coilI The actual yield strength of the coil should be within the tolerances

indicated by the order the coil belongs to



ONTOR UL E

Modeling the Use Case using OWL and Logical

Rules

I Steel industry: Galvanization Line process long strips of steel (coils)to coat with zinc

I The yield strength or yield point indicates stress at which steelbegins to deform irreversibly

is explanation (no modeling)



ONTOR UL E


Rules (2)

An order sets lower and upper tolerances for this yield strength

Order v ∃hasLower.ValueOrder v ∃hasUpper.Value



ONTOR UL E


Rules (3)

Produced coils are part of a certain order

ProducedCoil v ∃target.Order



ONTOR UL E


Rules (4)

A produced coil has an actual yield strength at a certain sampling pointon the coil

ProducedCoil v ∃actual.Value

What with the sampling point?

ProducedCoil v ∃coilSamplingPoint.Location

What with the actual yield strength?



ONTOR UL E


Rules (5)


Using a tight-coupling approach with ontology concepts ProducedCoil,Value, Location and rule predicates hasValue and yieldStrength:

Tight-coupling

← ProducedCoil(X), not hasValue(X)

hasValue(X) ← yieldStrength(X,L,V),Location(L),Value(V)



ONTOR UL E


Rules (6)


Using a loose-coupling approach with ontology concepts ProducedCoil,Value, Location and rule predicates hasValue and yieldStrength:

Loose-coupling

← DL[; ProducedCoil](X), not hasValue(X)

hasValue(X) ← yieldStrength(X,L,V),DL[; Location](L),DL[; Value](V)



ONTOR UL E


Rules (7)

The actual yield strength of the coil should be within the tolerancesindicated by the order the coil belongs to

Tight-coupling

← yieldStrength(X,L,V), target(X,Y), hasLower(Y,L1),V < L1

← yieldStrength(X,L,V), target(X,Y), hasUpper(Y,U1),V > U1

Loose-coupling

similar with external atoms



ONTOR UL E

Experience from Practice

I Rules are more flexible than OWL for expressing ternary relations

I Use of aggregate functions and built-ins common in LP (e.g., <)

I Minimality in rules allows to express transitive closure

I Different usage: OWL semantics would infer yieldstrength if notpresent, while LP semantics indicates inconsistency if not present

I Disadvantage rules: closed world reasoning (need a representativedata set – which in practical cases is usually there)



ONTOR UL E

Computational Complexity

Deciding strong answer set existence for normaldisjunctive dl-programs

(completeness results)

KB = (L,P) no dl-atoms L in SHIF(D) L in SHOIN (D)

positive EXPTIMENEXPTIME

EXPTIMENEXPTIME

NEXPTIME

stratified EXPTIME

NEXPTIMENPEXPTIME

NEXPTIMENPPNEXPTIME

NEXPTIMENP

general NEXPTIME

NEXPTIMENPNEXPTIME

NEXPTIMENPNPNEXPTIME

NEXPTIMENP

Note: The satisfiability problem in

I SHIF(D) /SHOIN (D) is EXPTIME-/NEXPTIME-complete.

I Key observation: loose-coupling comes with low or no extra costcompared to pure ontology reasoning



ONTOR UL E

Implementation

I NLP-DL implements dl-programs (prototype) http://www.kr.tuwien.ac.at/research/systems/semweblp/

I Combines DLV and RacerPro, incorporating optimization techniquesdeveloped using the PHP scripting language

I Loose-coupling for F-Logic Programming in Ontostudio usingbuilt-ins, see demo.

I combines Ontobroker F-Logic and Ontobroker-OWL (the successorof KAON2)


http://www.kr.tuwien.ac.at/research/systems/semweblp/

http://www.kr.tuwien.ac.at/research/systems/semweblp/


ONTOR UL E

Outline




Demo



ONTOR UL E

Combining Production Rules and Ontologies

I Loose Coupling of Production Rules and Ontologies

I Towards Tight Coupling: Logical Reconstruction of ProductionSystems



ONTOR UL E

Example

Example (Scrapping)

Ontology:

Product u ∃hasDefect.MechanicalDefect v∃hasPhenomenon.MechanicalPhenomenon

a ∈ Product b ∈ MechanicalDefect(a, b) ∈ hasDefect

Rule:

IF Product(x) ∧ ∃y.hasPhenomenon(x, y) THEN ADD assignedTo(x, scrap)

Expectation: rule is executed with assignment {x 7→ a} and a is assigned toscrap when the rule is executed

We need to perform OWL inferencing to match conditions



ONTOR UL E

Loose Coupling of Rules and Ontologies

I Principle: leave as much as possible of rule and ontology engines intact

I Idea: view Working Memory as part of the ontology (ABox) anddefine condition satisfaction as entailment

I Leave all other Production Rule machinery intact (e.g., conflictresolution)

I Loose coupling: any description logic reasoner can be plugged inI To define

I Satisfaction of conditions of rulesI Resulting working memory after application of action



ONTOR UL E

Condition Satisfaction

Ontology KBWorking memory WMVariable substitution σ

Rule r:

IF (φ+r , φ−r ) THEN ADD ... REMOVE ...

Definition

r is σ-fireable in WM iff KB ∪WM is consistent,

KB ∪WM |= σ(φ+r ), and KB ∪WM 6|= σ(φ−r )



ONTOR UL E

Example Revisited

Example

Ontology KB:Product u ∃hasDefect.MechanicalDefect v

∃hasPhenomenon.MechanicalPhenomenonWorking memory WM:

Product(a) MechanicalDefect(b) hasDefect(a, b)

Rule r:IF (Product(x) ∧ ∃y.hasPhenomenon(x, y)) THEN ADD assignedTo(x, scrap)

Substitution σ = {x 7→ a}

We have:

I KB ∪WM is consistent

I KB ∪WM |= σ(φ+r ), where σ(φ+

r ) = Product(a) ∧ ∃y.hasPhenomenon(a, y)

Therefore, r is σ-fireable in the working memory WM(196/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

PR<OWL> Loose Coupling Implementation



ONTOR UL E

Semantics of Actions: Syntactical Approach

Rule firing

If a ruler : IF φr THEN ADD ψadd

r REMOVE ψremover

is fired in a working memory WM with substitution σ, the resultingworking memory is

WM′ = (WM\ψremover ) ∪ ψadd

r

Example

When r is fired in WM with σ, assignedTo(a, scrap) is added:

WM′ = { Product(a) MechanicalDefect(b)hasDefect(a, b) assignedTo(a, scrap) }



ONTOR UL E

Limitations of the Syntactical Approach

Ontology KB = {MechanicalDefect v Defect}Working memory WM = {MechanicalDefect(b)}Variable substitution σ = {x 7→ b}

Rule r:

IF Defect(x) THEN REMOVE Defect(x)

r is σ-fireable

WM′ = WM\{Defect(b)} = WM and r is still σ-fireable!

Result may be non-intuitive

Solution: removing inferences, rather than facts



ONTOR UL E

Semantics of Actions: Semantical Approach

I Idea: update models, rather than formulasI Based on semantics of database update and erasure [Winslett,

1990]

Updates

Let KB be an ontology, WM a working memory, and F a set of updates,the update

(KB ∪WM) ◦KB F

defines a set of models, based on the models of KB ∪WM and F.



ONTOR UL E

Materializing Updates

Challenge: find a working memory WM′ such that

Mod(KB ∪WM′) = (KB ∪WM) ◦KB F

I WM′ does not necessarily exist for every ontology language (e.g.,for OWL DL)

I There are known languages for which such a WM′ does exist andcan be computed (e.g., DL-LiteFS) [Giacomo et al., 2006]

I There are further languages for which approximations can becomputed (e.g., DL-LiteFS ) [Giacomo et al., 2007]

I May need extension of the language for working memories


Towards Tight Coupling:Logical Reconstruction of Production Rules



ONTOR UL E

Logical Reconstruction of Production Rules

I ReconcileI Declarative, stateless semantics of OWL ontologiesI Operational, state-based semantics of production rules

I Embedding production rules in logic [de Bruijn and Rezk, 2009]I µ-calculus (propositional)I Fixed-Point Logic (variables)

I Provides logic-based understanding of production rules semanticsI Starting point for tightly coupled combination semantics



ONTOR UL E

Embedding Production Systems into Logic

Production World Logical World

Production System //

��

Axioms

��Computation Tree // Model



ONTOR UL E

Example

IF Product(x) ∧ ∃z.hasDefect(x, z) THEN ADD assignedTo(x, scrap)

fireabler(s, x):

[Product(s, x) ∧ ∃z.hasDefect(s, x, z)] ∧ ¬[assignedTo(s, x, scrap)]

RAppr:∀x.r(s, x)→ assignedTo(s, x, scrap)



ONTOR UL E

Axiomatization in Fixed-Point Logic

ΦPS = (Root ∧ NoFireable) ∨ (Root ∧ Appl ∧ Frame ∧ Complete∧Fireable ∧ ∀w(R(s,w)→ (ν.X.s.(Intermediate ∨ End)∧

∀w(R(s,w)→ X(w)))(w)))



ONTOR UL E

Axiomatization in Fixed-Point Logic

Theorem

Let PS be a Generic Production system.

Given a working memory WM for PS, there is a model I of∃s : ΦPS that is isomorphic to the computation tree of (PS,WM),and vice versa.



ONTOR UL E

Outline




Demo


Demo



ONTOR UL E

Summary (I)

From Business Policy Documents to a Business Model


State of the art

Corpus design






ONTOR UL E

Summary (II)

Integrating Ontologies and Rules




Demo



ONTOR UL E

References I

G. Antoniou et al.

I3-d3 - Combining rules and ontologies. A survey.

Technical report, Rewerse IST-2004-506779 NoE, 2005.

Susan Atkins, Jeremy Clear, and Nicholas Ostler.

Corpus design criteria.

Literary & Linguistic Computing, 7(1):1–16, 1992.

Sophie Aubin and Thierry Hamon.

Improving term extraction with terminological resources.

In T. Salakoski, F. Ginter, S. Pyysalo, and T. Pahikkala, editors, Advances inNatural Language Processing, LNAI 4139, pages 380–387. Springer, 2006.



ONTOR UL E

References II

Nathalie Aussenac-Gilles and Marie-Paule Jacques.

Designing and Evaluating Patterns for Relation Acquisition from Texts withCAMÉLÉON.

Terminology, Pattern-Based approaches to Semantic Relations,14(1):45–73, June 2008.

Nathalie Aussenac-Gilles, Brigitte Biébow, and Sylvie Szulman.

Revisiting ontology design: a methodology based on corpus analysis.

In Proceedings of the 12th International Conference on KnowledgeEngineering and Knowledge Management : Methods, Models and Tools(EKAW’2000), Juan-les-pins, France, Octobre 2000. Springer-Verlag.

Nathalie Aussenac-Gilles, Sylvie Despres, and Sylvie Szulman.

The terminae method and platform for ontology engineering from texts.

In Paul Buitelaar and Philipp Cimiano, editors, Bridging the Gap betweenText and Knowledge: Selected Contributions to Ontology learning fromText, pages 199–223. IOS Press, 2008.



ONTOR UL E

References III

Sergey Brin.

Extracting patterns and relations from the world wide web.

In WebDB ’98: Selected papers from the International Workshop on TheWorld Wide Web and Databases, pages 172–183, London, UK, 1999.Springer-Verlag.

Mooney R. J. Califf M. E.

Relational learning of pattern-match rules for information extraction.

In Proceedings of AAAI Spring Symposium on Applying Machine Learningto Discourse Processing, Stanford, CA„ 1998.

Philipp Cimiano and Johanna Völker.

Text2onto - a framework for ontology learning and data-driven changediscovery.

In Proceedings of the 10th International Conference on Applications ofNatural Language to Information Systems, pages 227–238, 2005.



ONTOR UL E

References IV

Ido Dagan, Shaul Marcus, and Shaul Markovitch.

Contextual word similarity and estimations from sparse data.

In Proceedings the 31th meeting of the Association for ComputationalLinguistics, pages 164–171, Columbus, Ohio, USA, june 1993.

Jos de Bruijn and Martín Rezk.

A logic based approach to the static analysis of production systems.

In Axel Polleres and Terrance Swift, editors, RR, volume 5837 of LectureNotes in Computer Science, pages 254–268. Springer, 2009.

Jos de Bruijn, Thomas Eiter, Axel Florian Polleres, and Hans Tompits.

Embedding non-ground logic programs into autoepistemic logic forknowledge base combination.

In Manuela Veloso, editor, Proceedings of the 20th International JointConference on Artificial Intelligence (IJCAI-07), pages 304–309. AAAIPress/IJCAI, 2007.

Extended paper to appear in ACM Trans. Computational Logic.(209/221) c© ONTORULE Consortium, all rights reserved


ONTOR UL E

References V

J. de Bruijn et al.

D2.5.8 - Integrating owl and rdf with other reasoning paradigms.

Technical report, KnowledgeWeb IST-2004-507482 NoE, 2007.

J. de Bruijn et al.

D3.1 - State-of-the-art survey of issues.

Technical report, ONTORULE IST-2009-231875 Project, 2009.

Włodzimierz Drabent, Thomas Eiter, Giovambattista Ianni, ThomasKrennwallner, Thomas Lukasiewicz, and Jan Małuszynski.

Hybrid reasoning with rules and ontologies.

In Francois Bry and Jan Małuszynski, editors, Semantic Techniques for theWeb: The REWERSE perspective, number 5500 in LNCS, chapter 1,pages 1–49. Springer, 2009.



ONTOR UL E

References VI

Thomas Eiter, Thomas Lukasiewicz, Roman Schindlauer, and HansTompits.

Well-founded semantics for description logic programs in the SemanticWeb.

In Proceedings RuleML-2004, volume 3323 of LNCS, pages 81–97.Springer, 2004.

Extended paper to appear in ACM Trans. Computational Logic.

T. Eiter, G. Ianni, T. Lukasiewicz, R. Schindlauer, and H. Tompits.

Combining answer set programming with description logics for the semanticweb.

Artificial Intelligence, 172(12-13):1495–1539, 2008.



ONTOR UL E

References VII

David Faure and Claire Nédellec.

Knowledge acquisition of predicate argument structures from technicaltexts using machine learning: the system asium.

In D. Fensel et R. Stude, editor, Proceedings of the 11th InternationalConference on Knowledge Engineering and Knowledge Management(EKAW’99), pages 329–334. Springer-Verlag, May 1999.

Charles Forgy.

Rete: A fast algorithm for the many patterns/many objects match problem.

Artif. Intell., 19(1):17–37, 1982.

Michael Gelfond and Vladimir Lifschitz.

The Stable Model Semantics for Logic Programming.

In Logic Programming: Proceedings Fifth Intl Conference and Symposium,pages 1070–1080, Cambridge, Mass., 1988. MIT Press.



ONTOR UL E

References VIII

Michael Gelfond and Vladimir Lifschitz.

Classical Negation in Logic Programs and Disjunctive Databases.

New Generation Computing, 9:365–385, 1991.

Giuseppe De Giacomo, Maurizio Lenzerini, Antonella Poggi, and RiccardoRosati.

On the update of description logic ontologies at the instance level.

In AAAI. AAAI Press, 2006.

Giuseppe De Giacomo, Maurizio Lenzerini, Antonella Poggi, and RiccardoRosati.

On the approximation of instance level update and erasure in descriptionlogics.

In AAAI, pages 403–408. AAAI Press, 2007.



ONTOR UL E

References IX

C. Giuliano and A. Gliozzo.

Instance-based ontology population exploiting named-entity substitution.

In Proceedings of the 22nd International Conference on ComputationalLinguistics (Coling 2008), pages 265–272, Manchester, August 2008.

Ralph Grishman and Beth Sundheim.

Message understanding conference-6: A brief history.

In Proceedings of the 16th International Conference on ComputationalLinguistics, pages 466–471, Copenhagen, Denmark, 5-6 August 1996.

B. N. Grosof, I. Horrocks, R. Volz, and S. Decker.

Description logic programs: Combining logic programs with descriptionlogics.

In Proceedings of the 12th International World Wide Web Conference(WWW’03), pages 48–57. ACM Press, 2003.



ONTOR UL E

References X

Thierry Hamon, Adeline Nazarenko, and Cécile Gros.

A step towards the detection of semantic variants of terms in technicaldocuments.

In Proceedings of the 8th International conference on ComputationalLinguistics, pages 498–504, Montréal, August 1998.

Zellig Harris, Michael Gottfried, Thomas Ryckman, Paul Mattick, Jr., AnneDaladier, T.N. Harris, and S. Harris.

The Form of Information in Science: Analysis of an ImmunologySublanguage.

Reidel, Dordrecht, 1989.

Marti A. Hearst.

Automatic acquisition of hyponyms from large text corpora.

In Proceedings of the 15th International conference on ComputationalLinguistics (COLING’92), volume 2, pages 539–545, Nantes, France, 1992.



ONTOR UL E

References XI

Donnald Hindle.

Noun classification from predicate-argument structures.

In Proceedings of the Association for Computational Linguistics, pages268–275, 1990.

Christian Jacquemin and Evelyne Tzoukermann.

Nlp for term variant extraction : synergy between morphology, lexicon, andsyntax.

In T. Strzalkowsko, editor, Natural Language Information Retrieval, pages25–74. Kluwer, Boston, MA, 1999.

Alon Y. Levy and Marie-Christine Rousset.

Combining horn rules and description logics in CARIN.

Artificial Intelligence, 104:165 – 209, 1998.



ONTOR UL E

References XII

Yue Ma, Adeline Nazarenko, and Laurent Audibert.

Formal description of resources for ontology-based semantic annotation.

In Proceedings of the International Conference on Language Resourcesand Evaluation, page to appear, Malta, May 2010.

Alex Maedche and Steffen Staab.

Ontology learning for the semantic web.

In IEEE Intelligent Systems., volume 16(2) of Special Issue on SemanticWeb., 2001.

Bernardo Magnini, Emanuele Pianta, Octavian Popescu, and ManuelaSperanza.

Ontology population from textual mentions: Task definition and benchmark.

In Proceedings of the OLP2 workshop on Ontology Population andLearning, Sidney, Australia, 2006.



ONTOR UL E

References XIII

Boris Motik and Riccardo Rosati.

A faithful integration of description logics with logic programming.

In IJCAI 2007, Proceedings of the 20th International Joint Conference onArtificial Intelligence, pages 477–482, 2007.

Boris Motik and Riccardo Rosati.

Reconciling description logics and rules.

Journal of the ACM, 2010.

To appear.

Boris Motik, Ulrike Sattler, and Rudi Studer.

Query answering for OWL-DL with rules.

Journal of Web Semantics, 3(1):41–60, 2005.



ONTOR UL E

References XIV

Adeline Nazarenko and Haïfa Zargayouna.

Evaluating term extraction.

In Proceedings of the International Conference on Recent Advances inNatural Language Processing, Borovets, Bulgaria, September 2009.

OMG.

SBVR homepage, 2008.

Version 1.0, January 2008,http://www.omg.org/spec/SBVR/1.0/PDF.

Riccardo Rosati.

On the decidability and complexity of integrating ontologies and rules.

Journal of Web Semantics, 3(1):61–73, 2005.


http://www.omg.org/spec/SBVR/1.0/PDF


ONTOR UL E

References XV

Riccardo Rosati.

DL+log: Tight Integration of Description Logics and Disjunctive Datalog.

In Proceedings of the Tenth International Conference on Principles ofKnowledge Representation and Reasoning (KR 2006), pages 68–78. AAAIPress, 2006.

Beth Sundheim, editor.

Proceedings of the Fourth Message Understanding Conference (MUC-4),Mc Lean, Virginia, 1992. Morgan Kaufman Publishers.

Sylvie Szulman, Jean Charlet, Nathalie Aussenac-Gilles, AdelineNazarenko, Eric Sardet, and Henry V. Teguiak.

DAFOE: an Ontology Building Platform From Text or Thesauri.

In Jan Dietz, editor, International Conference on Knowledge Engineeringand Ontology Development, pages 372–375, Madeira, Portugal, October2009.



ONTOR UL E

References XVI

Sylvie Szulman, François Lévy, Adeline Nazarenko, and Nouha Omrane.

Text-based interactive ontology acquisition tool.

Project deliverable 1.1, ONTORULE project (FP7 2009-231875), 2009.

Allen Van Gelder, Kenneth A. Ross, and John S. Schlipf.

The Well-Founded Semantics for General Logic Programs.

Journal of the ACM, 38(3):620–650, 1991.

K. Wang, D. Billington, J. Blee, and G. Antoniou.

Combining description logic and defeasible logic for the semantic web.

In RuleML, pages 170–181, 2004.

M. Winslett.

Updating Logical Databases.

Cambridge University Press, 1990.
