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.