ITEMS Header

FACE HASH TABLE FACE NECK HANDS EYES Anatomical-items Frame NECK HASH TABLE EYES HASH TABLE HANDS HASH TABLE

case-base organisation search m ay commence at a localised storage point, i.e., a specified hash table. For exam ple, suppose a user wants to retrieve all syndromes th a t list the ab­ norm ality (e y e s i r i s colobom a). The associated retrieval algorithm cem im mediately confine its search to th e place in memory where the eyes objects are stored. It then only needs to exam ine the objects in th a t particular hash table (using the generic access function for the iris slot). The identifiers of m atching header objects are simply returned to the calling procedure, which can then retrieve the relevant header objects and examine the o b je c t “ty p e slot in order to select the corresponding syndromes. Thus, only two points in m em ory are accessed in this instance. The ey es hash table and the h e a d e rs hash table. The first step involves accessing every object in the component table. The final step involves retrieving the header objects specified by the list of case identifiers returned by th e first hashing procedure.

3 .4 .1 I n d e x in g in D is tr ib u te d C a se M em o ry : A n E x te n d e d E x a m p le

This section gives an example which dem onstrates the retrieval mechanism th a t is possible w ith the d istributed CBR architecture. For this example, syndrome records from the LDDB system are used. The objective here is to illustrate how this case-based structure can enable th e default task of object retrieval (which m aps onto the diagnosis task). Furtherm ore, whereas search w ith a flat database structure such as LDDB would involve checking each syndrome record, search w ithin the distributed case-based organisation is confined.

In order to proceed, however, it is necessary to elaborate on how symbolic m atching is performed in the CBR system, and how this compares w ith LDDB’s equivalent process. In LDDB, individual dysmorphic features are compared in term s of their three-level nu­ meric codes, which enables loose coupling (a m atching procedure described in C hapter 2). This work has used th e triplet notation (ite m a t t r i b u t e v a lu e ) to represent individual abnorm alities, where item , a t t r i b u t e and v a lu e are Lisp symbols [71]. Common Lisp provides a num ber of predicates designed specifically to evaluate whether or not two or more symbols m atch. These predicates are employed by the relevant u tility functions for the purpose of m atching dysmorphic features. Furtherm ore, a utility function performs an equivalent operation to the loose m a tching of LDDB. The retrieval algorithm employs this utility function, which in tu rn allows the symbolic triplet (item attribute abnorm al) to m atch any feature described by item and attribute. In other words, it allows the same

b u ild 179 te e th 335 lower lim bs 408

s ta tu re 620 voice 106 feet 519

c ra n iu m 775 neck 164 blood vessels 57 h a ir 342 back &: spine 466 endocrine 137 forehead 266 th o ra x 686 h aem ato lo g y 153

ears 665 abdo m en 426 m uscles 124

eyes 880 pelvis 124 jo in ts 248

eye stru c tu re s 514 g en italia 362 neurology 803 nose 466 u rin a ry system 317 skeletal 408 face 644 up p er lim bs 350 skin 547 m o u th 353 hands 844 g e sta tio n /d e liv e ry 0 o ra l region 505 nails 205

Table 3.1: Number of stored objects per clinical region for 1885 LDDB syndromes.

type of general m atching as LDDB, albeit w ith symbols instead of numeric codes. As well as the individual cases (which are used in experiments w ith the case-based learning program s described in the following chapters), 1885 syndrome records have been m ade available from LDDB. The form at of LDDB syndromes is the same as for cases, and each syndrome is denoted by a list of three-level numeric codes corresponding to the feature nom enclature described by Table 2.1. In order to utilise this representation, therefore, thirty-seven different object classes are defined by the d e f c l a s s construct: a header class, an anatom ical-item s class, and a class corresponding to each of the thirty- five clinical regions denoted in Table 2.1. Table 3.1 shows the distribution of objects for each of the component classes when the 1885 syndrome records are entered into the case- base. For instance, of the 1885 syndromes, 880 list at least one eyes abnormality. Thus, 880 eyes class objects are created. Accordingly, there are 1885 header and anatomical- items objects, and the corresponding (integer) identifiers run from 1 to 1885.

Figure 3.7 shows a suite of retrieval functions th a t constitute the retrieval program . The functions R e tr ie v e and S e le c t employ a list no tation for an mdex, which com­ prises those features against which syndrome or case entities are m atched. Each item in the list is a symbolic triplet of the form (ite m a t t r i b u t e v a lu e ) . The functions R e tr ie v e - O b je c ts and S e le c t- O b je c ts take one specific abnorm ality as a param eter in order to retrieve those objects of the class ite m th a t exhibit th e specific anom aly denoted

In p u t: A list o f featu re trip le ts I.

O u tp u t: A list o f m atch in g case identifiers from m em ory.

R etrieve(I)

