Knowledge Bases Description Logics, Knowledge Bases ... · Deﬁnitions • Deﬁnitions are...

Description Logics, Knowledge Bases, Formal Ontologiesand Data Bases: Content

• Description Logics and Knowledge Bases

• Ontologies in Description Logics: Building Knowledge Bases

– Representation Languages: From RDF to OWL– Some Practical Advice on Building Knowledge Bases

• Description Logics and Data Bases

G. Gorz, FAU, Inf.8 8.1–1

Knowledge Bases(Acknowledgement: Enrico Franconi)

Knowledge Base Σ = 〈TBox, ABox〉

• Terminological Axioms: C � D

• Assertional Axioms: C(a), R(a, b)

• An interpretation I = (∆, ·I) satisfies C � D if CI ⊆ DI.

• I satisfies C(a) if aI ∈ CI.

• I satisfies R(a, b) if (aI, bI) ∈ RI.

An interpretation I = (∆, ·I) is said to be a model of Σ if every axiom ofΣ is satisfied by I. Σ is said to be satisfiable if it admits a model.


TBox Statements

1. A � C Primitive concept definition

2. A.= C Concept definition

3. C � D Concept inclusion

4. C.= D Concept equation

Acyclic Simple TBox

Concept definitions (1) and (2).

Acyclic TBox : Well-founded definitions,i.e. no concept name uses itself directly or indirectly in a definition.


Acyclic Simple Tbox

Subsumption in acyclic simple TBoxes (Σ |= C � D) can be reduced tosubsumption in an empty TBox (|= C � D).

Transformation steps:

1. Transform Σ into Σ′ by replacing primitive concept definitions A � Cas above (“checking subsumption”).

2. Iteratively substitute every occurence of any defined concept name in C(and D) by the corresponding definition in Σ′. Since Σ′ is still acyclic,the process terminates in a finite number of iterations. This process iscalled unfolding or expansion.

A concept is subsumed by a primitively defined concept if and only if itrefers to its name in its (unfolded) definition.


Inheritance

Unfolding realizes what is usually called inheritance in object-orientedframeworks.

Person.= ∃NAME.string � ∃ADDRESS.String

Parent.= Person � ∃CHILD.Person

Parent.= ∃NAME.string � ∃ADDRESS.String�

∃CHILD.(∃NAME.string � ∃ADDRESS.String)Female

.= ¬MaleMan

.= Person � ∀SEX.MaleWoman

.= Person � ∀SEX.FemaleTranssexual

.= Man � Woman

Transsexual.= ∃NAME.String � ∃ADDRESS.String � ∀SEX.⊥


Complexity of Unfolding

C1.= ∀R1.C0 � ∀R2.C0 � . . . � ∀Rm.C0

C2.= ∀R1.C1 � ∀R2.C1 � . . . � ∀Rm.C1

. . .Cn

.= ∀R1.Cn−1 � ∀R2.Cn−1 � . . . � ∀Rm.Cn−1

• The size of the TBox is O(n × m).

• The size of the unfolded concept Cn is O(mn).

• The complexity of the subsumption problem in FL− with empty TBox(|= C � D) is P.

• The complexity of the subsumption problem in FL− with an acyclicsimple TBox (Σ |= C � D) is coNP-complete.


Efficiency of Subsumption in Practice

The exponential worst case is unlikely to occur in real knowledge bases.

• Let n be the depth of a TBox, i.e., the max number of iterations whileunfolding every concept definition.

• Let m be the size of the largest definition.

• Let s be the size of the TBox, i.e., m times the number of conceptdefinitions.

The size of an unfolded concept is O(mn).

=⇒ If n ≤ logms, the size of an unfolded concept becomes polynomialO(s) with respect to the size of the TBox.


This is a reasonable assumption, since the depth of concept definitions isusually much smaller than the size of the knowledge base.This is why systems behave well in practice.


Definitions

• Definitions are intended to provide an exact account for the conceptname being defined.

• Given an initial interpretation of the primitive concept names, thereexists a unique way determine the interpretation of defined conceptnames; indeed, that’s why they are called definitions.

• This justifies the correctness of unfolding: We can always replace aconcept name with its definition, since it doesn’t add anything to thetheory.

