Description Logics (DLs)

Similar documents
From OWL to Description Logics. U. Straccia (ISTI - CNR) DLs & SW / 170

Thomas Lukasiewicz. Computing Laboratory, University of Oxford

Phase 1. Phase 2. Phase 3. History. implementation of systems based on incomplete structural subsumption algorithms

Fuzzy Description Logics

Introduzione alle logiche descrittive

DESCRIPTION LOGICS. Paula Severi. October 12, University of Leicester

Structured Descriptions & Tradeoff Between Expressiveness and Tractability

Teil III: Wissensrepräsentation und Inferenz. Kap.11: Beschreibungslogiken

Translating SWRL FOL, SWRL, and OWL DL to the Universal Policy Logic

An Introduction to Description Logic III

Decidability of SHI with transitive closure of roles

An Introduction to Description Logics: Techniques, Properties, and Applications. NASSLLI, Day 2, Part 2. Reasoning via Tableau Algorithms.

Chapter 2 Background. 2.1 A Basic Description Logic

Description Logics. Adrian Groza. Department of Computer Science Technical University of Cluj-Napoca

Description Logics. an introduction into its basic ideas

ALC Concept Learning with Refinement Operators

Description Logics: an Introductory Course on a Nice Family of Logics. Day 2: Tableau Algorithms. Uli Sattler

Logics for Data and Knowledge Representation

Knowledge Representation and Description Logic Part 2

FOUNDATIONS OF SEMANTIC WEB TECHNOLOGIES

An Introduction to Description Logics

arxiv: v2 [cs.lo] 21 Jul 2014

2. A tableau algorithm for ALC with TBoxes, number restrictions, and inverse roles. Extend ALC-tableau algorithm from first session with

OWL Basics. Technologies for the Semantic Web. Building a Semantic Web. Ontology

OWL Semantics. COMP60421 Sean Bechhofer University of Manchester

A Survey of Temporal Knowledge Representations

Reasoning in the SHOQ(D n ) Description Logic

OPPA European Social Fund Prague & EU: We invest in your future.

A RESOLUTION DECISION PROCEDURE FOR SHOIQ

On the Decidability Status of Fuzzy ALC with General Concept Inclusions

Description logics. Description Logics. Applications. Outline. Syntax - AL. Tbox and Abox

Week 4. COMP62342 Sean Bechhofer, Uli Sattler

EXPLANATION AND DIAGNOSIS SERVICES FOR UNSATISFIABILITY AND INCONSISTENCY IN DESCRIPTION LOGICS

Description Logics. Glossary. Definition

A Crisp Representation for Fuzzy SHOIN with Fuzzy Nominals and General Concept Inclusions

Mathematical Logics Description Logic: Introduction

A Zadeh-Norm Fuzzy Description Logic for Handling Uncertainty: Reasoning Algorithms and the Reasoning System

Relations to first order logic

Knowledge Representation for the Semantic Web

Decidability of Description Logics with Transitive Closure of Roles in Concept and Role Inclusion Axioms

A Description Logic with Concrete Domains and a Role-forming Predicate Operator

An Introduction to Description Logics: Techniques, Properties, and Applications. NASSLLI, Day 3, Part 2. Computational Complexity.

Nonmonotonic Reasoning in Description Logic by Tableaux Algorithm with Blocking

Description Logics: a Nice Family of Logics. Day 4: More Complexity & Undecidability ESSLLI Uli Sattler and Thomas Schneider

Knowledge Representation for the Semantic Web Lecture 2: Description Logics I

Expressive number restrictions in Description Logics

Ontology and Database Systems: Knowledge Representation and Ontologies Part 2: Description Logics

Next. Description Logics: a Nice Family of Logics. Some

A Refined Tableau Calculus with Controlled Blocking for the Description Logic SHOI

A MILP-based decision procedure for the (Fuzzy) Description Logic ALCB

Algebraic Tableau Reasoning for the Description Logic SHOQ

