Design ontology in context — a situated cognition approach to conceptual modelling

Design ontology in context — a situated cognition approach to conceptual modelling

Arti®cial Intelligence in Engineering 15 (2001) 121±136 www.elsevier.com/locate/aieng Design ontology in context Ð a situated cognition approach to ...

468KB Sizes 0 Downloads 52 Views

Arti®cial Intelligence in Engineering 15 (2001) 121±136

www.elsevier.com/locate/aieng

Design ontology in context Ð a situated cognition approach to conceptual modelling Debbie Richards a,*, Simeon J. Simoff b a

Department of Computing School of Information and Communication Sciences, Macquarie University, Sydney, NSW 2109, Australia b Department of Computer Systems, Faculty of Information Technology, University of Technology, Sydney, NSW 2007, Australia

Abstract If we take a situated view of cognition, human thought and action are inextricably connected and affected by the context. It is not just the external environment that will affect the context but that thinking itself modi®es further action and context occurs at a conceptual level that exists within a social setting. Thus, a situated view of knowledge necessitates knowledge acquisition techniques which handle change. This is particularly true of design knowledge where the design will change as more experience is gained and the changing model will itself change the perception of a design while designing. The approach described in this paper is based on the view that knowledge is always evolving and the premise that it is not easy to capture or evaluate a conceptual model. The alternative offered is based on the combined use of cases, rippledown rules (RDR), formal concept analysis (FCA) and the Activity/Space (A/S) ontology. Cases are design episodes and used to motivate the capture of rules in a simple user-driven manner. Cases ground the KBS in the real world and provide the context in which the knowledge applies. Rules are the indexes by which the cases are retrieved. Using FCA, we are able to build an abstraction hierarchy of the rules and cases. To facilitate comparison and validation we use A/S design ontology to acquire a consistently organised set of cases. This ontology provides a common structure and shared set of descriptive terms. The ease with which the knowledge is acquired and maintained using RDR, the use of a dynamic design ontology and the automatic generation of conceptual models using FCA allows for the continual evolution of the KBS in keeping with the notion that knowledge is continually evolving and `made-up' to ®t the situation. q 2001 Elsevier Science Ltd. All rights reserved. Keywords: Conceptual modelling; Design computing; Knowledge acquisition; Ontology; Ripple-down rules; Formal concept analysis; Knowledge-based design

1. Introduction Ð design knowledge acquisition as conceptual modelling The developments in distributed design environments (see Ref. [39]) increase the demand in methods for design knowledge sharing, exchange and reuse. The emphasis of knowledge engineering in design has been in the development of conceptual models that support knowledge-based design [11] and design information integration [36,38]. However, design knowledge is not easily captured, the process is time-consuming, painstaking and complicated, requiring carefully developed questioning strategies, observational procedures and analysis methods. Considering the interdisciplinary nature of the design ®eld, the `transfer of a designer's expertise' remains mainly an attractive metaphor rather than a working technology. It neither explains the nature of the design expertise, nor offers standardised * Corresponding author. Tel.: 161-2-9850-9551; fax: 161-2-9850-9567. E-mail addresses: [email protected] (D. Richards), [email protected] (S.J. Simoff).

methods for its transfer into computer data structures and reasoning algorithms. There were dif®culties for implementing this concept at every stage of the design process. 1.1. Design ontology A convenient approach to structuring design knowledge is in the form of cases [37]. From a computational point of view a design case can be viewed as a recorded memory model of design experience, which comprises previous design episodes. To be able to retrieve these episodes (cases) creatively, the memory model requires additional indexing and navigational knowledge. The adaptation and modi®cation of a selected case requires not only knowledge about the design solution, but also knowledge about the design requirements corresponding to that solution. A more elaborate model should include knowledge about the intermediate design steps and solutions, enhancing the `requirements Ð solution' models to `requirements Ð design approach Ð solution' conceptual models, where `design approach' categories capture the knowledge from

0954-1810/01/$ - see front matter q 2001 Elsevier Science Ltd. All rights reserved. PII: S 0954-181 0(01)00010-3

122

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

the intermediate design steps. The knowledge (case) base is a collection of characteristic data about each design case. Often these data are already available in existing databases or design documentation. The organisation of the data is critical to the successful use of the information during indexing and adaptation. The use of a conceptual model as a basis for a consistent organisation has been recognised as essential case based design. Thus, it seems reasonable to view knowledge acquisition in design as conceptual modelling rather than simply a transfer of knowledge and information. The advances in design computing both in physical and virtual design have increased the importance of conceptual modelling in design. Due to its nature, design both as process and as product remains a tough nut for conceptual modellers and knowledge engineers. When looking at the knowledge engineering means available to conceptual modelling in design, ontology is frequently viewed as the magic panacea. Originating in philosophy as a systematic account on the nature and the organisation of reality, ontology refers to the existence of the world. The attempt to place things into categories can be traced back to Aristotle. However, there is no ontology that is accepted as the de®nitive categorical scheme, different systems of ontology delineate different categories, which re¯ects the multiple views to the world that each of us possesses. A typical categorical scheme, a taxonomy, has a hierarchical structure with the most general entity as the top of the hierarchy. How the world that we model is divided below this indicates how the world can be understood. For example, an ontology could have the `entity' at the top level, with `concrete' and `abstract' at the next level. There is no general agreement on a speci®c ontology for categorising reality, which affects conceptual modelling. The concept of ontology entered the ®eld of arti®cial intelligence as a formal system for representing domain concepts and their related linguistic realisations by means of some basic elements. In a broad sense ontological knowledge includes various forms of encyclopaedic knowledge about the domain, the commonsense, rhetorical and metaphorical knowledge and expressions [53]. Dong and Agogino [14] exposed the variety of use of the term ontology in conceptual modelling in design, showing that the notion of design ontology spans from the works developed under the STEP initiative for product knowledge sharing and integration [36] to a concept structure for sharing ideas in design collaboration. The application of ontology as a conceptual modelling tool in design faces additional dif®culties due to the interdisciplinary, dynamic and evolutionary nature of the ®eld. Alberts [1] suggested to cope with such complexity by reducing ontology only to a taxonomy of concepts, which de®nes the semantic interpretation of the knowledge concerning a particular task or domain, in his case, engineering design. Simoff and Maher [60] showed that a design ontology can be much more than that, including constraints and interrelations among the concepts. A design ontology can serve more than one task. For instance,

an ontological description of a building design could serve as a knowledge source both for the development of a new design and as the evolving representation of a new design to the ®nal representation of the detailed design. In their framework taxonomy of concepts is only part of an ontology. In practical terms ontology relates to an elaborate schema of domain concepts and relations, including a formal lexicon or concept dictionary [25,33]. Gruber [26] calls this schema `an explicit speci®cation of a conceptualization'. Guarino [27] demonstrates that in this case ontology depends on the formal de®nition of conceptualisation. In this sense, the ontology de®nes the semantics of what is known about the world, or in terms of design, the semantics of what is known about the design domain that the ontology covers. To some extent the semantics of the conceptualisation is encapsulated in the formal structure of ontology. When de®ning an ontology as a conceptual design model, the knowledge representation formalism should be constrained in such a way that its intended models are made explicit. The goal of such an explicit description is to restrict the number of possible interpretations only to the ones speci®ed by the basic ontological categories used to describe the domain [27]. This allows the design knowledge to be shared and the development of the design solutions to be evaluated on a common ground. The capability of sharing knowledge is a key characteristic of a conceptual model in the design domain [39]. Gruber (cited in Ref. [61]) speci®es that an ontology embodies `agreements about shared conceptualizations'. Shared conceptualizations include conceptual frameworks for modelling domain knowledge, agreements about the representation of particular domain theories and knowledge communication protocols. In the knowledge-sharing context, ontologies are speci®ed in the form of de®nitions of representational vocabulary. This de®nition separates ontologies and conceptualisations. Thus, design ontology can be viewed not only as a speci®cation of a conceptualisation, but as an agreement about a conceptualisation. A characteristic of a design ontology is the notion of change, the change in design knowledge as more experience is gained, as well as the changing model or perception of a design while designing [39]. There has been a strong belief that product data modelling (PDM) could provide a framework for organising design knowledge and documentation on every stage of the design process. The mission of PDM was to standardise the handling of product information (whatever nature the product has) and to provide unambiguous transfer of such knowledge between applications software [63]. The leading international standardisation project STEP [36] has initiated a signi®cant volume of common rules, specialised grammars and shared ontologies for product modelling. However, derived from handbooks and various design documents, these models do not provide the means for self-modi®cation which can re¯ect the change and evolution in the design knowledge during the design process. Dong and Agogino [14] have pointed out, that

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

