In Proceedingsof the Thirteenth National Conferenceon Artificial Intelligence (AAA1-96).Copyright © 1996, AAAI.
11
From: AAAI Technical Report FS-96-03. Compilation copyright © 1996, AAAI (www.aaai.org). All rights reserved.
Closed Terminologies in Description Logics
Robert
A. Weida
IBMT. J. WatsonResearch Center
P. O. Box 218
Yorktown Heights, NY10598
weida @watson.ibm.com
Abstract
Weintroducea predictive conceptrecognitionmethodology
for description logics basedon a newclosed terminology
assumption. During knowledgeengineering, our system
adopts the standardopenterminologyassumptionas it automaticallyclassifies conceptdescriptionsinto a taxonomy
via subsumption
inferences. However,
for applicationslike
configuration, the terminologybecomesfixed duringproblem solving. Then, closed terminologyreasoning is more
appropriate.In our interactive configurationapplication,a
user incrementallyspecifies an individual computersystem
in collaborationwitha configurationengine. Choicescanbe
madein any order and at any level of abstraction. Wedistinguish betweenabstract andconcreteconceptsto formally
define whenan individual’s description maybe considered
finished. Wealso take advantageof the closed terminology
assumption,together with the terminology’ssubsumptionbasedorganization,to efficiently track the types of systems
and components
consistent withcurrent choices, infer additional constraintson currentchoices,andappropriatelyguide
future choices. Thus,wecan help focus the efforts of both
user and configurationengine.
Introduction
In a description logic (DL), a knowledgebase (KB)includes
a terminology composedof concept descriptions, plus descriptions of individuals in terms of those concepts (Woods
& Schmolze 1992). Previous work in DL has not distinguished between knowledgeengineering and problem solving phases of terminology usage. This paper pursues the
idea of closing the terminology after it is developed and
before problemsolving begins. Essentially, our closed terminologyassumption(CTA)holds that all relevant concepts
are explicitly defined, and that every individual, oncefully
specified, will corresponddirectly to at least one concept.
(Wedo not makea closed world assumption over individuals.) For certain applications, this CTAenables useful inferences that wouldbe impossible otherwise, e.g., we introduce
predictive concept recognition: given an individual’s unfinished description and some assumptions, we show how to
ascertain not only the concepts it already instantiates, but
those it mighteventually instantiate, and those it cannot.
Consider system configuration, where DLhas already
found practical success (wright et al. 1993). DLis ideal
for describing artifacts such as computersystems, and for
maintaining the consistency of large configuration terminologies as they evolve over time. Figure 1 showsthe system architecture we have in mind: a configuration engine,
11
Computer Science Department
Columbia University
New York, NY 10027
weida@cs.columbia.edu
whichspecializes in configuration problemsolving, utilizes
a DLsystem to represent and reason with a KB, which contains both a configuration terminologyand a description of
of the individual configuration being workedon. The configuration engine can makesignificant use of traditional DL
inferences, as well as newinferences introduced here.
The standard open terminology assumption (O-TA), which
presumesan incomplete terminology, is appropriate during
knowledgeengineering whenwe are still constructing a domain model of systems, components, and related concepts.
(we coined the term eTAto describe standard practice.)
However,during a specific configuration task, CTAreasoning is preferable because all relevant concepts, e.g., types
of systems, are known. Wewill show how CTAenhances
our ability to rule out concepts that an individual cannot
instantiate, and thus drawconclusions from the remainder.
Wealso distinguish betweenabstract and concrete concepts
to formally define when an individual’s description may
be considered finished, given a closed terminology. Imagine that a user incrementally specifies an individual computer system, in collaboration with a configuration engine.
The configuration engine is responsible for ensuring practical choices and recommendingdesirable ones. In general, choices can be made in any order and at any level
of abstraction. Hence, it may remain unclear for some
time precisely which type of system will result. Wecan
exploit the closed terminology and its subsumption-based
organization to (1) efficiently track the types of systems,
components,etc., that are consistent with current choices,
(2) infer constraints that follow fromcurrent choices and the
terminology’sspecific contents, (3) appropriately restrict future choices, and (4) characterize the most general choices
available for refining a particular individual’s description.
Thus, we can help focus the efforts of both user and configuration engine. This work evolved from DL-basedplan
recognition in the T-REXsystem (weida & Litman 1994;
1992). It is implemented in the X-l~P DLsystem (Mays,
Dionne, &Weida1991). Further details, including proofs
of theorems, are provided in (Weida1996).
Configuration System~
Configuration
t.__,J Description
Logic
Engine
System
Figure 1: Configuration System Architecture
In Proceedingsof the Thirteenth National Conferenceon Artificial Intelligence (AAAI-96). Copyright © 1996, AAAI.
(def’me-pnm-concept
COMPANY)
(define-prim-conceptCPU)
(define-prim-concept
Pasc)
(define-prim-conceptRAM)
(define-prim-concept
DISK)
12
(define-concept UNIPROCESSOR-SYSTEM
(def’me-concept
RISC-MULTIP
ROCES
S OR-S YSTF_~VI
(and COMPUTER-SYS~
(and COMPUTER-SYSTEM
(exactly 1 processor)))
(all processorRISC-CPU)
(at-least 2 processor)))
(define-concept DUALPROCESSOR-SY~
(clef’me-concept
DUAL-IBM-PRO
CBSS OR-SYST~--M
(and COMPLrrFA~-SY~
(exactly2 processor)))
(and COMPUTER-SYSTEM
(all processorIBM-CPU)
(define-conceptDISKI..ESS-SYSTEM
(exactly2 processor)))
(and COMPUTER-SYSTEM
(exactly 0 secondary-storage))) (def’me-concept UNIX-RISC-SY~
(and COMPtrrER-SYSTEM
(all processorRISC-CPU)
(the operating-system
UNIX)))
(define-prim-conceptSYST’~)
(define-prim-conceptOS
SYSTEM)
(define-prim-conceptUNIX
OS)
(def’me--concept
IBM-CPU
(andCPU
(fills vendorIBM)))
(def’me-conceptPdSC-CPU
(and CPU
(the technologyRISe)))
(define-conceptIBM-RISC-CPU
(and CPU
rills
vendor
IBM)
thetechnology
RISe)))
(define-concept
IBM-PROCESSOR-DEVICE
(all processorIBM-CPU))
(define-prim-concept COMPUTER-SYSTEM
(andSYSTEM
(the vendor COMPANY)
(all processorCPU)
(at-least I processor)
(all primary-storageRAM)
(at-least lprimary-storage)
(all secondary-storage
DISK)
(the operating-system
os)))
f
DIS KLESS,-SYSTE
M~
3SOR-SYSTEM)
Figure 2: Sample Concept Definitions and Taxonomy
Description
Logics
DLsystems reason about intensional descriptions of concepts, such as COMPANY,
and their instances, such as raM.
KeyDLinferences include subsumption,classification, and
recognition. Concept C1 subsumes concept C2 when every
possible instance of C2 is also an instance of C1, written
C2 ~ C1. DLimplementations maintain an explicit concept taxonomy, where each concept subsumes its descendants and is subsumedby its ancestors, without exception.
Whena new concept is defined, classification automatically
integrates it into the taxonomy.The standard recognition
inference determinesif individual I currently instantiates
concept C.
The K-REPDLprovides a formal language for defining
concepts and individuals, where roles denote binary relations betweenindividuals. A role’s value restriction is a
concept whichconstrains the range of the relationship; only
instances of the value restriction mayfill the role. Cyclicdescriptions are forbidden. A role also has at-least and at-most
restrictions which constrain howmanyfillers it mayhave.
Restrictions on role R are referred to as value-restriction(R),
fillers(R), at.least(R), andat-most(R); they default to THING
(the universal concept), the emptyset, 0, and oo, respectively. A concept or individual mayinherit from base concepts, i.e., subsumers
explicitly stated in its definition. Local
and inherited properties are combinedby logical intersection. The set of roles restricted by concept or individual X,
12
written restricted-roles(X), is as follows, whereRx denotes
role R of X:
Definition 1 The restricted roles of concept or individual
X are the roles R of X for which vaIue-restriction(Rx)
properly subsumedby THING,or Ifillers(Rx) I > O, or atleast(Rx) > O, or at-most(Rx) <
This paper uses concepts defined in Figure 2, where all
gives a value restriction. As shorthand, exactly combines
at-least and at-most restrictions of the samecardinality, and
the combinesa value restriction with a cardinalityrestriction
of exactly one. The resulting taxonomyalso appears in
Figure 2. Individuals such as mMare not shown. Assuming
that IBMhas been defined as a COMPANY
and 486DX-33MHZ123 as an individual PROCESSOR,
the following description
of an individual COMPUTER-SYSTEM
is well-formed:
(create-individualCOMPLrIT.R-SYSTEM
123
(andCOMPUTER-SYStEM
(fills
vendor
IBM)
(fills processor 486DX-33MHz-123)))
Although its primary-storage, secondary-storage, and
operating-system roles are not yet filled, COMPtrmgSYSTEM123
inherits restrictions on those roles from its base
concept, coMPtny_a-SYST~,a.
COMPtrmR-SYSTEM
is a primitive concept; whereas fully
defined concepts specify necessary and sufficient conditions for class membership,primitive concepts specify only
necessary conditions. Primitive concepts do not subsume
In Proceedingsof the Thirteenth National Conferenceon Artificial Intelligence (AAAI-96). Copyright © 1996, AAAI.
other concepts unless the subsumptionis explicitly sanctioned, e.g., COMPUTER-SYSTEM
subsumes UNIFROCESSORSYSTEM.
A description’s primitiveness is characterized by
the primitive conceptsamongits ancestors (inclusive) in the
taxonomy:
Definition 2 The primitives of concept or individual X are
the primitive concepts in the set containing X and the transitive closure of its base concepts.
For example, both primitives(COMPtrrEg-SYSTEM)and
primitives(COMPUTER-SYSTEM123)
are the set {COMFUTER-
13
Figure 3: Abstract / Concrete Conceptswith Individuals
SYSTEM, SYSTEM}.
K-PEPsupports explicit declarations that sets of primitive
concepts are mutually disjoint. Our sample terminologyhas
none for brevity, but declaring suitable disjointness conditions is crucial to sound knowledgeengineering. Moreover,
¯ it helps to guiderecognition as we shall see.
IncrementalInstantiation
To help decide if an individual’s current description may
be finished, we distinguish between concrete and abstract
concepts. A similar distinction was madein configuration
work by (Kramer 1991), but we will formally define the
notion of a finished individual. Abstract concepts represent
commonalityamonga class of concrete concepts, e.g., an
actual system’s processor may be of type 4869x-33Mt~
which is concrete (fully specific), but not merely of type
cPv, which is abstract (too general). All concepts in Figure 2 are abstract; concrete conceptsare omittedfor brevity.
Figure 3 illustrates the taxonomicrelationship amongabstract concepts (A) and concrete concepts (C); wide arrows
connect a concept to its most specific subsumer(s). Thin
dashed arrows connect individuals (I) to the most specific
concepts they instantiate. Wewill see that finished individuals must instantiate concrete concepts; before then they
can instantiate abstract and/or concrete concepts. Wewill
further characterize the abstract/concrete distinction after
introducing the helpful notion of bijective instantiation.
A bijective instantiation demonstratesthat concept C explicitly accounts for each of individual/’s primitives and
role restrictions, and that I explicitly respects all of C’s
primitives and role restrictions:
Definition 3 Individual I bijectively instantiatesconcept C
iyf
1. primitives(I) = primitives(C)
2. restricted-roles(I) -- restricted-roles(C)
3. For every role R on restricted-roles(I)
(a) at-least(Ri) > at-least(Pc)
(b) at-most(Rl) <_at-most(Pc)
(c) value-restriction(R1) =¢, value-restriction(Pc)
(d) fiIlers(Ri) D__fillers(Rc)
For example, COMPUTE~-SYSTEM123
bijectively instantiates COMPUTER-SYSTEM.
It inherits all of COMPUTERSYSTEM’S
primitives and restricted roles, and does not add
anyothers (it just adds fillers to alreadyrestricted roles).
The distinction between concrete and abstract concepts
is characterized in terms of bijective instantiation:
13
Definition 4 ConceptC is concrete iff an individual which
bijectively instantiates C might be both complete and suBciently specific for the purposesof the intendedapplication.
In configuration, 486DX-33MHZ
would be designated concrete, whereasmore general concepts such as cPUwouldbe
designatedabstract:
Definition5 A conceptis abstract iff it is not concrete.
Like the distinction betweenindividuals and concepts, the
distinction betweenconcrete and abstract concepts is clear
in principle, but can be a knowledgeengineering choice
in practice. The "possibility" alluded to in Definition 4 is
realized if the individual in question is also finished with
sufficient role fillers that are in turn finished:
Definition 6 Individual I is finished when
1, I bijectively instantiates a concrete concept, and
2. For every role R on restricted-roles(I)
(a) Ifillers(Xl)l > at-least(Ri)
(b) EveryfiIler of R1isfinished
Our languageforbids cyclic descriptions, so Definition 6 is
well-founded.
From the DLsystem’s perspective, configuration consists of describing a finished individual computersystem.
Observe that COMPUTER-SYSTEM123
is not yet finished. To
finish it, wecouldaddsuitable role fillers that are themselves
finished, e.g., an individual operatingsystem, so it instantiates a concrete subsumee of coMptrm~-sYSTEM
(as noted,
concrete concepts are not shownin Figure 2). Withrespect
to configuration, a finished individual systemis complete
and specific such that it can be ordered from the manufacturer. Of course, it maystill be updated, e.g., by adding
fillers to a role, subject to the rolCs at-mostrestriction.
A well-formedterminologyshould respect certain criteria
regarding abstract and concrete concepts. First, all leaf
concepts should be concrete. For the purposes of this paper,
all non-leaf concepts should be abstract. In configuration,
where the very goal is to describe a finished system with
finished components,etc., every concrete concept should
admita finished instantiation as in Definition 6. It mayalso
be appropriateto require that all concreteconcepts(leaves),
are mutuallydisjoint.
Assumptionsand Goals for Recognition
Our predictive concept recognition methodologywill make
two essential assumptions: CTAand a provisional assumption of monotonicupdates. Wenowdefine CTAprecisely:
In Proceedings
of the ThirteenthNationalConference
on Artificial Intelligence (AAAI-96). CopyrightO1996,AAAI.
14
Closed Terminology Consistency
Definition 7 Underthe closed terminologyassumption,it
is assumedthat no conceptswill be addedto the terminolDuringconfiguration, wewant to knowwhichconceptsare
ogy duringproblemsolving (by the application) and that
CTA-consistent
with a partially describedindividual, and
every individual will ultimately be finished accordingto
whichare not, so wecan distinguish betweenits possible
Definition6.
and impossibleconcepts. CTAis vital to our methodology:
CTA
further impliesthat all relevant roles of conceptsare
CTA
holds that an individual musteventuallybe finished in
explicitly restricted, so roles not explicitly restricted bya
accordwith Definition 6. Thus,an individual can be monoconceptare assumedto be unsatisfiable. CTAis essential
tonically updatedto instantiate conceptC underCTA
iff it
can be monotonically
updatedto bijectively instantiate an
for rulingout conceptsthat an individualcannotinstantiate,
explicitly definedconcept(perhapsCitself) whenit doesso.
and thus drawing conclusions from the remainder. CTA
Weare also concernedwith CTA-consistency
betweenconapplies onlyat the level of concepts;weneither assumethat
cepts, both in this section, to help decideCTA-consistency
the set of individualsis closed, nor do weperformclosed
of valuerestrictionson roles, andlater, to helpspeedrecogworldreasoningoverindividuals,as in (Doniniet al. 1992).
nition. WedecideCTA-consistency
via the mutuallyrecurByDefinition6, oncean individual is finished, it will
bijectively instantiate at least oneconcreteconcept.Such
sire definitions that follow. Fora pair of concepts,wemust
considertwo cases. First, a pair of conceptsare directly
¯ conceptsare referredto as ultimateconcepts:
consistent underCTAwhenever
a bijective instantiation of
Definition8 Giventhat an individual, whenfinished, will
one
can
also
instantiate
the
other.
Tocapturethis case, we
bijectively instantiate oneor moreconcreteconcepts,those
introduce
a
direct
consistency
inference
fromconceptC1to
conceptsare its ultimateconcepts.
concept C2, written C1~ C2:
Whilean ultimate conceptrestricts every property of an
Definition 13 C1~ C2iff
individual, it maydo so at an abstract level, in the same
sense that COMPUTER-SYSTEM
requires a processor, but only
1. primitives(C1) C primitives(C2)
constrainsit to be somecPv.Furthermore,
whena role of an
2. Noprimitiveof C1is disjoint fromanyprimitiveof C2
ultimateconceptdoesnot havea positiveat-least restriction,
3. restricted-roles(C1)
CC_restricted-roles(C2)
the individualmaydeclineto fill that role by specifyingan
4.
For
every
role
R
on
restricted-roles(C1), Rcl and Rc2
at-mostrestriction of zero, e.g., (at-most 0 SECONq3ARYare CTA-consistent
STORAGE)for a diskless workstation.
Wealso assume,provisionally,that an individualwill be
Intuitively, C1~-, C2demonstratesthat the primitivesand
updatedmonotonically:
role restrictions of C2admita bijective instantiation of C2
Definition9 Underthe monotonicupdateassumption,it is
whichalso instantiates C1. For example,IBM-PROCESSORDEVICE
~ COMPUTER-SYSTEM; even though neither one
assumed
that all updatesof an individualwill entail adding
baseconceptsand~oraddingrole restrictions (introducing
subsumesthe other, someindividual computersystemsmay
haveIBM-CPU
processors. Direct CTA-consistency
between
a restrictionon a role or tighteningan existingone).
concepts
can
occur
in
either
direction:
Thisassumption
is essential for conclusionsbasedon the individual’scurrentdescription.Still, if it provesunfounded, Definition 14 Concepts C1 and C2 are directly CTAwecan backout of it gracefully.
consistent iff C1~ C2or C2~ C1.
Ourfirst majorgoalfor predictiverecognitionis to track
Wemustalso define CTA-consistency
for roles:
the potential instantiationrelationshipsbetween
an individDefinition 15 Roles Rxandre are CTA-consistentiff
ual and conceptsin the terminologywhile the individual
is being specified. Givenour assumptions,a conceptcan
1. Theircardinalityrestrictions intersect
be categorizedas either necessary,optional, or impossible, 2. If at-least(Rx) > 0 or at-Ieast(Ry) > O, then valuerelative to an individual’scurrentdescription:
restriction(Rx) and value-restriction(Re) are
Definition10 ConceptC is necessarywith respect to indiconsistent
vidualI iffI instantiatesC.
3. ] fillers(Rx) U fillers(Re) < minimum(at-most(Rx),
Definition 11 ConceptC is optional with respect to indiat-most(Re))
vidualI iffI doesnot instantiateC but canbe monotonically 4. Every filler of Rx is CTA-consistent with valueupdatedto do so.
restriction(Ry), andeveryfiller of Re is CTA-consistent
Aconceptis possibleif it is either necessaryor optional.
with value-restriction(Rx)
Otherwiseit is impossible:
When
R x andR r" are CTA-consistent,
their restrictions can
Definition12 ConceptC is impossiblewith respectto indibe simultaneously
satisfied underCTA.Clearly, the procesvidual I iffI neitherinstantiatesCnor canbe monotonically sor and operating-system roles of UNIPROCESSOR-SYSTEM
updatedto do so.
and U~nX-~JSC-SYSTnM
are CTA-consistent.In addition,
both concepts inherit their primitives and their remainAnother major goal is to exploit the necesing role restrictions from a common
source, COMPUTERsary/optional/impossible
trichotomyto provideinformation
SYSTEM, SO UNIPROCESSOR-SYSTEM ~ UNIX-RISC-SYSTEM
andto derive additional constraints on an individual from
(and vice versa). Weconcludethat they are CTA-consistent.
the commonality
amongits optional concepts.
14
In Proceedingsof the ThirteenthNationalConferenceon Artificial Intelligence (AAAI-96).Copyright©1996,AAAI.
Thereis a second,indirect case of CTA-consistency
betweenconcepts.Evenif twoconceptsare not directly consistent, their consistencymaystill be explicitly sanctioned
by a third conceptconsistentwith both. This situation can
arise wheneachconcepthas a primitive or restricted role
that the other lacks. For example,mM-CPU
lacks a technology role and RISC-CPU
lacks a vendorrole. Onlyfromthe
existence of IBM-RISC-CPU
Canweconcludethat they are
CTA-consistent.
As a result, wehave:
Definition 16 ConceptsC1 and C2 are indirectly CTAconsistentiff there exists an explicitly definedconceptC3
suchthat C1~ C3,C2,---. C3,andfor everyroleR restricted
by both C1and C2, Rc~and Rc2are CTA-consistent.
Definition16 ensuresthat C1andC2are separately consistent with C3,andif restrictions on C1andC2interact, they
doso in a mutuallyconsistentway.Hence,an instanceof C3
can simultaneouslyinstantiate C1and C2. Combining
the
direct andindirect cases, CTA-consistency
identifies pairs
of conceptsthat can be instantiatedsirnultaneously:
Definition 17 ConceptsC1and C2are CTA-consistentiff
they are directly or indirectly CTA-consistent.
Thisdefinitionis justified as follows:
Theorem1 UnderCTA,the extensions of concepts C1and
C2intersect iff they are CTA-consistent.
Nowwe examineCTA-consistencybetweenan individual anda concept.Weagain distinguish betweendirect and
indirect cases. A direct consistencyinferencefromindividualI to conceptC, writtenI ~ C, essentially duplicates
Definition13:
Definition18 I ~ C iff
1. primitives(I) C primitives(C)
2. Noprimitiveof I is disjoint fromanyprimitiveof C
3. restricted-roles(I)C_restricted-roles(C)
4. For every role R on restricted-roles(I), RI and Rcare
CTA-consistent
Direct consistencyfollowsimmediately:
Definition19 IndividualI andconceptC are directly CTAconsistentiffI ~ C.
Intuitively, direct consistencyof an individualwitha concept establishesthat the individualcanbijectlvelyinstantiate
the concept,perhapsafter monotonicupdates. Consider:
(create-individual
coMPr..rrER-S~/~-r
r_M45
(and COMPIJTER-SYSTEM
(aU processorRISC-CPU)))
Although COMPU’l~R-SYSTEM45
is directly consistent
with
both
RISC-MULTIPROCESSOR-SYSTEM and DUAL-IBM-
PROCESSOR-SYSTEM,
it instantiates neither: regarding
DUAL-IBM-PROCESSOR-SYSTEM,
its processor role is neither
restricted to IBM-CPU
fillers nor a cardinalityof exactly2,
and regarding RISC-MULTIPROCESSOR-SYSTEM,
the cardinality of its processorrole is not known
to be at least 2.
In the context of a terminology,the fact that an individual is directly consistent with someconceptmayimply
consistencywith other concepts.Clearly, individual I is
indirectly CTA-consistent
with conceptC if there exists a
15
15
concept C~ such that I ~ C~ and C~ =~ C, i.e., if I can
be monotonicallyupdatedto instantiate C~ then it can be
monotonically
updatedto instantiate any conceptthat subsumesC~. For example, COMPLrIER-SYSTEM45
is directly
consistent with DUAL-IBM-PROCESSOR-SYSTEM
but not with
IBM-PROCESSOR-DEVICE. However, COMPUTER-SYSTEM45
is indirectly consistent with IBM-PROCESSOR-DEVICE
because the latter subsumesDUAL-IBM-PROCESSOR-SYSTEM.
Notall indirectly consistentconceptscan be identified via
subsumption
(but see the next section). Consider:
(create-individual
COMPUTER-SYS~67
(and COMPt,rrER-SYSTEM
(exactly 1 processor)))
Wecan not makea direct consistency inference from
COMPUTER-SYSTEM67
tO IBM-PROCESSOR-DEVICE,
e.g., because primitives(COMPUTER-SYSTEM67)
~ primitives(IBMPROCE, SSOR-DEVICE), or tO its only subsumee,DUAL-IBMPROCESSOR-SYSTEM,
becausethe cardinality restrictions on
their processorroles don’t intersect. Still, wecan monotonically update COMPUTER-SYSTEM67
tO directly instantlate
UNIPROCF_SSOR-SYSTEM
such that it also instantiates IBMPROCF_.SSOR-DEVICE,
by addingthe restriction (all processor
IBM-CPU).
Togeneralize,if individualI can potentially instantiate conceptC~ so it also instantiates conceptC, thenI
is indirectlyconsistentwithC via C~:
Definition 20 Individual I and concept C are indirectly
CTA-consistentiff there exists a concept C’ such that
I ~ C ~, C ~ C ~, andfor every role R restricted by both I
and C, RI andPc: are CTA-consistent.
Eitherdirectly or indirectly, CTA-consistency
identifies the
conceptsan individualmightinstantiate onceit is finished:
Definition21 Individual I and concept C are CTAconsistentiff they are directly or indirectly CTA-consistent.
Wesay that Ipotentially instantiates C whenthey are CTAconsistent. Thecorrectness of CTA-consistency
is established by the following:
Theorem2 UnderCTA,individual I can be monotonically
updated to instantiate concept C iff I and C are CTAconsistent.
Terminology Augmentation
Testing indirect consistencystraight from Definition 20
wouldmeanrun-timesearch for a conceptC’ throughwhich
indirection is licensed. However,
notice that whenindividual I instantiates conceptsC andCt simultaneously,it must
instantlate their conjunction.This insight will allowus to
quicklyidentify all casesof indirect consistencybytraversing explicit subsumptionlinks in the taxonomy.Wecan
augment
the terminologywith conceptsfor K-REP’S
internal
use as follows(these auxiliary conceptsare not considered
part of the domainmodel,so they do not violate CTA):
Definition 22 A terminologyis augmented
iff for all conceptsC 1 andC2suchthat C 1 ~ C2,there exists an explicitly
defined conceptC3such that C3= C1A C2.
WhenC1 subsumesor is subsumedby C2, we do nothing
becausethe subsumeeis their conjunction.As an example,
recalling that uNn’R~SOR-SYSTEM
(C1) ~ UNW-R~SCSYSTEM
(C2), wewouldaddtheir conjunction(C3), defined:
In Proceedingsof the ThirteenthNationalConference
on Artificial Intelligence (AAAI-96).Copyright© 1996,AAAI.
16
Figure4: Initial, Intermediate,andFinal Recognition
States
(and COMPUTER-SYSTEM
(the processor RISC-CPU)
(the operating-system UNIX))
After augmentation,two concepts are CTA-consistent
just
in case they have a commonsubsumee(subsumption is
reflexive). Consequently,
wecan reducethe indirect aspect
of consistencytesting to subsumption
checking:
Definition 23 Individual I is indirectly CTA-consistent
with conceptC in an augmented
terminologyiff there exists
a conceptC ’ suchthat I ~ C ’ andC’ :e~ C.
Withan augmented
terminology,Definition 23 is correct:
Theorem
3 UnderCTAand with an augmentedterminology, individualI canbe monotonically
updatedto instantiate
conceptC iffI and C are CTA-consistent
using Definition23
for indirect consistencyinsteadof Definition20.
UnderCTAand our monotonicupdate assumption,an individualis alwaysdirectly consistentwith its ultimateconcept(s), whichare concreteaccordingto Definition6. Thus,
wecan improveon Definition 22 by limiting augmentation
to cases where6"2 is a concreteconcept.Weneedonly augmenta terminologyonce, after its development
concludes
and before problemsolving begins. Thepossible drawback
of augmentationis degradedperformancedue to proliferation of system-definedconcepts. Thenumberof systemdefined concepts in an augmentedterminologyshould be
manageable
in practice, assuming
sufficiently distinct primitiveness androle restrictions among
user-definedconcepts.
Recognition via Terminology Partitioning
Givenan individualI, a KB,andour assumptions,predictive
recognitiondetermineseachconcept’sstatus, or modality,
with respect to I. Recall that conceptC is necessaryif I
instantiates C, else optionalif I can be monotonically
updated to instantiate C, else impossible.Thesedefinitions
implicitly partition the taxonomy
into regions as in Figure 4, wherenecessary, optional, and impossibleconcepts
are black, gray, and white, respectively. Sucha partition
constitutes the recognitionstate of I. Asan individualis
incrementallyupdated,wecan track its recognitionstate.
Initially, all conceptsare optionalexceptthe vacuousroot
concept,THrNo,
whichis trivially necessary.Themonotonic
updateassumptionimplies that eachupdatewill changethe
modalityof zero or moreoptional conceptsto necessaryor
impossible,so the necessaryand impossibleregions expand
as the individualis updated,further confiningthe optional
region. Finally, (at least) oneconcreteconceptandits ancestors are necessary;the remainderare impossible.(It is
straightforwardto test if an updateis nonmonotonic.
Then,
wemayneedto re-expandthe optional region. For brevity,
16
weonly elaborate here on monotonicupdates.) Our objective is to efficiently boundthe portionof the taxonomy
containingoptional concepts, therebylimiting the number
of conceptsthat mustbe directly compared
with the individual. Weexploit the terminology’ssubsumption-based
organizationin twoways.First, the current partition is
used to computethe next one. Second,the consequences
of comparingan individual with a conceptare propagated
to other concepts,so those other conceptsneednot be directiy comparedwith the individual. To these ends, we
distinguishthree sets of concepts:(1) the mostspecificnecessary concepts(MSNs),
(2) the mostgeneraloptional
cepts (MGOs),
and (3) the mostspecific optional concepts
(MSOs).Thefrontiers of the optionalregionare maintained
by the MGOs
and the MSOs.Thosesets need not be disjoint. The MSNs
serve to speed computationof the MSOs.
Initially, the MSN
set contains the root conceptTHINe,
the
MGO
set contains TmNG’S
children, and the MSO
set contains the leaf concepts.When
an individualis updated,our
algorithmoperates in three successivephasesto updatethe
MSNs,MSOs,
and MGOs,
respectively. Thefirst phasediscoversall newlynecessaryconcepts, the secondall newly
impossibleones. Thethird simplyprepares the newMGOs
for the MSN
phaseof the next roundof incrementalrecognition. Dueto limited space, readersare referred to (Weida
1996)for further details of the algorithm.Asan example,
an initial configurationdescriptionmightbe:
(create-individualCOMPUTER-SY~qhM89
(and COMPUTER-SYSTEM
(at-least 2 processor)
(at-least I secondary-storage)))
For this example,supposethat IBM-PROCESSOR-DEVICE
is
omittedfromthe terminologyof Figure2. Then,the necessary concepts are THING,SYSTEM
and COMPUTER-SYSTEM.
The optional ones are DUALPROCESSOR-SYSTEM, DUALIBM-PROCESSOR-SYSTEM,
UNIX-RISC-SYSTEM, and RISC-
MULTIPROCESSOR-SYSTEM.
The remainder are impossible.
Thisrecognitionstate is capturedas:
MSNs = {COMPS-SYSTEM}
MGOs={DUALPROCESSOR-SYSTEM,
UNIX-RISC-SYSTEM,
RIS C-MULTIPROCESSOR-SYSTEM}
MSOs = {DUAL-IBM-PROCESSOR-SY~,UNIX-RISC-SYS~,
RISC-MULTIPRO
CESSOR-SY~}
This recognitionstate indicates precisely whichconcepts
COMPUTER-SYSTEM89
might eventually instantiate. Notice that UNIPROCESSOR-SYSTEM
and DISIO.~-qS-SYSTEM
are
ruled out, as are manyother concepts,e.g., COMPANY.
If the
user nowspecifies exactly4 processors,the ensuingrecognition state will also rule out DUALPROCESSOR-SYSTEM
and
DUAL-IBM-PROCESSOR-SYSTEM:
MSNs
= {COMPtn’ER-SYSTEM}
MGOs={UNIX-RISC-SY~RISC-MULTIPROCESSOR-SYSTEM}
MSOs = {UNIX-RISC-SYSTEM,
RlSC-MULTIPROCESSOR-SYSTEM}
In Proceedingsof the ThirteenthNationalConferenceon Artificial Intelligence (AAAI-96).Copyright01996,AAAI.
Notice howthe MGOs
succinctly capture the most general choicesavailablein the current state. Auser interface
can guide the user to choose a subset of the MGOs
that
describethe desired system.
Wehave experimentedwith our partitioning algorithm
usinga smallbut realistic configurationterminology.
It was
developedby an independentgroup and engineeredfor a
configurationsystemthat uses a K-REP
KB.Theterminologyhas 501concepts, including270leaves. Althoughspace
limitations precludemuchdetail, performance
is easily fast
enoughfor interactive applications. In one experiment,
a programconductspredictive recognition while incrementally instantiatingeachleaf conceptin turn. Therecognition
algorithmspends86 percent of its time in the MSO
phase,
13 percent in the MSN
phase, and only 1 percent in theMGO
. phase. The"bushiness"of the concepttaxonomy,plus the
inherently bottom-upnature of the MSO
search, explains
whymosttime is devotedto finding MSO
concepts.
17
Open vs. Closed Terminologies
CTA
limits the conceptsthat an individual can instantiate,
perhapsafter monotonic
update,since ultimatelyit mustbijectively instantiate an explicitly definedconcreteconcept.
Thatrequirement
also imposesconstraints on an individual’s
descriptione.g., the combination
of roles it mayrestrict and
the particulars of those role restrictions. Considerthe followingindividual, whichinstantiates IBM-PdSC-CPU,
even
thoughIBM-RISC-CPU
isn’t stated as a base concept:
(create-individual
IBM-RISC-CPU86
(andCPU
(fills vendor
IBM)
(the technology
RlSC)))
UnderOTA,IBM-RISC-CPU86
is in the extension of both
IBM-CPU
and PdSC-CPO,
whetheror not mM-PdSC-CPU
is explicitly defined. Nowsupposefor the remainderof this
paragraphthat our terminologydoes not contain mM-RISCCPU.Then, under CTA,IBM-RISC-CPU86
is not allowable,
and indeedno individual cPUcan be both an IBM-CPU
anda
edSC-CPU.
(Since restricted-r01es(mM-CPU)
is neither a subset nor a supersetof restricted-roles(RISC-CPU),
nobijective
instantiation of onecan also instantiate the other. Also,
they would have no commonsubsumee.) Thus, CTArestricts the extensionsof IBM-CPU
and RISC-CPU.
In general,
a concept’sextensionunderCTA
is a subset of its extension
underOTA.Furthermore,all CTA-consistency
relationships
musthold underOTA,but the converseis not true. For example, IBM-PROC~SOR-DEVICE and UNIX-RISC-SYSTEM are
OTA-consistent.Without the presence of mM-RISC-CPU,
they wouldnot be CTA-consistent,becausetheir processor
roles wouldnot haveCTA-consistent
valuerestrictions. For
further examplesand discussion, see (Weida1996).
Finally, constraint derivationvia the LCSinferencedepends crucially on CTA.WithoutCTA,the "optional" concepts mightinclude any numberof conceptsnot explicitly
defined in the terminology.Consequently,taking the LCS
of optionalknownconceptsin order to derive constraints on
an individualwouldbe entirely unjustified.
Constraint Derivation
Wenowtake advantageof predictive recognitionto derive
additionalconstraints (primitivesand/orrole restrictions)
on an individual. Supposethe terminologyis partitioned
accordingto the current descriptionof someindividual, 1.
If I doesnot bijectively instantiate an MSN
conceptwhich
is concrete,then by CTA,I will ultimatelyinstantiate some
optional concept. Therefore, the commonalityamongMGO
conceptsconstitutesa set of implicit constraintsimposed
on
I by the closed terminology. Cohen,et al., showedhow
to computethe least common
subsumer(LCS)of a set
concepts (Cohen, Borgicla, & Hirsh 1992). LCS(MGOs)
is a conceptrepresentingjust their commonality
(we never
use the LCSconcept for any other purpose, so it is not
permanentlyinstalled in the terminology).Anyconstraint
on LCS(MGOs)
not reflected in I shouldbe addedto 1. The
basic strategyis, until arrivingat a fixedpoint, repeatedly:
1. Compute LCS(MGOs)
Related and Future Work
implies further constraints on
2. If LCS(MGOs)
Previousworkshowsthat DLis well suited to configura(a) Fold LCS(MGOs)
into/’s description,
tion problems. The BEACON
configurator based on KNET
(b) Updatethe recognitionstate of/
reached the advancedprototype stage (Searls & Norton
Sinceeachiteration of this processcan addbut neverremove
1990). In (Owsnicki-Klewe
1988), the entire configurarestrictions, it musteventuallyterminate.Thus,K-PEP
may
tion problemwascast as a matter of maintaininginternal
be able to infer constraintson I after it is first createdand
KBconsistency,i.e., logical contradictionsshouldfollow
wheneverit is updated. Similar reasoningapplies recurfromall invalid configurationsbut novalid ones. This goal
sivelyto fillers of l’s roles.
is moreambitiousthan ours or that of (Wrightet aI. 1993).
Recall COMPUTER-SYSTEM89’S
second recognition state
However,(Owsnicki-Klewe
1988) considered only "an (adin the previous section. Since the only MSNconmittedlylimited) example."PROSE
(Wrightet al. 1993)is
cept (i.e,, COMPUTER-SYSTEM)
is not concrete, COMPtn’ER- a successfullydeployedconfiguratorfeaturing productKBs
SYSTEM89
will eventuallyinstantiate at least oneMGO
conwritten in CLASSIC
(Borgida et aI. 1989). Like BEACON
cept. LCS({UNtX-~SC-SYSTEM,
P, aSC-MULTIPROCESSOI~-and PROSE,
Ourworkpositions the DLsystemas a product
SYSTEM}) ~ (and COMPIYrER-SYSTEM(all
processor mscknowledge
reasoner-- a key modulein a larger configurator
architecture, i.e., the DLsystemmaintainsinternal KBconcPu)). Hence,K-PEPdiscoversthat COMPIYIER-SYSTF_,M89’S
processors mustbe of type PdSC-CPU.
This conclusioncan
sistency duringconfigurationbut relies on configurationonly comefrom CTAreasoning. Thus, future choices respecific modulesfor further reasoning.Weshare the PROSE
gardingthe processorswill be suitably constrained.
developers’viewsthat (1) DLfosters a reasonable, even
Theprecedingwassimplifiedfor clarity; wecan often do
natural approachto productknowledge
representation, and
better. For details andfurther examples,see ONeida
1996).
(2) knowledgeengineeringefforts benefit fromenforcing
17
In Proceedingsof the Thirteenth National Conferenceon Artificial Intelligence (AAA1-96).Copyright © 1996, AAAI.
internal KBconsistency, However,no previous work has
pursued CTAreasoning in DL.
This work draws on a predictive recognition methodology for constraint networks representing rich temporal patterns, e.g., plans (Weida & Litman 1992; 1994;
Weida 1996). Our terminology partitioning algorithm
bears some resemblance to the candidate-elimination algorithm of (Mitchell 1982), howevercandidate-elimination
uses explicit negative examplesto exclude concepts, while
we derive the concepts to be excluded using CTA.Also,
candidate-elimination operates on sets of different positive
and negative examples, while we are concerned with successive descriptions of the same(positive) instance.
Someinferences described above are syntactic in nature,
thus dependent on the DL language under consideration.
.Our frameworkappears extensible for the remaining DL
operators used in PROSE
(Wright et al. 1993), amongothers. Weare not yet concernedwith disjunction and negation
operators because K-REPdoes not support them, but it is admittedly unclear howefficiently they can be incorporated in
the present framework.Importantly, CLASSIC
has achieved
great success in the configuration arena without supporting
either disjunction or negation (Wrightet al. 1993).
Weare investigating a formal semantics for CTAreasoning in DLbased on circumscription. There is an interesting analogy with Kautz’s use of circumscription to close
an event hierarchy for deductive plan recognition (Kautz
1991): Kautz’s hierarchy is composedof events related by
steps; our concept taxonomyis composedof concepts related by roles.
Conclusion
This paper presents a predictive concept recognition
methodologyfor DLwhich demonstrates, for the first time,
the value of CTAreasoning. These ideas apply to tasks
such as system configuration where all relevant concepts
are knownduring problem solving. No previous work has
differentiated betweenthe knowledgeengineering and problem solving phases of terminology usage in DL. Our configuration application led us to introducethe distinction betweenabstract and concrete concepts to DL,so we can judge
whenan individual’s description maybe finished. It also
led us to devise inferences for characterizing the completeness and specificity of incrementalinstantiation, i.e., bijectire and finished instantiation. Wetake advantage of the
closed terminologyand its subsumption-basedorganization
in several ways. As an individual system is incrementally
specified, weefficiently track the types of systemsthat may
result via CTA-consistencyinferences, which are stronger
than OTA-consistencyinferences. Weincrementally partition the terminologyby categorizing concepts as necessary,
optional, or impossible with respect to the system’scurrent
specification, based respectively on instantiation, potential
instantiation, or lack thereof. This information is inherentiy useful for both user and configuration engine. Wealso
exploit the current partition through novel use of the LCS
inference to derive constraints on the systemimplied by the
KBunder CTA.Similar reasoning applies recursively to the
system’s components.Finally, we take advantage of derived
18
18
constraints to informthe user and configuration engine, and
to appropriately guide future choices. This work is implemented in K-REP.Although we focused on configuration,
our methodologyis domain-independent.
Acknowledgements: I am extremely grateful to Diane
Litmanfor thoughtful thesis advice, Eric Maysfor valuable
insights and support, BonnieWebber,MukeshDalal, Steffen
Fohn, Brian White, and anonymousreviewers for helpful
commentson earlier drafts, and Bernhard Nebel and Werner
Nutt for useful discussions.
References
Borgida, A.; Brachman, R. J.; McGuinness, D. L.; and
Resnick, L. A. 1989. Classic: A structural data modelfor
objects. In Proc. 1989 ACMSIGMOD,58-67.
Cohen, W.; Borgida, A.; and Hirsh, H. 1992. Computing
least commonsubsumers in description logics. In Proceedings of AAA1-92, 754-760.
Donini, F.; Lenzerini, M.; Nardi, D.; Schaerf, A.; and
Nutt, W. 1992. Adding epistemic operators to concept
languages. In KR’92, 342-354.
Kautz, H.A. 1991. A formal theory of plan recognition and
its implementation.In Allen, J.; Kautz, H.; Pelavin, R.;
and Tenenberg, J., eds., Reasoning About Plans. Morgan
Kaufmann. 69-125.
Kramer, B. 1991. Knowledge-basedconfiguration of computer systems using hierarchical partial choice. In lnt.
Conf. on Toolsfor AI, 368-375.
Mays, E.; Dionne, R.; and Weida, R. 1991. K-rep system
overview. SIGARTBulletin 2(3):93-97.
Mitchell, T. M. 1982. Generalization as search. Artificial
Intelligence 18:203-226.
Owsnicki-Klewe,B. 1988. Configuration as a consistency
maintenance task. In GWA1-88,77-87.
Searls, D. B., and Norton, L.M. 1990. Logic-based
configuration with a semantic network. Journal of Logic
Programming8:53-73.
Weida, R., and Litman, D. 1992. Terminological reasoning with constraint networks and an application to plan
recognition. In KR’92,282-293.
Weida, R., and Litman, D. 1994. Subsumptionand recognition of heterogeneous constraint networks. In CAIA-94,
381-388.
Weida, R. A. 1996. Closed Terminologies and Temporal Reasoningin Description Logic for Concept and Plan
Recognition. Ph.D. Dissertation, ColumbiaUniversity.
Woods, W. A., and Schmolze, J. G. 1992. The kl-one
family. Computers and Mathematics with Applications
74(2-5).
Wright, J. R.; Weixelbaum~
E. S.; Brown,K. E.; Vesonder,
G. T.; Palmer, S. R.; Berman, J. I.; and Moore, H. H.
1993. A knowledge-basedconfigurator that supports sales,
engineering, and manufacturing at at&t network systems.
In Proceedingsof the Fifth IAAI.