Teil III: Wissensrepräsentation und Inferenz. Kap.10: Beschreibungslogiken

A Tableau Algorithm for Fuzzy Description Logics over Residuated De Morgan Lattices

Basic Concepts and Techniques for Managing Uncertainty and Vagueness in Semantic Web Languages. Lecture at Reasoning Web 2008

A Fuzzy Description Logic for Multimedia Knowledge Representation

A Framework for Reasoning with Expressive Continuous Fuzzy Description Logics

An Introduction to Description Logic IX Tableau-based algorithm

Lightweight Description Logics: DL-Lite A and EL ++

OWL Semantics COMP Sean Bechhofer Uli Sattler

Quasi-Classical Semantics for Expressive Description Logics

Inconsistency-Tolerant Reasoning with OWL DL

INTEGRITY CONSTRAINTS FOR THE SEMANTIC WEB: AN OWL 2 DL EXTENSION

Translating XML Web Data into Ontologies

The Complexity of Lattice-Based Fuzzy Description Logics

Complexity of Subsumption in the EL Family of Description Logics: Acyclic and Cyclic TBoxes

Knowledge Representation and Ontologies Part 2: Description Logics

On Axiomatic Rejection for the Description Logic ALC

Two Types of Key Constraints in Description Logics with Concrete Domains. Dũng Dinh-Khac

Role Conjunctions in Expressive Description Logics

Role-depth Bounded Least Common Subsumers by Completion for EL- and Prob-EL-TBoxes

Tableau-based Revision for Expressive Description Logics with Individuals

Knowledge Representation and Description Logic Part 3

ALC + T: a Preferential Extension of Description Logics

A Tableaux-based Algorithm for Description Logics with Transitive Closure of Roles in Concept and Role Inclusion Axioms

Extended Decision Procedure for a Fragment of HL with Binders

Description Logics. Deduction in Propositional Logic. franconi. Enrico Franconi

Description Logics. decidable, supported by automatic reasoning systems

A METRIC INTERVAL-BASED TEMPORAL DESCRIPTION LOGIC

University of Oxford. Consequence-based Datatype Reasoning in EL: Identifying the Tractable Fragments

From Tableaux to Automata for Description Logics

Özgür L. Özçep Ontology-Based Data Access

A Description Logic with Transitive and Inverse Roles and Role Hierarchies

Optimization Techniques for Fuzzy Description Logics

Inverting Proof Systems for Secrecy under OWA

A Tableaux Decision Procedure for SHOIQ

Optimisation of Terminological Reasoning

Ordering, Indexing, and Searching Semantic Data: A Terminology Aware Index Structure

The semantics of ALN knowledge bases is the standard model-based semantics of rst-order logic. An interpretation I contains a non-empty domain O I. It

Fuzzy OWL: Uncertainty and the Semantic Web

Conservative Extensions in Expressive Description Logics

A tableaux calculus for ALC + T min R

Introduction to Description Logic and Ontology Languages

Consequence-Based Reasoning for Ontology Classification

Modular Reuse of Ontologies: Theory and Practice

Principles of Knowledge Representation and Reasoning

A Tableau Algorithm for Description Logics with Nominal Schema

Tractable Extensions of the Description Logic EL with Numerical Datatypes

Computing Least Common Subsumers in Description Logics with Existential Restrictions*

Keys, Nominals, and Concrete Domains

Logic and Reasoning in the Semantic Web (part II OWL)

Transcription:

OWL Three species of OWL OWL full is union of OWL syntax and RDF (Undecidable) OWL DL restricted to FOL fragment (decidable in NEXPTIME) OWL Lite is easier to implement subset of OWL DL (decidable in EXPTIME) Semantic layering OWL DL within Description Logic (DL) fragment OWL DL is based on SHOIN (D n) DL OWL Lite is based on SHIF(D n) DL OWL 2 is based on SROIQ(D n) DL