though theoretically the inclusion of a new ontology and agreements enables product modelling to accommodate changes, the practical realisation in real time seems to be dif®cult. The stumbling block is the change in `meaning' of design elements during the design, which can be detected on a conceptual level. 1.2. Conceptual modelling and situated cognition The term `conceptual modelling' suggests that we are dealing with something that is abstract and likely to be hard to extract, understand and represent and that the end result will be an approximation at best. A model can be seen as `a description and generator of behaviour patterns over time, not a mechanism equivalent to human capacity' [6, p. 89]. Further, models have been shown to vary between experts in the same domain and even over time for the same individual [19]. If we take a situated view of cognition, human thought and action are inextricably connected and affected by the context. It is not just the external environment that will affect the context but that thinking itself modi®es further action and context occurs at a conceptual level that exists within a social setting [6]. The reliability of models is further questioned if we adopt Popper's view [44] which implies the impossibility of deduction in an ultimate sense. It is no wonder that conceptual modelling is dif®cult and error-prone. After years of working with experts, researchers in knowledge engineering and design domains have recognised the importance of the situation in which the expert acts, i.e. the context in which the expert applies the knowledge [7]. Winograd and Flores [67, p. 99] argue that it is the ability to act spontaneously that makes an expert an expert. Throwness [29] refers to the common human experience of acting in response to being thrown into a situation rather than re¯ecting ®rst and then acting. Kliensuasser, as cited by [35], has a similar view of the design as a `process of commitment and response that continues until the designer's conscience is satis®ed'. In his pioneering work, Schoen [56, Chapter 3] depicts the design process as a `re¯ective conversation' between the designer and the design situation. To some extent this can be interpreted as a recursive throwness into new situation, where the context can be de®ned as the current state of the design representation. Gero [23] and Gero and Fujii [24] recognise the in¯uence of situation both on the design process and design knowledge modelling. On the other hand, current conceptual modelling approaches in design rely on the development of a good model as a prerequisite to the capture of knowledge or data. They implicitly assume that it is in fact possible to acquire and validate `good' conceptual models. This group of work in conceptual modelling in design includes the ones that introduced the Activity/Space (A/S) ontology [38,69]. Simoff and Maher [59] proposed that design ontology could be viewed as a dynamic approximation of design domain knowledge. Such an

123

approximation has the potential to accommodate changes in meaning during the evolution of a design idea and maintain these changes at the conceptual level and levels of the data model and data structures. The presented A/S ontology considered both the representation and links between requirements and solution, and the intrinsic changing nature of design knowledge. Since conceptual models are dif®cult to capture, especially in design, an approach based on situated cognition may be preferable to one that requires a design expert to articulate their thought processes. An alternative approach is described in this paper which is based on a situated view of cognition and the premise that it is not easy to capture or evaluate a conceptual model. The approach offered combines the use of design cases, the A/S ontology [58,59] ripple-down rules (RDR) [8] and formal concept analysis (FCA) [65,66]. A/S ontology provides the framework and the high-level semantics for the knowledge acquisition process. Cases are design episodes, used to motivate the capture of rules in a simple user-driven manner. RDR is used as the knowledge acquisition (KA) and representation technique. The propositional rules are then interpreted as a binary formal context and a complete lattice is automatically generated using FCA. Cases are design episodes and used to motivate the capture of rules in a simple user-driven manner. Cases ground the KBS in the real world and provide the context in which the knowledge applies. Rules are the indexes by which the cases are retrieved. Using FCA, we are able to build an abstraction hierarchy of the rules and cases. To facilitate comparison and validation we use the A/S design ontology to acquire a consistently organised set of cases. This ontology provides a common structure and shared set of descriptive terms. The ease with which the knowledge is acquired and maintained using RDR, the use of a dynamic design ontology and the automatic generation of conceptual models using FCA allows for the continual evolution of the KBS in keeping with the notion that knowledge is continually evolving and made-up to ®t the situation. We start with presenting the underlying theoretical background for the combined approach, namely the RDR and FCA methodologies, and the A/S design ontology. Further we look at a case study which describes how RDR and FCA are used to develop and compare conceptual models under the framework of the A/S design ontology. Further we provide some overview of similar methodologies and conclude with consideration of the role of retrospective conceptual modelling. 2. Theoretical background of the `design ontology in context' approach This section introduces the three corner stones of the design ontology in context approach: RDR, FCA and A/S design ontology, in the context of their joint application. As

124

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

these theories have been published elsewhere only a brief description of each will be given here. The interested reader is invited to explore some of the references provided for a more detailed description. 2.1. An introduction to ripple down rules RDR were developed to address many of the issues raised by situated cognition [50]. One issue is the need to support ongoing maintenance which is based on the view that knowledge is never complete. Another issue is the need to provide the context in which the knowledge applies. This is done through the use and storage of cases. Another issue is the need to give the user control and provide direct interaction with the system. An awareness of the imperfections of models and acceptance that we as yet do not understand how an expert thinks has resulted in an approach that focuses more on the behaviour of the expert as they interact with a case. It was observed that experts are competent at assigning a conclusion to a case or scenario. When asked to explain that conclusion they tended to offer a justi®cation which differed according to the case and the audience [9]. Single-classi®cation RDR were developed ®rst and can be de®ned as a triple krule,X,Nl [54] where X are the exception rules and N are the if-not rules. When a rule is satis®ed the exception rules are evaluated and none of the lower rules are tested. The major success for this approach has been the Pathology Expert Interpretative Reporting System (PEIRS) [17], a large medical expert system for pathology laboratory report interpretation built by domain experts with minimal intervention of a knowledge engineer. PEIRS is one of the few medical ES that have actually gone into routine use. It went into operation with 198 rules and expanded over four years to over 2000 rules, covering 12 different pathology tests. A total of approximately 100 h were spent on KA. The development of 10 rules per hour for RDR is outstanding compared to industry standards of only 2 or 3 rules per day [16]. Multiple classi®cation RDR (MCRDR) have more recently been developed to handle classi®cation tasks where multiple independent classi®cations are required [31]. This method builds n-ary trees and consists only of exception branches. A better description may be sets of