• However, if the (simple) TBox is cyclic, this is no longer true.


Example of a Recursive Definition

Quiet− Person.= Person � ∀FRIEND.Quiet− Person

∆ = {john, sue, andrea, bill}PersonI = {john, sue, andrea, bill}FRIENDI = {〈john, sue〉, 〈andrea, bill〉, 〈bill, bill〉}=⇒ Quiet− PersonI = {john, sue}=⇒ Quiet− PersonI = {john, sue, andrea, bill}


(Least) Fixpoint Semantics

We associate to a cyclic concept definition an operator F : 2∆ �→ 2∆ , suchthat the interpretation of A corresponds to the fixpoints of the operator F .

Thus, we associate the equation A = F (A) to a cyclic concept definitionof the type A

.= C where C mentions A.

The least fixpoint semantics interprets a recursive definition A = F (A) byassigning to A the smallest possible extension in each interpretation I – ifit exists – among those satisfying AI = F (A)I, i.e., the least fixpoint ofthe corresponding operator.

If the operator is monotonic, then the equation singles out a uniqueinterpretation (subset of ∆), hence it defines the concept A.

Remark: Goes beyond first order!


In the example,F = λA.{x ∈ ∆ | PersonI(x) ∧ ∨

y .FRIENDI(x, y) → A(y).}A = F (A)=⇒ Quiet− PersonI = {john, sue}


Inductive Definitions

• An Empty− List is a List.

• A Node, that has exactly one SUCCESSOR that is a List, is a List.

• Nothing else is a List.

Node.= ¬Empty− List

List.= Empty− List � (Node � ∃≤1SUCCESSOR � SUCCESSOR.List)

∆ = {a, b, nil}NodeI = {a, b}Empty− ListI = {nil}SUCCESSORI = {〈a, nil〉, 〈b, b〉}With descriptive semantics: ListI = {a, b, nil}With least fixpoint semantics: ListI = {a, nil}


Properties of Formal Ontology Languages(Lassila/McGuinness)• Mandatory

1. Finite controlled (extensible) vocabulary2. Unambiguous interpretation of classes and term relationships3. Strict hierarchical subclass relationships between classes

• Typical, but not mandatory

4. Property specification on a per-class basis5. Individual inclusion in the ontology6. Value restriction specification on a per-class basis

• Desirable, but not mandatory nor typical

7. Specification of disjoint classes, inverse relationships, part-wholerelationships

8. Specification of arbitrary logical relationships between terms


Frame-Based Representations

Recall last slide of ch. 4!

• Various frame-based languages have been proposed in the 1980’s and1990’s, and used for large projects, e.g.

– CycL for the Cyc Project (Cycorp)– Ontolingua with KIF (FOL “dialect”) (Stanford FSL)– KM (Knowledge Machine, U.Texas) with KRL– etc.

• Notice analogy between frame systems, OOP systems, RDF(S), anddescription logics:

frame, schema | class, type | resource, class | concept, classframe, instance | instance | resource | instance, individualslot | attribute, instance variable | property | role, attributefiller | value | property value | filler


Frame-Based Representations: Example KM/KRL

• Knowledge Representation Language (KRL) with an interpreter sittingon top of Lisp

• expressive

• formal semantics

• A Reasoning Engine with backward chaining and automatic classification(What can be inferred from the facts? What can be inferred from theinferences from facts?)

• Reasoning with actions(Run Simulations in the World Described in the KB. What would be thestate of objects if certain events took place?)

• Defaults (inheritance with overrides)


G. Gorz, FAU, Inf.8 8.1–17 G. Gorz, FAU, Inf.8 8.1–18

OKDB: Open Knowledge Base Connectivity

Provides operations for manipulating knowledge expressed in an implicitrepresentation formalism called the OKBC Knowledge Model.

• Constants (basic types)

• Frames, own slots, own facets (restrictions)

• Classes and individuals

• Class frames, template slots, template facets

• Primitive and non-primitive classes

• Associating slots and facets with frames

• Collection types for slot and facet values (multiple values)

• Default values

• Standard classes, facets, slots


Semantic Web Layers


The Resource Description Framework (RDF)

• “The Resource Description Framework (RDF) is an infrastructure thatenables the encoding, exchange, and reuse of structured metadata. RDFis an application of XML that imposes needed structural constraints toprovide unambiguous methods of expressing semantics.´´