Description Logics (DLs) The logics behind OWL-DL and OWL-Lite, http://dl.kr.org/. Concept/Class: names are equivalent to unary predicates In general, concepts equiv to formulae with one free variable Role or attribute: names are equivalent to binary predicates In general, roles equiv to formulae with two free variables Taxonomy: Concept and role hierarchies can be expressed Individual: names are equivalent to constants Operators: restricted so that: Language is decidable and, if possible, of low complexity No need for explicit use of variables Restricted form of and Features such as counting can be succinctly expressed

The DL Family A given DL is defined by set of concept and role forming operators Basic language: ALC(Attributive Language with Complement) Syntax Semantics Example C, D (x) (x) A A(x) Human C D C(x) D(x) Human Male C D C(x) D(x) Nice Rich C C(x) Meat R.C y.r(x, y) C(y) has_child.blond R.C y.r(x, y) C(y) has_child.human C D x.c(x) D(x) Happy_Father Man has_child.female a:c C(a) John:Happy_Father

Toy Example Sex = Male Female Male Female Person Human hassex.sex MalePerson = Person hassex.male functional(hassex) umberto:person hassex. Female KB = umberto:maleperson

Note on DL Naming For instance, AL: C, D A C D A R. R.C C: Concept negation, C. Thus, ALC = AL + C S: Used for ALC with transitive roles R + U: Concept disjunction, C 1 C 2 E: Existential quantification, R.C H: Role inclusion axioms, R 1 R 2, e.g. is_component_of is_part_of N : Number restrictions, ( n R) and ( n R), e.g. ( 3 has_child) (has at least 3 children) Q: Qualified number restrictions, ( n R.C) and ( n R.C), e.g. ( 2 has_child.adult) (has at most 2 adult children) O: Nominals (singleton class), {a}, e.g. has_child.{mary}. Note: a:c equiv to {a} C and (a, b):r equiv to {a} R.{b} I: Inverse role, R, e.g. ispartof = haspart F: Functional role, f, e.g. functional(hasage) R +: transitive role, e.g. transitive(ispartof ) SHIF = S + H + I + F = ALCR +HIF OWL-Lite SHOIN = S + H + O + I + N = ALCR +HOIN OWL-DL SROIQ = S + R + O + I + Q = ALCR +ROIN OWL 2

Semantics of Additional Constructs H: Role inclusion axioms, I = R 1 R 2 iff R 1 I R 1 I N : Number restrictions, ( n R) I = {x I : {y x, y R I } n}, ( n R) I = {x I : {y x, y R I } n} Q: Qualified number restrictions, ( n R.C) I = {x {y x, y R I y C I } n}, ( n R.C) I = {x I : {y x, y R I y C I } n} O: Nominals (singleton class), {a} I = {a I } I: Inverse role, (R ) I = { x, y y, x R I } F: Functional role, I = fun(f ) iff z y z if x, y f I and x, z f I the y = z R +: transitive role, (R +) I = { x, y z such that x, z R I z, y R I }

Basics on Concrete Domains Concrete domains: reals, integers, strings,... (tim, 14):hasAge (sf, SoftComputing ):hasacronym (source1, ComputerScience ):isabout (service2, InformationRetrievalTool ):Matches Minor = Person hasage. 18 Semantics: a clean separation between object classes and concrete domains D = D, Φ D D is an interpretation domain Φ D is the set of concrete domain predicates d with a predefined arity n and fixed interpretation d D n D Concrete properties: R I I D Notation: (D). E.g., ALC(D) is ALC + concrete domains

