What Are Description Logics? A family of logic based Knowledge - PDF document

What Are Description Logics? • A family of logic based Knowledge Representation formalisms – Descendants of semantic networks and KL-ONE An I ntroduction to – Describe domain in terms of concepts (classes), roles (relationships) and individuals Description Logics • Distinguished by: – Formal semantics (typically model theoretic) • Decidable fragments of FOL • Closely related to Propositional Modal & Dynamic Logics – Provision of inference services • Sound and complete decision procedures for key problems • Implemented systems (highly optimised) DL Architecture Short History of Description Logics Phase 1: Knowledge Base – Incomplete systems (Back, Classic, Loom, . . . ) I nference System – Based on structural algorithms Tbox (schema) Phase 2: I nterface Man ≡ Hum an u Male – Development of tableau algorithms and complexity results Happy- Father ≡ Man u ∃ has- child – Tableau-based systems for Pspace logics (e.g., Kris, Crack) Fem ale u … – Investigation of optimisation techniques Phase 3: Abox (data) – Tableau algorithms for very expressive DLs – Highly optimised tableau systems for ExpTime logics (e.g., FaCT, John : Happy- Father DLP, Racer) h John, Mary i : has- child – Relationship to modal logic and decidable fragments of FOL Latest Developments Description Logic Family • DLs are a family of logic based KR formalisms Phase 4: • Particular languages mainly characterised by: – Mature implementations – Set of constructors for building complex concepts and roles – Mainstream applications and Tools from simpler ones • Databases – Set of axioms for asserting facts about concepts, roles and – Consistency of conceptual schemata (EER, UML etc.) individuals – Schema integration – Query subsumption (w.r.t. a conceptual schema) • ALC ALC is the smallest DL that is propositionally closed • Ontologies and Semantic Web (and Grid ) – Constructors include booleans (and, or, not), and – Ontology engineering (design, maintenance, integration) – Restrictions on role successors – Reasoning with ontology-based markup (meta-data) – E.g., concept describing “happy fathers” could be written: – Service description and discovery Man È ∃ hasChild.Female È ∃ hasChild.Male – Commercial implementations È ∀ hasChild.(Rich Ë Happy) • Cerebra system from Network Inference Ltd •1