Let 7/ be th e first featu re in th e list I. L et Ir be th e rest of th e list I.

Let J be th e set of case id ’s re tu rn ed by R etriev e-O b jects(7/ ). Let S be th e set of case id ’s re tu rn e d by S elect(J, 7r).

R e tu rn S

R etrieve-O bjects(F eature)

Let S be th e set of ceise id ’s retrieved from ta b le ite m w ith ( a t t r i b u t e v a l u e )

R e tu rn S

Select(J, I)

J := a list of object id ’s.

Let 7/ be th e first feature in th e list I. Let Ir be th e rest of th e list I. Let S be S elect(S elect-O bjects(J, I j ) , Ir).

R e tu rn S

S elect-O b jects(J, Feature) From th e list o f case id ’s J,

Let S be those for w hich th ere exists a corresponding ite m com ponent w ith ( a t t r i b u t e v a l u e ) .

R e tu rn S.

Figure 3.7: Object retrieval functions.

by the a t t r i b u t e and v a lu e (note th a t v a lu e could be the general form abnorm al). The la tte r of these two functions is passed a specific list of case identifiers so th a t it can check (or select) only these &om the relevant hash table. The S e le c t function is similar, bu t makes recursive calls in order to process the rest of the index (those features th a t comprise the index w ithout the first hsted triplet).

C hapter 2 described the mode of operation of LDDB using an example index of 07.06.03,15.01 and 32.01. The corresponding symbohc triplets produce the index:

((eyes iris coloboma) (neck general abnormal)

(neurology general abnormal))