Example: assume I = ( I, I ) such that I = {a, b, c, d, e, f, 1, 2, 4, 5, 8} Person I = {a, b, c, d} Consider the following concrete domain with of some unary predicates (n = 1) over reals D = R, Φ D = {= m, m, m, > m, < m m R} the fixed interpretation of the predicates is (= m) D = {m} ( m) D = {k k m} ( m) D = {k k m} (> m) D = {k k > m} (< m) D = {k k < m} Concrete properties: hasage I I R hasage I = { a, 9, c, 20, b, 12 } What is the interpretation of Person hasage. 18? (Person hasage. 18 ) I = Person I {x y R such that x, y hasage I y ( 18 ) I = {a, b, c, d} {x y. x, y { a, 9, c, 20, b, 12 } y 18} = {a, b, c, d} {a, b} = {a, b}

DL Knowledge Base A DL Knowledge Base is a pair KB = T, A, where T is a TBox containing general inclusion axioms of the form C D, concept definitions of the form A = C primitive concept definitions of the form A C role inclusions of the form R P role equivalence of the form R = P A is a ABox containing assertions of the form a:c containing assertions of the form (a, b):r containing (in) equality Axioms of the form a = b and a b An interpretation I is a model of KB, written I = KB iff I = T and I = A, where I = T (I is a model of T ) iff I is a model of each element in T I = A (I is a model of A) iff I is a model of each element in A

OWL DL as Description Logic Concept/Class constructors: Abstract Syntax DL Syntax Example Descriptions (C) A (URI reference) A Conference owl:thing owl:nothing intersectionof(c 1 C 2...) C 1 C 2 Reference Journal unionof(c 1 C 2...) C 1 C 2 Organization Institution complementof(c) C MasterThesis oneof(o 1...) {o 1,...} {"WISE","ISWC",...} restriction(r somevaluesfrom(c)) R.C parts.incollection restriction(r allvaluesfrom(c)) R.C date.date restriction(r hasvalue(o)) R.{o} date.{2005} restriction(r mincardinality(n)) ( n R) ( 1 location) restriction(r maxcardinality(n)) ( n R) ( 1 publisher) restriction(u somevaluesfrom(d)) U.D issue.integer restriction(u allvaluesfrom(d)) U.D name.string restriction(u hasvalue(v)) U. = v } series.= LNCS restriction(u mincardinality(n)) ( n U) ( 1 title) restriction(u maxcardinality(n)) ( n U) ( 1 author) Note: R is an abstract role, while U is a concrete property of arity two.

Axioms: Axioms Abstract Syntax DL Syntax Example Class(A partial C 1... C n) A C 1... C n Human Animal Biped Class(A complete C 1... C n) A = C 1... C n Man = Human Male EnumeratedClass(A o 1... o n) A = {o 1 }... {o n} RGB = {r} {g} {b} SubClassOf(C 1 C 2 ) C 1 C 2 EquivalentClasses(C 1... C n) C 1 =... = C n DisjointClasses(C 1... C n) C i C j =, i j Male Female ObjectProperty(R super (R 1 )... super (R n) R R i HasDaughter haschild domain(c 1 )... domain(c n) ( 1 R) C i ( 1 haschild) Human range(c 1 )... range(c n) R.C i haschild.human [inverseof(p)] R = P haschild = hasparent [symmetric] R R similar = similar [functional] ( 1 R) ( 1 hasmother) [Inversefunctional] ( 1 R ) [Transitive]) Tr(R) Tr(ancestor) SubPropertyOf(R 1 R 2 ) R 1 R 2 EquivalentProperties(R 1... R n) R 1 =... = R n cost = price AnnotationProperty(S)

Abstract Syntax DL Syntax Example DatatypeProperty(U super (U 1 )... super (U n) U U i domain(c 1 )... domain(c n) ( 1 U) C i ( 1 hasage) Human range(d 1 )... range(d n) U.D i hasage.posinteger [functional]) ( 1 U) ( 1 hasage) SubPropertyOf(U 1 U 2 ) U 1 U 2 hasname hasfirstname EquivalentProperties(U 1... U n) U 1 =... = U n Individuals Individual(o type (C 1 )... type (C n)) o:c i tim:human value(r 1 o 1 )... value(r no n) (o, o i ):R i (tim, mary):haschild value(u 1 v 1 )... value(u nv n) (o, v 1 ):U i (tim, 14):hasAge SameIndividual(o 1... o n) o 1 =... = o n president_bush = G.W.Bush DifferentIndividuals(o 1... o n) o i o j, i j john peter Symbols Object Property R (URI reference) R haschild Datatype Property U (URI reference) U hasage Individual o (URI reference) U tim Data Value v (RDF literal) U International Conference on Semantic We