decision lists joined by exceptions. In contrast to single classi®cation RDR all rules attached to true parents are evaluated against the data. Fig. 1 shows an example MCRDR concerned with designing a building to house a computing department. Two levels of decision lists are shown. The label `Corners' in the diagram refers to the cases associated with that rule and will be discussed further on. An MCRDR is de®ned as the quadruple krule,P,C,Sl, where P is the parent rule, C are the children/exception rules and S are the sibling rules within the same level of decision list. Every rule in the ®rst list is evaluated. If a rule evaluates to false then no further lists attached to that rule are examined. If a rule evaluates to true all rules in the next list are tested. The list of every true rule is processed in this way. The last true rule on each path constitutes the conclusions given. In rule 3 in Fig. 1, for a case where an individual shares the same role as someone else the person will need a large room to share. However, if the person is a Head of Large Project, then they will not share a room but will have a small room on their own. They will also need an airconditioned room if they will be using a computer. KA using RDR involves the expert being shown a case with a system assigned conclusion. If the expert agrees with the conclusion they continue to the next case. If they do not agree they assign a different conclusion and pick some features of the case which form the rule conditions. The features are attribute value pairs. The case that prompts a new rule to be added becomes stored in association with the new rule and is known as the cornerstone case. When a new rule is added, the cornerstone case of the rule that gave the misclassi®cation is shown to the user and they must pick some features which distinguish the two cases. Rules are never deleted or changed. Each new rule is a modi®cation of a previous rule. This may appear inef®cient, but studies have shown the exception structure representation to be at least as compact as KBS built using the machine learning algorithms C4.5 and Induct [9,10,40]. In single classi®cation RDR only one case is associated with each rule. In MCRDR, there may be multiple cases that must be distinguished from the current case. In the KA approach developed [30], the expert is presented with one cornerstone case at a time. The expert constructs a rule to distinguish the new case from the ®rst case presented and

Fig. 1. A simpli®ed MCRDR KBS for designing a building for a computing department.

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

then each case in the cornerstone list is evaluated to see if it is also distinguished by the new rule. If a case is satis®ed by the rule the expert must add extra conditions to the rule to distinguish this case. This continues until all related cornerstone cases are distinguished. Remarkably the expert provides a suf®ciently precise rule after two or three cases have been seen [31]. The decision of where to add a new rule to the KB is affected by the design of the user interface, user preferences and the situation. If rules tend to be added to the top level the domain will be covered more rapidly but there may be greater errors. If rules are added to the end of pathways less cases will be seen so there will be less errors but slower domain coverage [30]. New cases may be misclassi®ed in one of three ways: one or more of the conclusions are incorrect, one or more conclusions are missing or a combination of incorrect and missing conclusions. The user may decide to stop an incorrect conclusion instead of replacing it with a new conclusion. This is achieved by adding a rule which has a null conclusion in the same way as adding other types of rules. RDR has been typically used for classi®cation tasks. Exceptions include con®guring an ion chromatographer [45], room allocation [52] capturing search knowledge [4] and capture of control knowledge for ¯ight simulation [57]. Construction tasks, which include design problems, are more dif®cult than classi®cation. This is because in addition to parameters (attributes) and values we also need to take into consideration constraints, requirements, preferences and global cost function. To ®nd a solution each parameter must have a value, no constraints can be violated and all appropriate requirements must be satis®ed. Inferencing is also more complex as the inferencing cycle must be repeated a number of times until a solution can be found. This is because the outputs of one cycle will be the inputs of the next cycle until a solution is found [45]. This means that many intermediate rules (rules whose conditions are the conclusions of other rules) are necessary in a KB for a construction task. In classi®cation RDR intermediate rules are rare. As we see in Section 3.2 for our design problem, RDR is used to acquire rules which describe which singular activities must be combined to create composite activities. Despite the nature of the task KA is similar in all the variations and implementations of RDR. The ease with which KA and maintenance (these are one and the same in RDR) are performed by the domain expert is a major strength of RDR and the reason why it was chosen as the method of acquiring the initial model. However, the RDR model only provided a low-level view of the knowledge. This led to the addition of techniques from FCA. 2.2. An introduction to formal concept analysis FCA draws on ideas from lattice and order theory [65,66]. A concept in FCA is comprised of a set of objects and the set of attributes associated with those objects. Knowledge is seen as applying in a context and can be represented as a

125

crosstable and de®ned as a formal context. A formal context is a triple …G; M; I† where G (for Gegenstande in German) is the set of objects which forms the extension of the concept, M (for Merkmale in German) is the set of attributes which forms the intension of the concept and I is a binary relation connecting G and M. In the crosstable shown below, the rows are objects and the columns are attributes. An X indicates that a particular object has the corresponding attribute. Using the notion of a galois connection, formal concepts are found by determining the set of attributes shared by a set of objects or conversely the set of objects which share a set of attributes. More formally, the derivation operators: X # G : X 7 ! X 0 :ˆ {m [ Mug Im for all g [ X}

…1†

Y # M : Y 7 ! Y 0 :ˆ {g [ Gug Im for all m [ Y}

…2†

are used to construct all formal concepts of a formal context, by ®nding the pairs (X 00 ,X 0 ) and (Y 0 ,Y 00 ). We can obtain all extents X 0 by determining all row-intents {g} 0 with g [ G and then ®nding all their intersections. Alternatively Y 0 can be obtained by determining all column-extents {m} 0 with m [ M and then ®nding all their intersection. This is speci®ed as: \ X0 ˆ {g} 0 …3† g[X

Y0 ˆ

\

{m} 0

…4†

m[Y

Having found the set of formal concepts we can order these using the subsumption relation $ on the set of all concepts formed such that …X1 ; Y1 † # …X2 ; Y2 † iff X1 # X2 . By ®nding the predecessors and successors of each concept we can produce a visualisation of the concepts as a complete lattice. For a family …Xi ; Yi † of formal concepts of K the greatest subconcept, the join, and the smallest superconcept, the meet, are respectively given by: ! ! [ \ 00 _ …Xi ; Bi † :ˆ …5† A i ; Bi

i[I

^ …Xi ; Bi † :ˆ

i[I

i[I

\ i[I

Ai ;

i[I

[ i[I

! ! Bi

00

…6†

RDR and FCA share a number of views including the beliefs that knowledge applies in a context and that KA is a task that is best performed directly by experts. In both approaches KA is reduced to the task of classifying objects (cases) and the identi®cation of the salient features. In FCA, KA begins with the elicitation of a crosstable from which the concepts derived can be used to generate implications. The implications generated are shown to the user who is asked to say whether they agree or disagree with the implication. If the user does not agree they are asked to offer a counterexample. This study starts from the opposite direction by using the rules in the MCRDR KBS as the input into a formal context. The

126

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

² knowledge that allows linking design requirements to the design solution.

Building Design Space

Activity

Fig. 2. A/S design ontology (adapted from Ref. [58]).

reason for this is twofold. Firstly, the purpose of using FCA was to uncover higher models in rules that had already been acquired using MCRDR. Secondly, it was felt that the RDR approach to KA was probably less demanding for experts than the development of crosstables, the analysis of the generated implications and the offering of counterexamples, which is required by the FCA approach to KA. The combined approach [49] draws on the strengths of both approaches. That is we get the bene®t of easy KA and maintenance in an executable system from RDR with the more structured and deeper model provided by FCA. 2.3. An introduction to Activity/Space design ontology The A/S design ontology began as a conceptual model for information integration in building design [38]. Later, Simoff and Maher [58] expanded the model to design ontology. The Activity/Space design ontology was de®ned as a multi-level representation for formalisation of design knowledge, including: ² knowledge that constitutes the description of building design requirements; ² knowledge that constitutes the description of the building design;

The A/S ontology delineates the categories of building design knowledge as `activity' and `space', as shown in Fig. 2. The A/S ontology speci®cally focuses on architectural design, the design of space, bounded by physical objects, in contrast to other types of design, such as the design of engines or computer chips where the solid parts of the design are the focus. The concept of activity is related to the functionality of the design, or the activities that can take place in a given space. This knowledge model addresses the need to represent requirements corresponding to both the functionality of the spaces in the building and the geometric or physical description of the building. It makes explicit the representation of activities, spaces, and their relationships. Below we consider the basic categories of A/S design ontology: activity and space, expanded in Fig. 3. 2.3.1. Activity Activity is de®ned as a purposeful action, whose performance requires a particular amount of space, time and an object that performs this activity, as shown in Fig. 3a. Spatial need, time and performer are the notions of activity ontology which are always relevant, e.g. there is no activity which can be de®ned without spatial and time requirements, and without the object that performs this activity. The other notions of activity ontology are relevant in a particular design context or design stage. The spatial need is de®ned by a relationship between activity and space, as discussed in the next section. Equipment. Equipment is the knowledge container for the description of the instrumentation and furniture, necessary for activity realisation. Ontologies for description of instrumentation used by an activity consist of the characteristics