(Miller, D-Lib Magazine, May 1998)

• RDF expands from the traditional notion of document metadata (e.g.library catalogues) to the description of web resources, providinginteroperability for applications

• Knowledge representation in RDF: directed labeled graphs (DLGs)where nodes and arcs are named using URIs.

• Basic structure is the triple: Resource – Property ⇒ Valueconnectable, nestable


• Primitives: instance− of, subclass, properties withrange, domain, and cardinality restrictions

• RDF(S) (RDF-Schema) adds:class− def, subclass− of, slot− def, subslot− of, domain, range

• Problem: Inference ???


RDF (2)

• RDF: to represent meta-data

• RDF-S: to define vocabulary for RDF

• RDF is data-model + syntax

– only a very weak semantic interpretation– no inference model

• RDF-S goes a step further, but still

– no precisely described meaning– no inference model


Bluffer’s guide to RDFAcknowledgement: F. van Harmelen



Bluffer’s guide to RDFS


The Wine Ontology in RDFS


Protege: A Graphical Tool for Ontology Editing andKnowledge Acquisition

• Extensible Knowledge Model: Can easily be made OKBC compatibleand adapted to Semantic Web Languages (. . . metaclasses)

• Customizable output format

• Customizable user interface

• Extensible architecture (plug-ins) that enables integration with otherapplications, e.g. reasoning engines


The RDF Wine Ontology in Protege


OWL = DAML+OIL — The Logic Layer

OWL = DAML+OIL as an RDFS extension combines

• Frames: Modelling primitives

• Description Logics: Formal semantics, reasoning

• Web languages: XML and RDF based syntax

• In principle: Gives a semantics to RDF(S)(. . . semantic difference in mapping properties to domain objects —reified predicates mapped into tuples, i.e. extensions, in a second step)

• DL (is-a) can be used to provide automatic formal reasoning services(sound & complete); algorithm for deciding concept satisfiability


• Equivalent to a very expressive description logic: SHIQ• Official W3C standard since Feb. 2004


OIL Extensions to RDFS


SHIQ

SHIQ

• ALC plus

• Qualified number restrictions

• “General Inclusion Axioms” (GCI)

• Transitive and inverse roles

• Role hierarchies

• Extended by existentially defined classes (O = OneOf)

• Data types (“concrete domains”), e.g. real numbers


Class Constructors in OWL

Constructor Notation Example

(OWL = DAML+OIL)

intersectionOf C1 � . . . � Cn Human � Male

unionOf C1 � . . . � Cn Doctor � Lawyer

complementOf ¬C ¬Male

oneOf {x1, . . . , xn} {john, mary}toClass ∀P.C ∀hasChild.Doctor

hasClass ∃P.C ∃hasChild.Lawyer

hasValue ∃P.{x} ∃citizenOf.{USA}minCardinalityQ ≥ nP.C ≥ 2hasChild.Lawyer

maxCardinalityQ ≤ nP.C ≤ 1hasChild.Male

CardinalityQ = nP.C = 1hasParent.Female

Nesting of constructors,e.g. ∀hasChild.(Doctor �∃hasChild.Doctor)


Axioms in OWL

Axiom (OWL = DAML+OIL) Notation Example

subClassOf C1 � C2 Human � Animal � Biped

sameClassAs C1.= C2 Man

.= Human � Male

subPropertyOf P1 � P2 hasDaughter � hasChild

samePropertyAs P1.= P2 cost

.= price

sameIndividualAs {x1} .= {x2} {President-Bush} .

= {G-W-Bush}disjointWith C1 � ¬C2 Male � ¬Female

differentIndividualFrom {x1} � ¬{x2} {john} ⊆ ¬{peter}inverseOf P1

.= P−

2 hasChild.= hasParent−

transitiveProperty P + � P ancestor+ �ancestor

uniqueProperty �≤ 1P �hasMother

unambiguousProperty �≤ 1P− �isMotherOf−

Axioms usually reducible to subClass/PropertyOf


Protege: The OWL Plugin Architecture


Example: The CIDOC Common Reference Model (1)






Practical Advice on Building Knowledge Bases

During the design of a KB, decisions among the following distinctionsmust be made carefully:

• Primitive vs. Defined

• Definitional vs. Incidental

• Concept vs. Individual

• Concept vs. Role


When to Use Primitive Concepts?

• Some concepts can not be completely defined (e.g. natural kinds);

• It can be not convenient/useful to completely define a concept;

• Sooner or later we must end up with something not completely defined(encyclopedic knowledge cannot be given).

Thus, primitive concepts must be used when:

• There is no other way;

• Even if it were defined, an (automatic) classification among them willbe never required by the application.

Typically primitive concepts lie in the top region of the taxonomy.


When to Use Defined Concepts?

• “Ontological” reason: It is easy and natural (in the context of theapplication) to give a complete definition of the concept;

• Organization of the antecedents of rules;

• Capturing complete descriptions used by rules for populating primitiveconcepts.

Definitional vs. Incidental: Incidental are all properties that arecontingent features of a concept, and thus must not be part of itsdefinition.

Example:(∀SUGAR.Dry) is incidental for the concept RED− BORDEAUX− WINE, while(∀COLOR.Red) and (∀REGION.Bordeaux) are not


Concept vs. Individual

• The set of individuals is a countable, discrete set;

• The concept space is ideally continuous and infinite;

• Each individual has a clear identity: even if two individuals have thesame properties, they are distinct;

• If two concepts have equivalent descriptions, they denote the sameconcept;

• Individual descriptions can be modified;

• Concept descriptions cannot be modified;

• Individual update does (usually) not change the concept hierarchy;

• Rules apply only to individuals.


Nevertheless, it is not always easy to decide whether an object should be aconcept or an individual. The main issue to deal with is the “granularity”level.


Individual vs. Concept: Example

If we have Wine and White− wine, what about:

• chardonnay-wine

• forman-chardonnay

• 1981-forman-chardonnay

• 1981-forman-chardonnay-from-vineyard32

• 1981-forman-chardonnay-from-in-cask18

• 1981-forman-chardonnay-bottle#1576

A key to solve the problem could be asking the domain/application expert:How many wines do you have? in order to understand the neededgranularity.


Concept vs. Role

It is not always easy to decide what must be a concept and what a role.

Example:

• Person: is a concept.

• Mother:

– consider “Sue is a new mother” and “Sue is the mother of Tom”– Mother as a concept does not exist if we don’t consider the “role she

plays” in a parental relation, i.e., if “Sue is a new mother” she mustbe the MOTHER of somebody!

Thus: Mother.= (Woman � (∃MOTHER.Person))


Concept vs. Role (cont.)

• But when the role is not the only important component of thedefinition, this dual use is not so neat (consider VINTAGE, GRAPE).

• Another problem is the reading direction: In the above example the rolecould be MOTHER or CHILD.

• A clear convention must be stated, possibly creating long, nonambiguous names for roles, e.g.:HAS− CHILD, IS− THE− PARENT− OF, HAS− VINTAGE, HAS− GRAPE.

• As an alternative, the adoption of long names for concepts can be alsosuggested, e.g., Wine− Grape.


Example: Modeling a Red Wine

• Wine is a concept.

• Red is a concept, denoting all red objects; thus,Red− wine

.= Wine � Red.

• red is a specific color, an instance of the concept Color; but COLOR isalso a property of objects; thus,Red− wine

.= Wine � ∀COLOR.({red} � Color)

• Red is the concept of red color, possibly having several instancesrepresenting different real red colors, . . .


G. Gorz, FAU, Inf.8 8.1–49 G. Gorz, FAU, Inf.8 8.1–50

How to Design a KB in 12 Steps

1. Enumerate Objects as a bare list of elements of the KB; they willbecome individuals, concepts, or roles.

2. Distinguish Concepts from Roles. Make a first decision about whichobjects must be considered roles; remember that some could have a“natural” concept associated. The remaining objects will be concepts(or maybe individuals). Also, try to distinguish roles from attributes.

3. Develop Concept Taxonomy. Try to decide a classification of all theconcepts, imagining their extensions. This taxonomy will be used as afirst reference, and could be revised when definitions will be given. Itwill be used also to check if definitions meet our expectations(sometime, interesting, unforeseen (re)classifications are found).


