ORGANIZATION OF THEORY BASED SYSTEMS

Abstract: A theory-based system and specifically a logic programming system (knowledge based management system, KBMS) includes various theories - employment (10), genealogy (18), parts data (11), discount, and financial planning - some of which refer to each other (e.g. the discount theory refers to the parts data theory (11)). Some have special interpreters (e.g. tables theory (16) for the parts data theory (11)); some may have special assimilator theories (updaters) (e.g. (14) for theory (10)) and/or attribute theories (15). A system theory (22) contains or represents the relationships between the theories within the system, their names, interpreters and assimilators, and controls access to the other theories. Being a theory, the system theory itself can be maintained in the same way as any other, being updated to allow the creation of new theories (e.g. by updating).

Description: ORGANIZATION OF THEORY BASED SYSTEMS The present invention relates to the organization of theory-based systems and, more particularly, to the organization of a logic programming system or knowledge representation andmanagement system based on logic programming, which incorporates a provability interface to multiple modules, databases or theories. The basic terms such as theory, metatheory, assimilation and provability used in this specific follow the usage of D A Bowen and RA owalski, "Amalgamating Language and Metalanguage in Logic Programming", pages 153-182 of Logic Programming, edited by K L Clark and S-A Ternlund, Academic Press, New York, 1982 and also A Bowen and T einberg, "A meta-level Extension of Prolog", pages 48-53 of 1985 Symposium on Logic Programming, Boston, IEEE. It is to be understood that the term "theory" as used herein encompasses eguipment concepts such as logic databases, > modules and worlds (the latter term being one used by H Kauffmann and A Grumbach in "Representing and Manipulating Knowledge within 'Worlds'", at pages 61-73 of Proc First Int Conf on Expert Database Systems, edited by L Kershberg, 1986. The present specification also assumes a basic knowledge of logic programming such as that possessed by any skilled worker in the field. In particular, some knowledge of the logic programming language Prolog is assumed (for a basic text, refer to "Programming in Prolog", W. F. Clocksin and C. S. Mellish, Springer-Verlag, 1984). The basic concepts of a knowledge-base management system are also assumed (see Proc First Int Conf on Expert Database Systems, cited above) . Previous approaches to theory-based systems have used fixed, built-in schemes for defining the relationship between theory names, theories and their interpreters and assimilators. Thus in the above-mentioned paper by Bowen and Weinberg a theory's interpreter, assimilator and attributes are contained in a single metatheory with a built-in link to that theory. The main disadvantages of these previous approaches lie in the inflexibility and implicit nature of fixed, built-in links between theories and associated entities (name, interpreter, assimilator, attributes &c.) According to the present invention there is provided a computer-based logic programming system (knowledge based management system) which includes a plurality of named theories and which supports provability, characterized in that said system is arranged to utilize a further theory (the 'system' theory) to represent association relationships between the theories within the system and their names. The association relationships preferably comprise the relationships of a theory with an interpreter metatheory, an assimilator metatheory, and an attribute ethatheory therefor. Preferably the relationships are expressed within the system theory as clauses of first-order logic, or any appropriate fragment thereof, and the system theory has a declarative model that provides an explicit description of querying and updating within the system. This permits the definition of an arbitrary many-to-many relationships between theories (or other entities such as interpreters and assimilators) and their names. In.the same way, inheritance-type and other relationships between theories may be represented declaratively. The ability to query the system as a theory enables selection of particular entities (such as an interpreter) on the basis of information contained in the query. It also readily supports arbitrary levels of interpretation to be introduced in handling a query - an interpreter is found by querying the system (that is, the system theory) , and then this interpreter might be interpreted by another interpreter found by querying the system. In practice, this recursion is, of course, terminated by some built-in interpreter. Finally, by representing the system as a theory of the kind described in the above-cited Bowen & Weinberg paper, it is possible to obtain an elegant way of declaratively handling updates to the system. This is achieved because any change to any relationship in the system, including changes to named theories, requires a change to the system theory (if these changes are to be reflected in the system) . • Indeed, multiple versions of a system, can be handled by " additional references to different verions of the system, and the generality of this approach even allows these multiple versions to be referenced within any other theory (such as the current system) . This one device thus leads to the solution of many problems. DESCRIPTION OF THE PREFERRED EMBODIMENT A theory-based system embodying the invention will now be described, by way of example, with reference to the drawing, which is a diagram illustrating typical relationships between theories of various kinds. Prolog To understand the invention, a general understanding of Prolog is desirable. An exceedingly brief summary of Prolog is as follows. This summary is of course far from precise; for accuracy, reference must be had to a standard text on Prolog, such as the Clocksin and Mellish book cited above. Prolog is a declarative language designed primarily for symbolic, non-numeric computation, and a Prolog program consists of a set of fact and rule statements. There is almost nothing corresponding to the program structure of, say, Fortran. The ultimate elements of Prolog are constants. Variables also, of course, exist in Prolog, though they are "ultimately" (in the sense just used) instantiated as ("replaced by") constants. A constant is normally written with an initial lower-case letter (eg John) , a variable with an initial upper-case letter (egX or Father) . Atypical Prolog fact statement has the form parent(John,susan) , which can be taken as meaningthat John is the parent of susan. Aquery or goal has the same form as a fact statementprecededby a querysymbol ?. Thus ?parent( ohn,Child) is a query. AProlog systemwill recognise a query, identifythevariables in it (in this caseChild, identifiedas avariableby its initial upper¬ case letter) , andtryto finda "solution" to the implied goal of findinga constantwhichmakes the query statement true. (Inthis case, thevariable Child is instantiated to the constant susan) . A fact statement can have anynumber of arguments, and anyof these canbe variables; if the fact statement is a query, the system tries to find constants for all thesevariables. (A goal or query can consist of a combination of statements, so that for example avariable has to satisfy two ormore query statements together) . More general relationships are expressed as rules, which are composed of statements having the same general form as fact statements. An example of a relationship is grandfather(X,Y) :- father(X,Z) , father(Z,Y) ; father(X,Z) , mother(Z,Y) . (Here the comma indicates logical AND, so that for example father (X,Z) and father(Z,Y) must both be true, while the semicolon indicates logical OR, so that grandfatherhood can be paternal or maternal) . The system is able to utilize the rules to draw logical conclusions in trying to satisfy a goal or query; in otherwords, if it finds that the left- hand portion of a rule might satisfy a query, it is able to set up the right-hand side as one ormore sub-queries. A fundamental feature of Prolog is that rules can be recursive. A simple example is ancestor(X,Y) :- parent(X,Y) . ancestor(X,Z) :- parent(X,Y) , ancestor(Y,Z) The second rule defines the ancestorhood relationship recursively. A recursive relationship like this must always be accompanied by an alternative non-recursive rule for the same relationship; here, the first rule defines the required alternative ancestorhood relationship. (There are also further limitations which must be observed if the danger of infinite regress is to be avoided) . Diagrammatic illustration of theory relationships The figure shows a fragment of a hypothetical system containing a variety of different theories and relationships between them, (it mustbe realised that this ^ is an example of a system cast in the architecture under discussion and is not the architecture itself) . The principal forms of relationship are illustrated in this example, which gives the flavour of a relational database application. The relationships between the theories are of fourdifferent kinds; three true relationships, of a theory with its interpreter, assimilator, and attribute metatheories, and linkages between two theories. These are indicatedby the differenttypes of line indicated as I, As, At, andT respectively. The first important point to note about the example is the unifying effect of the architecture. All the data and metadata in the system is contained in theories, the aggregations of the theories being influencedby the * conceptual and structural roles of the differentpieces of data. Threetheories 10 to 12 - an employment theory 10, a parts theory 11, and a suppliers theory 12 - are together equivalent to a typicaldatabase ofprimarily factual data. The employment theory 10 is primarily a collection of facts concerningvarious people; it includes their employment details, and also various simple relationships between them (such as spouse and parent-child relationships) . The parts theory 11 is primarily a collection of facts about parts and components for a factory, andthe suppliers theory 12 is primarily a collection of facts about the suppliers of various rawmaterials for the factory. The employment theory 10 has an interpretertheory 13, an assimilator theory 14, and an attribute theory 15. The employment theory may include certain rules in addition to factual statements, so its interpreter 13 must incorporate a full theorem prover. The assimilator theory 14 is a specialised assimilator which ensures that any new data added to the employment theory does not violate any specified constraints. One type of constraint concerns the nature of the data being added; for instance, it must be consistent with a group of data, such as employee grade data, that is allowed in that theory. The allowed groups of data are defined in the attribute theory 15, which contains all the metadata about the employment theory. Thus to perform this check, the assimilator needs to reference (prove a result) in the attribute theory. This is an example of a theory-to-theory linkage. The parts theory 11 and the suppliers theory 12 are both inherently factlike and so each can have an interpreter which takes account of this and performs fact look-up instead of full theorem proving. These two theories therefore have a common interpreter 16. In the same way, they have a common assimilator 17, which ensures that no rules are added to either theory. In addition to the three fact-like theories 10 to 12, there is a genealogy theory 19, which is primarily composed of a set of rules defining complex genealogical relationships, such as ancestorhood and cousinhood, and many of which are therefore recursive. This theory has a special interpreter theory 19, which is designed to deal efficiently with recursive rules and so contain the types of inference explosion that can otherwise arise with such rules. The genealogy theory itself draws on the simple personal relationship information contained in the employment theory 10 - another, and different, example of theory-to-theory linkage. Returning to the employment theory 10, its assimilator theory 14 also takes account of a further type of constraint pertaining to the "meaning" of the data, for instance whether a new employee's relationship that is being added is consistent with the theory and with the knowledge about relationships held in the genealogy theory. This will involve the assimilator requiring results to be proved in the genealogy theory - a further example of theory-to-theory linkage. It will be noted that while some theories have other particular theories declared in the system as interpreters, there are other theories which do not. The latter theories, instead of having a special interpreter theory, are interpreted by the underlying interpreter of the system. This is a Prolog or Prolog-like interpreter which preferably-performs depth-first, left-to-right backtracking theorem-proving (although any other style of theorem- proving would be acceptable) . For a given theory, there is in fact always a chain of interpreter theories, which necessarily terminates with the built-in interpreter (not shown) ; there may or may not be one or more specific interpreter theories preceding the built-in interpreter. In the same way, every theory (including the metatheory interpreters, assimilators, and attribute theories) has an assimilator metatheory and an attribute metatheory; so, correspondingly, there are chains of assimilator theories and attribute theories, which are terminated by a built-in assimilator which merely adds or deletes any item specified, and a trivial built-in attribute theory which is the empty theory. In addition to the theories described so far, there are theories which contain information not normally treated as data in data base system. One of these theories is the log theory 20, which contains the dynamic information about the development and usage of the system over time. Another is the query interface theory 21; this can convert a standard database query language into an appropriate form for querying any of the other theories in the system. The most important of these latter theories is the system theory 22. This is the theory that details all the theories in the system, including itself, and the relationships between them (preferably holding these relationships as a set of four-term relationships each relating a theory with an attribute theory, an assimilator theory, and an interpreter theory) . There are four types of relationship that appear in the system theory: theory to theory name, and three corresponding to the relationships described above (theory name to interpreter name; theory name to assimilator name; and theory name to attribute theory name). The system"theory cannot be adequately represented in the drawing, because while it exists as a distinct theory, it also contains all the other theories and indeed itself. It should be noted that the theory-to-theory linkages described above are not relationships and are not detailed in the system theory; they are simply implemented as invocations of proofs in one theory from another. Each of these types of relationship can be a many-to-many relationship. For example, a given theory can have more than one interpreter. (If this is the case it is necessary to perform inference within the system each time this theory is invoked to determine which interpreter is appropriate at this time - probably on the basis of the goal that has to be proved) . All these relationships are dynamic. Successive versions of a system theory can have existing relationships updated and new relationships added. The relationships do not need to be specified in the system theory as facts; they can equally well be specified in rules of arbitrary complexity. The only fixed relationship is that the system theory's interpreter is the built-in interpreter. For each theory, the system theory holds a relationship statement between that theory and other theories associated with it; that is, all relationships between theories are explicitly represented in the form of a set of logical statements by the system theory. It is convenient for the relationship statement to define various distinct forms of association orrelationship, so that the types of relationship of a theory to other theories are automatically determined; in other words, there are distinct types of relationship between a theory and an interpreter theory, an assimilator theory, and an attribute theory. It will however be realised that differences between the various types of relationship are only defined by the structure of the system itself to the extent that each type of relationship has a specific place (first, second, etc) in the relationship statement. The choice of which place is used to give a relationship with an interpreter theory, which with an assimilator theory, and which with an attribute theory is arbitrary and to a large extent a matter of interpretation, though of course the choice, once made, must be the same for all theories. The manner in which the relationships between the various theories are held in the present system allows the relationships between the theories, and the population of theories, to change with time. For example, it may be desired to investigate the effects of various changes -of exchange rate. To this end, a financial theory (not shown) may be constructed which defines the manner in which discounts are determined. A series of queries may be directed to this financial theory, and these may cause the setting up of a series of distinct discount theories (not shown) , one for each possible exchange rate being considered. The system theory operates to keep track of these different discount theories, which are of course mutually inconsistent. (A simpler example is when a theory is updated; the system then includes the old theory and the new (updated) one) . The system then exists in a considerable number of distinct versions, corresponding to the different possible exchange rates being considered or to successive periods of time, and the appropriate version has to be selected for any particular query. Detailed description of the present system The above description is relatively informal, and is in terms of a particular possible combination of applications of the system. A more precise and abstract description of the system is as follows. The system can be regarded as an architecture which supports the storage, retrieval and updating of knowledge modularized into separate theories. Each theory in the system is associated with three other theories that assume roles corresponding to the methodological stance of the present system. All three are metatheories with respect to that theory, which correspondingly is an object theory with respect to those metatheories. First, there is an interpreter metatheory, which defines a provability relationship for the object theory, supporting query satisfactory as theorem proving. The interpreter controls inference within the object theory, supporting explicit, domain-specific characterizations of the object theory clauses where available. Second, there is an assimilator metatheory, which extends the logical update primitives provided by the underlying knowledge based management system to enforce syntactic and semantic constraints, on updates of the object theory. Third, there is an attribute, metatheory which expresses characteristics of the object theory clauses, such as type constraints, used by interpreters and assimilators to control inference and updating. The distinct representaion of this theory-specific metaknowlege allows interpreters and assimilators to be shared amongst several different object theories. Since interpreters and assimilators are themselves theories, they also may be associated with metatheories. However, only one or two levels of interpretation will be used in practice, for reasons of efficiency. Recursion is terminated by special built-in interpreter and assimilation theories. In this architecture, the whole knowledge base is represented by a special theory, the system theory, which is distinguished only by its role. ' This system theory describes the relationship between the name of a theory, the theory itself, and the names of its metatheories. In defining this relationship, the full power of Horn clause logic can be brought to bear. For example, a named object theory can have many interpreters and a particular interpreter may be used on many object theories. The ability to represent many-to-many relationships between theories and their metatheories allows reasoning within the system about which metatheory is appropriate for a particular task. This contrasts with the fixed associations of a static amalgamation. Since the system is itself a theory, it can easily be extended by including extra axios to define, for example, a variety of methods for retrieving named theories and choosing any metatheories required. All operations on theories, including updating, are declarative and hence free of side-effects. Every update to a named theory produces a new theory, since both are part of the system theory, a new system will also result. Hence access to all versions of all theories is potentially possible. The update model used in the present system is completely declarative. This means that any update to (addition to or subtraction from) a theory results in a new theory. Both the new version and the previous version are accessible as long as references to both still exist. This can be achieved with very little time and space overhead cost. Whenever a query is made in a named theory, that theory must be retrieved from the system. This is achieved by querying the system, by means of a predicate interface which is standard for all theories. This interface operates in the underlying knowledge based management system (KBMS) , and takes a theory name and a set of goals: kbms_prove(System,TheoryNa e,Goals) . The system theory is consulted to find the current version of the named theory and the name of its interpreter. If there is more than one interpreter for the named theory, then inference within the system is used to choose between them. The KBMS then attempts to prove that the interpreter can solve the goals. (If an interpreter is required for the interpreter, recursion occurs until the built-in interpreter is reached) . The use of interpreters specific to individual theories increases the efficiency of proving goals, since the proof techniques can be matched to the specific domains of the various theories, using appropriate syntactic and semantic constraints in inference control. The primary use of attribute theories is to allow a particular theory-dependent information to be abstracted out of interpreters and assimilators. This enables the interpreters and assimilators to be made relatively independent of particular theories, and hence to be applicable to more theories. All assimilation proceeds via a standard interface, like the standard query interface: kbms_update(System,TheoryName,Updates,NewSystem) . In a similarmannerto interpretation, eachassimilator must understand, andbe able to translate into, the representation of the theory it is updating. Anupdate is specified as a list of actions - all actions are eventually reduced to primitive declarative add and delete operations on the theorybeingupdated. The simplest form of assimilator simply carries out such additions and deletions. Amore elaborate assimilatorwill carry out some form of checking for consistency, either clause by clauseas they are added (withprovision for ignoring unavoidably inconsistent states of the theoryduring updating) or on the theory as fully updated; in either case, there is provision forbacktracking and restoration of the original state of thetheory in the event of an attempted illegal update. As with interpreter theories, the abstraction of consistency checking from a theory into an assimilatortheorymakes itmore likelythat an assimilator theorywill be applicable to more than one theory. The systemtheory in effect contains all theories, since it contains a description of all relationships between theories and any theory can be reached by means of a query directed initially to the system theory to find the required theory. An update to a theory is therefore also an update to the system, and since the system itself is a theory, a new system (or system theory) is created every time an update occurs. All previous versions of the system remain available as long as they are referenced. The system itself also has its own assimilator. A typical task for the system assimilator might be to check that when a new theory is being added to the system, all of its nominated metatheories also belong to the system. An interpreter theory may incorporate means for backtracking through a succession of theories having an inheritance relationship. One form of inheritance is merely theory selection, where a goal is proved in one member of a set of theories with an inheritance relationship. A more elaborate form of inheritance can readily be incorporated in a theory's interpreter, such that when the interpreter tries to satisfy a goal in a named theory and fails, it does not backtrack to the previous goal; instead, it queries the system to find the name of a theory from which the current theory inherits, and tries to satisfy the current goal in the ancestral theory. This elaboration allows each individual subgoal to be tried in each theory, instead of only the overall goal. Prolog formulation for system theory Since the invention is used in implementing a flexible query (provability) and assimilation (updating) interface to a logic programming system (KBMS) , the invention can be implemented by means of a Prolog program fragment implementing this facility. Such a program with statements in first-order logic thus forms a detailed embodiment of the invention. (The implementation of theories within Prolog is straightforward and not described here) . The following description is in the form of a particular predicate theory (the system theory) which relates theory names to theories to interpreter names, assimilator names and attribute names. The system theory is a 5-place- predicate theory relating a theory name TheoryName with a theory Theons, an interpretertheory name IntName, an assimilatortheory nameAssName and an attribute theory name AttrName. IntName names a theory defining a provability relation for Theory. Similarly, AssName names a theory defining an updatability relation for Theory. AttrName is the name of the theorywhich holds description information about (attributes of) Theory. The actual theories representedbythe names IntName, AssName and AttrName must be found by queryingthe systemtheory in just the sameway that the theory Theory is found given TheoryName. This generality enables arbitrary levels of interpretation to be introduced and arbitrary relationships to bedefined, the expressivitybeing limited onlybythe powerof the logic (predicate calculus) usedto represent the system. A formal definition in first-order logic of the meaning of "prove" and "update" is as follows. Clauses defining the conditions underwhichparticular associations apply are 17 represented within the system theory. The system theory is used during the first stage of query and update handling, and specified in the third (prove) and fifth (update) predicates . prove (System, systea, Goals) .- iaterpretTheary (Systea , Goals ) . prove (Systea, prolog Int, interpret σhearyWaae, Theory, Attrlaae, Goals ) r- in terpretTheory (Theory, Goals) . prove (Systea, Theorylaae, Goals ) .— prove (Systea, systea, theory σhearyWaae, Theory, IntWaae.AssWa j ue, AttrWaαe ) , prove (Syste , Intnaae,interpret (Theory Same. , Theory ttrWame, Goals ) . update (Syste , TheoryWaae, Clauses, yf Systea, We*i heory) .— prove (Syste , syste , theory (Theory Maae, Theory, In tWaae,AssWaae^A ttrWaae) ) , prove (Systea, AssWaae,assiailate (Syste , Theory . tirlaae, Clauses, WewTheαry) , pda teSysteα ( Systea , heorylaae, Theory, JewTheary,MeHSystea) . The meaning of these predicates, variables and functions is as follows: 1 ) prove ( Systea, Theory Maae, Goals) is true if the goal (or query) Goals is provable in the theory named TheσryWaαe, where the system theory Syste defines the naming relationships (i.e. which name names which theory, interpreter, assimilator, attributes) . In the case given, the clauses restrict the system's interpreter to being Prolog, 2 ) update ( Systea, Theor Waae,Clauses,WewSyεteπ,Jew Theory) is true if the clauses Clauses are added to the theory named TheαryFaαe in the system theory Systea to produce the new theory WewTheary and the new version of the system containing WewTheary, WewSystea. WewSystea is created from Systea in such a way that Theorylaae now names the_ new theory. ) IntWaae, AssMaae and Attrlaae represent the names of a theory's inter¬ preter, assimilator and attributes (see above) respectively. ) interpret ( ThearyWaae,Theσry ttrWaae,Gaals) is true if the goal Goals is provable in the theory Theory having name TheαryWaαe and an attribute theory named Attrlaae. 5) ass La Hate (Systea, TheoryWaae,Theory,AttrWaae,Clauses, WewTheary) is true if the clauses Clauses can be added to the theory Theory to yield a new theory WewTheary given AttrWaae and the system theory Systea. 6) ini-~rpretTheary(ThearyWaae,Gaals) is true if the goal Goals is provable using the Prolog proof procedure. 7) updateSysteα (Systea, ThearyWaae,Theary, WewTheary JewSystea) is true if the system theory WewSystea differs from the system theory Systea by having the theory WewTheary associated with the theory name ThearyW-ae instead of the theory OldTheory.

Claims: CLAIMS 1. A computer-based logic programming system (knowledge based management system) which includes a plurality of named theories and which supports provability, characterised in that said system is arranged to utilize a further theory (the 'system' theory) to represent association relationships between the theories within the system and their names. 2. A system according to claim 1 characterised in that the association relationships include the relationship of a theory with an interpreter metatheory therefor. 3. A system according to either previous claim characterised in that the association relationships include the relationship of a theorywith an assimilator metatheory therefor. 4. " .A system according to any previous claim characterised in that the association relationships include the relationship of a theory with an attribute metatheory therefor. 5. A system according to any previous claim characterised in that the relationships are expressed within the system theory as clauses of first-order logic, or any appropriate fragment thereof, and the system theory has a declarative model that provides an explicit description of querying and updating within the system.

Inventors: BLACK DAMIAN SEAN, MANLEY JOHN CYRIL, BLACK, DAMIAN, SEAN, MANLEY, JOHN, CYRIL
Applicants: HEWLETT PACKARD LTD, HEWLETT-PACKARD LIMITED
Application year: 1988
Main classification: G06F15
IPC codes: G06F9, G06N5