(a)

Activity

Equipment

Service

Time

Performer

Consumer

Constraints

(b)

Space

Geometry

Divider

Link

Constraints

Fig. 3. Extended view of A/S ontology (based on Ref. [58]): (a) activity part; (b) space part.

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

that are relevant to performed activity, including occupied space (becomes part of the space required by the activity), consumed energy, materials, used for activity realisation, relations with the environment. Product models, for instance, Engineering Data Model [15] and COMBINE Integrated Data Model [2], are sources of equipment ontologies. These ontologies contain also information about the spatial needs for the equipment. Service. Service knowledge container holds the descriptions of different services and environmental resources, which support activity performance. This includes heating, ventilating, lighting, water tempering. In some sense services can be interpreted as supplementary activities. Time. Time is a quantitative category represented by an interval value, which corresponds to a time period. We use the time category to be able to present the necessary knowledge to arrange activities with respect to the time coordinate. For consistency, we call this interval a time envelope. Performer and Consumer. The performer category denotes the object that carries out the activity. The consumer category denotes the object over which activity is executed. In the design of a building, performer and consumer could be a person, organisation, department, or other subdivision. In some cases performer and consumer can coincide. The evaluation of spatial needs for performer and consumer is closely related with the issues of the comfortable ergonomic ®t of the human body within the designed spaces because activities usually are performed by humans. Though most of the applications of human factors engineering have been in the industrial and military sectors, over the last decades concern for human dimensions and body size, as vital factors in the building design process, has steadily increased. Particular results of these efforts are the anthropometrically oriented design reference standards [12,42], structured to ensure a proper ergo®tting of people to the interior environments. Authors of these publications separate designed space into zones: activity zone as the space where activity is performed, circulation zone as the space where the circulation activity is performed, etc. Pheasant [43] presents an extensive analysis of anthropometric data in the context of its applicability in buildings design. These standards are a potential knowledge source for de®ning performer/consumer component of activity spatial needs. Constraints. The constraints category contains knowledge about the requirements of the activity towards other activities. Such knowledge is expressed through subcategories like degree of privacy, interference of one activity with another, and interdependence between two activities. This speci®es the knowledge necessary for the preliminary analysis of activity layout. 2.3.2. Space The spatial needs of an activity are de®ned by the spatial needs of the action itself and activity con®guration. The

127

Fig. 4. Spatial needs of activity `searching for a book' Ref. [58].

knowledge categories are illustrated in Fig. 3b. In general, the spatial need could have a very complicated form. Initially, spatial needs of an activity are formulated in a rather vague form, usually without any metric in it. For instance, an activity can be performed in an open space or within a facility or a building. The example in Fig. 4 illustrates the notion of spatial need for the activity `searching for a book' in the context (situation) of the arrangements in a physical library. The spatial need of this activity is de®ned by the spatial needs of: ² performer, who needs to be able to access every level of the bookshelf; ² equipment, in this case the bookshelf. In this sense, building reusable containers of activity con®guration knowledge could be a useful source for the evaluation of the spatial needs. Spatial needs are the bridge between the activities and spaces in the A/S ontology. A region of space is de®ned as the coalescence of all activity components, necessary to perform that activity. This general de®nition is suitable for handling many types of spaces because it neither distinguishes between open and closed regions, nor considers the mathematical notions of point, line or surface. Maher et al. [38] introduced the notion of spatial envelope to refer to the geometric description of the space. Spatial envelope s is a three dimensional hypothetically bounded region of space that enables the realisation of activity a. The spatial envelope approximates and visualises the spatial need of the activity. Thus every spatial envelope s belongs to the three dimensional space R 3. The spatial envelope is the ®rst step towards the building

128

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

of the space. Replacing activity by a spatial envelope means introducing explicit geometry and metric. Geometry. In the context of spaces, geometry is the category of knowledge that identi®es conventions for representing 2D or 3D space. The description can be based on the combination of geometrical primitives and the values of their parameters, e.g. length, width, radius of curvature. These geometric primitives correspond to the spatial envelopes of respective activities. Divider. Dividers are the real physical bounds of the space. Adding the appropriate dividers transfers a spatial envelope into a physical room, level or building, which encompasses these activities. Dividers inherit the characteristics of the materials used to implement them. Brick walls, concrete slabs, glass separators are examples of dividers. Link. Including dividers in our ontology means that we need to include a link category, which describes the connections between separated spaces, the accessibility and suitability of different spaces within the designed facility. Knowledge about the links implies the necessity to represent the path to each space. Doors, windows, stairways are example of links. Constraints. Like the category for activity, the knowledge associated with a space includes constraints. These constraints can express the rules imposed by building codes for maximum and minimum sizes of different types of space, or constraints speci®c to a particular design ®rm re¯ecting their own speci®cations of the type of buildings they design.

overlap in this case is represented as POab : Oab^ : Oab^ : Oba

…8†

…7†