DL Concept and Role Constructors DL Knowledge Base • Range of other constructors found in DLs, including: • DL Knowledge Base (KB) normally separated into 2 parts: – Number restrictions (cardinality constraints) on roles, e.g., – TBox is a set of axioms describing structure of domain (i.e., a ˘ 3 hasChild, ¯ 1 hasMother conceptual schema), e.g.: • HappyFather ≡ Man È ∃ hasChild.Female È … – Qualified number restrictions, e.g., ˘ 2 hasChild.Female, ¯ 1 hasParent.Male • Elephant Ç Animal È Large È Grey – Nominals (singleton concepts), e.g., {Italy} • transitive(ancestor) – Concrete domains (datatypes), e.g., hasAge.( ˘ 21), earns spends.< – ABox is a set of axioms describing a concrete situation (data), e.g.: – Inverse roles, e.g., hasChild - (hasParent) • John:HappyFather – Transitive roles, e.g., hasChild* (descendant) • <John,Mary>:hasChild – Role composition, e.g., hasParent o hasBrother (uncle) • Separation has no logical significance – But may be conceptually and implementationally convenient OWL as DL: Class Constructors RDFS Syntax E.g., Person u ∀ hasChild.(Doctor t t ∃ hasChild.Doctor): <owl:Class> <owl:intersectionOf rdf:parseType=" collection"> <owl:Class rdf:about="#Person"/> <owl:Restriction> <owl:onProperty rdf:resource="#hasChild"/> <owl:toClass> <owl:unionOf rdf:parseType=" collection"> <owl:Class rdf:about="#Doctor"/> <owl:Restriction> <owl:onProperty rdf:resource="#hasChild"/> <owl:hasClass rdf:resource="#Doctor"/> </owl:Restriction> XMLS datatypes as well as classes in ∀ P.C and ∃ P.C • </owl:unionOf> – E.g., ∃ hasAge.nonNegativeInteger </owl:toClass> • Arbitrarily complex nesting of constructors </owl:Restriction> – E.g., Person u ∀ hasChild.(Doctor t t ∃ hasChild.Doctor) </owl:intersectionOf> </owl:Class> OWL as DL: Axioms XML Schema Datatypes in OWL • OWL supports XML Schema primitive datatypes – E.g., integer, real, string, … • Strict separation between “object” classes and datatypes – Disjoint interpretation domain ∆ D for datatypes • For a datavalue d , d I ⊆ ∆ D • And ∆ D ∩ ∆ I = ∅ – Disjoint “object” and datatype properties • For a datatype propterty P , P I ⊆ ∆ I × ∆ D • For object property S and datatype property P , S I ∩ P I = ∅ • Axioms (mostly) reducible to inclusion ( v ) • Equivalent to the “ ( ( D D n ) ” in SH SHOIN OIN ( ( D D n ) – C ≡ D iff both C v D and D v C • Obvious FOL equivalences – E.g., C ≡ D ¤ ∀ x. x) j D( ¤ ∀ x. x) f D( x. C( C( x) D( x) x) , C v D D x. C( C( x) D( x) x) •2

Why Separate Classes and Datatypes? OWL DL Semantics • Philosophical reasons: • Mapping OWL to equivalent DL ( SHO SHOIN ( D n ) ): – Datatypes structured by built-in predicates – Facilitates provision of reasoning services (using DL systems) – Not appropriate to form new datatypes using ontology – Provides well defined semantics language ∆ I , DL semantics defined by interpretations: I I = · I ) • = ( ) , , where • Practical reasons: ∆ I is the domain (a non-empty set) – – Ontology language remains simple and compact – · I is an interpretation function that maps: – Semantic integrity of ontology language not compromised • Concept (class) name A → subset A I of ∆ I – Implementability not compromised — can use hybrid reasoner • Role (property) name R → binary relation R I over ∆ I • Only need sound and complete decision procedure for: • Individual name i → i I element of ∆ I d I 1 ∩ … ∩ d I n , where d is a (possibly negated) datatype DL Semantics Interpretation Example Interpretation function · I extends to concept expressions in ∆ = {v, w, x, y, z} • A I A I = {v, w, x} the obvious way, i.e.: B I = {x, y} v R I = {(v, w), (v, x), (y, x), (x, z)} w • ¬ B = x • A u B = ¬ A t B = • • ∃ R B = y • ∀ R B = z • ∃ R ( ∃ R A) = ∃ R ¬ (A t B) = • 6 1 R A = • B I > 1 R A = • DL Knowledge Bases (Ontologies) Knowledge Base Semantics • An OWL ontology maps to a DL Knowledge Base K = hT hT , Ai Ai An interpretation I satisfies (models) an axiom A ( I ² A ): • – T T (Tbox) is a set of axioms of the form: – I ² C v D D iff C I ⊆ D I • C v D D (concept inclusion) D iff C I = D I – I ² C ≡ D • C ≡ D D (concept equivalence) – I ² R v S S iff R I ⊆ S I • R v S S (role inclusion) – I ² R ≡ S S iff R I = S I • R ≡ S S (role equivalence) • R + v R – I ² R + v R R iff ( R I ) + ⊆ R I R (role transitivity) D iff x I ∈ D I – I ² x ∈ D – A A (Abox) is a set of axioms of the form – I ² h x , y i ∈ R R iff ( x I , y I ) ∈ R I • x ∈ D D (concept instantiation) I satisfies a Tbox T ( I ² T • h x , y i ∈ R R (role instantiation) • T ) iff I satisfies every axiom A in T I satisfies an Abox A ( I ² A ) iff I satisfies every axiom A in A • Two sorts of Tbox axioms often distinguished • I satisfies an KB K ( I ² K ) iff I satisfies both T – “Definitions” • T and A • C v D or C ≡ D where C is a concept name – General Concept Inclusion axioms (GCIs) • C v D where C in an arbitrary concept •3