4. Devise Partitions. Try to make explicit all the disjointness andcovering constraints among classes, and reclassify the concepts.

5. Individuals. Try to list as many as possible generally useful individuals.Some could have been already listed in step 1. Try to describe them(classify).

6. Properties and Parts. Begin to define the internal structure ofconcepts (this process will be continued in the next steps). For eachconcept list:

• intrinsic properties that are part of the very nature of the concept;• extrinsic properties, that are contingent or external properties of the

object; they can sometimes change with time;• parts, in the case of structured or collective objects.

They can be physical (e.g., “the components of a car”, “the casks ofa winery”, “the students of a class”, “the members of a group”, “thegrape of a wine”) or abstract (e.g.,“the courses of a meal”, “the


lessons of a course”, “the topics of a lesson”).

In some cases some relationships between individuals of classes can beconsidered too accidental to be listed above (e.g., “the employees of awinery”); but the matter could change if we consider Winery as asubconcept of Firm.

In general, the mentioned distinctions depend on the adopted level ofdetail.

Some of the listed roles will later be considered definitional, and someincidental.

After this and the next steps, a check/revision of step 3 could benecessary.

7. Cardinality Restrictions for the relevant roles for each concept.

8. Value Restrictions, as above. Also, choose the right restrictions.


9. Propagate Value Restrictions. If some value restrictions stated in theprevious step do not correspond to already existing concepts, they mustbe defined.

10. Inter-role Relationships. Even if hardly definable in DL, they can beuseful during the populating and debugging phases.

11. Definitional and Incidental. It is important to distinguish betweendefinitional and incidental properties w.r.t. to the particular application.

12. Primitive and Defined, as above.


And There is Much More to Say. . .

• Alternatives in Modellingcf. Welty: Formal Ontology for SubjectAmbiguity in the use of “subject” ⇒ unified framework

• Methodological “cleaning”: OntoClean/DOLCEcf. Guarino, Welty: A Formal Ontology of Properties, Proc. ECAI 2000⇒ Introduction in ch. 4Basic notions and constraints: Rigidity, Identity, Unity, Dependence

• Multi-Use Ontologies: Versioning, Leveling, Composition cf. Fikes:Stanford lecture on Knowledge Representation, CS 222, ch.8

• . . .


Guarino: Messy Ontology


Guarino: Cleaned Ontology


Some References

Baader, F., Horrocks, I., Sattler, U.: Description Logics as Ontology Languages for the

Semantic Web.

In: Festschrift in Honor of Jorg Siekmann. Ed. Hutter, D. Stephan W.

Berlin: Springer (LNCS), 2003, 21pp.

Horrocks, I.: Reasoning with Expressive Description Logics: Theory and Practice.

In: Proc. CADE-18. Ed. Voronkov, A.

Berlin: Springer (LNAI 2392), 2002, 1–15

Horrocks, I., Patel-Schneider, P.F.: Three Theses of Representation in the Semantic Web.

Proceedings of WWW2003, Budapest: ACM, 2003

Lassila, O., McGuinness, D.: The Role of Frame-Based Representation in the Semantic

Web.

Technical Report, Stanford, 2003


Noy, N. et al.: Creating Semantic Web Content with Protege-2000.

IEEE Intelligent Systems, March/April 2001, 60–71

Brachman, R., McGuinness, D., Patel-Schneider, P., Resnick, L., Borgida, A.:

Living with CLASSIC: When and How to Use a KL-ONE-like Language.

In: Principles of Semantic Networks. Explorations in the Representation of Knowledge. Ed.

Sowa, J.

San Mateo: Morgan Kaufmann, 1991, 401–456

Noy, N.: Ontologies.

In: Handbook for Language Engineers. Ed. Farghaly, A. Stanford: CSLI Lecture Notes

164, 2003, 181–211

Artale, A., Franconi, E., Guarino, N., Pazzi, L.:

Part-Whole Relations in Object-Centered Systems: An Overwiew.

Data & Knowledge Engineering, Vol. 20, 1996, 347–383


Knowledge Bases Description Logics, Knowledge Bases ... · Deﬁnitions • Deﬁnitions are...

Documents

Transcript of Knowledge Bases Description Logics, Knowledge Bases ... · Deﬁnitions • Deﬁnitions are...