XML representation of OWL statements Example: Person haschild.(doctor haschild.doctor) intersectionof( Person restriction(haschild allvaluesfrom(unionof(doctor restriction(haschild somevaluesfrom(doctor)))))

Description Logic Reasoning What can we do with it? Design and maintenance of ontologies Check class consistency and compute class hierarchy Particularly important with large ontologies/multiple authors Integration of ontologies Assert inter-ontology relationships Reasoner computes integrated class hierarchy/consistency Querying class and instance data w.r.t. ontologies Determine if set of facts are consistent w.r.t. ontologies Determine if individuals are instances of ontology classes Retrieve individuals/tuples satisfying a query expression Check if one class subsumes (is more general than) another w.r.t. ontology How do we do it? Use DLs reasoner (OWL DL = SHOIN (D)) Formal properties well understood (complexity, decidability) Known practical reasoning algorithms Implemented systems (highly optimised)

Description Logic System Inference System User Interface Knowledge Base TBox Defines terminology of the application domain" Man = Human Male HappyFather = Man haschild.female ABox States facts about a specific world" John:HappyFather (John, Mary):hasChild

Basic Inference Problems (Formally) Consistency: Check if knowledge is meaningful Is KB satisfiability? Is there some model I of KB? Is C satisfiability? C I for some some model I of KB? Subsumption: structure knowledge, compute taxonomy KB = C D? Is it true that C I D I for all models I of KB? Equivalence: check if two classes denote same set of instances KB = C = D? Is it true that C I = D I for all models I of KB? Instantiation: check if individual a instance of class C KB = a:c? Is it true that a I C I for all models I of KB? Retrieval: retrieve set of individuals that instantiate C Compute the set {a KB = a:c}

Reduction to Satisfiability Problems are all reducible to KB satisfiability Subsumption: KB = C D iff T, A {a:c D} not satisfiable, where a is a new individual Equivalence: KB = C = D iff KB = C D and KB = D C Instantiation: KB = a:c iff T, A {a: C} not satisfiable Retrieval: The computation of the set {a KB = a:c} is reducible to the instance checking problem

Exercise Problem: Consider the following conceptual schema Solution: Encode it into Description logics and prove that KB = ItalianProf LatinLover Lazy Italian Mafioso Italian LatinLover Italian Italian (Lazy Mafioso LatinLover) ItalianProf Italian Lazy Mafioso Lazy LatinLover Mafioso LatinLover Mafioso ItalianProf Lazy ItalianProf

Reasoning in DLs: Basics Tableaux algorithm deciding satisfiability Try to build a tree-like model I of the KB Decompose concepts C syntactically Apply tableau expansion rules Infer constraints on elements of model Tableau rules correspond to constructors in logic (,,... ) Some rules are nondeterministic (e.g.,, ) In practice, this means search Stop when no more rules applicable or clash occurs Clash is an obvious contradiction, e.g., A(x), A(x) Cycle check (blocking) may be needed for termination

Negation Normal Form (NNF) We have to transform concepts into Negation Normal Form: push negation inside using de Morgan laws C C (C 1 C 2 ) C 1 C 2 (C 1 C 2 ) C 1 C 2 and ( R.C) R. C ( R.C) R. C

Completion-Forest This is a forest of trees, where each node x is labelled with a set L(x) of concepts each edge x, y is labelled with L( x, y ) = {R} for some role R (edges correspond to relationships between pairs of individuals) The forest is initialized with a root node a, labelled L(x) = for each individual a occurring in the KB an edge a, b labelled L( a, b ) = {R} for each (a, b):r occurring in the KB Then, for each a:c occurring in the KB, set L(a) L(a) {C} The algorithm expands the tree either by extending L(x) for some node x or by adding new leaf nodes. Edges are added when expanding R.C A completion-forest contains a clash if, for a node x, {C, C} L(x) If nodes x and y are connected by an edge x, y, then y is called a successor of x and x is called a predecessor of y. Ancestor is the transitive closure of predecessor. A node y is called an R-successor of a node x if y is a successor of x and L( x, y ) = {R}. The algorithm returns satisfiable" if rules can be applied s.t. they yield a clash-free, complete (no more rules can be applied) completion forest

ALC Tableau rules without GCI s Rule Description ( ) if 1. C 1 C 2 L(x) and 2. {C 1, C 2 } L(x) then L(x) L(x) {C 1, C 2 } ( ) if 1. C 1 C 2 L(x) and 2. {C 1, C 2 } L(x) = then L(x) L(x) {C} for some C {C 1, C 2 } ( ) if 1. R.C L(x) and 2. x has no R-successor y with C L(y) then create a new node y with L( x, y ) = {R} and L(y) = {C} ( ) if 1. R.C L(x) and 2. x has an R-successor y with C L(y) then L(y) L(y) {C}

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C R.( C D) R.D} x

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C R.( C D) R.D} x

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C R.( C D) R.D} x

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} x

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} x

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} x R L(y 1 ) = {C} y 1

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} x R L(y 1 ) = {C} y 1

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, C} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, C} Clash y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D} y 2

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D} y 2

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D, C D} y 2

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D, C D} y 2

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D, C D, C} y 2