As expected, when this index is used w ith the case-based memory, the same five syn­ dromes are retrieved as those Hsted in Table 2.3. Figure 3.8 illustrates this retrieval process. The R e tr ie v e function selects the first feature of the index, (ey es i r i s

Retrieve (((eyes iris coloboma) (neck general abnormal) (neurology general abnormal)))

Retrieve-Objects((eyes iris coloboma)^

Select(S, ((neck general abnormal) (neurology general abnormal)))

Select-Objects(S, (neck general abnormal))'

145 606 630 643 728 736 neck table eyes table 1879 1864 1796 1790 1615 1607 1572 1532 1457 1413 1357 1355 1271 12441187 1141 1118 11061097 1011 989 890 809 785 779 736 735 728 711 686 680 643 630 618 606 359 346 333 297 239 214 196 192 163 161 150 145 44 9

Select-Objects((145 606 630 643 728 736), (neurology general abnormal))

neurology table 736 HANSON [1976] 643 GARDNER [1983] 630 FUJIMOTO [1987] 606 FRANCOIS [1973] 145 BARAITSER-WINTBR

Figure 3.8: Retrieval of syndromes w ith (eyes iris coloboma), (neck general abnorm al) and (neurology general abnorm al).

colobom a), and passes this to the R e tr ie v e - O b je c ts function, which m atches the spec­ ified feature w ith each object in the eyes hash table (using the i r i s access function). In to tal, 45 of the 880 eyes objects have this zmomaly listed w ithin the iris attrib ute. The syndrome identifiers w ithin the relevant slots of these 45 objects are then passed to the S e le c t function along w ith the rem aining peirts to the index: (neck g e n e r a l abnorm al) and (n e u ro lo g y g e n e r a l a b n o rm a l). This function then makes a call to S e le c t- O b je c ts , passing the list of 45 syndrome identifiers and the first item of the re­ m ainder of th e index, (neck g e n e r a l ab n o rm al), as param eters. The S e le c t- O b je c ts function checks the neck hash table w ith respect to the 45 listed syndromes, and returns 6 identifiers corresponding to those syndromes th a t have a general neck abnormality. This list of 6 syndrome identifiers is then passed as a param eter, along w ith remaining index item (n e u ro lo g y g e n e r a l a b n o r m a lity ) , in a recursive call to the S e le c t func­ tion. This results in a search of the n e u ro lo g y hash table w ith respect to the 6 listed syndromes. Five of these have a general neurology abnorm ality, and thus, m atch the full index. This final group correspond to those syndromes listed in Table 2.3 and is shown in Figure 3.8.

3 .4 .2 D isc u ssio n

Unlike a flat database such as LDDB, the distributed case-based architecture and the re­ trieval functions shown in Figure 3.8 prom ote a confined search for m atching entities. In the above example 931 (880 -|- 45 -f 6) m atches are performed. W ith a fiat database com­ prising the 1885 syndrome records of LDDB, search would comprise 1885 comparisons. Furtherm ore, every retrieval procedure w ith a flat syndrome database would involve com­ paring the index against each syndrome record irrespective of how large (or small) the index is. W ith the distributed organisation described in this chapter, the search proce­ dure win vary according to the size of the index and the relevant storage elements th a t correspond to anatom ical components.

A distributed approach to database design is certainly not new. It would not be too difficult to design an equivalent relational m odel and utilise an associated query language to retrieve case or syndrome records However, stan dard database packages do not offer the sort of functionality th a t has been used to develop th e generic aspect of the case-

*It is interesting to note th a t LDDB is w ritten in a relational database language, but is not relational in design.

based system. In a relational database system, a new case representation, resulting in a new relational design, would also necessitate new query progrcims. Also, the case-based architecture has the additional goal of cdlowing a CBL algorithm to operate upon it, and subsequently facilitate memory reorganisation.

3.5

C ase-B ased Learning w ith D istr ib u te d M em ory

The previous sections have described two im po rtant aspects of the case-based architec­ ture:

• The case-base is a distributed organisation in which object retrieval, and hence a diagnostic search procedure, is confined w ithout the requirem ent of a category hierzirchy.

• The underlying functionality of the system is generic w ith respect to the case repre­ sentation. Thus, the calling procedures czm perform their tasks w ithout knowledge of the specific case representation.

Section 3.4.1 gave an example of the (differential) diagnostic procedure in which the calling procedure was an object retrieval program , which in tu rn retrieved syndrome identifiers. The program knew which case-base entities were syndromes rath er than cases by checking the o b je c t- ty p e slot in the header object of each record. Chapters 4, 5 and 6 describe experiments in which the calling procedure is a case-based learning program . As w ith the object retrieval program , the CBL program operates ‘on-top’ of the underlying generic case-based architecture.

It has been noted th a t case-based learning (and increm ental concept form ation) pro­ cedures rely on a hierarchical category structure. W hilst the case-based organisation de­ scribed in this chapter is distributed rath er th a n hierarchical, a hierarchical network can be constructed w ithin this architecture. This takes the form of links between the p a r e n t, c h i ld r e n and in s ta n c e s slots of header objects. T h at is to say, one case-base entity can be linked (effectively) below another (more general) case-base record by creating a link

between the respective peurent and c h i ld r e n slots of the header objects. In this way, an individual case having a particular diagnosis can be linked to the respective syndrome record via its header object. In this instance, th e case would have a link from the p a r e n t slot of its header object to the c h i ld r e n slot of the relevant syndrome header object.

The calling procedure would know which entities are cases and which are syndromes by checking the o b je c t- ty p e slot of each header. This set-up is specific to syndromes and diagnosed cases, however. In term s of a m ore general concept hierarchy (which is what is developed by the case-based learning program s described in the following chapters, and such as th a t shown in Figure 3.1), parent and children entities are not necessarily syndromes or cases. They could p ertain to general categories such as syndrome families, or undiagnosed cases. In the former example, the parent of a syndrome record would be a general syndrome family, and in the la tte r example, the parent of an undiagnosed case would be the root. To enable a general concept hierarchy to be constructed, and in order to allow a case-based learning program to generate a category network w ith the distributed architecture, two different values for the o b je c t- ty p e attrib u te of a header object are defined: NODE and ROOT. The case-based learning program s described in the following chapters do not operate in term s of syndromes as such, they work w ith a root, individual cases, and generalised cases called nodes. Definitions for these entities are given in Chapter 4. In this section, the objective is to dem onstrate how the underlying software (which is hidden from the case-based learning program ) can operate in term s of a hierarchy w ithout physicedly storing objects as hierarchical units.

Figure 3.9 illustrates how a concept hierarchy is derived through links between header objects. W hilst storage is non-hierarchical, a concept hierarchy is effectively created by generating links between header objects (N.B. linkage only involves header objects). An individual case cannot have any children or instances linked below it. A generalised case, or node, can have b o th sub-nodes (listed in its c h i ld r e n slot) and individual cases (listed in its in s ta n c e s slot) linked beneath it. Unclassified cases are linked to the in s ta n c e s slot of the root. The root node will only comprise a header object. It is effectively a null entity which is only defined for use w ith a case-based learning program (smd the associated concept hierarchy). It is im p ortan t to note th a t an individual case can be linked to more th a n one node (e.g.. Case 12, which is linked to b o th Node 2 and Node 3). The concept networks generated by the CBL program s are designed to model the actual category structure th a t exists in dysmorphology, and so it is im p ortant th a t this aspect of category linkage is provided for.

Header Hash Table ID | 1 1 TYPE ROOT parents children instances 2 3 8 9 I D | 2 1 TY PE NODE parents children instances 1 12 ID I 3 1 TY PE NODE parents children instances 1 4 12 m | 4 1 TYPE NODE parents children instances 3 7 5 6 I D | 5 1 TY PE CASE parents children instances 4 ID | 6 1 TYPE CASE parents children instances 4 I D | 7 1 TYPE NODE parents children instances 4 10 11

Header Object Linkage