Kernel relations can produce sets of specialised relations, which serve particular design tasks. We illustrate this idea in Fig. 5. If we consider the overlap relation between two entities in more details, e.g. introducing a one-dimensional topological knowledge about size and mutual positions, then we derive 12 mutual exclusive relations 1 Ð all relations in Fig. 5 except (E), which corresponds to the notion of proper overlap. The practical use of these relations requires the inclusion of the operation of intersection and composition of these relations. In Fig. 5a these relations are interpreted in the context of one of the dimensions of spatial envelopes. (See Ref. [34] for a set of relations, which take in account more spatial dimensions.) In Fig. 5b they are interpreted in the context of time envelopes. In the case of temporal analysis of activities, the A/S ontology includes metric constraints in addition to the temporal relations shown in Fig. 5b. These constraints allow the representation of quantitative relations among time intervals. For two time points a and b, the metric constraint is expressed as …a 2 b† [ {I1 ; ¼; I2 }; assuming that the distance between the time points aand b is included in one of the intervals I1 ; ¼; I2 : Thus, within the A/S ontology, the arrangement of activities with respect to their time characteristic is reduced to the solution of a temporal constraint satisfaction problem. This problem is formally represented as a constraint network, where time point variables are placed in the nodes of the network and metric constraints are represented as link labels. Union and intersection are easily extended to constraint networks [13]. In addition, a partial order is de®ned using the relation `tighter'. A constraint A is tighter than constraint B if every pair of values allowed by A is also allowed by B. Viewing the design as activity con®guration (or allocation) problem, we can apply the A/S ontology for temporal optimisation of activity allocation. When we operate on the singular level, i.e. all activities are singular, the number of variables in the constraint network is constant, and thus the partial order can be extended to the networks. A network N1 is tighter than network N2 if the partial order is satis®ed for all the corresponding constraints. If the N1 and N2 have the same solution then they are equivalent. Thus for a given constraint network, we can compute the tightest corresponding network, which is minimal according to the partial order [13]. Computing the minimal network in terms of singular activities allows the evaluation of the minimal constraint between each pair of singular activities. This technique allows us to identify bottlenecks and inconsistencies at the stage of conceptual design. If one of the minimal constraints is empty then there is no solution to the network, which means that the corresponding activity system is time inadequate.

Thus, adding this relation to our ontological framework we can represent another relation. For example, relation proper

1 This is a subset of the relations de®ned in Allen's interval algebra (as shown in Ref. [3]).

2.3.3. Relations In addition to the categories of knowledge that represent concepts, the A/S ontology includes relations that de®ne the explicit connection between entities, or the realisation of the concepts. We identify two types of relations: ² relations between entities of the same kind, for example, only between spaces or only between time intervals; ² relations between entities of a different kind, for example, between activities and spaces. An example of a relation between entities of the same kind is overlap. Such a high level kernel relation, regardless of whether it operates over regions of space, time intervals or activities, can be formalised in symbolic form by the means of a standard ®rst order predicate language with identity. For example, if we denote by p a single binary predicate restricted to hold only between entities of the same kind and satisfy the mereological axioms [62], then we can formulate overlap as follows: Oab : 'c…p…ca† ^ p…cb††

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

129

Fig. 5. A set of 1D relations.

3. The combined technique In this section, the approach to developing a design using the three techniques is demonstrated. The generic A/S ontology is used to capture a set of consistently structured cases. The cases are used by RDR to select the key features in the case. These rules also provide the index for accessing the cases. The rules are used by FCA to generate an abstraction hierarchy. By allowing multiple people, such as the architect, builder, client, structural engineer, etc, to specify a design (i.e. enter and /or select features of the case that

are relevant for the design from their point of view) we can develop multiple hierarchies. The hierarchies can be compared using Gaines and Shaw's [19] four Quadrant model. The example data used in this exercise are taken from the design cases of health-care facilities. 3.1. Getting the cases/acquiring the knowledge If a set of cases with minimal descriptions exist in a database or in a design document, then it would be possible to progress directly to the second step and generate a

130

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

Fig. 6. A/S ontology of a Psycho-Geriatric unit in a hospital (adapted from Ref. [38]).

concept lattice. However, many design documents are not well structured or cases are not complete. Other documents or cases have too many irrelevant features that need to be removed to make the cases more generally applicable. Furthermore, if we wish to compare designs we need to

ensure that the designs use similar terms and a similar structure. Thus, we advocate use of the A/S ontology to provide consistent design descriptions. The examples used are based on earlier work [38] in the health care domain. The overall A/S ontology of a Psycho-Geriatric Unit is

Table 1 Singular activities for the composite activity a ˆ `Hospital Bed Placementº Singular activity

Laying, sleeping

Reading/writing, eating

Getting in/out

Spatial envelopes Time envelopes Performer Consumer Equipment Service Constraints

s2 s2 24 h Patient Patient Bed Air-conditioning Controlled visual and auditory privacy

s3 3h Patient Patient Movable table Power supply Complete visual and auditory privacy

s1 s1 10 min Patient Patient Bed Support (optional) Ergonomic safety

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

131

Fig. 7. Activities and corresponding spatial envelopes.

presented in Fig. 6 (see Ref. [38] for more details about the actual formalisation and derivation of the ontology). The ontology is used to develop a set of cases based on the design requirements. An example of a case representing a complex activity and its singular components is given in Table 1. The corresponding spatial envelopes are shown in Fig. 7. In many practical tasks, we have the reverse problem Ð instead of starting with the design requirements, we have a ready-made building and some case data about the functions of the rooms of this building. In this situation RDR is used to elicit requirements, the important features of the case according to the A/S ontology and to specify rules to indicate which singular activities combine to make up composite activities. The RDR rules to cover the composite activity in Table 1 are shown in Fig. 8. 3.2. Generating the hierarchy The RDR rules are used to generate a formal context. The

RDR exception structure is ®rst removed by traversing the list structure for each rule picking up the conditions from the parent rule until the top node with the default rule was reached. From this ¯attened KBS the user can choose either the whole KB or a more narrow focus of attention from which to derive a formal context. When the whole KB is chosen the rules and rule conditions form the extents and intents, respectively. Such a global view is only feasible for small, if not very small, KBS. This is due to the exponential nature of the algorithm and the problems associated with displaying and handling large graphs. More ef®cient algorithms can be found in Ref. [21]. To address the problem of dealing with large contexts, there are currently 13 different ways a context may be derived. The two main methods are choosing a conclusion or a rule. If a conclusion is chosen, all rules using that conclusion are selected and added as objects to the set G, forming the extents of the context. As each extent is added the conditions of the rules are added to the set M of attributes to form the intents of the context, ®rst checking

Fig. 8. The rules for the composite activity `Hospital Bed Placement'.

132

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

Table 2 The formal context based on the rules in Fig. 8 (Attributes: a: Spatial_Envelope ˆ 2; b: Time_Envelope ˆ 24 h; c: Performer ˆ Patient; d: Comsumer ˆ Patient; e: Equipment ˆ Bed; f: Service ˆ Air_Conditioning; g: Constraint ˆ Controlled_Visual; h: Constraint ˆ Auditory_Privacy; i: Spatial_Envelope ˆ 3; j: Time_Envelope ˆ 3 h; k: Equipment ˆ Movable_Tray;l: Service ˆ Power_Supply; m: Constraint ˆ Complete_Visual; n: Spatial_Envelope ˆ 1; o: Time_Envelope ˆ 10 min; p: Service ˆ Support_Optional; q: Constraint ˆ Ergonomic_Safety) Rule a 1a 2b 3c 4d 5e 6f 7g a b c d e f g

b

c

d

e

X X X X X X X X X X X

X X X X X X X

X X X X X X X X

X X

f

g

h

i

j

k

l

m n

X X X X X X X X X X X X X X X

o

p

q

X X X X X X X X

Rule 1 conclusion code %LAYIN Ð Singular Activity `Laying'. Rule 2 conclusion code %SLEEP Ð Singular Activity `Sleeping'. Rule 3 conclusion code %READN Ð Singular Activity `Reading'. Rule 4 conclusion code %WRITE Ð Singular Activity `Writing'. Rule 5 conclusion code %EATIN Ð Singular Activity `Eating'. Rule 6 conclusion code %GETIN Ð Singular Activity `Getting In'. Rule 7 conclusion code %GTOUT Ð Singular Activity `Getting Out'.

to see if any attributes have already been added by previous rules. Where the relation I holds, that is object g has attribute m, a cross is marked in the appropriate row and column. If the user chooses a particular rule then that rule is added as the ®rst object with the rule conditions as the initial intension. Every condition in each rule in the ¯attened RDR rule base is searched for a match on the initial set of attributes. If a match is found, that rule is added to the extension and all new attributes (conditions) found in the matching rule are also added to the intension. Table 2 shows the crosstable for the rules in Fig. 8. Treating the rule conditions as Boolean attributes, is similar to the technique known as conceptual scaling [22] which has

been used to interpret a many-valued context into a (binary) formal context. A many-valued context, such as that represented in an MCRDR KBS, is a quadruple …G; M; W; I† where I is a ternary relation between the set of objects G, the set of attributes M and the set of attribute values W (merkmalsWerte in German). Essentially, each attribute is treated as a separate formal context with the values as attributes associated with each of the original objects. A scale is chosen, such as a nominal scale ( ˆ ) or an ordinal scale ($), to order these attributes. From the many contexts, one for each attribute, the concepts are derived. The crosstable shown in Table 2 was then used to construct all formal concepts of the formal context, using the process described in Section 2.2. To allow drawing of the Hasse diagram it was necessary to compute the predecessors and successors of each concept. Predecessors were found by ®nding the largest subconcept, the join (Formula 5), of the intents for each concept. Successors were found by ®nding the smallest superconcept, the meet (Formula 6), of the intents. The successor list was used to identify concepts higher in the diagram, the parents, and the predecessor list identi®ed concepts lower in the diagram, the children. As Wille [65] points out, there is not one ®xed way of drawing line diagrams and often a number of different layouts should be used because concepts can be viewed and examined in different ways depending on their purpose and meaning. The user may also move a node anywhere they like providing the node is not moved higher than any of its parents or lower than any of its children. The concept lattice for the context table in Table 2 is shown in Fig. 9. Labelling has been reduced for clarity. To ®nd all attributes or objects belonging to a concept we traverse ascending or descending paths, respectively. For example, concept number 2 includes the set of attributes {(Equipment ˆ Bed), (Performer ˆ Patient, (Consumer ˆ Patient} and the set of objects {6 Ð %GETIN, 7 Ð %GTOUT, 1 Ð %LAYIN, 2 Ð %SLEEP}. We can see in

Fig. 9. The concept lattice for the composite activity `Hospital Bed Placement'.

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

133

Fig. 10. Comparing the concept lattice for the reading, writing and eating singular activities from multiple viewpoints.

Fig. 6 that all of the singular activities for the composite activity `Hospital Bed Placement' involve the patient as the performer and the consumer. Apart from these shared features, each set of activities is quite different from the other. Reading, writing and eating involves different equipment to the other groups of activities and getting in and out of bed does not have any auditory constraints. In the lattice many of the activities are not distinguished from one another. It may be that we wish to combine these activities to form a higher concept such as replacing the concepts `getting in' and `getting out' with the concept `bed access'. However, it may be decided that some aspect of these activities warrants a different concept. Perhaps it is quicker to get into bed than out or different equipment is available to assist with these activities. The purpose of the lattice is to clarify commonalities and differences between concepts to aid discussions between those involved in developing the ontology. 3.3. Comparing the conceptual models There are a number of ways the concept lattice for each KBS can be compared. One approach is to visually compare each lattice to determine what differences and similarities exist. While it is noted that comparison using FCA is quite simple it was desirable to automate the comparison process and to offer some assistance to the user by focusing the comparison. To this end, a tool we have developed, known simply as MCRDR/FCA will automatically generate a lattice from the multiple KBS showing only shared concepts OR only different concepts. Such an approach immediately shows what common ground exists and what differences need to be discussed. Another way to focus the comparison is to select certain aspects or views of the combined KBS.

The lattice can be used to identify differences in terminology and concepts. However, if there is little agreement over terms, the concepts described and the relationship between them it will be dif®cult to reach a shared view. This is why using the A/S ontology as the basis for knowledge acquisition facilitates comparison and validation. Fig. 10 shows the lattice for the singular activities: read, write and eating from three different viewpoints. These three viewpoints can be individuals or groups of people with different roles and/or perspectives. We can see in concept number 9 that viewpoints V1 and V3 are identical. V2 agrees on some aspects of the activities de®nitions but disagrees on others. In contrast to V1 and V3, V2 believes that writing, reading and eating require a bed. V2 does not agree that reading requires a movable tray or that eating requires auditory privacy. The example demonstrates that assigning values to the slots in the ontology is subjective and may involve interpretation and discussion. The concept lattice provides a means of identifying what variations exist and to track whether the parties involved in the design are moving towards a shared conceptual model. 3.4. Determining the distance between models A simple measure can be computed to determine the distance between conceptual models. The measure is to be used before and after changes are made to one or more models. The measure is a relative score designed to assist in determining if models are moving closer together or further apart. For each conclusion (object), we determine how many attributes are NOT shared divided by the total number of attributes. The higher the score the greater the distance or higher the degree of con¯ict. Using the four

134

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

Table 3 A summary of the four quadrant model State

Concept

Terminology

Consensus Correspondence Con¯ict Contrast

Same Same Different Different

Same Different Same Different

quadrant model of comparison between experts [19], shown in Table 3, we can classify concepts to be in certain states. If two conceptual models contain an object with the same set of attributes (properties), that concept is in a state of consensus and the score is 0. Similarly, if two conceptual models contain an object which shares no common attributes, the concepts for that object are seen to be in a state of contrast and achieve a score of 1. Where some attributes are shared the concept is seen to be in a state of (partial) con¯ict. Where the cause of the con¯ict is a difference in terminology (a state of correspondence) a change in terminology or the use of a table to map one term to another can rectify this con¯ict. Identifying the state of a concept allows us to apply the appropriate resolution operator. The distance between viewpoints will be less using the A/S ontology since the ontology itself represents a set of shared terms. However, if new cases are found or a new member joins the group, the lattice would be a good way of identifying differences. A comprehensive discussion of our handling of multiple sources of expertise is found in Ref. [48]. 4. Conclusion The concept lattices are term subsumption hierarchies. A key aspect of generating and comparing such hierarchies is the use of consistent terminology. The main objective of the work by [60] is to `develop an ontology that can be used as a surrogate for the meaning of words' (p. 3). They propose the use of an ontology to support database design automation. There is much similarity between their goals and components (a semantic network, a knowledge base, an expert system-based knowledge acquisition component and a measure for determining the distance between terms) with the research reported in this paper. The research in this paper also focuses on the semantics of a term by describing each concept as a set of objects with certain properties. The key difference is that the ontology in Ref. [60] is represented in a semantic network which is prede®ned and used to extract the meaning of new terms. In contrast, the MCRDR/FCA semantic network is an automatically generated output not a hand-crafted, albeit skilfully, input. Differences in terminology can be identi®ed from the lattice. For example, two objects with different object names (conclusions) which share the same set of attributes (rule conditions). The solution is to change the term in one or more KBS or to use a table for mapping common terms to one another. There is considerable work into mapping correspondences

between terms such as the work by Weinstein and Birmingham [64] which uses KL-ONE style description logics [5] to determine compatibility between terminology. In the KA community starting with an ontology is the common approach to ensuring that knowledge is systematically structured and acquired [28,32]. In the ProteÂge approach [41] mappings are organised into an ontology. However, most approaches require manual speci®cation of mappings which are expensive to build due to complexity of the semantic differences and limitations in the expressiveness of the KR [65]. To address this shortcoming Weinstein and Birmingham [64] seek to automatically generate an ontology of mappings. Shaw and Gaines [55] have also proposed a methodology for analysing terminological and conceptual differences which can be captured using a visual language [20]. Much other research into ontologies exists in a range of ®elds, such as [18] who use ontologies as the basis for extracting and structuring data taken from the web. There is no doubt that exploring an ontology can increase understanding of a domain but to some extent building the ontology becomes the new bottleneck. The methodology described acknowledges that knowledge is continually evolving and that ontologies are dif®cult to de®ne and even harder to validate. By dealing with low level concepts in the form of actual cases, de®nition and validation becomes a more manageable task. FCA allows the high level model to follow later. The technique outlined reduces the reliance on the a priori capture of a good or ideal model before knowledge acquisition can commence. The assumption that such a model exists does not ®t with a situated view of knowledge. Instead, the approach described begins and evolves an ontology. Firstly, the A/S ontology can be used to develop a set of structured cases. If cases in an alternative format already exist then RDR can be used to extract some of the design knowledge to ®t the ontology. A visual representation, itself an ontology, can then be automatically generated from the rules and/or cases using FCA. The lattice supports comparison of terms and the identi®cation of appropriate mappings. The iterative population of the ontology with examples and terminological mappings makes the ontology dynamic. Thus, it is possible to manage evolving design knowledge through incremental maintenance and validation. The goal of many ontological approaches is to reduce the knowledge acquisition bottleneck. While we share this goal, the approach offered sees a conceptual model as a goal in itself and not merely the means to an end. For example, the PEIRS system did not require the development of domain ontology or even detailed analysis of the domain to be able to successfully interpret pathology reports. However, abstraction hierarchies can be useful tools in gaining understanding and insights into a domain. In this way, they can assist in the validation of the knowledge or data acquired. In the case of knowledge-based systems, it is important to offer an explanation of the concepts underlying the knowledge to assist in the decision of whether to accept or reject a conclusion. The concept lattice is one

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

dimension of the explanation that can be provided and has also been shown to be useful for critiquing, KA and tutoring purposes [46,47,51]. The MCRDR/FCA tool needs further improvement particularly in the areas of handling large concept lattices and the selection of primitive concepts to include in a formal context. While we have already conducted studies supporting the value of the lattice for communication, documenting and gaining understanding in a number of other problem domains [50,51] we intend to perform more extensive evaluations of the methodology for design knowledge, given its various idiosynchrasies. In particular, the RDR approach to handling design cases needs to be clari®ed. The example offered suggests that it is possible to acquire knowledge with minimal modelling or knowledge engineering effort and to later generate and compare models. This is one approach to addressing the problems associated with the capture of design knowledge, the development and validation of individual models and the comparison of multiple models. Acknowledgements This research was supported by a grant from the Australian Research Council. References [1] Alberts LK. YMIR: an ontology for engineering design. University of Twente, 1993. [2] Augenbroe G. COMBINE project: the broad perspective. Proceedings of the International Construction Information Technology Conference InCIT'96, Sydney, 1996. p. 103±8. [3] Bettini C. Time-dependent concepts: representation and reasoning using temporal description logics. Data Knowledge Engng 1997;22(1):1±38. [4] Beydoun G, Hoffmann A. Building problem solvers based on search control knowledge. In: Gaines B, Musen M, editors. Eleventh Workshop on Knowledge Acquisition, Modeling and Management (KAW'98), Banff, Alberta, Canada, 18±23 April, 1998;1:SHARE3. [5] Brachman R, McGuiness D, Patel-Scheider P, Resnick L, Bordiga A. Living with CLASSIC: when and how to use a KL-ONE-Like Language. In: Sowa JF, editor. Principles of semantic networks San Mateo, California. Los Altos, CA: Morgan Kaufman, 1991. p. 401±56. [6] Clancey WJ. Situated action: a neurological interpretation response to Vera and Simon. Cognitive Sci 1993;17:87±116. [7] Clancey WJ. Situated cognition: on human knowledge and computer representations. Cambridge: Cambridge University Press, 1997. [8] Compton P, Jansen R. A philosophical basis for knowledge acquisition. Knowledge Acquisition 1990;2:241±57. [9] Compton P, Preston P, Kang B. Local patching produces compact knowledge bases. In: Steels L, Schreiber G, Van de Velde W, editors. A future in knowledge acquisition. Berlin: Springer, 1994. p. 104±17. [10] Compton P, Preston P, Kang B. The use of simulated experts in evaluating knowledge acquisition. Proceedings Ninth Banff Knowledge Acquisition for Knowledge Based Systems Workshop Banff, vol. 1, February 26±March 3, 1995. p. 12.1±12.18. [11] Coyne RD, Rosenman MA, Radford AD, Balachandran MB, Gero JS. Knowledge based design. Reading, MA: Addison-Wesley, 1990. [12] De Chiara J, Callender J. Time-saver standards for building types. New York: McGraw-Hill, 1990. [13] Dechter R, Meiri I, Pearl J. Temporal constraint networks. Artif Intell 1991;49:61±95.

135

[14] Dong A, Agogino A. Text analysis for constructing design representations. In: Gero J, Sudweeks F, editors. Arti®cial intelligence in design '96. Holland: Kluwer Academic Publishers, 1996. p. 21±38. [15] Eastman CM, Chase SC, Assal HH. System architecture for computer integration of design and construction knowledge. In: White I, Tzonis A, editors. Automation based creative design. Amsterdam: Elsevier, 1994. p. 185±203. [16] Edwards G. Re¯ective expert systems in clinical pathology. MD Thesis. University of New South Wales; 1996. [17] Edwards G, Compton P, Malor R, Srinivasan A, Lazarus L. PEIRS: a pathologist maintained expert system for the interpretation of chemical pathology reports. Pathology 1993;25:27±34. [18] Embley DW, Campbell DM, Jiang YS, Liddle SW, Ng Y-K, Quass DW, Smith RD. A conceptual-modeling approach to extracting data from the web. Proceedings of the Seventeenth International Conference on Conceptual Modelling, Singapore. Berlin: Springer. LNAI1507, November 1998, p. 78±91. [19] Gaines BR, Shaw MLG. Comparing the conceptual systems of experts. The Eleventh International Joint Conference on Arti®cial Intelligence, 1989. p. 633±8. [20] Gaines BR. An Interactive Visual Language for Term Subsumption Languages IJCAI'91. Proceedings of the 12th International Joint Conference on Arti®cial Intelligence, Darling Harbour, 24±30 August, 1991. p. 817±23. [21] Ganter B, Kuznetsov S. Stepwise Construction of the DedekindMacNeille Completion, 1999. http://www.math.tu-dresden.de/ ~ganter/fba.html. [22] Ganter B, Wille R. Conceptual scaling. In: Roberts F, editor. Applications of combinatorics and graph theory to the biological sciences. New York: Springer, 1989. p. 139±67. [23] Gero JS. Conceptual designing as a sequence of situated acts. In: Smith I, editor. Arti®cial intelligence in structural engineering. Berlin: Springer, 1998. p. 165±77. [24] Gero JS, Fujii H. A computational framework for concept formation in a situated design agent. Knowledge-Based Syst 2000;13(6):361±8. [25] Gruber TR. A translation approach to portable ontology speci®cations. Knowledge Acquisition 1993;5(2):199±220. [26] Gruber TR. Toward principles for the design of ontologies used for knowledge sharing. Int J Human Comput Stud 1995;43(5/6):907±28. [27] Guarino N. Understanding, building and using ontologies. Int J Human Comput Stud 1997;46(2/3):293±310. [28] Guha TV, Lenat DB. CYC: A Mid-Term Rep AI Mag 1990;11(3):32±59. [29] Heidegger M. Being and time. New York: Harper and Row, 1962 (Translated by John Macquarie and Edward Robinson). [30] Kang B. Validating knowledge acquisition: multiple classi®cation ripple down rules. PhD Thesis. Australia: School of Computer Science and Engineering, University of NSW, 1996. [31] Kang B, Compton P, Preston P. Multiple classi®cation ripple down rules: evaluation and possibilities. Proceedings Ninth Banff Knowledge Acquisition for Knowledge Based Systems Workshop, Banff. vol. 1. February 26±March 3, 1995. p. 17.1±17.20. [32] Komori, Satoshi, Yamaguchi Takahira. Interactive composition of software engineering process using Ontologies. In: Motoda H, Mizoguchi R, Compton P, Liu H, editors. Proceedings of the Paci®c Knowledge Acquisition Workshop (PKAW'98), Singapore, 22±23 November 1998. p. 1±12. [33] Lehmann F. Machine-negotiated, ontology-based EDI (Electronic Data Interchange). In: Adam NR, Yesha Y, editors. Electronic commerce: current research, issues and applications, New York: Springer, 1996. p. 14±45. [34] Lee S-Y, Hsu F-J. Spatial knowledge representation for iconic image database. In: Chang SK, Jungert E, Tortora G, editors. Intelligent image database systems. London: World Scienti®c, 1996. p. 87±113. [35] Leslie HG. Strategy for information in the AEC industry. International Construction Information Technology Conference InCIT'96, Australia. Australia: The Institution of Engineers; 1996.

136

D. Richards, S.J. Simoff / Arti®cial Intelligence in Engineering 15 (2001) 121±136

[36] Loffredo D. Fundamentals of STEP Implementation, 2000. http:// www.steptools.com/library/fundimpl.pdf. [37] Maher ML, Balachandran B, Zhang DM. Case-based reasoning in design. New Jersey: Lawrence Erlbaum Associates, 1995. [38] Maher ML, Simoff SJ, Mitchell J. Formalising building requirements using an A/S model. Automn Constr 1997;6:77±95. [39] Maher ML, Simoff SJ, Cicognani A. Understanding virtual design studios. London: Springer, 2000. [40] Mansuri Y, Kim JG, Compton P, Sammut C. A comparison of a manual knowledge acquisition method and an inductive learning method Australian Workshop on Knowledge Acquisition for Knowledge Based Systems. Pokolbin 1991;1991:114±32. [41] Park J, Gennari J, Musen M. Mappings for reuse in knowledge-based systems. In: Gaines B, Musen M, editors. Eleventh Workshop on Knowledge Acquisition, Modeling and Management (KAW'98), Banff, Canada. Calgary, Canada: SRDG Publications. Departments of Computer Science, University of Calgary, 1998. [42] Panero J, Zelnik M. Human dimensions and interior space. London: The Architectural Press, 1979. [43] Pheasant S. Bodyspace: anthropometry, ergonomics and design. London: Taylor & Francis, 1986. [44] Popper K. Conjectures and refutations. London: Routledge & Kegan Paul, 1963. [45] Ramadan Z, Compton PZ, Preston P, Le-Gia T, Chellen V, Mulholland M, Hibbert DB, Haddad PR, Kang B. From multiple classi®cation ripple down rules to con®guration ripple down rules. Proceedings Australian Knowledge Acquisition Workshop (AKAW'97) in conjunction with AI'97, 1997. Perth, Australia: University of Western Australia. p. 5.1±5.17. [46] Richards D. The reuse of knowledge in ripple down rules knowledge bases systems. PhD Thesis. University of New South Wales, 1998. [47] Richards D. An evaluation of the formal concept analysis line diagram. In: Slaney J, Antoniou G, Maher MJ, editors. Poster Proceedings of 11th Australian Joint Arti®cial Intelligence Conference AI'98, 13±17 July, 1998. Brisbane, Australia: Grif®th University, Nathan Campus. p. 121±33. [48] Richards D. Reconciling con¯icting sources of expertise: a framework and illustration. In: Compton P, Hoffmann A, Motoda H, Yamaguchi1 T, editors. Proceedings of the Sixth Paci®c Knowledge Acquisition Workshop, Sydney, December 11±13, 2000. p. 275±96. [49] Richards D, Compton P. Combining formal concept analysis and ripple down rules to support the reuse of knowledge. Proceedings of the Ninth International Conference on Software Engineering and Knowledge Engineering SEKE'97, Madrid, 18±20 June 1997. p. 177±84. [50] Richards D, Compton P. Taking up the situated cognition challenge with ripple down rules. Int J Human Comput Stud 1998;49:895±926 (Special Issue on Situated Cognition). [51] Richards D, Compton P. A new look at knowledge-based system explanation. In: Motoda H, Mizoguchi R, Compton P, Liu H, editors. Proceedings of the Paci®c Knowledge Acquisition Workshop (PKAW'98), 1998, Singapore, 22±23 November. p. 122±39. [52] Richards D, Compton P. Sisyphus I revisited: an incremental approach to resource allocation using ripple down rules. In: Gaines B, Musen M, editors. Twelfth Workshop on Knowledge Acquisition, Modeling and Management (KAW'99), Banff, Canada. Calgary, Canada: SRDG Publications. Departments of Computer Science, University of Calgary, 1999. [53] Saint-Diszier P, Viegas E. An introduction to lexical semantics from a linguistic and a psycholinguistic perspective. In: Saint-Diszier P, Viegas E, editors. Computational lexical semantics. Cambridge: Cambridge University Press, 1995. p. 1±29. [54] Scheffer T. Algebraic foundation and improved methods of induction of ripple down rules repetition. In: Compton P, Mizoguchi R, Motoda H, Menzies T, editors. Proceedings of Paci®c Knowledge Acquisition Workshop PKAW'96, 1996, Coogee, Australia, October 23±25. p. 279±92.

[55] Shaw MLG, Gaines BR. A methodology for analyzing terminological and conceptual differences in language use across communities. In: Kohler R, Rieger BB, editors. Contributions to quantitative linguistics, Proceedings of the First Quantitative Linguistics Conference, (QUALICO). TrierDordrecht: Kluwer Academic, 1991. p. 91±138. [56] SchoÈn DA. The re¯ective practitioner: how professionals think in action. New York: Basic Books, 1983. [57] Shiraz GM, Sammut C. Acquiring control knowledge from examples using ripple-down rules and machine learning. Eleventh Workshop on Knowledge Acquisition, Modeling and Management, Banff, Canada. vol. 1. SRDG Publications, Departments of Computer Science, University of Calgary, Calgary, Canada, 1998. KAT-5. [58] Simoff SJ, Maher ML. Deriving ontology from design cases. Int J Design Comput 1998;1 (http://www.arch.usyd.EDU.AU/kcdc/journal/). [59] Simoff S, Maher ML. Designing with the Activity/Space ontology. In: Gero JS, Sudweeks F, editors. Arti®cial intelligence in design '98. 1998. p. 23±44. [60] Storey, Veda C, Ullrich H, Sundaresan S. An ontology for database design automation. Proceedings of the 16th International Conference on Conceptual Modelling, Los Angeles, USA. Berlin: Springer, LNAI-1331, November 1997. p. 2±15. [61] Uschold M, Gruninger M. Ontologies: principles, methods and applications. Knowledge Engng Rev 1996;11(2):93±136. [62] Varzi A. Parts, wholes, and part-whole relations: the prospects of mereotopology. Data Knowledge Engng 1996;20:259±86 [63] Watson A. Product models and beyond. In: Brandon P, Betts M, editors. Integrated construction information, E and FN Spon. London: Chapman & Hall, 1995. p. 160±72. [64] Weinstein P, Birmingham W. Comparing concepts in differentiated Ontologies. In: Gaines B, Musen M, editors. 12th Workshop on Knowledge Acquisition, Modeling and Management (KAW'99), Banff, Alberta, Canada, 16±21 October, 1991, 2001 (in press). [65] Wille R. Concept lattices and conceptual knowledge systems. Comput Math Appl 1992;23(6±9):493±515. [66] Wille R. Conceptual graphs and formal concept analysis. In: Lukose D, Delugach H, Keeler M, Searle L, Sowa JF, editors. Conceptual Structures: Ful®lling Peirce's Dream, Proceedings of the Fifth International Conference on Conceptual Structures (ICCS'97), August 3±8, University of Washington, Seattle, USA. Lecture Notes in Arti®cial Intelligence, Number 1257. Berlin: Springer, 1997. p. 290±303. [67] Winograd T, Flores F. Understanding computers and cognition: a new foundation for design. Norwood, NJ: Ablex, 1986. Debbie Richards is currently a lecturer at Macquarie University in Sydney. She received her PhD in 1999, which was concerned with the retrospective generation of conceptual models from propositional knowledge based systems using FCA. This approach was particularly useful when used in conjunction with a simple yet powerful knowledge acquisition and representation technique known as ripple-down rules. Her current research interests include meta-knowledge discovery from knowledge bases and the reconciliation of con¯icts between different sources of expertise. This latter work is being applied to the ®eld of requirements engineering.

Simeon J. Simoff is a Senior Lecturer at the Department of Computer Systems, University of Technology Sydney. His eclectic teaching and research applies an interdisciplinary approach to computer systems and design computing, combining diverse topics such as data mining, collaborative virtual environments, information visualisation and digital media, with design science and information systems. Recently, he has co-authored a research monograph on virtual design studios. His current research interests include concurrent data mining technologies, multimedia communication in collaborative virtual environments and distributed intelligent systems.