Example Is R.C R.( C D) R.D satisfiable? Yes. L(x) = { R.C, R.( C D), R.D} L(y 1 ) = {C, C D, D} y 1 x R R L(y 2 ) = {D, C D, C} y 2 Finished. No more rules applicable and the tableau is complete and clash-free Hence, the concept is satisfiable The tree corresponds to a model I = ( I, I ) The nodes are the elements of the domain: I = {x, y 1, y 2 } For each atomic concept A, set A I = {z A L(z)} C I = {y 1 }, D I = {y 2 } For each role R, set R I = { x, y there is an edge labeled R from x to y} R I = { x, y 1, x, y 2 } It can be shown that x ( R.C R.( C D) R.D) I

Example Is R.C R. C satisfiable? No. L(x) = { R.C R. C} x

Example Is R.C R. C satisfiable? No. L(x) = { R.C R. C} x

Example Is R.C R. C satisfiable? No. L(x) = { R.C R. C} x

Example Is R.C R. C satisfiable? No. L(x) = { R.C, R. C} x

Example Is csomer.c R. C satisfiable? No. L(x) = { R.C, R. C} x

Example Is R.C R. C satisfiable? No. L(x) = { R.C, R. C} x R L(y 1 ) = {C} y 1

Example Is R.C R. C satisfiable? No. L(x) = { R.C, R. C} x R L(y 1 ) = {C} y 1

Example Is R.C R. C satisfiable? No. L(x) = { R.C, R. C} L(y 1 ) = {C, C} y 1 x R

Example Is R.C R. C satisfiable? No. L(x) = { R.C, R. C} L(y 1 ) = {C, C} y 1 x R Clash Finished. No more rules applicable and the tableau is complete, but not clash-free Hence, the concept is not satisfiable I.e. no model can be built, e.g. I = {x, y1 } C I = {y1 } R I = { x, y1 } is not a model because ( R.C R. C) I = ( R.C) I ( R. C) I = {x} =

Soundness and Completeness Theorem Let A be an ALC ABox and F a completion-forest obtained by applying the tableau rules to A. Then 1. The rule application terminates; 2. If F is clash-free and complete, then F defines a (canonical) (tree) model for A; and 3. If A has a model I, then the rules can be applied such that they yield a clash-free and complete completion-forest.

