RULE ACQUISITION IN KNOWLEDGE BASED SYSTEMS

Abstract: A rule-based system concerned with a domain of knowledge or operations (the domain theory) and having associated therewith a rule-based entity relationship (ER) system (the ER theory) which represents the domain theory diagrammatically is supported by a computer system. The apparatus includes means for constructing a new rule for the domain theory (in storage 19), comprising entry means (13-15) for controlling the entry into conditions storage means (16) of conditions which together represent the desired rule, and rule assembly logic (17) for generating the desired rule from those entries. The entry means comprises a display means (14) for displaying an ER diagram (Fig. 2) obtained from the ER theory (in storage 11 and 12). The operator selects, by mouse type control means (13, 15), elements of the ER diagram. These elements are thereby entered into the conditions storage means (notepad 16). Attributes are also entered, by a combination of selection from the ER diagram and semantic constraint on their values. When all elements and attributes have been so entered, they are compiled into the new rule by rule assembly logic (17) and assimilated into the domain theory by assimilator logic (18).

Description: RULE ACQUISITION IN KNOWLEDGE BASED SYSTEMS The present invention relates to rule based systems (which include expert systems, knowledge based systems and information management systems) , and more specifically to knowledge acquisition in such systems. An expert system is a data processing system which is capa of operating on some domain of knowledge. The knowledge which human experts have about the domain and the modes of reasoning which those experts employ in reasoning about the domain are captured and represented, more or less accurately, by a collect of statements or rules. The system comprises these rules together with an inference engine, so that queries which are pu to the system are processed in accordance with the rules to yie answers which are rational deductions from the rules - that is, from the incorporated knowledge of the experts. Such systems now becoming well established. Early systems were constructed by knowledge engineers who interviewed the experts and constructed the system from the information so gained. This process requires large amounts of the time of the knowledge engineers as well as the experts. There is an obvious and continuing need to improve the accessibility of such systems. The level of skill and knowled demanded of the users of such knowledge based systems has to be reduced as far as possible, so that those potential users of su systems who are expert in the relevant domain of knowledge but unskilled in information technology can use such systems withou having to undergo lengthy training (or alternatively having to call on the services of knowledge engineers to aid them) . Specifically, there is a need to provide appropriate tools to those who possess knowledge or whose job involves managing knowledge or business procedures, to enable them to codify such knowledge or procedures in a machine understandable form, i.e. rules. One approach to this problem has been the development of expert system shells. A shell is a rule based system includin an inference engine but lacking any domain specific knowledge. Instead, the shell includes a knowledge acquisition interface which guides the expert user in entering his knowledge about hi domain of knowledge. However, this approach has various drawbacks. Users fin hard to learn the complex rule syntaxes which are generally incorporated in the knowledge acquisition interfaces of such shells. Also, users need access to a *domain lexicon 1 before they start defining their knowledge, but normal shells only provide users with a rule syntax, leaving them without a start point from which they can begin to define their own knowledge. In addition to these general matters, there are certain specific matters which are at present unsatisfactory. For example, there is a particular need to be able to unify data i existing databases with rules in knowledge based systems. Th is crucial for the development of business systems. Also, th is a need to enable users to locate and read existing rules in knowledge based systems. This is a problem analogous to providing a query language for a database, only in this case w need a 'query language 1 for rules rather than data. Expert systems are an example of a wider category, that o rule based systems, and broadly the same considerations apply this wider category. An example of a knowledge based system which is not usually thought of as an expert system is a rule-based complicated accounting system. Such a system may incorporate a large number of rules, relating for example to t treatment of different customers in dependence on their regula of ordering, their promptness in paying, their geographical location, the profile of the goods they order in different categories of goods, &c. Another type of rule based system i knowedge management system, which is a database organized arou internal rules rather than containing only "pure data". Accordingly the present invention provides, in a computer system supporting a rule-based system concerned with a domain o knowledge or operations (the domain theory) and having associat therewith an entity relationship (ER) system (the ER theory) wh 5 relates to the domain theory and which can be represented diagrammatically, apparatus for constructing a new rule for the domain theory, comprising entry means for controlling the entry into conditions storage means of conditions which together represent the desired rule, and rule assembly logic for generati 1 0 the desired rule from those entries, characterized in that the entry means comprises display means for displaying an ER diagra obtained from the ER theory, and control means enabling elements of the ER diagram to be selected and related expressions to be entered into the conditions storage means (notepad) . 15 Thus the system provides a technique for the construction o new rules using interactive graphics as the main channel of communication with the user. Specifically, the system takes advantage of a family of diagrammatic conventions known collectively as the entity-relationship approach as a style of 2o diagram which is well suited as an interface for creating, viewing, modifying and managing sets of rules for knowledge base or expert systems. The approach also applies to other uses of rules, for example for describing semantic integrity constraints for databases. ? r The system preferably uses commercially standard ER type diagrams, of which there are many syntactic varieties. This improves market acceptability and compatibility with existing system analysis and design techniques. In the context of exper system shells, the present system makes syntactic aspects of rul 3 0 construction very simple and gives the user a domain specific lexicon to work with. A system analyst may be needed to set up the system initially, but he or she need generate only a skeleto of rules which can then be fleshed out by the user. 35 As a more general matter, the present system takes advantag of the close relationship between ER diagrams, relational databases and Prolog programs, and the actual implementation provides a unified model for querying and defining knowledge bases. The entity-relationship approach provides a view of d in existing databases and yet it also provides a natural way o 5 communicating with knowledge bases. Thus it offers a powerfu tool for unifying knowledge and data processing. A computer system embodying the invention will now be described, by way of example, with reference to the drawings, which: _ 0 Fig. 1 is a block diagram of the system; Fig. 2 is a typical ER diagram; Fig. 3 is a flow diagram of the first phase of the operation o the system; Figs. 4 to 8 show displays occurring at various stages of this 15 first phase; and Fig. 9 is a data flow diagram of the second phase of the opera of the system. Introductory Summary The present invention operates in a computer system havin 20 rule-based system concerned with some domain of knowledge or operations. The set of rules relating to this domain is term the domain theory. Associated with this domain theory there i Entity Relationship (ER) theory, which is capable of generatin ER diagram showing at least the entities of the domain theory 25 the binary relationships between them, and preferably also sho attributes of the entities. The invention is concerned specifically with means for generating new domain theory rules in such a system. Hithert in order to generate a new rule, the user has had to construct 30 rule in the language of the domain theory, or a higher level language which can be compiled into the domain theory language Techniques for guiding the user in such rule construction have been developed, but the construction of new rules has neverthe 35 been a relatively arduous task, demanding considerable knowled of the language from the user for success. By the invention, means are provided for constructing a ne domain theory rule graphically, the user extracting entities an relationships from the ER diagram, and the system then constructing the desired rule from the entities and relationshi so extracted. Preferably, the ER theory includes information relating to attributes of entities, these being displayed in the ER diagram and the system includes means whereby the user can select these attributes, and means for prompting the user to enter values fo these attributes, the selected attributes and their values bein stored in the notepad. Prolog The present specification assumes a basic knowledge of log 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) . As an aid in understanding the invention, however, an exceedingly brief summary of Prolog is a follows. This summary is of course far from precise; for accuracy, reference must be had to a standard text on Prolog, s as the Clocksin and Mellish book. Prolog is a declarative language designed primarily for symbolic, non-numeric computation, and a Prolog program consist of a set of fact and rule statements. There is almost nothing corresponding to the program structure of, say, Fortran. For present purposes, 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 wit an initial lower-case letter (eg John) , a variable with an ini upper-case letter (eg X or Father) . A typical simple Prolog fact statement has the form parent(john,susan) , which can be taken as meaning that John is 5 parent of susan. A query or goal has the same form as a fact statement preceded by a query symbol ?. Thus ?parent(John,Ch is a query. A Prolog system will recognize a query, identify variables in it (in this case Child, identified as a variable its initial upper-case letter) , and try to find a "solution" t 0 the implied goal of finding a constant which makes the query statement true. (In this case, the variable Child is instantiated to the constant susan.) A fact statement can h any number of arguments, and any of these can be variables; if fact statement is a query, the system tries to find constants 5 all these variables. (A goal or query can consist of a combination of statements, so that for example a variable has satisfy two or more query statements together.) More general relationships are expressed as rules, which composed of statements having the same general form as fact o statements. An example of a relationship is grandfather(X,Y) :- father(X,Z) , father(Z,Y) ; father(X,Z) , 5 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 semic indicates logical OR, so that grandfatherhood can be paternal maternal.) The system is able to utilize the rules to draw Q logical conclusions in trying to satisfy a goal or query; in o words, 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 o or more sub-queries. 5 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 recursive A recursive relationship like this must always be accompanied b an alternative non-recursive rule for the same relationship; he the first rule defines the required alternative ancestorhood relationship. (There are also further limitations which must observed if the danger of infinite regress is to be avoided.) The normal convention in Prolog is that the operator or functor of a statement is placed at the left-hand end of the statement. That is, parent(X,Y) is written rather than X is_parent_of Y. This convention will be largely maintained herein. But it is possible to define infix operators and functors; internal conversion to prefix operators and functors normally automatic, and conversion the other way can also be achieved readily. It is also straightforward to obtain representations of Prolog statements in English-like form, so t Prolog statements such as entity( el, invoice) . entity( e2, gross). entity( e4, account). relationship( rl, has, el, e2, 1:1). relationship( r3, book to, e2, e4, n:l). can be presented to a user in forms such as Relationship rl: invoice has gross Relationship r3: book gross to account which are more readily understood by users who are familiar wit the field being represented but are unfamiliar with conventiona Prolog. Prolog is primarily a declarative rather than a procedural language. The primary way to achieve something in Prolog is therefore by formulating a goal - a statement preceded by a qu symbol. The system attempts to satisfy this goal, by looking constants which can be substituted for the variables in the go In so doing, the system searches through the various stateme looking for ones which match the goal or some part of it. Th may involve replacing a variable in the goal by a statement in system, which then becomes a sub-goal. So statements can oft be regarded as declarative formulations of what, in procedural systems, would be subroutines. (The ancestor rules above are simple example of this.) The setting up of a subgoal in a Pr system is broadly similar to the calling of a subroutine in a procedural system. Although Prolog is primarily symbolic, it is possible to include numeric functions in it. In fact, some basic functio like addition of integers are normally built into the system, more complicated functions can be defined in terms of these ba functions. In the description which follows, the conventions of Prol will be used, though somewhat loosely and informally. Furthe some aspects of the invention will be described procedurally rather than declaratively. It will be realized that on the o hand, the invention can be implemented largely by means of declarative statements supported by a conventional Prolog or Prolog-like system; on the other hand, the invention can be implemented procedurally if required. Domain and ER Theories A rule-based system, such as an expert system, comprises a set of rules which are formulated explicitly, together with an inference engine for drawing conclusions from the rules in 5 response to queries. Many other types of system are capable o being cast into a similar form; for example, a complicated accounting system can have the various rules (e.g. "for account no. so-and-so, give discount of such-and-such for orders for a certain class of goods over a certain value") represented 0 explicitly, together with a processing engine which uses the ru to process transactions. With such systems, it is often desirable to include a mode which displays the entities in the domain and the relationships between them in a diagrammatic form. The term Entity 5 Relationship (ER) system will be used herein for such a diagrammatic illustration or display system. (The term ER is used here in a general sense, not limited to any specific forma definition) . The set of rules of the rule-based system has associated with it an ER model which represents the various o relationships between the entities in the domain. An ER model essentially generates a diagram in which entities are displayed elemental areas or boxes, and the relationships between them ar displayed as linking lines or arrows. A rule-based system is concerned with some particular doma 5 such as the accounting system of a particular organization, and will call the set of rules the domain theory (so that individua rules are domain theory rules) . The ER system may itself be a set of rules, the ER rules. The domain is defined by the doma theory, and the ER system represents this domain. The ER syst 0 may alternatively not be rule-based but may involve some other form of representation, and may be written in a procedural language such as C or Pascal. 5 The accuracy of the representation of the domain by the E theory is limited, for various reasons. A simple relationshi between two entities can readily be illustrated by an arrow joining the two entity boxes. But complicated logical relationships cannot easily be expressed by arrows. Differen types of arrows can be used, and linkages between arrows can b indicated by drawing "bags" round associated arrows and the bo at their ends, or by joining them by "meta-arrows"; but these techniques are complicated and rapidly become unintelligible. Also, abstract conditions (e.g. age between 21 and 65) cannot easily be diagrammed. Disregarding such complications, there is a 1-to-l correspondence between the domain theory and the ER system (or theory) . However, this is only a global correspondence, not correspondence between individual domain rules and individual rules. On the one hand, a single domain rule which defines a complicated relationship may have various parts of that relationship expressed by different ER rules; and on the other single ER rule may represent parts of several different domain rules. This distinction arises from the differing purposes o the two theories. Each domain theory rule defines a single relationship of the theory in abstract terms, where the relationship may be a complicated one involving several variab The ER theory rules are primarily organized around binary relationships between pairs of variables, and a single binary relationship may be common to several domain theory rules. T ER theory is designed, of course, so that small areas of it ca displayed; it is obviously impracticable to display the whole the ER theory at once, and if that were done, the result would unintelligible. The ER theory can itself be subdivided into two constitue theories, the ER semantics theory and the ER picture theory. typical extract of rules from the former is given in Table II below. A typical selection of rules from the latter would be somewhat as follows: Table I Typical ER Picture Theory rules rectangle( el, X, Y, w, h, ...) text( el, X, Y, colour, "invoice") line( rl, XI, Yl, X2, Y2, colour) This is an informal and simplified example, but it indicat how the actual display or plotting aspects of the ER system are handled. The ER picture theory rules control the positioning the various elements of the display on the display device. Fo present purposes, this subdivision of the ER theory can usually disregarded, and the theory thought of as primarily the ER semantics theory. The present invention will be described with reference to example set in the context of a complicated accounting system ( domain) . Fig. 2 is a diagram of the ER theory associated with this system and Table II shows the corresponding rules from the theory. (Obviously, Fig. 2 and Table II are only fragmentary. Table II Rules from ER theory corresponding to Fig. 2 pi: entity( el, invoice) . p2: entity( e2, gross). p3: entity( e3, discount). p4: entity( e4, account). p5: relationship( rl, has, el, e2, 1:1). p6: relationship( r2, has, el, e3, l:n0) . p7: relationship( r3, book_to, e2, e4, n:l). p8: relationship( r4, book_to, e3, e4, n:l). p9: attribute( al, el, date) . plO attribute( a2, el, order_type) . pll attribute( a3, e2, value) . pl2 attribute( a4, e3, value), pl3 attribute( a5, e3, type), pl4 attribute( a6, e4, number) . pl5 domain( al, date_type) . pl6 domain( a2, enum( [01, II, T2, T3])). P 17 domain( a3, numeric), pl8 domain( a4, numeric). pl9 domain( a5, enum[ typeA, typeB]). p20 domain( a6, numeric) . p21 entity_pattern( el, invoice( date(D), order_type(0) )) p22 entity_pattern( e2, gross( value(V))). p23 entity_pattern( e3, discount( value(V) , type(T))). p24 entity_pattern( e4, account( number(N) ) ) . The relationship between this set of rules and the ER dia of Fig. 2 (in which, to avoid confusion, no references have be added) is as follows. The four boxes correspond to the four entities el to e4, and the four lines joining them to the four relationships rl to r4. (The "l:n" and "n:l" in relationship rl, r3, and r4 indicate that those relationships are potential 1-to-many and many-to-1, and are indicated by the small branch on the corresponding lines. The "nO" in r2 indicates that th lower limit for the "many" is 0 rather than 1, and this is indicated by the partially broken line in the diagram of Fig. The attributes al to a6 are shown adjacent to their associat entity boxes. The ER diagram is shown with maximum information displaye the names of the entities are given in their boxes, the names the relationships are given on their lines, and the names of t attributes are all given. To some extent, the user may be gi the power to simplify the diagram by deleting some of this information, e.g. the attributes. (Alternatively, of course, system may initially display such a simplified diagram, with t user having the power to cause further information to be added that all information is eventually displayed.) It will be noted that there are properties of the system which are included in the ER theory but are not displayed as s on the ER diagram. In other words, the ER theory is not mini in the sense of containing only what is essential for generati ER diagrams. Thus there are domain rules for the attributes (these define the domain restrictions of the attributes, e.g. attribute must be a date and another must be a numeric value; these domains are of course entirely unrelated to the domain o the domain theory) . Also, there are entity patterns for the entities. The reason why these properties are included in th system is that they are needed for the construction of the rule as will be seen later. In the present system, the ER diagram shows only binary relationships between entities, and shows attributes only of entities. In principle, however, more complicated relationshi (ternary or even higher) could also be shown, and attributes of relationships as well as of entities could also be shown if desired (and provided that an adequate diagrammatic representat can be devised) . An ER theory will also normally have associated with it display control means for inspecting it. Such means in effect comprise a movable "window". The ER theory as a whole is in effect a very large diagram, and the window can be moved around different parts of the whole notional diagram. The window is logical rather than a geometrical window, in that it permits designated variables and/or relationships to be deleted from it The contents of the window can be increased by asking the disp control means to add new relationships to variables already in window. (Conventionally, if a relationship is displayed, the variables at the ends of the relationship are also diplayed automatically, so there is no need to be able to ask the displa control means to add new variables to a relationship which is already displayed.) System Structure Fig. 1 is a simplified block diagram of a computer system incorporating a domain theory, an associated ER theory (semanti theory plus picture theory) , display means, and display control means. A main memory unit 10 contains all files of the syste such files include a variety of theories, including in particu a domain theory and the associated ER theory. To inspect the theory, that theory is extracted from the files storage unit 1 and passed to an ER theory storage unit 11, and the associated picture theory is extracted from the files storage unit 10 and passed to an ER picture theory unit 12. The two units 11 and are coupled to a logic unit 13, which is in turn coupled to a display unit 14. A controls unit 15 is also coupled to the l unit 14, and consists of control elements, such as a mouse wit switches mounted on it, by means of which the user can feed control signals to the logic unit 13. The ER theory is selected by e.g. being chosen by means o conventional keyboard name entry, or by means of a conventiona mouse selection from a list of theories on the display unit 14 That selection causes the theory to be fed to unit 11, and the associated picture theory to unit 12. The logic unit 13 then automatically displays an initial portion of the ER theory on display unit 14. By means of the controls unit 15, the user select particular parts (boxes and/or relationships) , and eith erase them or call for the display of further parts associated with them. (Alternatively, the logic unit 13 may initially display parts of the ER theory in tabular (menu) form, with th user selecting a desired part, and the logic unit 13 then replacing the initial tabular display by a true ER diagram dis of the parts of the ER theory which include the initially sele element.) 5 The selection of elements by means of the controls unit 15 conventional. The logic unit 13 monitors the way the controls unit (mouse) is moved by the user and maintains a pair of co-ordinates accordingly. It generates a marker on the displ with corresponding co-ordinates, moving it around the display 1 0 match the way the mouse is moved. When control switches on t controls unit 15 (mouse) are operated, the logic unit 13 compa the mouse co-ordinates with the co-ordinates of the various pa of the display; a match (within certain small error limits) identifies the part of the display, and hence the element (box 1 relationship) selected by the user. The particular control switches operated and the state of the system determine what action is then taken, e.g. deleting the selected element from t display, displaying the attributes of the selected element, initiating a search in the ER theory for a rule with an element 2o matching the selected element, highlighting the selected elemen etc. System Operation 25 The present invention is normally used in a system in whic substantial domain theory and corresponding ER theory already exist, and provides a semi-diagrammatic way of constructing a n rule. The process is divided into two major phases: in the fi phase, the user enters into the system the various conditions o , constraints which the rule is to express; in the second, the system automatically constructs the new rule from those constraints. In the first phase, a display from the ER theory used as the source of at least some of the conditions or constraints. 35 First phase To initiate the first phase, the user must first call up t ER diagram and move the window around it until a portion resembling the new rule is located. This is then used as a source of information to build up the conditions which will for the new rule. These conditions are obtained from the ER diagr by the user selecting items graphically, to the extent that thi is possible. As will be seen, however, some non-graphical inp will also generally be required in order to build up the comple set of conditions. The present system will be explained by discussing a particular example. It is assumed that the domain is a complicated accounting system, and that the rule to be constru and added into the domain theory is discounts book to account 1296 if the discount type is one of set {typeA, typeB} and if the discount occurs on an invoice wh has the order_type T3. It will also be assumed that in the associated ER theory, the diagram shown in Fig. 2 has been located and selected as the appropriate ER diagram to use. In other words, this particul part of the ER theory most closely resembles the new rule whic to be constructed. (The test for the closest resemblance is subjective one which depends on the user's judgement.) In the first phase of generating the desired new rule, th user has to assemble together all the conditions which are together equivalent to the rule. For conditions which have a graphical representation, the user does this by selecting item from the ER diagram. As these items are selected they are ad to a notepad 16 (Fig. 1) . Fig. 3 is a flowchart for the process of building up a description of a rule on the notepad. The process is a loop which is passed round each time a fresh condition is added to notepad, going down the left-hand branch for entities and relationships and the right-hand branch for attribute conditio In the case of selecting entities or relationships from th diagram (the left-hand path in Fig. 3) , the process is straightforward. The desired rule concerns the booking of discounts to accounts, so the user can start by selecting the entities "discount" and "account" and the relationship "books_t between them. (That is, the user moves the marker (not shown) lie over the "discount" entity box by means of the mouse, and t operates a switch on the mouse to select that entity, and repea the process for the "account" entity and the "books_to" relationship.) The system automatically emphasizes the select elements on the display 14. The user can of course deselect a element if it has been selected in error. In fact, if a relationship is selected, the system prefera 5 then automatically selects the entities which it connects as we Thus the selection process can be simplified by selecting the relationship first; the entities are then automatically selecte with it. o Tne display device 14 preferably includes several display areas, one of which, 14A, is used to display the ER diagram (Fi 2) . A second area 14B is used to display the elements current being selected, and a third area 14C is used to display the totality of items so far selected. Thus at this point the sec 5 and third areas have the displays shown in Fig. 4, these both being the same. The display in area 14B matches the emphasize elements of the display in area 14A (the full ER diagram) . (F convenience, the remaining graphical elements of the ER diagram are also shown, in broken form, in Figs. 4 to 8.) 0 When the user is satisfied with the selection, he or she t presses another switch on the mouse to confirm the selection. The system then enters the selected items into the notepad 16. More precisely, as the various elements are selected, so their 5 corresponding rules in the ER theory are identified by the logi unit 13, and when the selection is confirmed, that unit copies these rules into the notepad 16. The emphasized elements on t ER diagram (Fig. 2) are automatically de-emphasized at the same time. With reference to Fig. 3, the logic unit 13 passes from th start block 30 to the read input block 31, and waits in that st until the selection is confirmed. It then checks the selected rules, block 32, to see whether any of them are attributes. I this instance none of them are, so it copies the selected rules the notepad, block 33. It then checks to see whether the assembly of conditions is finished, block 34. (This state is signalled by an input signal from the user.) In this instance the assembly of conditions is not finished, so the system retur to block 32 to await the entry of further conditions. The notepad contents are therefore as follows (the *'s indicate the conditions which have just been entered) : Notepad contents * nl: conclusion( relationship( r4, books_to, e3, e4, n:l)) * n4: entity( e3, discount) . * n5: entity( e4, account) . It will be noticed that the relationship r4 has been enter in the notepad not simply as a relationship but as a conclusion This is because in the particular example we are considering, rule to be constructed has to have a specific conclusion, as wi be seen in due course. The user has to identify which of the conditions being entered into the notepad is to be the conclusi e.g. by keying in a suitable signal on the controls unit 15. system preferably constrains the possible choice of conclusion, e.g. by permitting only relationships and not entities or attributes as possible conclusions. The conclusion is preferably distinctively identified on the display unit 14, e.g by a distinctive colour on the display 14C. The desired rule also concerns invoices having discounts. The user therefore next selects the entity "invoice" and the relationship of this entity to the entity "discount". This gi the displays shown in Fig. 5. Confirming this selection cause another pass round the left-hand side of the loop of Fig. 3. Accordingly, the display area 14B is cleared, all elements in display area 14A are de-emphasized, and the notepad contents become: Notepad contents nl: conclusion( relationship( r4, books_to, e3, e4, n:l)} * n2: relationship( r2, has, el, e3, l:n0)) * n : entity( el, invoice). n4: entity( e3, discount). n5: entity( e4, account). The two relationships required for the desired rule have n been defined, but the attribute constraints must now be entered. This process is more complicated (right-hand side of Fig. 3). The user has to specify an expression constraining or defining attribute. The present system provides an attribute constrain language which is implemented by a menu driven input sequence. This menu driven approach ensures that only syntactically valid attribute constraints can be constructed. A number of languag can be used for defining the constraints; a suitable one is giv by Table III (in which it will be realized the the vertical bar represents logical OR) . Examples of valid constraints express in this language are:- not is_in_the_set [manufacturing, sales, distribution] = 244 not >= 50000 Table III Attribute Constraint Language Con : :=0perator Value Operator::=not SimpleOperator [ SimpleOperator SimpleOperator: :=> | < | >= | <= | = | is_in_the_set Value: :=Numeric | Constant | Set Numeric: :=Numeric Numeric | 0 - 9 | Constant: :=Constant Constant | a - Z | Set : :=[ Setlte s ] Setltems::=Item | Item , Setltems Item: :=Numeric I Constant In the present example, there are three attribute constrai which have to be entered, relating to the particular account (account number) , the account type, and the invoice order type. Taking the account number first, the user selects the attribute "number" for the entity "account" on the display 14A. This results in the attribute being copied to the notepad 16 (block 3 Fig. 3) as the start of a fresh item. The menu driven input sequence is then displayed on the display device 14 (block 36) , the sequence asking for an attribute identifier to be entered. In this case, rule p20 specifies that the identifier is numeric, and this selects the appropriate part of the input sequence so that the user is prompted to enter a numeric value. (The inpu sequence rejects a non-numeric value.) When the value is entered, it is copied to the notepad to complete the item. Th the new display state is as shown in Fig. 6, and the new notepa state is Notepad contents nl: conclusion( relationship( r4, books_to, e3, e4, n:l)) n2: relationship( r2, has, el, e3, l:n0)) n3: entity( el, invoice). n4: entity( e3, discount). n5: entity( e4, account). * n6: attribute_def( a6, [=, 1296]). The user next selects the attribute "type" for the entity "discount", and the loop of Fig. 3 is repeated round the right-hand path again, with the user being prompted to enter the values "typeA" and "typeB" as the value of "is_in_the_set" attribute of the entity "discount", so that the display is as i Fig. 7 and the system state is now Notepad contents nl: conclusion( relationship( r4, books_to, e3, e4, n:l)) n2: relationshi ( r2, has, el, e3, l:n0)) n3: entity( el, invoice). n4: entity( e3, discount). n5: entity( e4, account) . n6: attribute_def( a6, [=, 1296]). * n7: attribute_def( a5, [ is_in_the_set, [typeA, typeB]]). The process is repeated once more for the attribute "order__type" of the entity "invoice", with the user selecting th attribute and entering its value "T3", so that the display is as shown by Fig. 8 and the system state is Notepad contents nl: conclusion( relationship( r4, books_to, e3, e4, n:l)) n2: relationship( r2, has, el, e3, l:nO)) n3: entity( el, invoice). 5 n4: entity( e3, discount). n5: entity( e4, account). n6: attribute_def( a6, [=, 1296]). n7: attribute_def( a5, [ is_in_the_set, [typeA, typeB]]). * n8: attribute_def( a2, [=, T3])» 10 This completes the first phase of the process. Second Phase ^ When enough information has been defined in the notepad, t second phase of the process is entered, in which the informatio is used to generate a rule. That is, the information in the notepad must be manipulated into a form which complies with the formal requirements for rules in the domain theory, and can be 2 Q assimilated into that theory. This process is a kind of compiling; the contents of the notepad define the required rul one type of language, which must be compiled into a rule in the domain theory language. _5 The main body of this process is carried out by a rule assembly logic unit 17 (Fig. 1) , which is a compiler processor. Its operation is described with reference to Fig. 9, which is a data flow diagram for rule construction. 30 The process starts at block 40, find conclusion and antecedents. This extracts the conclusions and antecedents ( remaining relationships) from the data in the notepad. In th example, these consist of clauses nl and n2 from the notepad. Thus there is a data flow F2 through the process of block 40 f the notepad contents to block 41. 35 F2 nl: conclusion( relationship( r4, books_to, e3, e4, n:l)). n2: relationship( r2, has, el, e3, l:nO) . This is followed by the process of block 41, locate entity patterns. This extracts the entity patterns corresponding to entities mentioned by the conclusion and antecedents, which arri as the data flow F2 from process 40. The process of block 41 analyses the items in the data flow F2 to determine what entity items they include; the entities are el, e3, and e4. This process therefore extracts, from the notepad 16, the items defining those entities, thus generating data flow F4. F4 n3: entity( el, invoice). n4: entity( e3, discount). n5: entity( e4, account). The process of block 41 also obtains, from the ER theory, the entity patterns corresponding to those entities, thus generating data flow Fl. Fl p21 : entity_pattern( el, invoice(date(D) , order_type(0)) ) . p23 : entity_pattern( e3, discount(value(V) , type(T))). p24 : entity_pattern( e4, account(number(N) )) . The resulting data flow from the process of block 41 is F5. F5 nl : conclusion( relationship( r4, books_to, e3, e4, n:l)). n2 : relationship( r2, has, el, e3, l:n0) . n3: entity( el, invoice). n4: entity( e3, discount). n5: entity( e4, account) . p21 : entity_pattern( el, invoice( date(D) , order_type(0) ) ) p23 : entity_pattern( e3, discount( value(V) , type(T))). p24 : entity_pattern( e4, account( number(N))). The next process is that of block 42, find attribute constraints. This process extracts the attribute constraints from the notepad. Thus this generates the data flow F3. F3 n6 : attribute_def( a6, [, 1296]). n7 : attribute_def( a5, [is_in_the_set, [typeA, typeB]]). n8 : attribute_def( a2, [=, « T3']). This is followed by the process of block 43, construct attribute subgoals. In this process, an appropriate Prolog go is created for each of the attribute constraints. Variable na are generalized and the operators in the attribute constraint language are replaced with Prolog predicates. For example, th attribute constraint language operator 'is_in_the_set* is converted to the binary Prolog predicate member(X, Y) . All of the variables generated are simply called Var here, though in an actual Prolog implementation they would all have unique names. This is unimportant, as the variables only function as placeholders until we reach the process of block 45 where variables are 'renamed' by unification. The effect of the process of block 43 is therefore to generate the data flow F7. F7 Var = 1296. member( Var, [typeA, typeB]). Var = 'T3'. The next process is that of block 44, construct rule. Th process combines the data flows F5 and F7 in the following way. First, for each conclusion or antecedent, a binary subgoal created by using the name of the relationship as the predicate symbol and by inserting the appropriate entity_pattern as each the two arguments of the predicate. For example, taking the conclusion and the two associated entity patterns from F5: nl : conclusion( relationship( r4, books_to, e3, e4, n:l ) p23 : entity_pattern( e3, discount( value(V), type(T))). p24 : entity_pattern( e4, account( number(N) ) ) . we first create the binary predicate thus: books_to( Somethingl, Something2) . and then make each of the arguments take the value provided by t entity_pattern, thus: books_to( discount( value(V), type(T)), account( number(N) ) ) . Second, a rule is then built by combining these binary subgoals with the attribute subgoals (from data flow F7) . Thes elements are combined in the following order: the conclusion binary subgoal the Prolog implication symbol ':-' the remaining binary subgoals, if any the attribute subgoals the Prolog clause terminator " . ' If there are no subgoal patterns or attribute subgoals, the following are concatenated to form the rule: the conclusion binary subgoal the Prolog implication symbol • :-' the constant 'true' the Prolog clause terminator ' . ' (The details of this process are specific to Prolog, but rules f other languages could be constructed in the same general manner, changing only the details of this process) . In the case of our example the output generated by this process is data flow F8, which is an unlinked rule. F8 books_to( discount( value(V) , type(T)), account( number(N)) has( invoice( date(D) , order_type(0)) , discount( value(V) , type(T)))), Var = 1296, member( Var, [typeA, typeB]), Var = 'T3'. The final process of phase 2 is that of block 45, rename variables, which links together the appropriate variables. Th process has two steps. First, the variables in binary subgoal are renamed. This ensures that the appropriate variables are shared between entities linked by relationships. Second, the variables in attribute goals are renamed. This connects the variables in attribute subgoals to the appropriate variables in the conclusion and other binary subgoals. Tne result of the process of block 45 in our example is th linked rule of data flow F9. F9 books_to( discount( value(V) , type(T)), account( number(N) has( invoice( date(D), order_type(0) ) , discount( value(V), type(T)))), N = 1296, member( T, [typeA, typeB]), 0 = 'T3 » . The rule assembly logic 17 also checks that the rule being assembled will be well-formed; for example, all the entities selected must be connected into a single network by the relationships selected. This condition will normally be satisfied, because it is unlikely that the user will deliberate select a combination of entities and relationships which do not satisfy this condition. The final stage of this second phase, once the linked rule has been constructed, is performed by an assimilator unit 18, F 1. The domain theory has an associated domain assimilator theory, and the assimilator unit 18 uses this domain assimilato theory to insert the new rule into the domain theory, which is held in unit 19. Similarly, the ER theory has an associated E assimilator theory, and the assimilator unit 18 uses this ER assimilator theory to insert the new rule into the ER theory, which is held in units 11 and 12. (In the example discussed, ER assimilator theory will find that the ER theory does not nee to be changed, since it already contains everything necessary t express the relationships of the new rule.) General Remarks It will be realized that the system can also be used for r deletion, i.e. for deleting a rule from the domain theory. Th process is considerably simpler than the process of creating an adding a new rule. To delete a rule, the ER diagram is displayed, and moved until the relationships relating to the undesired rule are located. These relationships are then used goals for searching the domain theory for rules which, match the These rules are displayed for inspection. It is safest if t display is textual (though the rule can of course be interprete and displayed in a form which is more readily understandable th the pure Prolog form) , but this display can be accompanied by a display of the type shown in the lower half of Fig. 8, in which substantially all the information incorporated in the rule is shown. Once the desired rule has been found, it is deleted fr the domain theory, using the domain assimilator theory. The deletion of a rule from the domain theory may result i some of the rules of the ER theory becoming superfluous. It m be desirable for the ER theory to be updated as well, so that t correspondence between the domain and ER theories is maintained. The rules in the ER theory associated with the domain theory r being deleted are known, and are therefore candidates for deletion. However, these rules must be checked against all th other rules in the domain theory, to determine whether any of th are associated with any other domain theory rules as well. An theory rule can only be deleted if there are no remaining domain theory rules associated with it. 5 Alternatively, the ER theory may be left unchanged. Although this will occasionally result in some rules remaining i the ER theory when there are no corresponding rules in the domai theory, this will not normally have any significant adverse effects. The ER theory will then serve equally well for all th 0 different historical versions of the domain theory. Also, it will be advantageous to retain those rules in the ER theory, in case a new domain rule is required in the future which incorporates the substance of such ER theory rules. 5 The system has been described above on the assumption that there is a single domain theory and a single ER theory, the two theories being co-extensive (within the limits discussed above) . However, the system can operate under a considerably weaker fo of assumption, since all that is required is that some part of o ER theory should correspond to some part of the domain theory. In particular, it may be desirable for the ER theory to extend beyond the domain theory. A specific instance has been discus above, arising out of rule deletion. A much more general situation is where there are several different domain theories, 5 concerned with distinct domains. If the subject matters of th various domains are sufficiently closely related, it may be preferable to have a single ER theory common to all the domain theories than to maintain several distinct but similar ER theories. The situation which arises when different historica 30 versions of a domain theory are all maintained, as discussed above, can be regarded as a specific example of this, since the different versions are in a strict sense different theories. effect, the ER theories corresponding to the individual domains are combined into a single broader ER theory common to all the D _D_ domains. A much more rad cal change of assumpt on can be made than that discussed in the previous paragraph. The previous discussion has been based throughout on the assumption of the primacy of the domain theory, with the ER theory being subordin 5 to it. That approach tends to restrict the understanding of t principles of the system; fuller understanding can be gained by regarding the ER theory as basic, with the domain theories bein constructed using the ER theory. In other words, the ER theory can be considered more abstractly to be a language for constructing a certain class of domain theories. As an analogy, consider a set of red toy building bricks. 5 They can be used to build a large number of different red buildings, but a a green building will never be generated as th colour green is not in the "vocabulary". The ER theory provid a similar vocabulary which constrains but does not prescribe th set of domain theories which can be built. Alternatively o consider the laws of algebra in mathematics. We can consider these laws to be equivalent to the ER theory. Various mathematical systems may be constructed on the foundation provi by these laws, corresponding to domain theories. 5 These analogies have properties which reflect on the relationship between ER and domain theories. Above all there the notion that the ER theory provides a foundation for domain theories and is prior to them. We can thus see that deleting information from a domain theory will not necessitate a Q corresponding update in the ER theory. This would correspond a change in a mathematical system causing a law of algebra to change, which is usually nonsense. Hence even if all the rule are removed from a domain theory, the corresponding ER theory w remain unaltered. 5 On the other hand, if we change some of the rules in the E theory, this may make some of the rules in the domain theory invalid. In this case we would have to be aware of the potent effects of such a change. In this situation, the computer sys should signal when a change in the ER theory necessitates a corresponding change in a domain theory.

Claims: CLAIMS l In a computer system supporting a rule-based system concern with a domain of knowledge or operations (the domain theory) and having associated therewith an entity relationship (ER) system (the ER theory) which relates to the domain theory and which can be represented diagrammatically, apparatus for constructing a ne rule for the domain theory, comprising entry means (13-15) for controlling the entry into conditions storage means (16) of conditions which together represent the desired rule, and rule assembly logic (17) for generating the desired rule from those entries, characterized in that the entry means comprises display means (14) for displaying an ER diagram (Fig. 2) obtained from t ER theory, and control means (13, 15) enabling elements of the E diagram to be selected and related expressions to be entered int the conditions storage means (notepad 16) . 2 Apparatus according to claim 1, characterized in that the E diagram (Fig. 2) shows a plurality of entities (e.g. "discount") and relationships between entities (e.g. "books_to") . 3 Apparatus according to claim 2, characterized in that the operation of the control means (15) to select a relationship fro the ER diagram also selects the entities linked by that relationship. 4 Apparatus according to either of claims 2 and 3, characterized in that the ER theory includes information relatin to attributes (e.g. "value") of its entities and/or relationship and in that the display means can display such attributes for selection. 5 Apparatus according to claim 4, characterized by a semantic constraint system (Table III) operative to constrain the entry o attribute values when an attribute is selected. 6 Apparatus according to either of claims 3 and 4, characterized in that the attribute values entered are displaye in the ER diagram. 7 Apparatus according to any previous claim, characterized i that the display means (14) is divided into a plurality of area (14A to 14C) , one of which (14A) displays the ER diagram and further one or ones of which display the entities and relationships currently selected (14B) and/or those entered int the conditions storage means (14C) .

Inventors: FREEMAN PAUL ROBERT WILLIAM, FREEMAN, PAUL, ROBERT, WILLIAM
Applicants: HEWLETT PACKARD CO, HEWLETT-PACKARD COMPANY
Application year: 1989
Main classification: G06F15
IPC codes: G06F9, G06F17, G06N5