KBs with GCIs We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable with T? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human} umberto

KBs with GCIs We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable with T? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, Human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, Human} Clash umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human} hasmother y 1

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human} hasmother y 1

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 L(y 2 ) = {Human, Human hasmother.human} hasmother y 2

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 L(y 2 ) = {Human, Human hasmother.human} hasmother y 2

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 L(y 2 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 2

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 L(y 2 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 2

KB Satisfiability We have seen how to test the satisfiability of an ABox A But, how can we check if a KB KB = T, A is satisfiable? Basic idea: since t(c D) x. t(c, x) t(d, x) we use the rule: for each C D T, add C D to every node But, termination is not guaranteed E.g., consider KB = T, A T = {Human hasmother.human} A = {umberto:human} L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 L(y 2 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 2.

Node Blocking in ALC When creating new node, check ancestors for equal label set If such a node is found, new node is blocked No rule is applied to blocked nodes L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother hasmother L(y 2 ) = {Human, Human hasmother.human, hasmother.human} y 2 blocked: L(y 1 ) = L(y 2 ) y 1

Node Blocking in ALC When creating new node, check ancestors for equal label set If such a node is found, new node is blocked No rule is applied to blocked nodes L(umberto) = {Human, Human hasmother.human, hasmother.human} umberto L(y 1 ) = {Human, Human hasmother.human, hasmother.human} hasmother y 1 hasmother hasmother L(y 2 ) = {Human, Human hasmother.human, hasmother.human} y 2 blocked: L(y 1 ) = L(y 2 ) Block represents cyclical model I = {umberto, y 1, y 2 } Human I = {umberto, y 1, y 2 } hasmother I = { umberto, y 1, y 1, y 2, y 2, y 1 }

Blocking in ALC A non-root node x is blocked if for some ancestor y, y is blocked or L(x) = L(y), where y is not a root node. A blocked node x is indirectly blocked if its predecessor is blocked, otherwise it is directly blocked. If x is directly blocked, it has a unique ancestor y such that L(x) = L(y) if there existed another ancestor z such that L(x) = L(z) then either y or z must be blocked. If x is directly blocked and y is the unique ancestor such that L(x) = L(y), we will say that y blocks x

ALC Tableau rules with GCI s Rule Description ( ) if 1. C 1 C 2 L(x), x is not indirectly blocked and 2. {C 1, C 2 } L(x) then L(x) L(x) {C 1, C 2 } ( ) if 1. C 1 C 2 L(x), x is not indirectly blocked and 2. {C 1, C 2 } L(x) = then L(x) L(x) {C} for some C {C 1, C 2 } ( ) if 1. R.C L(x), x is not blocked and 2. x has no R-successor y with C L(y) then create a new node y with L( x, y ) = {R} and L(y) = {C} ( ) if 1. R.C L(x), x is not indirectly blocked and 2. x has an R-successor y with C L(y) then L(y) L(y) {C} ( ) if 1. C D T, x is not indirectly blocked and 2. {nnf ( C), D} L(x) = then L(x) L(x) {E} for some E {nnf ( C), D} (nnf ( C) is NNF of C)

Soundness and Completeness Theorem Let KB be an ALC KB and F a completion-forest obtained by applying the tableau rules to KB. Then 1. The rule application terminates; 2. If F is clash-free and complete, then F defines a (canonical) (tree) model for KB; and 3. If KB has a model I, then the rules can be applied such that they yield a clash-free and complete completion-forest.

Representing degrees in OWL-DL/OWL-Lite How can we represent degrees of uncertainty and vagueness in OWL-DL/OWL-Lite? Unfortunately, as for RDF, no standard exists yet We may make an encoding as for RDF s1: hassubject.({o1} IsAbout.{snoopy}) hasdegree. = 0.8 But, again then such statements have to be appropriately be managed by the system according to the underlying uncertainty or vagueness theory A rather dangerous approach