UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A classification theory based information systems model Parsons, Byron Jeffrey 1992

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1992_spring_parsons_byron_jeffrey.pdf [ 9.69MB ]
Metadata
JSON: 831-1.0086718.json
JSON-LD: 831-1.0086718-ld.json
RDF/XML (Pretty): 831-1.0086718-rdf.xml
RDF/JSON: 831-1.0086718-rdf.json
Turtle: 831-1.0086718-turtle.txt
N-Triples: 831-1.0086718-rdf-ntriples.txt
Original Record: 831-1.0086718-source.json
Full Text
831-1.0086718-fulltext.txt
Citation
831-1.0086718.ris

Full Text

A CLASSIFICATION THEORY BASED INFORMATION SYSTEMS MODELByByron Jeffrey ParsonsB.Com., Memorial University of Newfoundland, 1985A THESIS SUBMI1 1ED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFDOCTOR OF PHILOSOPHYinTHE FACULTY OF GRADUATE STUDIES(Commerce and Business Administration)We accept this thesis as conformingto the required standardTHE UNIVERSITY OF BRITISH COLUMBIAJune 1991© Byron Jeffrey ParsonsIn presenting this thesis in partial fulfilment of the requirements for an advanceddegree at the University of British Columbia, I agree that the Library shall make itfreely available for reference and study. I further agree that permission for extensivecopying of this thesis for scholarly purposes may be granted by the head of mydepartment or by his or her representatives. It is understood that copying orpublication of this thesis for financial gain shall not be allowed without my writtenpermission.Department of 0,41p (- 6_2The University of British ColumbiaVancouver, CanadaDate FifTvrs DE-6 (2/88)ABSTRACTInformation systems (IS) development is viewed as a process of transforming users' knowledgeabout some subject matter into a computer-based system which faithfully represents that knowledge. Acritical step in this process is conceptual modelling - the development of an implementation-independentrepresentation of the relevant knowledge. While the importance of conceptual modelling has gainedincreasing recognition, many existing conceptual models remain based on software, rather than knowledge,constructs.This research adopts the premise that a conceptual model should provide constructs for directlymodelling knowledge. Since the subject matter of organizational IS is typically things in organizations,theories of concepts (classification), which deal with the structure and organization of knowledge aboutthings, are an appropriate source of modelling constructs. A classical theory of concepts suggests fiveknowledge constructs - instance, property, concept, specialization, and composition.The thesis develops formal definitions of each of these constructs. The notion of directcorrespondence is then used to define a conceptual information systems model called MIMIC, whichcontains a corresponding set of constructs - object, attribute, class, specialized class, and composite class.The model offers several contributions to conceptual modelling research and practice, including:1) minimal requirements for a "good" class structure;2) naturalness of a lattice structure for class organization;3) refinements to the meaning of IS-A connections between classes in a lattice;4) distinction between simple relationships and those which can be regarded as objects;5) simple foundation for treating time in conceptual modelling; and6) a normative model of objects under the assumption that a fundamental objective of the objectparadigm of computing is to provide a set of natural modelling constructs.iiThe value of the model is further illustrated by using it as a framework to evaluate several otherconceptual modelling approaches. The results of this comparison indicate that, while other models dosupport cognitive constructs to varying degrees, each is weak in supporting some elements of the classicalview of concepts. Finally, a detailed example is used to demonstrate the capability of the model foruniformly representing knowledge across several classes of applications.iiiTABLE OF CONTENTSABSTRACT^  iiTABLE OF CONTENTS ^  ivLIST OF FIGURES ^  ixACKNOWLEDGEMENT^  x1 INTRODUCTION ^  11.1 TRADITIONAL VIEW OF INFORMATION SYSTEMS ^  11.2 IMPACT OF TRADITIONAL VIEW ON SYSTEMS ANALYSIS ^ 41.3 AN ALTERNATE VIEW AND RESEARCH PROBLEM ^  51.4 ROLE OF THE OBJECT PARADIGM ^  81.5 RESEARCH OBJECTIVES AND METHODOLOGY ^  91.6 EXPECTED CONTRIBUTIONS ^  102 CONCEPTUAL INFORMATION SYSTEMS MODELLING^  122.1 INTRODUCTION ^  122.1.1 Conceptual Modelling and Models ^  122.1.2 Importance of Conceptual Models  132.1.3 Range of Conceptual Models ^  142.2 CONCEPTUAL MODELS ^  152.2.1 TaxisJRML/Telos  162.2.2 NIAM^  182.2.3 ACM/PCM  192.2.4 JSD ^  202.2.5 OBCM  212.2.6 Other Conceptual Models ^  232.3 SEMANTIC DATA MODELS  23iv2.3.1 Entity-Relationship Model and Extensions ^  242.3.2 SDM ^  252.3.3 FDM/DAPLEX ^  272.3.4 Other Semantic Data Models ^  282.4 OBJECT-ORIENTED MODELS  282.4.1 The Object Paradigm ^  282.4.2 Object-oriented Data Models  302.4.3 Object-oriented Analysis ^  322.5 SUMMARY ^  333 CONCEPT THEORIES AND MODELLING IMPLICATIONS ^  353.1 CONCEPTS AS A BASIS FOR INFORMATION SYSTEMS MODELS ^ 353.1.1 Introduction ^  353.1.2 Reference Disciplines ^  353.1.3 Cognition ^  363.1.4 Concepts and World Knowledge ^  383.1.5 Components of Conceptual Representation ^  393.1.6 IS Models and Conceptual Representation  403.2 THEORIES OF CONCEPTS^  413.2.1 Classical View  413.2.1.1 Theory ^  413.2.1.2 Extensions  433.2.1.3 Applicability ^  443.2.1.4 Limitations  443.2.1.5 Summary^  463.2.2 Prototype View  463.2.2.1 Theory ^  463.2.2.2 Applicability  473.2.2.3 Limitations ^  483.2.3 Exemplar View  493.2.3.1 Theory ^  493.2.3.2 Applicability  493.2.3.3 Limitations ^  503.2.4 Summary ^  503.2.5 Semantic Organization of Concepts ^  503.2.5.1 Major Principles ^  513.2.5.2 Some Findings  523.2.5.3 Summary^  533.3 ON THE CONCEPTUAL REPRESENTATION OF ORGANIZATIONS ^ 533.3.1 Organization Entities ^  543.3.1.1 Structural Properties ^  543.3.1.2 Relational Properties  543.3.1.3 Behavioral Properties ^  553.3.2 Goals of Representation  553.3.3 Suitability of the Classical View ^  554 A CONCEPTUAL INFORMATION SYSTEMS MODEL ^  574.1 INTRODUCTION ^  574.2 A CLASSICAL MODEL OF CONCEPTS ^  584.2.1 Basic Constructs of Classical Concept Theory ^  584.2.2 Primitive Constructs ^  594.2.2.1 Instance  604.2.2.2 Properties ^  614.2.2.2.1 Structural Property ^  624.2.2.2.2 Relational Property  664.2.2.3 State, Change, and Time ^  724.2.2.3.1 State ^  724.2.2.3.2 Change  784.2.2.3.3 Time ^  814.2.3 Derived Constructs  834.2.3.1 Behavioral Property ^  834.2.3.2 Concept ^  884.2.3.3 Specialization  954.2.3.4 Composition ^  99vi4.3 ON DIRECT REPRESENTATION AND GOODNESS ^  1054.4 MIMIC: AN OBJECT-BASED INFORMATION SYSTEMS MODEL^ 1064.4.1 Preliminaries ^  1064.4.2 Primitive Constructs  1074.4.2.1 Object ^  1074.4.2.2 Structural Attribute ^  1084.4.2.3 Relational Attribute  1104.4.2.4 Object State and Change ^  1134.4.2.4.1 Object State  1134.4.2.4.2 Object System Change ^  1154.4.3 Derived Constructs ^  1174.4.3.1 Behavioral Attribute ^  1174.4.3.2 Class  ^1184.4.3.3 Specialization ^  1214.4.3.4 Composition  1224.4.4 Well-definedness of MIMIC ^  1235 MODELLING INSIGHTS AND PRESCRIPTIONS ^  1245.1 INTRODUCTION ^  1245.2 ON CRITERIA FOR DEFINING A CLASS STRUCTURE ^  1245.3 ON CLASS STRUCTURE - HIERARCHY VERSUS LATTICE  1365.4 ON THE MEANINGS OF "ISA" ^  1435.5 ON ASSOCIATIONS - RELATIONAL ATTRIBUTE VERSUS COMPOSITECLASS ^  1475.6 ON THE IMPLICATIONS OF A UNIFORM FORMALISM ^ 1525.7 ON THE MEANING OF TIME ^  1555.8 ON THE OBJECT PARADIGM AND CONCEPTUAL MODELLING ^ 1625.9 SUMMARY ^  1686 A COMPARISON OF CONCEPTUAL MODELS^  1696.1 INTRODUCTION ^  1696.2 CRITERIA FOR COMPARISON ^  170vii6.3 EXTENDED ENTITY-RELATIONSHIP MODEL^  1736.4 TELOS ^  1796.5 NIAM  1856.6 OBJECT-ORIENTED ANALYSIS^  1906.7 SUMMARY ^  1937 CONCLUSIONS AND FURTHER RESEARCH ^  1957.1 THESIS SUMMARY^  1957.2 CONTRIBUTIONS  1967.2.1 Theoretical Contributions ^  1967.2.2 Practical Contributions  1987.3 LIMITATIONS ^  1997.4 DIRECTIONS FOR FUTURE RESEARCH ^  201BIBLIOGRAPHY ^  203APPENDIX 1: MODELLING AN EXAMPLE WITH MIMIC ^  213A.1 INTRODUCTION^  213A.2 REVIEW OF MIMIC CONSTRUCTS^  213A.3 OPERATIONS TO CONSTRUCT A REPRESENTATION ^  214A.4 CONSTRUCTING THE EXAMPLE ^  221A.5 UNIFORMITY OF THE MODEL  230APPENDIX 2: GUIDE TO NOTATION ^  235viiiLIST OF FIGURESFigure 4-1: Reality, Knowledge, and Information Systems ^  57Figure 4-2: Simple Structural Property ^  63Figure 4-3: Binary Relational Property  67Figure 4-4: Structural Attribute ^  109Figure 4-5: Binary Relational Attribute  112Figure 5-1: A Hierarchical Class Structure ^  137Figure 5-2: A Lattice Class Structure  137Figure 5-3: Extension of a Class ^  139Figure 5-4: Extensional Meaning of IS-A ^  144ixACKNOWLEDGEMENTI am happy to have the opportunity to thank the people who have supported me in various waysduring the completion of this research.I am indebted to Yair Wand for introducing me to research in information systems modelling andfor providing insightful and constructive supervision of this thesis. I also thank the other members of mythesis committee, Alain Fournier and Carson Woo, for suggestions which helped me to focus the research.In addition, I am grateful for the stimulating intellectual environment provided by participants in the MISWorkshop series at the University of British Columbia.It gives me greatest pleasure to acknowledge those whose personal support helped me weathereach storm that arose over the past several years. Thanks to Dave and Jane for many interesting lunches.To Katherine, words cannot express how much your friendship has given me the strength to press on.Thanks for putting up with me. Finally, I want to thank my parents for the unending source of love andsupport they have been. Thanks for always being there when I needed someone to talk to.CHAPTER 1INTRODUCTION1.1 TRADITIONAL VIEW OF INFORMATION SYSTEMSIn the 40 or so years since the introduction of computers to businesses, there has been aproliferation of applications and rapid advances in both hardware and software technology. Initialcommercial uses involved primarily high-volume, transaction-oriented data processing in a few areas ofan organization (e.g., accounting and inventory). Today, applications encompass data processing,management reporting, and decision support in all functional areas (e.g., purchasing, production,marketing, personnel) and at all managerial levels (operational, tactical, strategic) of a firm. In addition,advances in technology have created new opportunities and challenges in areas such as databasemanagement and the development of knowledge-based systems.Throughout this period, though, the accepted view of what an information system (IS) is from a software point of view s has remained relatively unchanged. A typical diagram of an IS, similar to thosefound in introductory textbooks, is given below:INFORMATION SYSTEM INPUT ----> PROCESSING ----> OUTPUTIn this elementary model, there are essentially two components: data (input and output) andprograms (processes). These are created and maintained independently and distinctly, and interact only1 0f course, an IS may also be viewed as a social system (e.g., London, 1976), or as a physical system.However, these aspects are outside the scope of this research.12during the execution of a program. Data capture facts about the world. Programs accept input data,transform data, and generate output data, either for storage or for use by a human or machine.This orientation is reinforced by many of the tools and methodologies used in systemsdevelopment. For example, many high level programming languages, such as COBOL and PASCAL,encourage the "data-program" dichotomization by separating the development of procedures and algorithmsfrom the development of data structures. In addition, database management systems, by emphasizing dataindependence, contribute to the rift between data and programs. Furthermore, the most widely usedsystems development methodologies, such as structured analysis (DeMarco, 1979), support thisprogramming orientation by handling processes and data quite separately during systems analysis anddesign.This traditional separation of programs and data is recognized to be a source of difficulty ininformation systems development. According to Love (in Pressman, 1987):[t]he roots of software problems may lie in the most traditional terms for describing our industry -data processing. We have been taught that data and programs are two distinct "things" which aresomehow fundamental to our business. That partitioning may be far more detrimental than werealize. (p. 364)Several problems arise when the "data processing" view of IS is taken. All are rooted in the factthat there is not a one-to-one correspondence between things in the domain being modelled (e.g., acompany) and things in the information system, in part due to the artificial separation of application dataand programs which act on that data. As a consequence, a rather significant transformation is required inmoving from domain-oriented constructs, which are familiar to the user, to software-oriented constructssuitable for implementation.The most obvious problem is that there is nothing in the structure of files to indicate whether theinformation in a record relates to a single entity, several entities, or a relationship among several entities.Although data fields capture the values of properties of things, a single record in a file may contain fieldsdescribing any number of things (e.g., customers and accounts). In addition, one file may contain fields3describing a relationship among several types of things (e.g., customers holding accounts), while anotherfile may describe only things from a single class (e.g., customers). Furthermore, information about a singleentity may be distributed among several files. In short, the meaning of the data has to be largelyinterpreted by a user based on knowledge of the domain. As well, there is no simple way of determiningwhich data files may be used by which programs. There is no explicit recognition that the execution ofprocedures to change data values often reflects actual or potential changes to properties of entities.This type of problem occurs frequently in record-oriented IS (Kent, 1978; 1979). The lack ofdirect correspondence between data records (and/or procedures which act on them) and distinct things inthe environment of the IS makes it difficult to build and understand systems. As Kent (1979) states:the use of record structures depends on supplementary information, often reflected only in thespecial-purpose application programs written to process the data, and which may or may not stillbe remembered by the users of the data. (p. 107)A second problem with the traditional view of IS is that there may be considerable duplicationof development effort and, also, of programs and data. Systems development projects are often undertakenquite independently of each other. Solving the problem may be equated with writing the software toperform a particular task. As a result, applications are developed in an ad hoc manner. New data files maybe constructed which contain data that already exist in files built for other applications2. In addition tothis obvious duplication of data, the failure to take advantage of existing systems and files may result inunnecessary systems analysis and design efforts.When a new application belongs to a different class from existing applications using data aboutthe same entities, a closely related problem can occur. Not only may data be duplicated, but new programs2This is a problem which database research has sought to address by providing application-independentrepresentations of data. In particular, the reduction of duplication is a major justification for the databaseapproach. However, as noted earlier, databases encourage the separation of data from the procedures whichmodify it. In addition, the redundancy mentioned here is more general, encompassing the duplication thatoccurs when applications as diverse as transaction processing and expert systems use data about the sameentities. Such applications generally use different software technologies and data formats, leading toduplication.4may be developed to describe essentially the same activities as existing programs. As a result, ISdevelopment is fragmented across different classes of applications, again resulting in redundancy indevelopment efforts. For example, consider a system to simulate arrivals of goods at a warehouse andsubsequent shipments to customers. A simulation generates hypothetical shipments to and from thewarehouse that can be handled in the same way as actual shipments that are processed by an existinginventory program (e.g., replenishment and depletion of quantity-on-hand). In this case, simulation andtransaction processing constitute two classes of applications, characterized by different goals. Nevertheless,code for processing shipments into and out of inventory may be very similar for inventory tracking andsimulation software.In short, the traditional data processing view of IS creates problems of comprehensibility,fragmentation, and duplication. Although these problems are most obvious in IS implementation, they alsoimpede earlier stages of systems development. A fundamental shift in perspective is required to supportdevelopment of IS to cope with growing user and application demands. The next two sections argue thata logical place for the shift in perspective to originate is in systems analysis methodologies.1.2 IMPACT OF TRADITIONAL VIEW ON SYSTEMS ANALYSISThe view of an information system as a collection of software and data components has had asignificant influence on the nature of systems development approaches. Many analysis and designmethodologies are based on constructs closely related to files and programs Perhaps the best known ofthese is structured analysis (DeMarco, 1979; Gane and Sarson, 1979), which is based on data flows andprocesses which transform these data flows. However, many other approaches also appear to be heavilyinfluenced by implementation considerations (e.g., Jackson, 1983; Verheijen and van Bekkum, 1982: see[011e et al., 1982; 1983; 1986] for descriptions and comparisons of a variety of methodologies).Many methodologies fail to explicitly recognize that data and programs constitute a model or5representation of some aspects of the domain or problem area constituting the subject matter of aninformation system. Consequently, they cannot be expected to provide a representation which can be easilyunderstood by users who are immersed in the problem domain but are not well-versed in softwaretechnology (Sibley, 1986). The fundamental premise of the research in this dissertation is that:a systems analysis methodology should provide a set of constructs for directly modellingthe subject matter of information systems.This premise is consistent with a view of IS development as the process of transformingknowledge about a domain (e.g., an organization) into an implemented system that properly reflects thatknowledge (Wand and Weber, 1989). At early stages (referred to by terms such as conceptual modellingand enterprise analysis), it is particularly important that descriptions be based on constructs familiar tothose who regularly deal with the subject matter and/or will be users of the implemented system. Thisshould facilitate the verification of specifications so that the risk of problems in later stages ofdevelopment is reduced. A methodology which conforms to the above premise will directly reflect theconstructs of the domain of information systems, giving rise to a competing view of IS as representationsof knowledge about some "world" such as an organization.1.3 AN ALTERNATE VIEW AND RESEARCH PROBLEMIn recent years, several researchers have explicitly recognized that an IS can be viewed as arepresentation of some elements of reality (Wand and Weber, 1988; Bubenko, 1986; Borgida et al., 1985;Jackson, 1983; Nijssen, 1976). For example, Nijssen (1976) states that:Mlle origin of an information system has to do with the need of one and usually more persons tocollect, note, process and distribute data, related to a certain part of the reality. (p. 2)Given this view, information systems development can be regarded as the construction of a model of thetarget segment of reality. Key development issues can then be addressed by determining how best toidentify and represent the important elements of the domain.6To be more precise, though, we know reality only as we perceive and conceive it. Therefore, anIS actually represents aspects of our knowledge (i.e., cognitive representation) of things in some part ofreality. Wand and Weber (1988) hint at this distinction by claiming that:[amn information system is an artificial representation of a real-world system as perceived byhumans. (p.213, italics mine)They then use this proposition to justify an ontological approach to developing a theoretical foundationfor IS. In doing so, they focus on a model of the nature of reality, implicitly assuming that perception isselective, but does not distort. This assumption is identified by Lakoff (1987) as central to what he callsthe "objectivist paradigm". He characterizes "objectivist cognition" as follows:Thought is the manipulation of abstract symbols. Symbols get their meaning via correspondenceto entities and categories in the world. In this way, the mind can represent external reality and besaid to "mirror nature". (p. 165)A number of conceptual modelling methodologies have been developed which draw fromknowledge representation principles (e.g., Mylopoulos, 1991; Mylopoulos et al., 1990; Greenspan andMylopoulos, 1984; Hammer and McLeod, 1981; Bubenko, 1980). Despite this growth of interest in animportant early stage in systems development (e.g., Bubenko, 1986; Brodie et al., 1984), such approachesare not explicitly or formally derived from a theory of the structure and organization of knowledge aboutthings, and no model has emerged as dominant among those which have been proposed. Chapter 2 reviewsa number of conceptual modelling approaches and highlights the need for greater emphasis on justifyingthe choice of representation constructs.This thesis endeavours to show that additional insight into IS development (in particular,conceptual modelling) can be achieved by explicitly considering the nature of human cognition, especiallyin the area of representing knowledge about things or entities 3 . If an IS is viewed as a representation ofhuman understanding of an organizational reality which is used by humans, a theory of how people3The terms thing and entity are used interchangeably here. Both refer to existents in a reality (suchas an organization).7represent the world can serve as a natural foundation for developing methodologies best suited forconceptual modelling4. Such a theory need not be one of general human cognition, since informationsystems represent only a small segment of human knowledge - that pertaining to things in organization s .Moreover, since things in organizations (as well as in everyday life) are understood by classifying theminto relevant categories, a theory of concepts and classification may be adequate to deal with theknowledge typically contained in IS.The field of cognitive science offers a number of theories of concepts and classification thatattempt to describe the bases for organizing things in the perceived world into meaningful categories. Ingeneral, these theories attempt to:1) define what concepts are,2) explain how concepts are acquired, and3) account for the ways in which concepts help us survive by reducing complexity.Chapter 3 describes the importance of concepts and categorization in organizing knowledge about things,reviews three theories of concepts, and explores the suitability of one of these for representing knowledgeabout things in organizations6. Given the assumption that an IS represents knowledge, a conceptualmodel" developed from a cognitive foundation may be instrumental in allowing systems analysts toconstruct representations that can be more easily understood by users, so that errors and omissions ininitial descriptions can be detected and corrected at minimal cost.4If IS development is the process of transforming from knowledge of a domain to an implementedsystem which represents this knowledge, the products of intermediate stages of development - includingthe conceptual model - also represent domain knowledge.5A general theory of cognition would deal also with learning, planning, and other cognitive activities.6This knowledge constitutes the subject matter of various kinds of information systems.'Interestingly, the term conceptual model embodies the term concept. Hence, it is somewhat surprisingthat existing conceptual models do not make more explicit and rigorous use of theories of conceptsdeveloped by cognitive scientists.8Interestingly, one recent approach to modelling, referred to as object-oriented analysis, appearsto be implicitly based on a theory of categorization. However, a lack of agreement about exactly what themethodology should involve, and its underlying foundations, raises the issue of whether a grounded formalapproach to defining an object paradigm can help resolve the debate over exactly what is meant by theterm object-oriented, as discussed next.1.4 ROLE OF THE OBJECT PARADIGMRecently, a new software paradigm has emerged and is beginning to challenge the traditionaldata/program view. It is referred to in the context of programming as object-oriented programming and,more generally, as the object paradigm (Nierstrasz, 1987; Pascoe, 1986; Stefik and Bobrow, 1986). Ofgreatest interest here is the emergence of interest in object-oriented systems analysis and design (Booch,1991; Coad and Yourdon, 1991; Bailin, 1990; Henderson-Sellers and Edwards, 1990) and object-orienteddata models (e.g., Banerjee et al., 1987; Fishman et al., 1987).The essence of the paradigm appears to be the encapsulation of data and procedures in a singleunit or package. In addition, objects are intended to be in one-to-one correspondence with things in theproblem domain. Beyond these two principles, however, there is widespread disagreement as to whatfeatures the paradigm should include (e.g., compare Nierstrasz, 1987 with Stroustrup, 1986).Although the justifications most often forwarded for object constructs are technical andimplementation-based, various claims have also been made about the "naturalness" of objects, suggestingthat there may be an implicit theory of concepts underlying object-oriented approaches (e.g., Coad andYourdon, 1991). However, the lack of consensus on an object model may in part be due to a confoundingof technical and "naturalness" advantages. Thus, while the focus of this research is not the objectparadigm, it is proposed that a theory of concepts can be used to suggest what objects should be, resultingin an object model that is explicitly based on the principle of providing natural representations of things9in a domain of interest.1.5 RESEARCH OBJECTIVES AND METHODOLOGYIn accordance with the research problem outlined above, the overall purpose of this research isto answer the general questions:Can a theory of concepts be used as a foundation to define a uniform formal model ofknowledge about entities that supports "direct" representation across several classes ofinformation systems applications?Does such a model provide insights and guidelines for conceptual modelling relative toexisting models?To answer these questions, the research seeks to achieve the following specific objectives:1. To develop a precise formal (object) model for directly representing cognitive constructs.This will provide a mechanism for directly representing knowledge about the entities in anorganization. Chapter 4 presents a formal definition of the components of the model. The purposeof the formalization is to define a set of object constructs in precise and unambiguous terms basedon an underlying theory of knowledge (thereby providing a normative model). Appendix 1illustrates the use of the model on several applications in a banking environment, and shows itsvalue in uniformly dealing with several classes of IS applications.2. To explore the model as a tool for addressing open problems in conceptual modelling.Existing conceptual models do not deal clearly with a number of issues related to the semanticsand usefulness of constructs such as classes, class specialization, and time. Chapter 5 identifiesseveral contributions of the proposed model to understanding and resolving important questionsabout conceptual model semantics, and presents a number of guidelines for modelling whichemerge from this analysis.103. To evaluate the model by comparing it to several other conceptual modelling approaches.The purpose of this comparison is to assess the degree to which the constructs of the proposedmodel are supported by existing conceptual models which are not formally grounded in theoriesof concepts. If the model is to be valuable, it should be at least as expressive as existing models,without being more complex. Chapter 6 contains this evaluation.The methodological approach taken in this research has two components. The first may bedescribed as formal model building and involves the development of a small set of constructs forrepresenting knowledge according to a theory of concepts. The second is model evaluation, which involvesboth a discussion of the insights offered by the model for representing knowledge about a domain and anassessment of its representation power with respect to several existing models.1.6 EXPECTED CONTRIBUTIONSThe anticipated contributions of this research are both theoretical and practical. On the theoreticalside, the value of the work is primarily in providing a comprehensive, uniform model of knowledge whichoffers a number of insights into the semantics of conceptual modelling constructs. This model providesa vocabulary for describing a subject matter in the early stages of IS development. Additionally, it isviewed as a model of the object paradigm that emphasizes the essence of objects in supporting directrepresentation. Existing literature has provided conflicting views of what the object paradigm is and/orshould be. This thesis suggests a precise resolution based on the modelling objective of representingconcepts and instances of concepts Finally, the model provides a framework for understanding andevaluating the constructs of existing conceptual models.Beyond this, an important practical outcome of the research is the demonstration of the model'susefulness in representing knowledge for several kinds of applications. In this way, the modelling11constructs are shown to provide a uniform tool for describing several classes of applications, in which asingle object corresponds to a single instance of a concept across application areas.Through these contributions, the work should help address the stated problems associated with thetraditional data-program dichotomy in IS. First, since the model is based on a theory of the structure andorganization of knowledge, it is expected that specifications created from it will be more easily understoodand verified by users since the constructs employed by the model reflect the theory's view of the waypeople represent the world8. Second, just as human knowledge appears to be integrated, the representationof knowledge about one thing by one object, which can participate in several types of applications,facilitates greater integration (less fragmentation) at the conceptual modelling stage of IS development.Consequently, use of the model may result in less duplication of development effort, and less redundancyin resulting systems.The work also provides a starting point from which a program of future research can bedeveloped. First, an implementation of the model might prove useful in reducing the "semantic gap"between constructs oriented toward users' knowledge of a problem area and constructs used to implementIS by providing implementation primitives which are based on the model. Second, either the model or animplementation of it may be used as a tool for conducting experiments on the naturalness of the objectparadigm for users, a frequently claimed - but rarely justified - benefit of object-oriented computing.Third, the model may provide a foundation for developing a methodology for object-oriented systemsanalysis and design for integrated systems. This would be accomplished by further developing thecontributions and guidelines which emerge in Chapter 5, and would be valuable since it is currently notat all clear how to handle issues such as determining appropriate classes when modelling an enterprise.Chapter 7 summarizes contributions and limitations of the research, and outlines areas for future work.&This will hold to the extent that the theory of concepts on which the model is based is a suitabletheory of knowledge for the domain of interest. Chapter 3 elaborates on this issue.CHAPTER 2CONCEPTUAL INFORMATION SYSTEMS MODELLING2.1 INTRODUCTION2.1.1 Conceptual Modelling and ModelsIt is widely recognized that the development of large-scale information systems proceeds througha number of stages, the collection of which is generally referred to as the systems development life cycle9(e.g., Davis and Olson, 1985; Wasserman et al., 1983). While the number and naming of these stagesvaries among systems development methodologies, most approaches can be divided broadly into analysis,design, and implementation. These stages are necessary because of the semantic gap betweenimplementation constructs, such as data and programs, and the constructs by which users describe thedomain modelled by the IS (Greenspan and Mylopoulos, 1984; Hammer and McLeod, 1981; Kent 1978).Recently, the importance of developing models and languages for expressing users' understandingof the things in a domain of interest, as an early step in IS development, has gained widespread attention(e.g., Borgida et al., 1988; 011e et al., 1986; Brodie et al., 1984; Nijssen, 1976). The products of thisresearch have variously been referred to as conceptual models (Bubenko, 1986; Brodie et al., 1984),information systems models (Bubenko, 1980), and semantic data models (Hull and King, 1987).Despite this recognition of the importance of modelling users' knowledge about a domain, thereis no general definition of conceptual model, or of related terms. According to Bubenko (1980, p.399),a conceptual information model is "an abstract model of the enterprise", while Schmid (1977, p.121)describes a conceptual model as a model which "is suitable to represent somebody's interpretation of some9For certain kinds of applications, other approaches to development, such as prototyping, may be moreappropriate (e.g., see Davis and Olson, 1985).1213slice of reality". Similarly, Mylopoulos (1991) states that "conceptual modelling is the activity of formallydescribing some aspects of the physical and social world around us for purposes of understanding andcommunication" (italics original), and views a conceptual model as a notation for expressing suchdescriptions.These definitions suggest that a conceptual model either represents reality directly or someone'sknowledge (interpretation) of it. The models reviewed in this chapter predominantly adopt the firstposition, in the sense that the importance of the structure of knowledge in guiding the development of aconceptual model is not explicitly considered. By contrast, much of this thesis advances the argument thatthe second position leads to modelling insights which may be obscured when the role of human perceptionand cognition is not explicitly considered. Consequently, a conceptual model is, for this discussion,defined as a set of constructs for representing knowledge about things in some domain. A specificrepresentation (e.g., for a particular organization) created from such a set of constructs will be referred toas an instance (or manifestation) of the model. In this chapter, attention is focused on the nature and originof the constructs proposed for a variety of conceptual models'''.2.1.2 Importance of Conceptual ModelsConceptual models provide constructs for creating high-level, implementation-independentrepresentations of information about things in, or otherwise related to, organizations, in order to supportthe systems development process. According to Kung and Solvberg (1986), an instance of a conceptualmodel has the following uses:/) It serves as a common reference framework, which is used during the systems analysis phaseto communicate with the future users of the system.'6This means that there is no discussion here of techniques for using these constructs. In other words,the methodology (or process) of conceptual modelling is not examined.142) It serves as a model of reality, which gives insight into the application domain. In other words,the construction of the conceptual model enables the systems analysts to have a betterunderstanding of the application and the users' needs.3) It serves as a basis upon which the design and implementation of the database can be carriedout and, against which the design and implementation can be tested.4) It serves as a part of the documentation to be used during the maintenance phase to facilitatemodification and enhancements of the system. (pp. 146- 147)From this characterization, it is clear that conceptual modelling is a pivotal activity in the earlystages of systems development, and that problems at this stage will be magnified later in the developmentprocess. In short, conceptual modelling supports the development and use of information systems throughthe construction of an explicit description of the things in an organization (or application), on which anIS design and implementation are based. For this research, the second point mentioned by Kung andSolvberg is of particular interest, as it indicates the role of conceptual modelling in representing reality(as perceived by users).2.13 Range of Conceptual ModelsThe move from implementation-dependent views of IS to more conceptual views which recognizethe role of systems in representing knowledge about reality (Abbott, 1987; Borgida et al., 1985) has beenobserved in several contexts. Systems analysis and design methodologies have become concerned withdeveloping an abstract description of the entities to be represented in an IS, which is independent oftechnology and implementation considerations (e.g., 011e et al., 1986; Borgida et al., 1985; 011e et al.,1983; 011e et al., 1982; Nijssen, 1976). In addition, semantic data models stress the use of constructswhich are "natural" from the point of view of users (e.g., Hammer and McLeod, 1981; Shipman, 1981).Furthermore, programming languages have moved toward ever higher levels of abstraction (Abbott, 1987;Liskov and Guttag, 1986).15In the remainder of this chapter, a variety of approaches to conceptual modelling are reviewed.These are roughly classified into systems analysis methodologies (conceptual models), semantic datamodels, and object-oriented models'. The review is not exhaustive, as there are dozens, if not hundreds,of such approaches described in the literature (Hull and King, 1987; Bubenko, 1986). However, a numberof diverse models are examined in order to illustrate the important constructs and emphases of conceptualmodelling approaches. Examples used here are generally those provided by the authors. The chapterconcludes by evaluating the commonality among models, and suggests an important reason fordissatisfaction with the current state of conceptual modelling research. Four of the models discussed hereare again considered in Chapter 6, where they are compared with the model proposed in Chapter 4.2.2 CONCEPTUAL MODELSIn the following discussions, a somewhat artificial distinction is drawn between conceptualmodelling approaches which are part of a larger development methodology, and those which "stand alone".The latter will be dealt with in subsequent sections on semantic data models and object-based models.First, a number of conceptual models which are part of more comprehensive systems developmentmethodologies are reviewed.11This is simply a classification which parallels three streams of literature. There is no firm distinctionbetween the categories apart from their evolution, with the first emerging to address the weaknesses ofearlier systems analysis methods, the second emerging from the database community to address thelimitations of traditional data models, and the third emerging from developments in programminglanguages.162.2.1 Taxis/RML/Telos (Mylopoulos et al., 1980; Greenspan and Mylopoulos, 1984; Mylopoulos et al.,1990; Mylopoulos, 1991) 12The Taxis project originated with a database design language called Taxis 13 and a language,called RML (Requirements Modelling Language), for use in the conceptual modelling of an application(Borgida et al., 1985; Greenspan and Mylopoulos, 1984). The project has evolved to produce CML(Conceptual Modelling Language) (Borgida et al., 1988) and, most recently, Telos (Mylopoulos, 1991;Mylopoulos et al., 1990). The entire project covers phases from requirements specification to databasedesign and implementation. The core of all the above languages consists of the use of tokens to representindividual entities, attributes to describe entities, and several abstraction mechanisms - classification,generalization/specialization, and aggregation - to model a domain.The main differences between RML and Telos are that (1) Telos is intended, not only formodelling the subject matter of an information system, but also the system, development, and usagedomains', (2) Telos offers more uniformity, using the notion of a proposition to represent all knowledgeabout a domain, (3) certain features, such as the kinds of attributes allowed, are fixed (or built-in) in RML,while Telos endeavours to provide a more flexible environment in which features can be added as needed,and (4) Telos offers a more sophisticated model of time, as well as a sublanguage for expressing rules andconstraints (Mylopoulos et al., 1990).Uniformity and simplicity of model constructs are stressed in Telos, with two primitive units -token (representing a concrete or abstract entity) and attribute (representing a binary association betweenentities) - forming the basis for defining what are called structured objects (which describe knowledge12A collection of early papers describing various aspects of the Taxis project is found in (Nixon, 1984).°Hence, Taxis could also be discussed as a semantic data model. However, since the evolution oflanguages in the project has increasingly emphasized conceptual modelling, a descendant of Taxis calledTelos is discussed here as a conceptual model."Hence, Telos is more general in scope than most conceptual models (Mylopoulos, 1990).17pertaining to an entity). Taxis, RML, and Telos is all incorporate facilities to describe the structural andbehavioral properties of entities. Structure is expressed using a hierarchy of object classes linked by IS-Aassociations. Each class is defined in terms of a number of attributes. In addition, the model also viewsclasses as objects. These, in turn, are classified into metaclasses, permitting facts about sets of things tobe represented. Behavioral knowledge is modelled in Telos as activities 16. Activities describe changesto entities, may include prerequisites, and are instances of activity classes. As with object classes, activityclasses may be organized in a hierarchy.Another important feature of Telos and its ancestors, from the point of view of providing "natural"representation (Mylopoulos, 1991; Borgida et al., 1988), is the notion of a 1-1 correspondence betweenobjects and entities in the domain being modelled.Telos extends the Taxis and RML models by including a mechanism for representing andreasoning about temporal knowledge using time intervals as a primitive (cf. Allen, 1983).Four features stand out in Telos and its ancestors. First, there is a strong emphasis on a uniformapproach to modelling entities (structurally) and behavior via classes (object and activity, respectively)which are linked via IS-A associations. Thus, classification and specialization are strongly supportedabstraction mechanisms. Second, uniformity is extended by considering classes as objects and thenclassifying them into metaclasses. Telos uses this notion to support infinite levels of classification. Third,there is the notion of a 1-1 correspondence between Telos objects and entities in the domain beingmodelled. Finally, while Taxis emphasizes data manipulation through transactions in modelling behavior,RML and Telos handle behavior in a less procedural manner using events and activities, which are subjectisThis review does not consider in detail the differences among Taxis, RML, CML, and Telos. Sincethe other models evolved from Taxis, there are many similarities. However, where appropriate, theimproved modelling capability of successive refinements is mentioned.16There are some terminological differences among models in this regard. Taxis supports proceduraldescription of behavior through transaction, RML uses the term event to describe non-proceduralspecification of behavior (and constraints), and Telos uses activities to model behavioral knowledge.18to pre- and post-conditions.2.2.2 NIAM (Nijssen, 1976; Verheijen and Van Bekkum, 1982)NIAM (Nijssen's Information Analysis Method) is a modelling approach based on the structureand flow of information in an organization. Knowledge about the structure of things in the domain ofinterest (referred to in NIAM as the object system) is expressed in a binary model" which recognizesassociations between lexical and non-lexical objects and object types. Lexical objects may be viewed assurrogates or names (e.g., the string "John"), whereas non-lexical objects are things in the domain or objectsystem (e.g., the person John). Lexical and non-lexical object types are classes of lexical and non-lexicalobjects, respectively (e.g., Name and PERSON).Binary associations among objects are of two kinds: bridge types and idea types. A bridge typeis a binary association between a non-lexical and a lexical object type, such as PERSON Has nameName, and is often referred to in other models as an attribute. An idea type reflects a binary associationbetween two non-lexical object types, such as PERSON Employed_by COMPANY, and is morecommonly referred to as a relationship. Bridge and idea types are populated by bridges and ideas, linkingmembers of the respective types.Additionally, NIAM recognizes a number of constraints on the participation of objects in ideasand bridges. Identifier constraints restrict the cardinality of lexical/non-lexical objects (of some type) ina binary association (more commonly referred to as cardinality constraints). Subset constraints restrict theobjects involved in one kind of binary association (e.g., presenters of papers) to be a subset of thoseinvolved in another type of association (e.g., authors of papers). Disjoint constraints indicate that thepopulations of two subtypes are mutually exclusive (e.g. ACCEPTED_PAPERS andREJECTED_PAPERS). Total role constraints indicate that all instances of one type participate in a171n NIAM, an instance of the model is expressed as an information structure diagram (ISD).19certain binary association with another type (e.g. PERSON Child_of PARENT).In addition to information structure, NIAM allows the representation of information flows and thetransformation of information by functions. The mechanism by which this is achieved in NIAM is referredto as information flow diagrams (IFDs). These are similar to data flow diagrams (DeMarco, 1979). Theintent of this part of the model is to capture information about the changes (processing) which objectsundergo in a domain.To summarize, NIAM is a methodology for expressing knowledge about the structure of thingsin some domain via binary associations (represented in information structure diagrams). In addition,information flow diagrams are introduced to capture processes (dynamics). However, ISDs and IFDs donot constitute an integrated package, as they use different constructs, and behavior is not part of objecttype definitions.2.2.3 ACM/PCM (Brodie and Ridjanovic, 1984; Brodie et al., 1983; Brodie and Silva, 1982)ACM/PCM (Active and Passive Component Modelling) is a development methodology based onthe semantic data model SHM+ (Brodie and Ridjanovic, 1984) 18. SHM+ permits the modelling ofstructural properties of things in a domain. It is based on one fundamental construct, the object, andutilizes four abstraction mechanisms19 - classification, aggregation, generalization, and association - torelate objects.Classification abstracts the common properties of each of a collection of objects (e.g., johnINSTANCE_OF PERSON). An object is an instance of a class if it possesses the properties defining the"This is a good example of the fuzzy distinction between conceptual models and semantic datamodels. SHM+ could as easily be discussed under the heading "semantic data models". However, it isconsidered here because it is a part of the larger methodology that is ACM/PCM.°Abstraction mechanisms permit the hiding of certain details to highlight other information. Thesefeatures constitute an important part of most conceptual and semantic models.20class. Aggregation abstracts a collection of objects (parts) into a more complex object (e.g., <Name,Address, Birthdate, ...> = PERSON) 20. Generalization abstracts the IS-A relationship between specializedand more general classes (e.g., CUSTOMER IS-A PERSON). Association, which is a less widely usedabstraction, captures the "member of relationship between a set and its elements (e.g., EMPLOYEEMEMBER_OF UNION). These abstractions and their semantics have been defined formally in SHM+ usingpredicate-based axioms and functions on sets.Together, these mechanisms form the basis for representing static (structural) knowledge aboutthings in a domain. In addition, transaction modelling is used to specify structural and behavioralproperties of transactions and queries. Behavioral properties of applications are supported in SHM+ byprimitive operations on objects (including insert, delete, and update), by three kinds of control abstractions(sequence, iteration, and choice) to compose operations, and by two forms of procedural abstraction(actions and transactions).As with NIAM, there is an effort in ACM/PCM to capture structural and behavioral knowledgeabout things, although the behavioral knowledge is closely related to the detailed specific content ofprograms or procedures (i.e., the how, rather than the what, of change) and structure and behavior are notintegrated in class definitions.2.2.4 JSD (Jackson, 1983; McNeile, 1986)JSD (Jackson System Development) is a methodology consisting of six steps which span thesystems development process from analysis to implementation. The concern here is with the first twosteps, which involve the description of the real world, since these steps deal with the conceptual modellingcomponent of the method. These steps are called the entity action step and the entity structure step.20This is more precisely called Cartesian aggregation, since the parts here are attributes instead ofobjects which, in turn, possess attributes.21In the entity action step, entities and the actions they perform and suffer are listed. JSD doesrecognize some abstractions with respect to entities, such as classification in terms of common properties.However, it does not appear to deal with generalization or aggregation. An action is defined as an eventwhich occurs in the real world modelled by the system. Entity actions express the behavior of entities overtime.In the entity structure step, the ordering of actions in time is described 21 . Entity structure actuallydescribes the behavior of entities as events occur through the well-known control mechanisms of sequence,iteration, and choice.Subsequent steps in JSD relate to the design and implementation of systems. JSD does not dealwith the structural and relational properties of things, unlike most other conceptual modelling approaches.In addition, the support for abstraction mechanisms is weak.2.2.5 OBCM (Takagaki, 1990; Takagaki and Wand, 1991)OBCM (Ontology-Based Conceptual Model) is an approach to information systems modellingbased on the ontology of Mario Bunge (Bunge, 1977; 1979). This work differs from other conceptualmodels in two important respects. First, OBCM is built on the strong theoretical foundation provided byBunge's model of the nature of reality. Consequently, all the constructs introduced reflect primitives fromthe underlying ontology. Second, OBCM is intended to provide a uniform modelling environment thatencompasses both conceptual modelling and implementation activities in systems development 22 .The ontological foundation behind OBCM offers a small number of modelling constructs.According to the ontology, the world is composed of things. A thing possesses properties, which21Note that structure as described here bears no relation to the notion of structural attributes discussedin relation to other models.22For this reason, OBCM is discussed here, although it could equally well be discussed as a object-oriented model (Section 2.4).22determine its state. States of things are subject to law-governed changes. This means that both allowedproperty values and allowed changes to property values are constrained. Things may be composed ofother things and possess emergent properties. Things may also be grouped into classes which sharecommon properties.OBCM is, in turn, defined in terms of constructs which have ontological equivalents. Surrogatesrepresent the existence of things. The notion of a model object (or simply model) is used to describe aview of a set of surrogates. A model object defines a class, and includes sets of state functions, lawstatements, and change functions. State functions represent properties. Law statements limit the valuesthat may be assumed by one, or a combination of two or more, state functions. Change functions defineallowed changes to state functions. A surrogate and a model together determine what is called an object.An object may thereby be thought of as a view of a particular thing as a member of one class (out ofmany possible classes). Conversely, a surrogate may be regarded as different objects by virtue of differentmodels (or views) of it. For example, a given individual (whose existence is represented by a surrogate)can be considered as a CUSTOMER by modelling a certain set of properties, including Account_ balance.The same individual can be considered as an EMPLOYEE by modelling a different set of properties,including Salary. In other words, the same surrogate can be combined with different models to producedifferent objects. OBCM also supports the notion of composition, by which objects may compose intoothers (conversely, an object may be decomposed into simpler objects).Like several other conceptual models, OBCM supports the representation of both structural andbehavioral information. The former is achieved through state functions, which map surrogates to values,and laws, which constrain allowed states. The latter is achieved through change functions. Furthermore,the model supports commonly used abstraction mechanisms. Classification is formalized through a pairingof surrogates to models. Specialization is supported via the lattice structure relating classes. Aggregationis realized through associations among objects.23In short, OBCM is a theoretically grounded, formal conceptual model for representing things ina domain. A major strength is its formal relationship to a well-developed theory of the nature of reality.A small set of ontological primitives provides a foundation for defining modelling constructs. Unlikesome other conceptual models, OBCM does not introduce ad hoc constructs to model a particular situation.Instead, it uses only mechanisms which are fully justified from the ontology. The constructs used supportthe representation of both structure and behavior and capture many widely used abstraction mechanisms.2.2.6 Other Conceptual ModelsMany conceptual models have been proposed, as indicated by a series of books (based on IFIPworking conferences) devoted to the description, comparison, and evaluation of such approaches (011e etal., 1986; 1983; 1982). Among these models is CIM (Gustafson et al., 1982; Bubenko, 1980), which isa formal model based on entities, entity types, and events. Entities possess attributes and participate inrelationships. This model is noteworthy for introducing a notion of time to conceptual modelling. Anotherformal model which includes time modelling is the set-function (SF) model (Berztiss, 1986).In addition to these, a number of other modelling approaches have emerged with a database focus.These are generally referred to as semantic (or conceptual) data models. The next section reviews severalsemantic models.2.3 SEMANTIC DATA MODELSParalleling the emerging emphasis on conceptual modelling in the systems analysis literature hasbeen a movement in the database field away from machine-oriented data models and toward problem-oriented data models (Peckham and Maryanski, 1988; Hull and King, 1987). These so-called semantic datamodels have been developed to compensate for the semantic limitations of data structures in conventionaldata models such as the hierarchic, network, and relational (Brodie, 1984; Kent, 1979; Kent 1978). That24is, they are intended to allow database designers to model data in ways that correspond more closely tousers' knowledge.Two noteworthy early models have contributed much to the field of semantic data modelling. Thebinary data model (Abrial, 1974; Bracchi et al., 1976) is an early attempt to capture additional semanticsof an application by modelling relationships among things via binary associations. One advantage of binarymodels is the inherent simplicity achieved by representing all associations as binary links (Tsichritzis andLochovsky, 1982). In addition, work by Smith and Smith (1977) highlights the importance of abstractionmechanisms such as aggregation and specialization in capturing application semantics. While these modelsare not reviewed in detail here, they have influenced many models which were subsequently developed.A large number of semantic data models have been proposed and extensive reviews are found inHull and King (1987) and Peckham and Maryanski (1988). In this section, a number of prominent modelsare briefly described.2.3.1 Entity-Relationship Model and Extensions (Chen, 1976; Teorey et al., 1986)The Entity-Relationship (E-R) model (Chen, 1976) is frequently cited as an early and importantcontribution to capturing application semantics in an implementation-independent manner. The basicconstructs of the model are entities23, relationships, and attributes. An E-R diagram' documents thelogical structure of a domain by specifying entity types (sets), the attributes possessed by entities of eachtype, and the binary relationships between entity types. Furthermore, relationships may also possessattributes: however, the model does not distinguish in any way those which do from those which do not.23Chen distinguishes between entity sets and entities (likewise between relationship sets andrelationships). Entity and relationship sets denote classes of entity and relationship instances, respectively.As with most other discussions of the E-R model (e.g., Teorey et al., 1986), the term "set" will be omittedfrom this review.24In the E-R model, the diagramming technique is the basic representation tool.25As well, the existence of entities of some types may be recognized to be dependent on the existence ofentities of other types. In addition, the model allows the imposition of cardinality constraints to describethe participation of entities of various types in a relationship. One of the significant limitations of the E-Rmodel is that it contains no mechanism to express behavioral properties of entities.Extensions to the E-R model have been proposed (e.g., Teorey et al., 1986). The primary goal ofthese extensions has been to add abstraction mechanisms such as generalization/specialization to themodel, and to deal with n-ary relationships, as well as mandatory versus optional associations.The E-R model is widely used as a tool in conceptual database modelling. According to Teoreyet al. (1986):[t]he entity-relationship model has been most successful as a tool for communication between thedesigner and the end user during the requirements analysis and conceptual design phases becauseof its ease of understanding and its convenience in representation. (p. 198)In addition, techniques exist for converting E-R schemata to schemata of the traditional data models. Forexample, Teorey et al. discuss the conversion of an extended E-R schema to a normalized relationalschema.2.3.2 SDM (Hammer and McLeod, 1981)The Semantic Data Model (SDM) is, as its name suggests, a data model intended to capture thesemantics of data with a set of constructs that are claimed to be "natural" for modelling databaseapplications. One of the stated objectives of SDM is to "serve as a conceptual database model in thedatabase design process" (Hammer and McLeod, 1981, p.351). More specifically:Our goal is the design of a higher-level database model that will enable the database designer tonaturally and directly incorporate more of the semantics of a database into its schema. Such asemantics-based database description and structuring formalism is intended to serve as a naturalapplication modelling mechanism to capture and express the structure of the applicationenvironment in the structure of the database. (p. 352)Despite this, the authors do not indicate what constitutes "naturalness". They do present a number of26modelling constructs but do not justify the choice of these constructs nor evaluate their naturalness.As with other semantic models, SDM views a database as a collection of entities correspondingto things in the application domain. Entities possess attributes, and are organized into classes, which sharecommon attributes. Classes are related to other classes via interclass connections.The specific treatment of classes, attributes, and interclass connections in SDM is as follows.Classes introduce a classification abstraction. A class consists of a set of entities, which may be concreteobjects (e.g., persons), events (e.g., transactions), names, or even classes25 (e.g., kinds of ships). Classesare characterized in terms of member attributes, which describe each member of a class by relating it toone or more members of the same or other classes. Classes also possess class attributes which describeproperties of the class as a whole.SDM also distinguishes base from non-base classes. Non-base classes are defined in terms ofinterclass connections to other classes (e.g., subclasses linked to superclasses by IS-A connections). SDMrecognizes two essential kinds of interclass connections, subclass and grouping connections. Subclassconnections establish IS-A links between classes. Subclasses may be defined based on common values foran attribute (e.g., Address='Vancouver'), or on other criteria. Grouping connections are used to definemetaclasses.Attributes in SDM are used to describe classes. The instances of a class possess a value for eachattribute of the class. A value is either an entity in the database or a collection of such entities. Attributesmay be mandatory (null values not allowed) or optional (null values allowed). In addition, an attribute maybe specified as the inverse of another attribute.SDM does not describe entities (or classes) in terms of their behavior, or how attribute values may(or may not) change over time. In addition, it provides a large number of convenient mechanisms (rules)for describing how subclasses may be defined and attributes constrained. However, there is no indication25A class of classes is generally referred to as a metaclass.27that these are in any way complete, nor any argument as to why they are natural.2.3.3 FDM/DAPLEX (Shipman, 1981)The Functional Data Model (1DM) (and the accompanying data description language DAPLEX)is a semantic data model based on functional representation. The model has two basic constructs, entityand function. The stated goal of the model is:to provide a conceptually natural database language. That is, the DAPLEX constructs used tomodel real-world situations are intended to closely match the conceptual constructs a human beingmight employ when thinking about these situations. (Shipman, 1981, p.140)However, the authors do not indicate how this matching is achieved.In the language DAPLEX, data are modelled as entities which are intended to directly represententities in the user's reality. Functions model relationships among entities (i.e., properties and otherassociations). Properties may be primitive, or derived from previously defined properties.Functions are also used to define entity types or classes (as function without arguments). Althoughthere is no explicit mechanism for class specialization, functions can be introduced to model thisabstraction. Also supported is function inversion, recognizing that properties may be inverses of otherproperties (e.g., Child_of and Parent of). Furthermore, derived functions may be used to define variousviews of a database, thereby supporting semantic relativism. Functions may also be used to enforce severalkinds of integrity constraints.To summarize, FDM/DAPLEX is a semantic model (and data language) based on two fundamentalconstructs, entity and function. Entities are intended to correspond to real-world objects. Functions playa large role in defining properties, abstractions such as classification and generalization, and user views,as well as in enforcing integrity constraints. FDM does not deal with representing information about thebehavior of entities. Finally, FDM has served as the foundation for Iris, an object-oriented data model (seeSection 2.4.2).282.3.4 Other Semantic Data ModelsThis review has summarized a number of important semantic data models to highlight the natureof the constructs used and the similarities and differences among models. More extensive reviews containdetails of these and other models (e.g., Peckham and Maryanski, 1988; Hull and King, 1987). Among theother significant models are the Semantic Association Model (SAM*) (Su, 1983), which introduces a largenumber of association types (membership, aggregation, interaction, generalization, composition, cross-product, and summarization), and the event model (King and McLeod, 1984), which supportsclassification, generalization, and aggregation, as well as dynamic modelling via events.2.4 OBJECT-ORIENTED MODELS2.4.1 The Object ParadigmHistorically, the technologies available for constructing information systems have not been basedon a model that views an IS as a representation of knowledge. Perhaps as a consequence, the plethora ofmethodologies for creating a set of user requirements for a system, and then translating these requirementsinto a collection of programs, data files, and guidelines for use, have frequently failed to produce systemswhich meet users needs and/or expectations.Recently, however, a new metaphor of computing - the object paradigm - has emerged andattracted a lot of attention, as evidenced by the proliferation of literature on the subject. For example, Kimand Lochovsky (1989), Meyrowitz (1989; 1988; 1987; 1986), Schriver and Wegner (1987), and Sigplan(1986) are devoted to object-oriented programming, while papers in Kerschberg (1986) and Kerckhoffset al. (1986) apply the paradigm to databases and simulation, respectively. This interest is at least in partbecause of claims that object-oriented constructs are more "natural" than those of previous approaches.Since the objective of this research is to develop an IS model that provides for the direct representation29of knowledge and, hence, could reasonably be called "natural", it is useful to determine the extent towhich the object model of computing does allow for the direct representation of knowledge.The essence of the object paradigm is the encapsulation of data and the procedures which operateon that data in a single unit called an object (Nierstrasz, 1987; Rentsch, 1982; Robson, 1981). A secondfundamental construct is that class objects and instance objects are distinguished, with classes providinga common form for creating instances which are in one-to-one correspondence with entities in somedomain. Other constructs are also used, such as specialization/inheritance, independence, homogeneity,message passing, and composition. However, there is widespread disagreement as to which of these arenecessary to the paradigm (e.g., Nierstrasz, 1989; Wand, 1989; Banerjee et al., 1987; Pascoe, 1986).The roots of object-oriented computing go back to the simulation programming language SIMULA(Birtwistle et al., 1973). This language introduced both the ideas of encapsulation and of class/instancedistinction. Simulation applications dealing with entities serviced by physical facilities, both of which haveproperties important to the application, are well-suited to modelling via objects. The other primarycontribution to object orientation was the development of the Smalltalk programming language. Throughvarious refinements (Smalltalk-72, Smalltalk-74, Smalltalk-80, and more recent versions) 26, additionalconcepts, such as independence, homogeneity, and message passing, were introduced to provide a uniformprogramming environment in which everything is represented by objects.The object-oriented approach has been taken beyond the domain of programming languages andsimulation and used as a general modelling tool for databases and knowledge representation systems.Database systems such as IRIS (Fishman et al. 1987; Lyngbaek and Kent, 1986) and ORION (Banerjeeet al., 1987) exhibit varying degrees of "object-orientedness". Frame-based knowledge representationsystems, such as KEE (Fikes and Kehler, 1985) and Nexpert (Neuron Data, 1988) use concepts that arerelated to those available in object-oriented programming languages such as Smalltalk. In addition, the26For a discussion of the evolution of Smalltalk, see Goldberg (1984).30constructs have been applied more generally to the analysis and design of information systems (e.g., Coadand Yourdon, 1991; Bailin, 1990; Henderson-Sellers and Edwards, 1990; Wirfs-Brock and Johnson, 1990).Two uses of object constructs involving conceptual modelling are surveyed here. The first isobject-oriented data models, which are closely related to, and extend, earlier semantic data models (King,1989). The second is the recent explosion in interest in object-oriented analysis and design.2.4.2 Object-oriented Data ModelsIn recent years, there have been several research efforts aimed at developing database systemsbased on object-oriented data models such as ORION (Banerjee et al., 1987), IRIS (Fishman et al., 1987),and ENCORE (Hornick and Zdonik, 1987). In general, these models extend concepts taken from object-oriented programming to consideration of technical issues critical in a database environment. Such issuesinclude persistence of objects, data integrity, data security, data sharing, changes to database schema, andquery management.ORION (Banerjee et al., 1987) is an object-oriented data model supporting encapsulation,classification, inheritance, and message passing, as well as composite objects (i.e., objects that arecomprised of other objects as parts and are treated as a unit for storage, retrieval, and integrity purposes),dynamic schema evolution (i.e., changes to class definition and hierarchy), and versions. Some of theadditional features are intended specifically to meet the needs of engineering "design databases".Other features of ORION expand on the object paradigm. For example, the model supportsmultiple inheritance of properties and behavior, so that classes are arranged in a lattice or directed acyclicgraph. A special set class is predefined (instances of which are sets) to facilitate predicate-based querieson a database. This class has messages for searching a set, adding elements, and so on.In addition, the semantic construct PART_OF27 is captured through the specification of composite27This corresponds to a composition abstraction.3 1objects. A composite object is one with a hierarchy of exclusive component objects (i.e., no componentmay belong to more than one composite object). In implementation, clustering of these composite objects(which are often used together) on secondary storage devices reduces retrieval time. Provision is also madefor the more general concept of aggregate objects. These are loose collections of objects forming a coveraggregation'''. Aggregate objects can represent many types of relationships among their constituents, ascriteria for membership in the aggregate can be specified by the user. Consequently, an object canparticipate in many aggregate objects.As with several other object-oriented database systems (e.g., Hornick and Zdonik, 1987), ORIONsupports multiple versions of objects. This is a consequence of the particular class of applicationsenvisioned for the ORION system - engineering design databases.ORION also supports the notion of a stored-value variable (for which all instances of a class takeon a specified value). This is analogous to the use of class variables in the programming languageSmalltalk (Robson and Goldberg, 1981). In addition, the use of default-value variables (for which theinstances of a class whose value for this variable is not defined take on the specified default value)corresponds closely to the use of default values in frame-based knowledge representation schemes (Bobrowand Winograd, 1977).The IRIS database system (Fishman et al., 1987; Lyngbaek and Kent, 1986) is the result of anothereffort to combine an object-oriented data model29 with the features necessary to form a complete databasesystem (e.g., transaction management, query management, concurrency control). As in other systems, IRISobjects represent entities and concepts from the application domain. These objects are completely28SDM (Hammer and McLeod, 1981) provides the example of a convoy of ships as such anaggregation. In addition, this abstraction mechanism parallels what is called association in ACM/PCM(Section 2.2.3).291n this case, the system is based on the functional data model DAPLEX (Shipman, 1981) describedearlier (Section 2.3.3).32described by their defined and inherited behaviors and property values, and are classified by type. Manyof the features supported by IRIS are similar to other object-oriented database systems such as ORION.These include:• class definitions in terms of properties and methods,• type hierarchies and multiple inheritance,• object independence.Another database system based on an object-oriented model is the GemStone system (Bretl et al.,1989). GemStone extends the Smalltalk approach to object orientation in the context of programming byproviding mechanisms for concurrency control and data integrity in a multi-user environment, and formanaging the physical storage of objects. The grounding in Smalltalk means that the system exhibits theobject-oriented characteristics of the Smalltalk programming language.2.4.3 Object-oriented AnalysisWithin the last few years, attention has been focused on object-oriented approaches to systemsanalysis and design (e.g., Booch, 1991; Henderson-Sellers and Edwards, 1990; Bailin, 1989; Pressman,1987). In particular, object-oriented constructs have been claimed to correspond to the way peopleorganize knowledge and, hence, to be useful for representing knowledge (Coad and Yourdon, 1991). Inthis section, the main elements of the approach to analysis advocated by Coad and Yourdon is reviewed.According to Coad and Yourdon, object-oriented analysis (OOA) borrows from both semantic datamodelling and object-oriented programming domains. The first step in OOA is identifying objects. Theapproach allows for distinguishing between things that exist in the domain and a class for describing thecommon attributes of a collection of things. The justification offered for identifying objects is to "matchthe technical representation of a system more closely to the conceptual view of the real world" (p. 53).Classes, once identified, are related to other classes by two abstraction mechanisms:33specialization/generalization and whole/part (or composition). Each class is then described in terms ofattributes which define the structural properties of instances. Finally, services model the behavior ofobjects in time. Services are described in terms of processing (i.e, the how, rather than the what).On the whole, OOA contains mechanisms similar to those of other conceptual models andsemantic data models, including the notion of correspondence between entities in the domain andsurrogates (objects) in the representation, the abstraction mechanisms of classification, aggregation,specialization, and composition (the last not being adequately dealt with in most other approaches), alongwith the encapsulation of structural and behavioral knowledge.The justification for OOA constructs centers around "naturalness". The authors explain their choiceof constructs based on "classification theory" as described in the Encyclopedia Britannica (see Coad andYourdon, 1991, p.1). However, there are at least two problems with the justification. First, theclassification theory constructs used are not clearly or precisely defined, and the authors do not make useof widespread literature in cognitive science on classification or concept theory 30. Second, thecorrespondence between these constructs and those of OOA is not precisely indicated.2.5 SUMMARYIn most approaches to conceptual modelling (including semantic data models and object-orientedanalysis) described above, several themes are evident. First, there is a strong emphasis on acorrespondence between model constructs (objects, instances, and so on) and things in the domain ofinterest. Second, there is widespread use of abstraction mechanisms in the various models. This suggeststhe importance of abstractions in modelling knowledge about a domain. Although the exact mechanisms30For example, Coad and Yourdon state:It would be intellectually satisfying to the authors if we could report that we studied the philosophical ideasbehind methods of organization ... . Then, based on the underlying methods human beings use, we couldpropose the basic constructs essential to an analysis method. But in truth, we cannot say that, nor did wedo it. (1991, p.16)34vary from model to model, some conclusions are clear. Classification and (some form of) aggregation areubiquitous, generalization/specialization is nearly universal, but composition and association are presentin only some models. Third, there is a strong tendency to capture both structural and behavioral propertiesof entities in an application, although the tendency to define classes in terms of both is less commonDespite this commonality, with the notable exception of OBCM, there has been little effort torigorously explain or justify the constructs chosen in any modelling approach on the basis of naturalness.In particular, many semantic data models have been described as providing a "natural" approach tomodelling, without indicating what is meant by natural, or how naturalness is achieved in the model. Suchmodels have been marked by a lack of theory to support constructs used, relying instead on intuitiveappeal and convenience. OOA goes one step further by relating the model to classification theory, butprovides neither a clear description of the theory nor a precise indication of how OOA directly reflectsclassification theory. On the other hand, while OBCM does present a rigorously defined set of constructsfully supported by a comprehensive ontology, it avoids issues related to the fact that conceptual modellingultimately deals with representing knowledge of reality. Consequently, it may prove valuable to combinea formal approach, as taken by OBCM, with an explicit focus on theories of the organization ofknowledge about entities, as hinted at (but not explored in detail) by OOA.This thesis is motivated by the belief that a lack of attention to the nature of concepts andclassification hinders the development of a "natural" conceptual model. The primary claims to bedemonstrated are that a formal conceptual model can be developed based explicitly on a theory ofclassification, and that such a model provides useful modelling insights. Since a basic assumptionunderlying the work is that an information system represents knowledge about things in an organization,an obvious area to look for a foundation for conceptual models is one which deals with the theory ofrepresenting knowledge about things. To this end, Chapter 3 is devoted to a review of literature incognitive science/psychology dealing with theories of concepts and classification.CHAPTER 3CONCEPT THEORIES AND MODELLING IMPLICATIONS3.1 CONCEPTS AS A BASIS FOR INFORMATION SYSTEMS MODELS3.1.1 IntroductionAs stated earlier, a basic assumption of this thesis is that IS development can benefit by directlyadopting the view that an information system represents knowledge about things in an organization. Inorder to develop a precise model of IS which embodies this assumption, a grounding in theories ofknowledge about things is required. In this chapter, three theories of concepts, which deal with thestructure and organization of knowledge about things, are briefly reviewed. One of these theories is thenselected as a foundation for the model of knowledge that is developed in Chapter 4.3.1.2 Reference DisciplinesCognition is studied in many fields of research. Three fields which are most relevant and whichhave provided much insight are psychology, artificial intelligence (AI) and philosophy 31 . Work in theseareas sometimes converges in a hybrid field referred to as cognitive science (e.g., Winograd and Flores,1987; Haugeland, 1981).While one goal of research in these fields is essentially the same (i.e., a better understanding ofcognition), the research methodologies used differ considerably. Cognitive psychology is not just a studyof cognition. It is also a methodology for conducting research, since the experimental method is the meansby which research in cognitive psychology is carried out. Artificial intelligence focuses instead on the31Additionally, considerable work in linguistics is relevant to cognition. Such work is covered hereonly to the extent that it overlaps with philosophical and psychological investigations (e.g., Lakoff, 1987).3536performance of machines. Insight into cognition is gained by constructing computer programs that behavein some way as a human would under specified conditions. Finally, philosophical investigations ofcognition rely on logical arguments that provide explanations consistent with commonly observable (asopposed to experimentally induced) human behavior.Despite these methodological differences, there is considerable agreement between the theories ofcognition advanced in each field. Consequently, while the theories described here are taken primarily frompsychological literature, they are consistent with work done in AI, philosophy, and linguistics.3.1.3 CognitionFor the purposes of this research, cognition is defined as:the acquisition and use of knowledge by humans, including "all processes by which the sensoryinput is transformed, reduced, elaborated, stored, recovered and used." (Best, 1986, p. 4)32Cognitive activity is extremely varied and complex. Humans engage in such diverse activities asperceiving, understanding perceptions by relating new experiences to existing knowledge, locating andusing relevant knowledge in diverse situations, making decisions, reorganizing knowledge based on newexperiences, making plans or establishing goals, seeking means to achieve goals, and engaging in activityto accomplish these goals (e.g., Best, 1986; Medin and Smith, 1984; Simon, 1979; Crutchfield, 1973;Newell and Simon, 1972).One component of cognition critical to survival is our knowledge of things in the real world. Everyperson is exposed to new things daily, and must learn to represent these things and classify them in termsof previous experiences in order to survive. The importance of classification or categorization to humanlife is widely recognized by cognitive scientists. As Lakoff (1987) states:32The quote is actually offered by Best as a definition of cognitive psychology. However, inaccordance with section 3.1.2, cognitive psychology is here viewed more narrowly as imposing a particularmethodology - laboratory experimentation - for investigating the phenomena described above.37Without the ability to categorize, we could not function at all, either in the physical world or inour social and intellectual lives. An understanding of how we categorize is central to anyunderstanding of how we think and how we function .... (p. 6)Similarly, Smith and Medin (1981) open their well-known book on concepts and categorization with thestatement:Without concepts, mental life would be chaotic. If we perceived each entity as unique, we wouldbe overwhelmed by the sheer diversity of what we experience and unable to remember more thana minute fraction of what we encounter. (p.1)There appear to be two primary functions of concepts (Smith, 1978). The first is to support whathas been called cognitive economy (Bosch, 1978). By grouping many instances into a single category,these instances are identified as being the same in certain respects. Usually, this can be taken to mean thatthe instances share some set of properties, referred to as a concept. This permits reasonable questions tobe asked with respect to known instances of the concept. For example, if the concept EMPLOYEE hasas one its defining properties Department, meaning that each employee works in one department, thenit makes sense to ask "which department does x work in?", for any x who has been previously classifiedas an employee. Similarly, given a new individual y, if we are told that y works in a department, we maybe able to classify y as an EMPLOYEE".The second important role of concepts emerges from the previous statement. If an individual isclassified in a particular way on the basis of incomplete information about its properties (i.e., on the basisof knowing only a subset of its properties), one can infer additional properties of interest that theindividual must possess. That is, possessing a subset of properties may imply that an individual possessesanother subset, all of which are defining properties of the concept. For example, people learn fromexperiences with fires that they generate heat. Consequently, on observing a distant fire (by the presenceof flames), an individual "knows" that it will be hot, even if the heat is not felt at that distance. Of course,33This holds only if EMPLOYEE, along with specializations of it such as SUPERVISOR, are theonly concepts which have the property Department. Otherwise, knowledge of additional properties maybe needed to classify an instance.38misclassification sometimes occurs. When this happens, we may question our perception of the thing,refine our conceptualization to either define the associated category more precisely, or develop a newconcept based on the experience.3.1.4 Concepts and World KnowledgeEvery theory of knowledge about reality makes (sometimes implicit) assumptions about the natureof what is represented: that is, assumptions about reality. The branch of philosophy that deals with thenature of reality is ontology. Most research in cognitive science presupposes an objectivist ontology (seeLakoff, 1987; cf. Newell and Simon, 1976). That is, the world is assumed to consist of concrete thingsor entities34 that are associated in various ways.It is not the intent of this thesis to deal explicitly with the nature of reality. Instead, the focus ison providing a formal description of cognitive representation that constitutes the basis for a conceptualIS model. However, it is worth explicitly mentioning (without detailed comment) a few ontologicalassumptions that underlie this research, and the implicit relationship between reality and its representation.These assumptions are given without comment. A formal treatment of these and many more aspects ofthe nature of reality can be found in, for example, the ontology of Bunge (1977;1979).The fundamental building block of reality is the thing. Things are described by characteristics (orproperties). Collections of physical or abstract things may share some characteristics. A concept is, forthis research, defined as a mental abstraction of the common characteristics of a collection of things.Things, in turn, are represented mentally by what are called instances. An important premise of this workis that concepts and instances together, and their organization, make up our mental representation of thereal world. That is, they constitute our knowledge of things.340ften, the word object is used synonymously with thing or entity. However, in this proposal, theword object has a specialized meaning, introduced in Chapter 2, and which is refined and formalized inChapter 4.393.1.5 Components of Conceptual RepresentationTo represent a thing adequately, its various properties must be accounted for. For this research,four components of knowledge are identified35.First, perception of an individual thing leads to representation of its existence. Second, there arevarious structural properties that characterize a thing (Smith, 1978; Bruner et al., 1956). Third, a thinghas physical or abstract relationships to other things (Smith, 1978). A relational property describes anassociation among two or more things that holds for some period of time. This association may becharacterized by its own structural and relational properties, and by constraints on the behavior of theparticipating entities. Some relationships are permanent, while others are transitory. Finally, there are rulesgoverning the behavior of things in various contexts (Smith, 1978). Behavioral properties determine theallowable changes in the values of other properties. Each property of a thing belongs to exactly one ofthese categories.This view of the components of knowledge is similar to the characterization of objectivism givenby Lakoff (1987):objectivism holds that reality is structured in a way that can be modeled by set-theoretical models;that is, the world consists ofentities [existence]the properties of entities [structure/behavior]the relations holding among those entities. (p. 159)35These components are not always explicitly recognized in the literature. However, examples of eachand their role in categorization can be found, for example, in Categories and Concepts (Smith and Medin,1981). Chapter 4 formally defines each of these elements.403.1.6 IS Models and Conceptual RepresentationKnowledge of things in the world may be characterized in terms of high volume and complexity.This often makes it difficult to accurately recall large amounts of data, or to recall data about a specificthing in a reasonable period of time. Further, knowledge tends to decay over time if not frequently used.For these reasons, people have devised many aids to relieve the cognitive burden of "knowing the world".One of the tools that has proved most useful and reliable in this respect is the computer.The data and programs that inhabit a computer can be viewed as representations of knowledgeabout some aspects of the real world (Abbott, 1987; Brooks, 1987). Data capture static knowledge aboutthings, whereas programs may describe their behavior. According to Abbott's "principle of knowledgeabstraction":It is the domain-level knowledge embodied by a program that represents the program's only realconnection to the problem domain. (1987, p. 667)In organizations, the knowledge contained in an IS relates to the elements of reality relevant tothe functioning of that organization. Typically, these include employees, products, customers, suppliers,contracts, and so on. However, since we know the world only through our cognitive representation of it(concepts and instances), an IS is ultimately a representation of a conceptual system as is any intermediateproduct of IS development (e.g., an Entity-Relationship diagram). Consequently, the following workinghypothesis motivates the current research.Working Hypothesis:Methodologies for IS development can benefit from an IS model based explicitly andformally on a theory of concepts.413.2 THEORIES OF CONCEPTSA theory of concepts generally specifies several things. Foremost, the structure or internalcomposition of cognitive abstractions, as well as the relationship between concepts and things perceived,must be explained (Medin and Smith, 1984). In addition, mechanisms for determining whether an instancebelongs to a category are needed (Bruner et al., 1956). Furthermore, a comprehensive theory shoulddescribe how concepts are related to other concepts in memory (Smith, 1978; Collins and Loftus, 1975;Quillian, 1968), reflecting how things are linked in reality. Finally, a theory of concepts should offer anexplanation of how concepts are acquired36.Theories of concepts that have been proposed in psychology, AI, and philosophy are in many wayssimilar. They differ primarily in the manner of accumulating evidence to support or refute theirpredictions. In particular, the three psychological theories examined here are each surrounded by a varietyof experimental evidence (see Smith and Medin, 1981 for a summary). For each theory, there is evidencewhich is consistent with the theory's predictions, as well as evidence that contradicts its predictions.3.2.1 Classical View3.2.1.1 TheoryThe oldest and most precise psychological theory of concepts has been with humans in one formor another since the ancient Greeks. In its modern incarnation, the classical view was first detailed andstudied by Bruner, Goodnow, and Austin (1956) 37. This theory holds that a concept can be stated in36The review of concept theories in this chapter does not discuss the position of each theory withregard to concept acquisition.37It should be noted that the studies reported by Bruner et al. were primarily concerned with strategiesfor acquiring concepts. However, the nature of the concepts used forms a useful basis for describing theclassical view.42terms of individually necessary and jointly sufficient conditions for membership of a thing in a category.That is, the conditions define the concept.To illustrate this, suppose that A designates the set of all known instances (each representing athing) sharing properties P1, P2, and P3. Then a new instance is classified as belonging to the conceptassociated with A if and only if it has properties P1, P2, and P3. The concept, then, is the three properties.In symbols:C = {Pi, P2, P3 ), andA = { alP 1(a),P2(a),P3(a)) ,where C designates a concept and a designates an instance of A. For example, a classical definition ofa triangle is:P1:closed figureP2:bounded by three line segments.Obviously, other properties characterize a triangle (e.g., sum of the angles is 180). These lead toalternate definitions. However, the other properties of a triangle can be derived from the above definition.From this, a looser view of necessary and sufficient conditions can be stated, in which there may beseveral subsets of properties, each sufficient to classify an instance 38 . This supports classification on thebasis of incomplete information, and enables one to infer the presence of other (possibly non-observed)properties as discussed in Section 3.1.3.A tacit assumption of the classical view is that all concepts can be defined this way. Furthermore,concepts can be organized hierarchically by the consideration of proper subset relations among sets ofproperties (Keil, 1979). For example, the set of equilateral triangles is a subset of the set of all triangles,and possesses properties in addition to every property possessed by all triangles (e.g., line segments areof equal length).38The model developed in Chapter 4 adopts this relaxed view.43Classical concepts can also be linked by part/whole associations (see, e.g., Miller and Johnson-Laird, 1976). In some contexts, a concept is viewed as a collection of parts or components. For example,in an automobile manufacturing context, a car may be best thought of as a collection of parts, includinga motor, chassis, and frame. The configuration of these components, however, yields a composite conceptwith emergent properties. For example, considered holistically, a car has properties, such as fuelconsumption, that are not properties of any of the components3.2.1.2 ExtensionsBruner et al. (1956) do not fully describe what may constitute a property or attribute that may beused to define a concept. They do, however, state that an attribute is:any discriminable feature of an event that is susceptible of some discriminable variation from eventto event". (p.26)It is clear from the experiments they conduct that structural properties may be used in thedefinition of a concept, since the concepts they use differ on clearly discernible properties of visualstructure. For example, a structural property of a triangle is that it is a closed figure.In addition, behavioral and relational properties can be used to define a concept (Glass andHolyoak, 1986), as expected from the characterization of components of knowledge about things, statedearlier. For example, the concept of STUDENT can be defined as a specialization of the concept ofPERSON. The specialization involves defining students as those instances of person that are involved ina particular relationship with the instances of another concept called SCHOOL.39It is clear from the context that, by "event", is meant a perception of a thing or entity. For example,they define a "criterial variable" as "a discriminable feature ... used as a means of inferring the identityof something." (p. 26, italics mine)443.2.1.3 ApplicabilityIn the experiments described in Bruner et al., the concepts used are artificial, based on sets ofgeometric figures that share certain physical properties. In other empirical work on the classical view, theconcepts used tend to be quite concrete (e.g., Armstrong et al., 1983; Bourne et al., 1976).The use of classical concepts, in the form of technical definitions, is most obvious in domains suchas mathematics and the physical sciences. In these fields, precise definitions are needed for theorydevelopment, experimentation, and measurement. Furthermore, the criticality of technical (formal)definitions to a field such as mathematics demonstrates that concepts need not contain instances thatrepresent perceptible things in order to be subject to precise defmitions in terms of necessary and sufficientconditions.3.2.1.4 LimitationsThe limitations of the classical view can be subdivided into two categories. First, the nature of theconcepts to which technical definitions can be applied appears limited to those representing either physicalthings or abstract things which are not subjectively interpreted by the individual (Lakoff, 1987; Armstronget al., 1983). Thus, concepts such as honesty and fairness are not definable under the classical view (Glassand Holyoak, 1986). Interestingly, these are concepts that would not generally be regarded as containingidentifiable things.The second set of limitations appears more substantive. Considerable experimental work has beendone in testing the classical theory. As a result, a number of well-known criticisms have emerged (Smithand Medin, 1981). For one thing, the theory does not account for so-called typicality effects (Armstronget al., 1983; Roth and Shoben, 1983; Rosch and Mervis, 1975). That is, in experiments, some instancesor specialized concepts are described as more typical of the concept than others (e.g., equilateral versus45obtuse for triangle)40. Clearly, though, this need not be a problem with the ability to define conceptsunambiguously. Instead, typicality may be an empirical phenomenon relating to the relative frequency ofexperiences with the various exemplars of a category. The level of exposure to, or familiarity with, certainexemplars (facts) may produce such an effect (cf. Tversky and Kahneman, 1984).In addition, Roth and Shoben (1983) have shown that the degree to which exemplars areconsidered typical of a category depends on the context in which information is presented, indicating thattypicality is situation specific. Furthermore, in most of the arguments that have proposed this as aweakness of the theory, the tests that have been used in fact compare concepts to concepts (e.g., Medinand Smith, 1984; Rosch and Mervis, 1975). Thus, typicality, as the term has been used, often implies ameasure of the association between two concepts (as in the case of equilateral vs. obtuse triangles), andnot between an instance and a concept. Consequently, researchers should be comparing, for example,instances of equilateral triangles and those of obtuse triangles in an attempt to assess typicality.Another criticism of the classical view is that people have very limited success in accuratelystating necessary and sufficient conditions for membership in most categories (Medin and Smith, 1984;Posner and Keele, 1968; Wittgenstein, 1958). This has been used to support the proposition that peopledo not use such conditions to classify. However, this situation may be akin to one of recognition versusrecall. As most exam situations demonstrate, human recognition ability exceeds recall ability. Thus,information that is represented cognitively need not be immediately articulable Similarly, a failure to statedefining conditions does not demonstrate that subjects do not use them in making classifications. A lessdirect, but equally valid, test of whether people use technical definitions to classify is to measure theirsuccess in classifying instances of well-defined concepts. Evidence ranging from laboratory experiments(Bruner et al., 1956) to the survival and adaptation of the species suggests that people tend to be very40Note that equilateral and obtuse are also concepts that are special cases of the more general concepttriangle. This refinement of concepts makes possible their arrangement into hierarchies (see Section 3.2.4).46good at correctly classifying things.3.2.1.5 SummaryEmpirical work on the classical theory of concepts shows that while the theory does not accountfor the observed behavior of people in all classification and concept definition tasks, there is support forthe theory as a description of our abstraction of the common elements of concrete and/or technicallydefinable things in the world.Even advocates of other theories of concepts concede that the classical view is appropriate in well-defined domains (Lakoff, 1987; Medin and Smith, 1984; McCloskey and Glucksberg, 1978). For example:the typicality rating, verification latency, and truth judgment data do not exclude the possibility thatcategories have clear boundaries. (McCloskey and Glucksberg, 1978, p. 462)[W]hile [people] may appear to have vague and fuzzy notions about the criteria for categorymembership, they could, in principle, learn more about such concepts and then be perfectlyconsistent in their judgments. (p. 466)A technical taxonomy would be an example of such an idealized category system. (p. 466)[Under the classical view], a conceptual category is defined in terms of necessary and sufficientconditions shared by all members. Such conditions include properties of entities and relationsholding among entities. (Lakoff, 1987, p. 166) ... Such metaphysical assumptions about physicalobjects certainly won't get us into trouble when we are dealing with tables and other familiarphysical objects. (p. 175)3.2.2 Prototype View3.2.2.1 TheoryThe prototype theory of concepts and concept formation emerged largely as a response to theproblems identified in experiments on the classical theory (Smith, 1988; Medin and Smith, 1984; Smithand Medin, 1981). In this view, concepts are defined by prototypes, or statistical abstractions, in whichthe value of each feature or property is computed as the average of the value of that feature for the known47instances of the category (Rosch and Mervis, 1975; Rosch, 1973; Reed, 1972; Posner and Keele, 1968) 41 .Thus, properties are no longer defining, but are probabilistic. All properties need not be shared by allmembers of a category.One interesting consequence of this theory is that concepts change as new instances are classifiedbut, nevertheless, become more stable as the set of instances grows (Glass and Holyoak, 1986). Thus, thetheory addresses the phenomenon of concepts from a developmental perspective (Rosch, 1973).Membership of an instance in a category is determined by comparing a candidate instance againstthe prototype, and accepting if the candidate does not differ "significantly" from the prototype. Theconcept or prototype is then updated by incorporating the new instance into the average of features.3.2.2.2 ApplicabilityAs a developmental theory, the prototype view accounts for the types of errors that can beobserved among children during the acquisition of concepts and the modification of a concept that occursafter a misclassification (Rosch, 1973). If a new instance differs on some important dimension from theexisting instances, the prototype must be modified to accommodate this difference.That the theory was developed specifically in response to the empirical problems of the classicalview is evident from its ability to handle typicality effects. The prototype itself is regarded as the mosttypical instance (Medin and Smith, 1984). Less typical instances are ordered by their "distance" from theprototype (Rosch, 1973). Further, since the concepts used in tests of the theory are often not defined bynecessary and sufficient conditions (e.g., Posner and Keele, 1968), it is not surprising that people cannotelucidate such conditions in experimental situations where statistically abstracted concepts are used.As with the classical theory, the nature of the concepts that may be defined with a prototype41There are several variations on prototype theory. These are encompassed in the citations given here.The details of these differences are outside the scope of this research and, hence, are not discussed.48theory seems to be those that abstract from physical things.3.2.23 LimitationsThe most serious problem with this theory is that most proposed versions of it do not specify howproperties are averaged42. This is especially relevant when a property is qualitative rather thanquantitative, and gives rise to the attachment of probabilities to the presence and/or values of variousproperties in a given instance (Medin and Smith, 1984). Unfortunately, procedures for calculating theseprobabilities are not clear. In addition, the notion of "significant" differences between a prototype and acandidate instance is generally ill-defined in prototype theories.Additionally, the theory is unable to account for the fact that people are capable of elucidatingnecessary and sufficient conditions in many situations. In particular, sufficient conditions cannot be derivedfrom a prototype. Also, the theory does not appear to account for abstract definable concepts such as thosefound in mathematics.A final criticism of prototype theory as a superior alternative to the classical view (although notstrictly a limitation) is that the apparent use of typicality information to classify instances (identificationprocedure) is not inconsistent with the existence of defining properties (core). In fact, experimentalsubjects often believe that defining properties exist, even if they cannot state them (cf. Armstrong et al.,1983).42All exception is given in Osherson and Smith (1981). These authors give a formalization of prototypetheory and use fuzzy set theory to demonstrate that the formalization yields contradictions. They also pointout that the classical view, and the associated use of standard set theory, is immune to such contradictions.493.2.3 Exemplar View3.2.3.1 TheoryBoth the classical and prototype views regard a concept as an abstraction that is distinct from theinstances which satisfy its definition. In contrast, classification can be treated as a process wherebycandidate instances are compared to stored instances. So-called exemplar theories do not regard a conceptas an explicit abstraction. Instead, the concept is implicit in the instances of a category (Medin and Smith,1984).Exemplar theories hold that candidate instances are evaluated by comparing them to a collectionof existing instances that constitute a category, rather than to an abstraction of these instances.The basis for this position comes from the Wittgensteinian notion of family resemblances(Wittgenstein, 1958; see also Lakoff, 1987). That is, many things can be classified under a common labeleven though any given pair of things in a collection have little, if anything, in common However, eachinstance shares different properties with different instances of the same category'''.3.2.3.2 ApplicabilityAs with the prototype view, the problems incurred by people in specifying necessary and sufficientconditions is consistent with the general theory. That is, since there is no abstraction, it is not expectedthat people would be able to state defining properties for concepts. In addition, the typicality effectsreported by Rosch and her colleagues (e.g., Rosch, 1973; Rosch and Mervis, 1975) can be explained interms of a high degree of similarity of an instance to other instances along several dimensions.43Wittgenstein uses the common concept of game as an example. The diversity of activities that maybe called games seems to demonstrate that there are no properties that all games share, and that it isnonsensical to postulate a prototypical game (Wittgenstein, 1958, pp. 31-34).503.2.3.3 LimitationsThe limitations of exemplar theories of concepts are similar to those of prototype theories. Thetheories are generally ill-specified (e.g., see Glass and Holyoak, 1986; Medin and Smith, 1984). Theanalogy of family resemblances gives only an intuitive understanding of the relationships among instances,and does not appear to be easily formalizable. As with prototype theory, there is also the issue of definingsimilarity and establishing cutoffs for the boundaries of a category. Finally, the theory does not accountfor the ability (and necessity) to rigorously define concepts in scientific and mathematical domains.3.2.4 SummaryThe conflicting evidence on the relative merits of these different theories of concepts has led someauthors to suggest that each theory has certain strengths and is appropriate for certain situations. Inparticular, Smith and Medin (1981) and Lakoff (1987) argue that different theories produce verifiablepredictions in different situations and, consequently, each may be appropriate in certain circumstances.This factor must be considered in selecting a theory for formalizing a model of knowledge about theorganizational domains for which most IS maintain knowledge (see Section 3.3.3).3.2.5 Semantic Organization of ConceptsA theory of concepts alone is inadequate to account for the creation and use of knowledge of thephysical world. An important cognitive activity involves recognizing various associations among concepts.These relationships give further meaning to a concept by linking it to other concepts in certain well-defined ways.The branch of research that studies the nature of the organization of knowledge is called semanticmemory research, and has been pursued widely in both cognitive psychology and AI (e.g., Smith, 1978;Collins and Loftus, 1975; Minsky, 1975; Schank and Abelson, 1971; Quinlan, 1968). Of the many theories51proposed, some, such as the hierarchical-network model (Quillian, 1968) and the predicate-intersectionsmodel (Meyer, 1970), adopt a classical theory of concepts. Others, such as the feature comparison model(Smith, Shoben and Rips, 1974), appear to be based on a prototype theory of concepts. The latter are notexamined here.3.2.5.1 Major Principles"A theory of semantic memory endeavours to explain how we understand concepts in the largercontext of how they relate to each other. In fact, in some theories (e.g., Quillian, 1968), concepts are tobe understood entirely in terms of links to other concepts. Consequently, the major contribution of anysuch theory is a set of constructs describing the nature of relationships 45. These constructs should leadto predictions about performance on tasks that require using relationships among concepts (Smith, 1978).One of the linkages proposed in the hierarchical-network theory of semantic organization is thatconcepts are linked hierarchically. Thus, many concepts are specializations of others. The hierarchy rangesfrom concepts of high generality (Keil, 1979), such as PHYSICAL OBJECT, to ones of high specificity(Quillian, 1968), such as KITCHEN TABLE. Further, properties of higher level concepts are inheritedby all descendant concepts (Smith, 1978; Quillian, 1968). These connections are referred to in mosttheories as IS-A links and lower level concepts may be called specializations. Concepts which arespecialized possess properties in addition to those of the concepts from which they descend (Smith, 1978).A second major conceptual link is that of composition. Many concepts are composites of simpler"'These principles are evident from an examination of the literature, but are not always identified assuch, particularly in some of the early theories. In fact, the principles are dealt with in other areas ofcomputer science, such as database theory, under the label of abstraction mechanisms (Smith and Smith,1977). As noted in Chapter 2, it is interesting that work in this area is often referred to as conceptualmodelling (Brodie et al., 1984).45Network theories of semantic memory typically represent concepts by nodes and links (relationships)by arcs connecting nodes.52concepts, each of which has properties and can be regarded, for some purposes, as independent of thecomposite. In theories of semantic memory, these links are usually referred to as PART-OF (or HAs) links(Smith, 1978). Thus, a CAR can be viewed as composed of a number of other things, including MOTOR,CHASSIS, and FRAME.A composite is not, however, a simple collection of other concepts. It has emergent properties thatare not present in any subset of components. For example, fuel consumption is a property of CAR thatis not a property of any of its components.The third major link is essentially a catch-all covering other types of associations. Theserelationships may or may not be required or permanent. That is, for any instance of a concept, they mayor may not hold, and may or may not change over time (e.g., marriage, employment, and ownershiprelationships do change over time). Temporal links do not appear to be present in some theories ofsemantic memory (Quillian, 1968; cf. Smith, 1978, p. 14).3.2.5.2 Some FindingsMuch of the experimental work on semantic memory has focused on measuring the "closeness"of concepts in terms of the number of links of a particular type (usually hierarchical) that separate twoconcepts (Smith, 1978; Collins and Loftus, 1975; Quillian, 1968). The general prediction of these theoriesis that the closer two concepts are in meaning, the less time should be required by subjects to answerquestions that involve the relationship between the concepts involved".The findings of this work have been mixed. While some support exists for the organization ofconceptual memory as described above (see Collins and Loftus, 1975 for a review), other work has yieldedconflicting results. In particular, response times can be shorter for pairs of items that are postulated to be"For example, "Is a dog a mammal?" would be predicted to be answered more quickly than "Is a dogan animal?", since there are presumably more intervening levels of concepts in the latter case.53connected by more (transitive) links than other pairs (see Smith, 1978). This suggests at least thatknowledge can be retrieved in other than a strict hierarchical manner.3.2.5.3 SummaryHierarchical-network theories of semantic memory seem to be consistent with a classical theoryof concepts. In fact, the classical theory can be used to describe how concepts can be defined asspecializations, compositions, or in terms of temporal relationships among other concepts. In particular,specializations can be defined by the addition of structural, relational, and behavioral properties toconcepts; compositions can be defined in terms of existing concepts (parts), along with emergentproperties that do not belong to any of the parts; and concepts determined by temporal relationships canbe defined by relational properties. This is dealt with formally in Chapter 4.3.3 ON THE CONCEPTUAL REPRESENTATION OF ORGANIZATIONSAn information system exists to maintain information for use by members of an organization. Thescope of information and its use ranges from accounting data kept to satisfy legal requirements tomanagement reports and decision aids which support decisions critical to the survival of the organization.An IS supports human cognitive activity by reducing both memory and processing demands on individualsin an organization with respect to the entities about which information is maintained. Systems andmethodologies, then, need to be able to represent static knowledge about the organization, along withinformation to describe the ways in which this static knowledge can be changed (e.g., Kung and Solvberg,1986; Brodie, 1984; Verheijen and Van Bekkum, 1982).543.3.1 Organization EntitiesAn organization can be viewed as composed of entities belonging to a number of classes. Theseclasses are subclasses of very high level classes which describe an organization's products and the factorsthat facilitate production (physical resources, human resources, financial resources), as well as groups ofentities in the environment that affect the organization's goals and performance (e.g., suppliers, customers,fmancial institutions, governments, etc.). The knowledge about such things that an IS needs to contain canbe broken into the components of knowledge identified earlier: existential, structural, relational, andbehavioral.3.3.1.1 Structural PropertiesMuch of the knowledge of the types of entities described above is factual in nature, and describesstatic elements of instances of the kinds of concepts identified earlier. Employees are represented in termsof properties such as address, birth date and salary. Products are described by such qualities as physicalattributes (e.g., size, weight), cost, and location. Other entities can be similarly described.3.3.1.2 Relational PropertiesSome information may not describe any single class of entities, but rather, possible relationshipsbetween instances of two or more classes of things. Such relationships include contracts of various sorts -including employment, loans, and agreements to supply certain quantities of products under certaincircumstances - as well as relationships that describe physical or logical configurations of entities, suchas the fact that a warehouse contains a certain quantity of a certain product at a particular time.553.3.1.3 Behavioral PropertiesThe behavior of organizational entities that is of interest relates to the manner in which the valuesof structural and relational properties may change. In traditional IS, this behavior is implicit in theprograms that process data. It is not always explicitly recognized that these procedures represent behaviorsof things in the organization that have to be accounted for by the IS (e.g., Abbott, 1987; Kent, 1979).3.3.2 Goals of RepresentationAn organization may conveniently be thought of in terms of the entities or things that compriseit. This is essentially an "accounting" point of view. For this research, an organization is viewed ascontaining a collection of things which operate together to achieve certain goals.Within this context, an IS represents (some of) the things of interest to individuals in theorganization. The development of an IS involves transforming knowledge to a form that can be representedand processed by a computer. As a first step in this process, a vocabulary for describing knowledge (i.e.,a conceptual model) is needed. This model should reflect human concepts of things in the organization,as well as individual things that are instances of these concepts. In general, the concepts of interest relateto the aforementioned resources or assets of the organization, the external entities which affect thedecisions and performance of the organization, and relationships among various entities (e.g., contracts).The purpose of a conceptual model, then, should be to provide constructs to represent all fourknowledge components which describe instances of concepts representing things in the organization, aswell as to represent concepts and their organization.3.33 Suitability of the Classical ViewThe primary things of interest in a representation of an organization are either concrete or describeabstract relationships among concrete things (Mattessich, 1989). Further, for legal, accounting, and56practical purposes, it is most often the case that these things are clearly and unambiguously defined. It waspointed out earlier that the classical theory of concepts is the best available for providing precise technicaldefinitions of concepts. Consequently, the classical view is chosen here as best-suited for providing atheory of representation on which IS models can be based.It may be posited that concepts are inherently subjective and, hence, a general theory of conceptualrepresentation does not account for the fact that different people may have different concepts to representtheir "world". Two arguments reduce the validity of this claim.First, the provision of legal and/or accounting and/or technical definitions of organizational entitiesincreases the likelihood that different members of an organization will have the same conceptualizationsof these entities. If they do not, inconsistencies will be reflected in the behavior of these individuals andshould not be difficult to identify.Second, there is a body of psychological research which shows that there is a nearly universal setof ontological concepts for describing reality (Keil, 1986; 1979)47. This ontological hierarchy describesa number of very high-level concepts, such as physical things, solids, liquids, animals, events, and so on,from which all concepts that serve us in day to day life can be derived as specializations. Hence, thereis good reason to believe that concepts which can be defined by necessary and sufficient conditions willbe shared across members of an organization (although the specific properties of interest may vary amongorganizational members). This supports an implicit assumption in information systems development thatusers share a largely common view of the things in an organization (Bubenko, 1986), although differentusers may be interested in different roles of the same things and, therefore, in different subsets ofproperties.47At least, this seems to be the case within a given society. A discussion of differences among societiesis contained in Women, Fire, and Dangerous Things: What Categories Reveal about the Mind (Lakoff,1987).CHAPTER 4A CONCEPTUAL INFORMATION SYSTEMS MODEL4.1 INTRODUCTIONThe previous chapters have dealt with three levels or domains of analysis (Figure 4-1). At the levelof reality, there are things which possess characteristics. The level of cognitive representation (orknowledge) contains constructs which represent reality. Finally, the level of information systemsrepresentation" contains constructs which represent knowledge. This chapter deals with the second andthird of these levels. The objective is to present a formal conceptual information systems model forrepresenting knowledge about things, which conforms to the classical theory of concepts. In other words,a "vocabulary" is defined (at the third level) on the basis of a set of constructs at the second level.Figure 4-1: Reality, Knowledge, and Information SystemsREALITY^COGNITIVE^EXTERNALREPRESENTATION^SYMBOL ICREPRESENTATION"More generally, this third level can be referred to as a level of external symbolic representation. Thisrecognizes that the representation of knowledge need not be in a machine, but may equally well exist inanother medium, such as paper, in which some form of symbols or surrogates represent elements ofknowledge. Furthermore, this level may contain several sub-levels, such as a written description and animplemented system.5758In order to construct this model, it is first necessary to have a precise view of the constructs ofclassical concept theory, which were introduced only informally in the previous chapter. Consequently,the next section reviews the major elements of the classical view and presents formal definitions of each.Section 4.3 then discusses the importance of directness in developing a conceptual IS model, andoperationalizes directness in terms of a 1-1 correspondence between constructs at the cognitive andinformation system levels. Section 4.4 defines the model MIMIC (Morphological 49 Information systemsModel of Instances and Concepts). In the concluding section, the model is shown to support a necessarycondition for creating good representations. As this chapter introduces considerable notation, Appendix2 summarizes the important symbols used, organized in the order in which they are introduced here.4.2 A CLASSICAL MODEL OF CONCEPTS4.2.1 Basic Constructs of Classical Concept TheoryTo briefly review and set the stage for the remainder of this section, the main elements of classicalconcept theory, as introduced in Chapter 3, are:1. Instance - represents the existence of an individual thing in the world2. Property - describes an instance in terms of structure, relationships, or allowed behavior3. Concept - abstracts the common properties of a set of instances4. Specialization - establishes a concept as a refinement of another5. Composition - recognizes a concept as consisting of  simpler parts and possessing emergent properties.As this research focuses on formalizing these basic constructs, two important simplifications°Morphological means pertaining to structure or form. Accordingly, the proposed model deals withrepresenting the structure or form of knowledge about things.59influence what follows. First, issues involving the potential uncertainty of knowledge are not pursued.For example, a person may know only that the value of a property (e.g., weight) is in a certain range (e.g.,150 to 170 lbs) or that the value is a guess (e.g., 165 lbs). Database researchers will recognize this as aform of closed world assumption (Reiter, 1984). This assumption is deliberately adopted in order to focuson the task of formalizing the basic cognitive structures. Further research would be appropriate to extendthe formalism to deal with various forms of uncertainty.The second simplification is that the model considers only the representation of knowledge aboutsome subject matter. In general, humans also have higher level knowledge about what is known about asubject matter. For example, a person may know the average value of some attribute, such as accountbalance, for the known instances of a class. Such metaknowledge (knowledge about knowledge) is notdirectly captured by the formalism. However, if knowledge is indeed the subject matter of interest, thedefinitions which follow do indirectly offer a framework for expressing knowledge about knowledge.The constructs listed above are described in the cognitive science literature, but are not generallyclearly defined. However, in order to have a formal conceptual model that corresponds to classical concepttheory, precise definitions of each are needed. The remainder of this section is devoted to providing thesedefinitions. The constructs are divided into two types. The notions of instance, along with structural andrelational properties are primitive in that they are not derived from other constructs. After defining thesefundamental constructs, the derived constructs of behavioral property, class, specialization, andcomposition are considered.4.2.2 Primitive ConstructsRecall from Section 3.1.4 that reality is assumed to contain things. The basic constructs ofclassical concept theory suggest that people represent the existence of individual things and haveknowledge of them in terms of structural facts and relationships with other things.604.2.2.1 InstanceThe most basic construct of interest is the instance. An instance is a surrogate or symbol whichdesignates the existence of a thing. Thus, every thing "known" in some domain is known via an instance,and there is a 1-1 correspondence (or a bijective function) between any set of instances and a set of things.The following definitions formalize notions of identification function (1-1 correspondence) and surrogate,and use these to define the instance construct.Definition 1:Let T and W denote sets of equal size, and f:T—AV denote a bijective function. f will be referredto as an identification function of W in T.This means that f describes a correspondence between elements of T and W.Definition 2:Let f:T--)W denote an identification function of W in T. An element tE T is a surrogate of WE Wiff f(t)=w.If t is a surrogate of w, it may stand in the place of (represent) w in suitable situations. Forexample, student numbers are surrogates of students in many administrative contexts in a university.Definition 3:An instance is a cognitive surrogate which designates a thing in the real world.In other words, given some T, W, and a bijective function f:T—)W, an element te T is an instance61if and only if t is a symbol at the cognitive leve150 and w (i.e., f(t)) is a thing. Similarly, T is a set ofinstances if and only if W is a set of things. For example, W may be a set of students and T a set ofnames, each of which uniquely identifies a student.Postulate 1:For any finite set of things, W, there exists a set of instances, T, and a bijective function f:T-4W.This assumption states that a one-to-one correspondence can be established between a finite setof things of interest in some domain, and instances in a cognitive representation of that domain. A usefulway of viewing the nature of instances as surrogates is that they represent the existence of things.However, any things which might "actually exist" in the domain, but which have not been observed, arenot "of interest" and, therefore, are not included in W.4.2.2.2 PropertiesAs defined above, an instance tells us nothing about the referent thing except that it exists. In otherwords, an instance simply names its referent. In most cases, however, people have knowledge of specificcharacteristics of a thing that may distinguish it from other things. In this regard, property is viewed asthe second fundamental construct in cognitive representations.Three kinds of properties will be defined: structural, relational, and behavioral. These correspondto the components of knowledge described in Section 3.1.5. A structural property describes an independentaspect of all elements of a set of things which is stable over some time interval. A relational propertydescribes a relationship, or linkage, between elements of one or more sets of things which is stable over50Ultimately, this means that t has some physical manifestation in the brain. However, the linksbetween the neurophysiology of the brain and cognition are well outside the scope of this research.62some time interval. A behavioral property is derived from structural and relational properties, anddescribes a rule for the allowable changes in the values of the other kinds of properties. Structural andrelational properties are fundamentally different from behavioral properties in that they can be used todescribe the state of instances. Behavioral properties, on the other hand, describe the allowed changes ofstate that instances may undergo. Formal definitions of structural and relational property are given next.The notion of behavioral property is defined later.4 .2 .2.2.1 Structural PropertyStructural properties describe independent qualities that assist in describing similar things.Independence means that a structural property does not describe any association of things. For example,knowledge about people includes knowledge about height, weight, hair color, and so on. Every humanhas a value associated with each of these properties. Values are distinguished from instances in that thelatter possess properties while the former do not. Examples of values include units of measurement suchas kilograms and meters. The values of some properties may be permanent, while others may change. Inaddition, properties generally describe or apply to more than one instance, as evidenced by those listedabove. Consequently, a structural property, S, of a set of instances, T, will be modeled as a finite set offunctions, each of which maps from T to a set of values, V 51 . The reasons for modelling a property asa set of functions are discussed later (Sections 4.2.2.3 and 5.7).51All sets of instances, values and functions dealt with here are assumed to be finite.63Definition 4:Let T be a set of instances, V a set of values, and S = Is i ls i :T-->V1 a set of functions. S will bereferred to as a (simple) structural property of T (Figure 4-2)52 .Figure 4-2: Simple Structural PropertyVExample:Weight (S) is a structural property of humans (T) since (in principle) a set of functions can beconstructed, whose domain is the set of instances representing humans" and codomain is the set of52This may be extended to the case of composite (or emergent) structural properties. A composite (oremergent) structural property is a set S = {s ils i :T 10...0TK-->V}. Emergent properties are considered furtherin Section 4.2.3.4.53For simplicity, a set of instances representing a set of things, W, will hereafter be referred to as theset W. For example, the "set of instances representing humans" will be referred to as the "set of humans".Unless otherwise specified, such statements describe the cognitive representation level.64weight values. Weight describes the weight of every human, with each function in the set describing apotential mapping. That is, for any instance tE T, at a given time (i.e., for some s, indicating an assignmentof weights to people), s,(t)E {xlx is a weight value).Example:Birthdate (S) is a structural property of humans (T) since a function s can be constructed whosedomain is the set of humans and whose codomain is the set of dates. That is, 3 s:T—>V such that s(t)E {xlxis a date} V tE T. This means that Birthdate = {s).The depiction of a structural property in Figure 4-2 can be equivalently described using a set oftables, since each element of the set S in Figure 4-2 is a function. For example:s2The property S, then, is a set {s i ,...,sN} of such tables. As the functions have a common domain, it willbe convenient to speak of the members of the domain as possessing the property.Definition 5:Let S:T--)V be a structural property, and A be any subset of T. A (and each of its elements) willbe said to possess S.65Example:The set of adults (A) is a subset of the set of humans (T). Therefore, adults possess the propertiesweight and birthdate.In addition, A may constitute the intersection of the domains of several structural properties. Sucha set will be called a category.Definition 6:Let SA = S 1 ,...,SK ) denote a set of structural properties having domains T 1 ,...,TK, respectively. Theset A = T ln...nTK will be called a category on SI ..... SK (or simply a category).Example:The set of humans is a category determined by the intersection of a set of properties whichincludes weight and birthdate.Definition 7:The function that describes the mapping for property S at some time 8 will be referred to as theactive function of S (at .5).Example:In the property illustrated in Figure 4-2, one function (e.g., s 2) describes the correct mapping ata given time. Using a specific example, there is a single function which accurately describes theassignment of weight to people. As weights change over time, the function which accurately describesthese assignments changes.66There is an important distinction between the properties weight and birthdate described in theabove examples. In the case of weight, S may contain many elements (functions), while for birthdate,S contains exactly one element. This distinguishes properties that are temporal (changeable) from thosethat are atemporal (unchangeable). In the former case, the active function may change over time, whilein the latter it cannot. This distinction is represented by whether a property set contains more than one,or just a single, function (respectively), thereby capturing the different semantics of these cases. In fact,the treatment of time in this and subsequent definitions is implicit only (see Sections 4.2.2.3 and 5.7). Thatis, while the value of a property may change (as in the weight example), time is not a parameter ofproperty functions 54. The fact that values of a property may change is modelled by the presence ofseveral elements (functions) in the property set, only one of which is active. Change, and the passage oftime, is understood by the fact that different functions from a set containing more than one element maydescribe the instance. This is a simple way of distinguishing the permanent or temporal nature of propertyvalues for a set of instances.4.2.2.2.2 Relational Property (binary, n-ary, optional, required)Some knowledge of instances can only be described with reference to other instances. A relationalproperty is an association of instances which describes an association of things. For example, commonrelationships such as employment and ownership constitute knowledge of things beyond structuralproperties. The former describes an association between a person and an organization. The latter describesan association between a person (or organization) and other things.A binary relational property, R, of a set of instances, T, is defined as a set of functions, each ofwhich maps from T to Q, a subset of the power set of another set of instances, T 1 (i.e., Qc p(Tl)). The54An alternative treatment would be to model a property as a single function of both instances andtime. That is, S:TOA—N, where it denotes a set of time points.67codomain is specified as a subset of the power set to indicate that an instance in T may be linked witha fixed or varying number of instances of T I . For example, a relational property "has parents" links eachperson with two other persons (with additional restrictions) and, therefore, the codomain of the propertyis restricted to a subset of the power set of persons which contains only sets with two elements.Definition 8:Let T, T1 denote sets of instances, Qc (T 1 ), and R = fri lri :T—'Q} denote a set of functions fromT to Q. R will be referred to as a (simple) binary relational property of T (see Figure 4-3) 55 .Figure 4-3: Binary Relational PropertyT^R55As with structural properties, the definition may be extended to composite (or emergent) relationalproperties. A composite (or emergent) binary relational property is a set R =Emergent properties are considered further in Section 4.2.3.4.68Example:T = {tit is a person},T' = R i le is a company),R = Employed_by.Assuming a world in which there is no moonlighting, the codomain of this property is actuallya subset of Ti (which, of course, is a subset of p(T)).As with a structural property, the depiction of a relational property in Figure 4-3 can beequivalently described using a set of tables, since each element of the set R in Figure 4-3 is a function.For example:ri^ r2t i q1 q1t2 q2 t2 qit3 q3 t3 q7The property R, then, is a set {r i ,...,rN} of such tables.As the functions have a common domain, it will be convenient to speak of the members of thedomain as possessing the property. Specifically, any set of instances A (as well as each of its elements)will be said to possess relational property R:T—>Q if AcT (cf. Definition 5, page 64). In other words, Apossesses R when A is a subset of the domain of R. In addition, A may constitute the intersection of thedomains, T 1 ,...,TK, of relational properties R 1 ,...,RK : that is, A = T in...nTN. In that case, A will be referredto as a category on R' ,...,RK (cf. Definition 6, page 65). The set of relational properties possessed by Awill be denoted by RA = {R1,...,RK}.69A binary relational property, R, is more completely described as a binary relational property ofinstances in T with instances in T1 . For notational convenience, this may be written T R T' or R(T,T 1 ).For a particular instance tE T at a particular time, the relationship is designated t where q je Qc p (V),and je {1,...,IRI}.Since relational properties link instances from one set with instances from another set, one canthink of "inverse" properties which describe mappings from elements of the second set to elements of thefirst. For example, if Employed_by links persons with companies, there should be a relational propertyEmploys, which links companies with persons. Furthermore, if any person t i is employed by company t 1 1(i.e., tl ie Employed_by(t)), then t ie Employs(t 11). This is stated more formally as a postulate.Postulate 2:If T R T1 , then 3 R', a relational property of instances in T 1 with instances in T (T 1 R' T), suchthat for any tE T, tie T 1 , t'E R(t)^tE R'(t 1)."Each element of the binary relational property R is a function, r j , whose domain is T, andcodomain is Q, a subset of p(T 1). Now, ri (t) describes the relationship holding at some time between anelement of T and a subset of T' (q3e Q). Several cases can be distinguished:1) qi is restricted to a single element (including the null element).This is the situation of the previous example where an instance t is associated with, at most, asingle element of T' at any given time. Relationships such as Married to fit this description.2) ch may contain varying numbers of elements, depending on the active function of R.This is the case where an instance t may be associated with several elements of T 1 at any given56R(t) is a shorthand meaning "for every rj E R, Or, which is appropriate since every function in aproperty set has the same domain.70time, and includes relationships such as Parent_of and Supplies.3) R contains a single element.This means that the relationship is unchanging. The Child_of relationship satisfies this condition.4) R may contain several elements.In this case, various elements of R may hold over time. Supplier and Employed-by relationshipssatisfy this condition.Note that the links commonly described by the term IS-A are not considered here as relationalproperties. Despite this, these associations are very important for cognitive representation (see Section 5.4).However, the IS-A link describes a connection between sets of instances, rather than between instances,such that all elements of one set also belong to another (more general) set. The distinction is best madeby considering the following examples.Married(PERSON, PERSON) is a relational property. Selecting an element of the property (e.g.,a function inj) and an instance of the domain (e.g., a person) yields meaningful descriptions such asmi (John) = Jane. On the other hand, IS-A(EMPLOYEE, PERSON) cannot be instantiated in the samemeaningful way. The only correct instantiations are of the type IS-A i(Jane) = Jane, which does not containany information. Instead, IS-A links simply imply that all properties possessed by one set of instances arealso possessed (inherited) by the other.The definition of relational property provides the basis for distinguishing between required andoptional relationships. The difference is that, for required properties, every element of T must be in arelationship with some non-null element(s) of Ti (hence, the exclusion of the null set from the codomainof functions in R).71Definition 9:Let T, T 1 be sets of instances, Qc p(T 1), and R = frj lri :T---)Q) a set of functions from T to Q. Ris referred to as a required relational property of T if (230 Q, or as an optional relationalproperty iff OE Q.Example (required):T = {xlx is a person),T' = T,R = Child of.In this example, there are a number of implicit constraints on the child relation which can be usedto demonstrate how certain knowledge can be captured by the formalism. For example, for the singlefunction c of the unchanging property Child_of, yE c(x) Xf4 c(y), where x and y denote person instances.That is, if x is y's child, then y cannot be x's child. Another restriction is that xo c(x). That is, a personcannot be one's own child. Such restrictions are implicitly captured by the nature of the assignments madeby the function c.Example (optional):T = [xlx is a person),T1 = T,R = Married to.Thus far, only binary relationships have been considered. However, many associations may involveinstances from several sets. The definition of relational property is, therefore, extended to handle arbitraryn-ary relationships.Definition 10:72Let T,T1 ,...,T1-1 be sets of instances, Qc p (T ...0r4), and R = {ri lri :T-4Q} a set of functions from€,•1T to Q. R is referred to as an n-ary relational property of T.Example:T = {xlx is a supplier),T 1 = {xlx is a project},T2 = {xlx is a part},R = Supplies = frj Irj :T—)Q , where Qg p (T T24.2.2.3 State, Change, and TimeAn important part of our knowledge about things includes knowledge about how they may changeover time. This knowledge will be formalized as behavioral properties, which constrain allowed changes.In order to formalize the notion of behavioral property, several ancillary definitions are first provided.Change is defined in terms of events, where an event is a change in state. A state is defined as a collectionof active functions of structural and relational properties. In addition, this section offers some preliminarycomments on the treatment of time.4 .2 .2 .3 .1 StateAt a given moment, a person's knowledge about a domain is in a certain state that reflects apotential state of known things in that domain. The usual way of describing state is in terms of the valuestaken on by a set of variables at a specific time. However, using the definitions of structural and relationalproperties given earlier, state can be defined in terms of the elements of the property sets that are activeat any time. These elements (functions) in turn determine values when applied to specific instances.An important assumption of concept theory is that knowled ge of things is unavoidably linked to73the categories to which they belong. In other words, it only makes sense to talk of the state of a thing asan instance of a category. For example, it is meaningless to speak of the state of an instance Herbie,without classifying Herbie as a member of PERSON, PARROT, AUTOMOBILE, or some other category.The act of categorizing an instance identifies a set of properties it possesses, thereby providing a basis fordescribing its state with respect to those properties. Furthermore, every instance of a given category willhave a state with respect to the set of properties shared by that category. Defining the state of a categoryis an explicit reminder of this. Consequently, two complementary notions of state are presented. The stateof an entire category of instances is introduced as a mechanism for giving meaning to a instance levelview of state.Definition 11:Let T denote a category57 of instances, and PT= {P 1 ,...,Pic } denote the set of structural andrelational properties shared by T. The state of T, designated o(T), is a vector containing the activefunction of each of the structural and relational properties possessed by T applied to the instancesin T:58a(T)= <Pk>k€ 1^= <P 1 ip•••91)KiK>59 9where pki, Pk, and the index ike 1,...,1Pk1}.At a certain time, the state of an instance tE T is:57 Category is defined in Definition 6 (page 65). The set of properties that intensionally defines acategory may have a special status and, in such cases, will be referred to as a concept (see Section4.2.3.2).58Each property in ST and RT has a domain which is a superset of T. Consequently, in considering thestate of T (and in this notation), only the application of the active function of each of the propertiespossessed by T to the instances in T is of interest.59The index ik should be read ik.74G(t) =At a later time, the state of t may be:•Y(t) = <p in(t),...,pKix(t)>, where i'k#ik for at least one kE {1,...,K}.Consequently, a(T) may also be written:a(T) = <a(0>1ET= <G(t),...,040>.That is, the state of T is the joint state of the elements (instances) of T.The following simple example illustrates the independence of structural and relational properties,as well as the meaning of the indexing in the above definition. This example will be used to illustratevarious points through the remainder of the chapter.Example:Suppose GLASS is a category containing two instances: GLASS = {glassl, glass2}. The instancesof GLASS share two structural properties, S 1 = ORIENT and S2 = CONTENT, with codomains {upright,upsidedown} and {empty, full}, respectively. GLASS also has one binary relational property, R 1 = ON,with a set of tables, TABLES = {tablel, table2}. The potential combinations of values of the propertiesof GLASS are:75ORIENT:^t^s1 1(t)^s12(t)^s13(t)^s14(t)glassl upright^upright^upside_down upside_downglass2 upright^upside_down upright^upside_downCONTENT:^t^s21(t)^s22(t)^s23(t)^s24(t)glassl empty^empty^full^fullglass2 empty^full^empty^fullON^t^r11(t)^r12(t)^r13(t)^r14(t)glassl tablel^tablel^table2^table2glass2 tablel^table2^tablel^table2The potential states of, say, glassl are:<s 1 / (glass 1), s2 / (glass 1 ),r 1 / (glass 1)> = <upright,empty,table 1 > (1)<s 1 / (glass 1),s2 / (glass 1),r 13(glass 1)> = <upright,empty,table2> (2)<s 1 / (glass 1), s23(glass 1)4.1 / (glass 1)> = <upright,full,table 1> (3)<s l i (glass 1), s23(glass 1 ),r 13(glass 1)> = <upright,full,table2> (4)<s 1 3(glass 1),s2 / (glass 1), r 1 / (glass 1)> = <upside_down,empty,table 1> (5)<s 1 3(glass 1), s2 / (glass 1),r 13(glass 1 )> = <upside_down,empty,table2> (6)<s 1 3(glass 1), s23(glass 1),r1 / (glass 1)> = <upside_down,full,table 1> (7)<s 1 3(glass 1), s23(glass 1),r13(glass 1)> = <upside_down,full,table2>. (8)In this example, i 1 , i2, j 1 E { 1,2,3,4}. However, it will not generally be the case that two propertiescontain the same number of functions.The potential states of glass2 can be similarly enumerated. Furthermore, by considering glassl and76glass2 together, the potential joint states of the set GLASS can be listed`.This example demonstrates the general independence of the states of instances in a category. Thefact that there are four functions in each of the two properties of GLASS (instead of two) indicates thatthe value taken on by glassl (upright or upside_down) is independent of the value taken on by glass2.However, by modelling properties as functions in this way, constraints on the joint states of instances withrespect to a single property can be imposed61 . For instance, it may be that both glasses are required tobe in the same orientation. This semantic constraint can be implicitly imposed by omitting both functionss12 and s13 from the property SI .The notion of state gives rise to two useful definitions of state space which together highlight therole of the functions in a property set in restricting the values which may occur for properties. That is, ifparticular instances have certain values for a property, other instances may be constrained to have certainother values. For instance, the salaries of employees in a department may be constrained so that no morethan five employees may have a salary over $50,000. This eliminates certain potential functions from theproperty set.60In terms of the states of the category, joint states should be considered. However, even in this simplecase, there are 23 .23, or 64 potential joint states. For manageability, the example considers only thepotential state space of a single instance. In addition, the index numbering here does not completelycoincide with the consideration of the joint state of instances, since in the latter case, the independenceof states of different instances in a set needs to be considered. Hence, s11 could be replaced by s 12, s 1 3could be replaced by s lo and so on, in describing the state of glassl.61Constraints with respect to several structural or relational properties are also important, and areconsidered later in the discussion of behavioral properties.77Definition 12:The potential (or conceivable) state space, E(t), of every instance t in a category T is theCartesian product of the codomains of the structural and relational properties of T. That is,E(t) DP10 ODPK ,where the D's denote the codomains of the respective structural and relational properties of T.Example:In the "glass/table" domain, the potential state space of both glassl and glass2 is given by:{upright, upsidedown} ® {empty, full}0 {tablel, table2}.Every instance in a category has the same potential state space with respect to the attributes onwhich that category is based. In fact, this is a derived view of what it means to categorize instances basedon similarity (i.e., derived from the notion of classifying based on common properties).Definition 12 suggests that, while the conceivable functions in a property collectively map eachelement of the domain to each element of the codomain, the actual functions in a property will generallybe a subset of this.Definition 13:The possible state space, E(T), of a category, T, is the set of vectors formed by taking theCartesian product of the structural and relational properties of T. That is:E(T) = S 1 0...0SN R 10.. .0Rm .It will always be the case that the state of a set of instances is an element of the possible statespace (i.e., a(T)€ E(T)).78Example:Not all the potential states of a thing or things in a category may be possible. Suppose there isa rule governing the states of glasses, stating that both glasses cannot be simultaneously upsidedown.This rule implies that the potential element of ORIENT, s14 (where s 14(glass1)=s 14(glass2)=upsidedown),is not an actual function in the property. Thus, whereas the potential state space of GLASS includes stateswhere both glasses are upside-down, the possible state space does not.In addition to these restrictions, there may be restrictions on the jointly active functions of severalproperties. For example, a glass may not be both upside_down and full. This is modeled implicitly bybehavioral properties (Section 4.2.3.1), which restrict changes in active functions.4 .2 .2 .3 .2 ChangeTwo important kinds of change to the state of a cognitive representation are proposed. First, thenotion of state gives rise naturally to the view of an event as a state change of one or more instances ina category. An event is described by two states - before and after - and involves a change in the activefunction of one or more properties. The second kind of change involves modifying the domain ofproperties. This notion of change is dealt with first.Our knowledge of the world changes as we "become aware" (i.e., perceive the existence) of newthings. This is captured in this formulation by the creation of new instances to represent the perceivedexistence of these things. In addition, knowledge of the characteristics of these entities is represented bythe properties which the new instances possess. In order for an instance to possess properties (and,therefore, to have values for properties), it must be an element of the domain of these properties.Consequently, the notion of domain expansion is defined to accommodate the representation of knowledgeabout new entities.79Definition 14:Let T designate a category of instances, A a nonempty set of instances such that AnT=0,T'=TuA, and P = {pilpi:T—W} a structural or relational property of T. A domain expansion is achange in the domain of P such that P =The creation of a new instance will be accompanied by a domain expansion for each of thestructural and relational properties which the new instance initially possesses. Similarly, if an entity isperceived to no longer exist in the real world, an instance is removed from the cognitive representation.This is modeled by the notion of domain contraction.Definition 15:Let T designate a category of instances, A a nonempty set of instances such that ACT, T'=T-A,and P = {pi lpi :T—AT} a property of T. A domain contraction is a change in the domain of P suchthat P = .Example:Consider the category GLASS = {glassl, glass2} introduced earlier (see page 75). The additionof glass3 to the domain of ORIENT, CONTENT, and ON would be a case of domain expansion 62. Onthe other hand, the removal of glass2 from the domain of these properties (for example, by smashing it)would be an example of domain contraction.The remaining kind of change deals with the change of state of existing instances. Events are62This change may be relative to the glass-table system of interest, in which case glass3 may have aprevious existence, or the change may be understood as the creation (i.e., perceiving the existence) ofglass3. The distinction is made here only to show that an instance may enter or leave categories.80defined to describe changes in the active function of one or more properties and, therefore, to describechanges in the state of sets of instances. In the notation which follows, p kik denotes the i kth function ofthe structural or relational property Pk .Definition 16:Let 15 = <p lii ,...,pKiK> denote a vector containing the active functions of the K structural/relationalproperties 111,...,P1( of a category of instances T. An event with respect to T is a change in theactive function of at least one of P1 ,...,PK, denoted:e: <G(T),a'(T)> =where pi^and pkrk pkik, for at least one k=1,...,K.This definition describes an event as a change in the state of instances in one or more of the setsT1 ,...,TK (i.e., the domains of properties P 1,...,PK). However, the interest here is only in changes toinstances of T=TExample:Consider the "glass/table" domain (see page 75). Suppose that glassl is upright and full on tableland that glass2 is upright and empty on table2. That is, the state of the two glasses is given by the vectora(GLASS)=<s l 1 ,s23 ,r12>.63 Further, suppose an event occurs whereby a person removes glass! fromtablel, drinks the contents and replaces it upside_down on tablel. The resultant state is cr'(GLASS) =<s 1 3 ,s2 1 ,r12>. Using the notation introduced above, the event can be described by its before and after states:e: <a(GLASS),•Y(GLASS)> = «s l 1 ,s23,r12>,<s 1 3 ,s2 1 ,r12>>.63Recall from the earlier description that S'=ORIENT, S 2=CONTENT, and R 1=ON. Furthermore,s l i (glass 1 )=upright, s l 1 (glass2)=upright, s23(glass 1)=full, s23(glass2)=empty, r 12(glass 1 )=table 1 , andr12(glass2)=table2.8 1This recognizes that there has been a state change to the category GLASS: that is, to one or moreinstances of the category.This event can also be described with respect to each glass:e(glass 1): «s l i (glass 1 ),s23(glass 1 ),r12(glass 1 )>,<s 1 3(glass 1 ),s2 i (glass 1 ),r 12(glass 1 )»= <<uprightfull,tablel>,<upside_down,empty,tablel>>; ande(glass2): <<s l i (glass 1 ),s23(glass 1 ),r12(glass 1 )>,<s 1 3(glass 1 ),s2 1 (glass 1 ),r12(glass 1 )»= «upright,empty,table2>,<upright,empty,table2»,where the italicized values are changed by the event.A note about the semantics of an event is in order here. The event above involves two changesin active function. In addition, the event does not "detect" that a glass is off a table. If the codomain ofthe property ON was extended to include the value nothing, one could capture intermediate stages in theabove change, and the above event could be described by two (or more) events. This is an issue of"granularity" (or "coarseness" versus "fineness") of events, and reflects an abstraction with respect to thegranularity of knowledge. That is, if a person looks more closely at the changes involved in an event, itis often possible to refine a single event as a series of several events. Furthermore, different people mayview the same domain with different degrees of granularity.4.2.2.3.3 TimeThe notions of state and event are very important in the handling of time in this model. There areat least two ways to model time as it relates to the states of things. First, time may be considered aparameter of property functions. This explicitly shows the fact that property values and, hence, states, aretime-dependent. Using this approach, a property P might be regarded as a single function P:T®0—)V,82where T designates a set of instances, A designates a set of time points, and V designates a set of values.However, the main drawback of this treatment is that an additional parameter is introduced which isunlikely to vary the value of the function over many values of that parameter. In other words, P(T,O) willbe constant over many values BE A, for a fixed tE T. In addition, this treatment would not be useful fordistinguishing unchanging properties such as Birthdate, from changing ones such as Address.A simpler way to model time-based change is by "measuring time" only through the occurrenceof events. In this view, time is not incorporated as a parameter of a property defined as a single function.Instead, a property is modelled by a set of functions, one of which is an accurate reflection of the (realor imagined) world with respect to that property. An event is defined as a change in the function from thatset which correctly describes the domain. This is the approach taken in this formalization. Its mainadvantage is conceptual simplicity, in that time is strictly implicit (i.e., measured only by the occurrenceof events) and need not be carried as a parameter of property fiinctions 64. In addition, it provides a usefulway to distinguish changeable from unchangeable properties, the former having several functions in aproperty set and the latter only one. Furthermore, this treatment allows constraints on the joint values ofa property for instances of a category to be conveniently captured through the absence of certain potentialfunctions from the actual set of functions that constitutes the property. For example, in the glass-tableenvironment described earlier, there may be a constraint that both glasses may not be on table2. Thiswould be reflected in the specific example by the presence of only the functions r 11 , r 12 and r 13 in theproperty ON (thereby excluding the potential function r'4 from the set of actual functions, sincer14(glass1)=r 14(glass2)=table2). Chapter 5 (Section 5.7) contains a more detailed consideration of themeaning of time in the model.This completes the discussion of the primitive knowledge constructs. Using these, the important64The major disadvantage of this approach is related to implementation, since the set of functionsconstituting a property may be very large. Since implementation is not the immediate concern of thisresearch, determining potential implementation strategies is left for future research.83derived constructs of behavioral property, concept, specialization, and composition are defined, beginningwith the notion of behavioral property.4.2.3 Derived Constructs4.2.3.1 Behavioral PropertyIn addition to knowledge about states, an important part of knowledge about things involves theirallowed behavior, or how states may change over time. However, the inclusion of behavior in definingconcepts is not precisely characterized by cognitive science researchers (e.g., Smith, 1988, p.27; Smith andMedin, 1981, p.71). Instead, behavior is often discussed in terms of predicates such as "can fly" (as aproperty of, say, birds).Given that behavior is only informally incorporated in theories of concepts, an assumption isneeded before the notion of behavioral property can be formally defined. Thus, what follows goes beyondwhat is explicitly stated in the classical theory of concepts, but is offered as an interpretation of moreinformal treatments of behavior based on the preceding formulation of structural and relational properties.The assumption is essentially that predicates such as "flies", "swims", and "walks" (Smith andMedin, 1981, p.72) describe constraints on the ways in which instances may change state (in these cases,properties such as position and orientation of limbs). Everyday observations suggest that the states ofthings do not change arbitrarily, but behave in a manner that is to some extent regular, or even predictable.This is expressed in the following postulate.Postulate 3:The changes of state that a set of instances may undergo are subject to certain restrictions.84Consequently, behavioral properties will be defined as restrictions on changes to the activefunctions of one or more structural and relational properties. That is, given a certain combination of activefunctions for one or more structural/relational properties, a behavioral attribute specifies which events areallowed with respect to these same properties.Definition 17:Let P1 ,...,PK denote K structural and/or relational properties with domains T I ,...,TK, respectively.A behavioral property is a function b:P le... pK_.) p (p1(8) ...0pK) .In other words, given a K-tuple of active functions (pl ,...,pK) of structural attributes (pkE Pk),b(p i ,...,pK) returns a set of K-tuples of functions, thereby indicating the allowed joint changes in the activefunctions of P1 ,...,PK given that p l,...,pK are active (see example following Definition 18). The structuraland relational properties affected by a behavioral property will be referred to as the parameters of thatproperty. Formally:Definition 18:Let b:P1 0...OPK—)0(P 1e...OPK) denote a behavioral property. P 1 ,...,PK will be called theparameters of b.The definition of behavioral property is general and several special cases are possible. Forproperties having K=1, changes in the active function depend only on the current active function of thatproperty. When K> 1 , changes in the active functions of K properties are jointly constrained by the activefunction of the remaining K-1 properties.85Example (K=1):In the "glass/table" world introduced earlier (see page 75), suppose that there is an arbitrary rule 65that a single glass cannot change from upside_down to upright unless the other glass is also upside_down.The behavioral property (i.e., the function b) is specified in the following table, where S 1 denotes theproperty ORIENT, and the s11 (i=1,...,4) are the functions in the set which assign orientations to glasses 66 .bElement of S 1 Element of g (S 1)s 1 1 {s',,s'3,s14}S 12° (S14)S130 3 {S14)S0 4 I^1^1ISDS2,S3}Here, allowed changes to the active function of ORIENT depend only on the present activefunction of ORIENT.Example (K=2):Suppose that there is a restriction that a glass which is upside_down must be turned upright beforebeing filled and a glass which is upright must be empty before it can be turned upside_down. Prohibitedby this behavioral property are all events in which any glass changes from a state in which itsORIENTation is upside_down and CONTENT is empty (or ORIENTation is upright and CONTENT is65This means a rule which is not inherent to the system. Arbitrary rules may be akin to "businessrules": that is, stated or implied practices followed by an organization. By contrast, the fact that a glass,for example, cannot (normally) be upside_down and full is based on the law of gravity.66Recall that s 1 = {<gl,u>,<g2,u>}, s2 = {<gl,u>,<g2,d>}, s 3 = kg 1 ,d>,<g2,u>}, s4 ={<gl,d>,<g2,d>}, where gl and g2 denote the glasses, and u and d denote possible orientations.86empty or full) to a state in which its ORIENTation is upside_down and its CONTENT is full.This example illustrates another potential role of behavioral properties. A generalization of theabove behavioral property is that no glass may simultaneously be upside_down and full. Consequently,a behavioral property can be useful in implicitly providing restrictions on the joint active functions of twoor more properties by prohibiting transitions to such states from any other state. This requires thefollowing assumption, which is adopted by the model.Assumption:If a behavioral property prohibits a transition to a certain state from any other state, then thatstate may not be the initial state of a (set of) instances.This assumption ensures that states which cannot be reached from other states are fully prohibited.It follows from Definition 17 that, when K>l, T 1 ,...,TK (the domains of P 1 ,...,PK, respectively) maybe identical, partially overlapping, or disjoint. Consequently, behavioral constraints may involvestructural/relational properties outside of PT, the set of structural/relational properties shared by a set ofinstances, T. For example, for PA = {PA', pA2} and pB = {pB 1 , pB2 , ,j there may be a behavioral attributeb:P A ' OPB2-4 p (PA PB2), indicating that behavior is linked across categories. Later, when the notion ofconcept is defined, it will be shown that a behavioral property may, therefore, "belong" to two or moredifferent concepts. This illustrates how the formalization goes beyond what is explicitly discussed intheories of concepts with respect to behavior.For example, consider a university context in which changes to the active function of theCourses_offered property of a department may depend on the active function of the Teaching_load87property of the faculty members in that department 67 . A department may not be able to offer addedcourses if, for instance, every faculty member has a teaching load of four or more courses.To conclude this section, an implied connection of behavioral properties to structural and relationalproperties is examined. The connection is that, for a given "universe" of properties, any subset of structuraland relational properties determines a specific set of behavioral properties which affect the former. Thus,for any category, knowledge about the state of its instances is determined by the active functions of thestructural/relational attributes possessed by those instances. Knowledge about the allowed changes of stateis determined by the set of behavioral attributes which have as a parameter structural/relationalstructuraVrelationattribute defining the category.To state this more precisely, if PT = (P',...,Pm is a set of structural/relational properties(Pm:Tm—>Vm) shared by a category T = T in...nTm, there is an associated set of behavioral properties BT= (b1 ,...,b1( } such that each bke B has at least one property Pm E P as a parameter of its domain.Consequently, PT may also be written <PT,BT> or <ST,RT,BT> (since PT=STLAZT) to emphasize that, in anycognitive representation, a collection of structural and relational properties "implies" a set of behavioralproperties which constrain how the active functions of the former may change: that is, This hasimplications for the definition of concept in the next section.°Such an attribute may be linked with the notion of composition (Section 4.2.3.4) in that a departmentmay be seen as a composite instance which has a set of faculty members as one of its components. Theallowed changes of the property of the composite are then dependent on the active functions of propertiesof components. Developing this notion of linking behavioral properties which "cross categories" tocomposites is left as future work, since the concept theory literature does not appear to deal with it.884.2.3.2 ConceptThe notion of category was introduced earlier as an extensional construct, defined as a set ofinstances sharing a set of structural and relational properties. However, both the classical and prototypetheories of concepts view concepts as abstractions of the common properties of a set of instances. In thesetheories, this notion of abstraction is essential to what a concept is (Medin and Smith, 1984, p.115). Forexample, the concept of PERSON is distinct from knowledge of any individual human, and may bethought of as the set of properties that is common to all humans.As discussed in Chapter 3, the abstraction of common features or properties is an essential aspectof managing or reducing the complexity of the world, and enables humans to categorize perceived thingsaccording to commonality of properties (Smith, 1988). In short, people group similar things together.Similarity will be operationalized here in terms of the sharing of properties. Two instances, t i and t2 , sharea structural or relational property, P, if t i and t2 possess P: that is, if p,(ti) and pi(t2) are defined for allfunctions p i€ P. In this regard, a concept is a vehicle for expressing a group of shared properties (i.e., aconcept consists of a collection of properties shared by a non-empty set of instances), and identifyingcollections of properties which are shared by sets of instances may be regarded as the fundamental taskof concept formation.In formally defining the notion of concept, the basic objective is to provide an intension (orabstraction) based on the sharing of properties, since we group instances based on their commonproperties. In addition, there are several other requirements that the formalization must satisfy. Theserequirements are proposed here as "principles of conceptualization". They are not explicitly articulated byany of the three major theories of concepts, but are consistent with claims about the fundamental reasonsfor categorizing the things we perceive: cognitive economy and inference (e.g., Smith, 1988; Lakoff, 1987;Smith and Medin, 1981).89Principle of Abstraction from Instances:A concept abstracts the properties shared by a non-empty set of instances.In perceiving the world, we classify instances according to the properties they share with others.If a concept is defined as a set of properties, there must be a non-empty set of instances (correspondingto real or imagined things) which possess all of these properties. Otherwise, the concept would not beuseful68 .Principle of Maximal Abstraction:Every property possessed by an the instances of a concept is part of the definition of that concept.This is related to the notion of cognitive economy discussed in Chapter 3. According to Rosch(1978, p.28), "the task of category systems is to provide maximum information with the least cognitiveeffort". In other words, classifying an instance as belonging to a concept enables certain questions to beanswered about that individual. Clearly, if a concept definition omits some properties which are possessedby all its instances, it would not be possible to answer questions related to that property when an instanceis classified. For example, there can be no concept defined only by the property Works_in_department,since all who work in departments are persons, and therefore, share numerous other attributes. In otherwords, if one can ask of an instance x, "Which department does x work in?", one can also ask "What isx's address?", "What is x's birthdate?", and so on."Consider a concept such as unicorn, which has no manifestation in the real world. Such a conceptcould be formed by "imagining" an instance which possesses a certain combination of properties. Thepoint is that instances (corresponding to real or imaginary things) form the basis for the abstraction.90Principle of Non-redundancy:A concept whose properties are a superset of those of each of several other concepts must containat least one property not in the union of the properties of these other concepts.This means that a concept which "specializes" one or more other concepts must containinformation (i.e., additional properties) which cannot be found by considering an instance as a memberof any of the more general concepts. For example, suppose that CUSTOMER, EMPLOYEE, andCUSTOMER_ EMPLOYEE are concepts, and the set of properties of CUSTOMER_ EMPLOYEE isa superset of those of each of the other two. If the collection of properties definingCUSTOMER_ EMPLOYEE is to be a "meaningful" abstraction (in the sense of permitting morequestions to be answered), it must contain at least one property that is not in the definition of eitherCUSTOMER or EMPLOYEE. Otherwise, any question that can be asked of an instance ofCUSTOMER EMPLOYEE can be asked of the same instance as either an EMPLOYEE or aCUSTOMER. This principle is based on an assumption, implicit in many theories of semantic memory(e.g., Smith, 1978), that conceptual organization is efficient in the sense that each refined concept addsnew knowledge.Principle of Completeness:Given a "universe of knowledge" consisting of (1) a set of instances, (2) the set of all propertiespossessed by any of these instances, and (3) a set of concepts, every property will be used in thedefinition of at least one concept in that set.This principle essentially states that no properties are omitted in the abstraction of some universeof knowledge. If a property was not abstracted in the definition of any concept, there would be some91questions about the set of instances possessing that property which could not be answered by classifyingthose instances into any available concept. In other words, properties are a crucial classification tool, andare not normally considered independently of the concepts they define.Principle of Variety:Given a "universe" of knowledge (a domain), there are many ways of conceptualizing that domainwhich satisfy the first four principles.This principle recognizes that there is no single "correct" set of concepts for abstracting one'sknowledge about a domain (cf. Lakoff, 1987). Instead, any "world view" which satisfies the previousprinciples is as valid as any other. Different individuals may abstract different sets of properties to formdifferent concepts depending on various factors, such as the context within which the knowledge will beused (e.g., Barsalou, 1982; Rosch, 1978) and the culture within which the individual lives (Lakoff, 1987).However, any abstraction which violates any of the earlier principles violates some elementary assumptionabout the nature and reasons for classification.These principles are offered here as "desiderata" of conceptualization. They are based onfundamental assumptions about why we categorize, and constitute a minimal set of conditions for decidingwhether a collection of concepts is "good" for some universe of knowledge. In what follows, the principlesare used to define two complementary constructs which give precision to the notion of a concept. Apotential concept is defined as a set of properties which embodies the principles of abstraction frominstances and of maximal abstraction, while a concept structure is defined as a set of potential conceptswhich satisfies the principles of non-redundancy, completeness, and variety.In defining concepts, it is useful to recognize the connection between a concept as an intension,92and its extension, which is a category (Definition 6, page 65). The extension of any set ofstructural/relational properties, P, is the joint intersection of the domains of these properties, and willhereafter be denoted e(P).To define potential concept, the following notation is used. T denotes the complete set of instances(universe) in a cognitive representation, PT = {131 ,...,Pm } denotes the set of all structural and relationalproperties possessed by any members of T, and Trn denotes the domain of 13'n (m=1,...,M). This means thatT=Tiu...ur. Finally, C = {Pl iEJ, Jc { 1,...,M} denotes a subset of PT, and e(C) denotes the extensionof C.Definition 19:C will be called a potential concept in T ifa) e(C)#0, andb) (PT-C) such that T'De(C) (where T' is the domain of P').This definition ensures that every potential concept (a) has a non-empty extension, and (b) containsall properties possessed by all instances in its extension. Hence, it satisfies the principles of abstractionfrom instances and maximal abstraction. The example given earlier, where C = {Works_in_department},does not constitute a potential concept, since all instances which possess the propertyWorks in _ department also possess numerous other properties, such as Address and Birthdate (i.e., allwho work in departments are persons). Hence, the domain of the latter two properties is a superset of thatof the first.Note that, for any C={131 ,...,PK } ,^where B denotes a set of behavioral properties. Therefore,C may be written <P,B> or <S,R,B> to emphasize that a potential concept also includes the behavioralproperties which affect the structural/relational properties in its definition (see page 87).93The definition of potential concept leads to a theorem about an importance characteristic of distinctpotential concepts which has implications for concept specialization (see Section 4.2.3.3). Note, first, thattwo distinct potential concepts cannot have the same set of properties (else they are the same).Theorem 1:Two potential concepts cannot have the same extension.Proof:Suppose that CA= (PA 1 ,...,PAm} and CB= EPB 1 ,...,PBNI denote two potential concepts. Since CA#CB ,there is at least one property P' (with domain T') which is in either CA or CB, but not both. SupposeP'E CA. By Definition 19, T'=(CB) (in particular, Thte(CB)). Yet T'De(CA) since it is possessed by theinstances of CA. Therefore, e(CA)*e(CB). The result is the same if P'E CB. ■Every person forms many concepts for categorizing instances. For a variety of reasons related tothe goal of reducing the complexity of experience (Lakoff, 1987; Medin and Smith, 1981), people identifycertain groups of properties as important. The reasons for identifying collections of properties as usefulabstractions has not been fully explained by cognitive scientists and is beyond the scope of this research.However, it is reasonable to conclude that particular groupings are useful because they permit inferencesto be made about non-perceived properties (given perceived ones), thereby supporting adaptation andsurvival (Smith, 1988).A set of concepts used to organize knowledge about a domain will be called a concept structure.A concept structure must satisfy the principles of non-redundancy, completeness, and variety, therebyimposing some constraints on the nature of the potential concepts it contains.Let T denote a "universe" of instances, PT = (131 ,...,Pm } denote the set of all structural/relational94properties possessed by any members of T, CS = {C 1 ,...,CK} denote a set of potential concepts, and CS'denote any subset of CS.Definition 20:CS is a concept structure over T iffa) ukE (1,...,x}Ck=PT, andb) A Jg {1,...,K} such that ujEjCi=CE CS, where CSC } for any jE J.If CS is a concept structure, each potential concept CkE CS will be referred to as a realized concept(or simply a concept).By its definition, a concept structure (a) contains every property possessed by any members of Tin at least one of its concepts, and (b) contains no concept whose properties are exactly the union of theproperties of any other concepts in the structure. The second condition is important in defining conceptspecialization (see Section 4.2.3.3). The definition prohibits a concept structure from containing potentialconcepts which do not have at least one extra property with respect to its superconcept (if only one), aswell as potential concepts which simply contain the union of the properties of two (or more)superconcepts.To illustrate the definition, an example of a collection of potential concepts which may not be partof the same concept structure is given. Suppose that CUSTOMER={Name, Address, Spouse,Holds_account}, EMPLOYEE={Name, Address, Spouse, Experience}, andCUSTOMER_EMPLOYEE={Name, Address, Spouse, Holds_account, Experience}. In this case,{CUSTOMER, EMPLOYEE, CUSTOMER_EMPLOYEE} does not constitute (a subset of) a conceptstructure since CUSTOMER_EMPLOYEE=CUSTOMERuEMPLOYEE. This means that, as defined here,the potential concept CUSTOMER_EMPLOYEE abstracts no additional information with respect to the95other concepts considered, since all questions that can be answered with respect to any instance ofCUSTOMER EMPLOYEE can be answered with respect to that instance as a member of CUSTOMERor EMPLOYEE.4.2.3.3 SpecializationThe concept is the fundamental abstraction mechanism by which instances can be compared. Inaddition, concepts can be associated with other concepts based on the degree to which they shareproperties. This leads to the consideration of concept specialization.There is a great deal of evidence suggesting that we organize knowledge about things into generaland more specialized categories. Biological taxonomies are a clear example. Keil (1979, 1986) suggeststhat there is an ontological hierarchy of generic concepts common to all humans. A segment of one pathon this hierarchy is THING -4 PHYSICAL THING —> SOLID -4 LIVING THING —> ANIMAL -->Given the definitions of potential concept and concept structure, the notion of conceptspecialization can be formalized In accordance with the intuitive meaning of specialization in classicalconcept theory, the following principle, which is a special case of the principle of non-redundancy, guidesthe formal definition.Principle of Refinement:The set of properties possessed by a specialized concept is a strict superset of the set of propertiesof a more general concept.This principle is used to define specialization intensionally. Specialization also has the extensionalmeaning that the instances of a specialized concept are a strict subset of those of a more general conceptand, therefore, are also instances of the latter. The definition will be shown to satisfy this condition.96Definition 21:Let C' and C 2 denote two concepts in a concept structure (i.e., C' and C 2 are each a set ofproperties). Then, C 2 is a specialization (or subconcept) of C' (alternatively, C2 IS-A C') ifC'cC2 .If C2 is a subconcept of C I, then C' may be referred to as a superconcept of C2. For example, ifPERSON = {Name, Address, Birthdate} and CUSTOMER = {Name, Address, Birthdate, Holds_accounts}are two concepts in a concept structure, then CUSTOMER IS-A PERSON.If a concept is a specialization of two or more others, it must possess added properties with respectto the union of those of all its superconcepts. Otherwise, all questions about instances can be answeredwith respect to one or more of the more general concepts. This is implied by the definitions of conceptstructure and specialization, as shown by the following theorem.Theorem 2:Let C°, C' denote two concepts in a concept structure such that neither is a specialization of theother. Then, if C 2 is a specialization of both C ° and C', C°uC'cC2 .Proof:Since C2 IS-A C ° and C 2 IS-A C', C°cC2 and C'cC2 (by Definition 21). Therefore, C 2jC°uC'.But, by the definition of concept structure, C 2*0uC l . Therefore, C2DC°u0. ■The definition of specialization satisfies the basic extensional intuition of specialization - that theextension of a specialized concept is a strict subset of that of a more general one, as shown by thefollowing theorem.97Theorem 3:Let e(C 1), e(C2) denote the extensions of C 1 and C2, respectively, where C 2 IS-A C 1 . Then,e(C2)ce(C 1).Proof:Since C2 IS-A C 1 , C 1cC2 (by Definition 21). Let T' denote the intersection of the domains of theproperties in (C2-C 1). Since C l is a potential concept, there is no property in (C2-C 1) whose domain is asuperset of e(C 1). Therefore, T'42e(C 1). By the definition of extension (category) (Definition 6, page 65),e(C2) = e(C 1)nT'. Therefore, e(C2)ce(C 1). ■The restriction that a specialized concept must possess additional properties with respect toconcepts which it specializes is not generally made in the existing concept literature. Hence, the formalmodel denies two potential grounds for defining specializations. The first is the definition of subconceptsbased only on the addition of behavioral properties. An example of this might be the distinction of two"kinds" of EMPLOYEE: those who are authorized to lay off employees versus those who are not. Thesecond is the definition of subconcepts based only on differentiating instances of an existing concept byspecific values of one or more structural or relational properties. An example of this might be thedistinction of two "specializations" of EMPLOYEE - those who work at the Vancouver office versus thosewho work at the Seattle office. In both cases, it is proposed here that such subconcepts are useful onlyif they also possess additional structural and/or relational properties. In fact, according to the model thisis the only basis for defining subconcepts. The importance and contribution of these distinctions isdiscussed further in Section 5.2.In concluding this section, some implications of the definition of specialization for behavioral98properties are examined. Recall from the previous section that a set of structural/relational propertiesimplies an associated set of behavioral properties, each of which constrains changes to some propertiesp^+,1C,in the former set. That is, a behavioral property is a function b:Pi^(pl 0... 0r---) specifying whichchanges in active function may occur given any combination of active functions of the structural/relationalproperties P 1,...,PK.The set of behavioral properties of a concept C' is denoted 13 1 = {1:0 1 ...bm } and is implied by thestructural/relational properties in C' (Section 4.2.3.1). If C 2 is a specialization of C I , then C2 possessesat least one structural or relational property which C' does not. Now, since each member of C 2 is amember of C', it is subject to the behavioral properties of C'. However, when considering an instance asa member of the specialized concept, there may be additional restrictions on behavior related to the extrastructural/relational properties: that is, 13 1c132 .Two cases can be distinguished. First, a behavioral property of the subconcept may extend(subsume) a behavioral property of the superconcept to incorporate restrictions with respect to an addedstructural/relational property. For example, there may be a property b of C' such thatb:1310...OPK—> p (PIO...0V% and a property b* of C2 such that b*:P10...opKopK+1__> p (pl 0 ... opKopK+1)where PK+I is a structural or relational property defining C 2 as a specialization of C'.The semantics of b* with respect to b is as follows. For any fixed element of P","subsumes" b(p 1 ,...,pK). To see what this means, consider a case where b:S---> (S) and b* :SOR--> p (SOR),where S and R denote a structural and relational property, respectively. Now, for each s iE S, b(s i)=Q i ,where Q i denotes an element of the power set of S. That is, Q, is some subset of S, such as Q.{s i , s2 ,s3 } . Similarly, for any s i€ S and rie R, b *(s„rj)=Q *y , where Q *y denotes an element of the power set of S®R(i.e., some subset of S®R, such as Q a ii={(s i ,r1), (s2 ,r1), (s3 ,r3))). b* subsumes b in the sense that, for anyS iE S, the set of first elements of each pair in Qs0, denoted Q *, (i.e., {s,, s2, s 3 }), is in the above case thesame as the set Q. This means that there should not be any function s 4 in any ordered pair in Q*0.99Otherwise, b* contradicts b when elements of the subconcept are considered as elements of thesuperconcept. In this situation, b * will be said to be compatible with b.The second case involves behavioral properties that do not extend those of the superconcept. Anexample would be a property of C 2, b* :P 10...OPm0Pm+ 1-4p(P1 e...OPm®Pm+ 1), where P 1 ,...,Pm are propertiesof C 1 , Pm' is an added property of C 2, and there is no attribute b:1310...OPm— (P IO_ ®Pm) of conceptC l .4.2.3.4 CompositionThe remaining major construct of classical concept theory to be formalized is composition.Composition/decomposition is, in addition to generalization/specialization, a means of managing thecomplexity of the world (e.g., Lakoff, 1987, p.273). Complex instances may be viewed as composed ofa number of component instances, each having independent properties. However, the components can becombined to account for certain emergent properties: that is, properties ascribed to the whole, but notpresent in any subset of the components (including emergent behavioral properties which may enforcerestrictions on changes of joint states in the composite). This is an important construct which recognizesthat certain things "belong" together for some purposes, but their components can be understood as thingspossessing their own properties.Intuitively, a composite concept is made up of several component concepts and, additionally,possesses a number of emergent properties. An instance of such a concept, then, is a surrogate composedof the surrogate of one instance of each of its components. The domain of the emergent properties of theconcept will be such surrogates69 .69An alternative way to model composition would be to have a separate surrogate for the compositeinstance that is independent of its components. One feature of such an approach would be that it wouldtreat the composite instance as having an existence independent of its components, in that somecomponents could be removed or changed without affecting the existence of the composite. By notadopting this approach, this work takes the position that a composite instance changes if any of its100To support the definition of a composite concept, the notions of composite (versus simple)structural and relational properties are first introduced. A composite structural property associates acollection of component instances from one or more categories with a unique value, and is not possessedby any subset of the components.Definition 22:Let e(C 1),...,e(CK) denote the extensions of K concepts in a concept structure,e(C)ce(C 1) ...0e(CK), V denote a set of values, and S=fs,Is i :e(C)----W). S will be called acomposite (emergent) structural property of degree K.For example, Grade may be considered as a composite structural property of degree two. Thedomain of this property is a subset of e(STUDENT) e(COURSE), where STUDENT and COURSEdenote two concepts. A grade cannot be associated with either a student or a course, but only with a(student,course) pair.Next, the notion of composite relational property is defined. A composite relational propertyassociates a collection of component instances from one or more component concepts with a unique setof instances from one or more other concepts, and is not possessed by any subset of the components. Lete(C 1),...,e(CK) denote the extensions of K concepts in a concept structure, e(C)Qe(C 1)0...0e(CK),e(C"),...,e(CK+m) denote the extension of M other concepts, and Qcp(e(C K+ 1)0...0e(CK+m) (i.e. Qcontains the sets of instances which are linked to the elements of the domain) ).components change. In addition, at any time there is a maximum of one composite of the same set ofcomponents.101Definition 23:Let R =^R will be called a composite (emergent) relational property of degree K.For example, if a student enrolled in a course is assigned a tutor for that course, Tutor may beconsidered an emergent relational property whose domain is, again, a subset of e(STUDENT)0(COURSE),and codomain is a subset of STUDENT. That is, a tutor may not be associated with just a student or acourse, since a student may have different tutors for different courses, and a several tutors may providehelp in a given course° .A composite structural/relational property is defined on a domain which includes instances fromseveral concepts. These will be referred to as the components of the property.Definition 24:Let C1 ,...,CK be a set of concepts, e(C)ce(C 1)®... e(CK), and P be a composite property withdomain e(C). Then, C1 ,...,CK will be referred to as the components of P.For example, the Tutor property just described has components STUDENT and COURSE.Given a group of emergent structural and relational properties, it is possible to recognizerestrictions on the changes to the active functions of these, giving rise to the notion of compositebehavioral property.70This example glosses over some added restrictions on the domain and codomain of such a property.For example, a student may not be a tutor in any course which s/he is enrolled.102Definition 25:Let P.:(131 ,...,PK ) denote a set of composite structural and/or relational properties. A compositebehavioral property is a function b:P10...^p (P10 o PK)An example of such a property will be given shortly.These definitions allow the notion of a composite potential concept to be defined as a triple ofcomposite structural, relational, and behavioral properties.Definition 26:Let C be a potential concept <P,B> (i.e., P=B). C will be called a composite potential conceptof ,...,CK, if P and B are sets of composite (structural/relational and behavioral) properties andthe shared domain of the properties in P is a non-empty set71 .Given this definition, an instance c i of C is a surrogate (c 1 i ,c2i,...,ei), where ckie Ck and(c1 i,c2i,...,c1c1) is an element of the common domain of P 1 ,...,P7 E P. The nature of the emergent propertiesimplies that, at any time, there is only one instance of a composite concept having exactly the samecomponent instances. The implications of this are considered further in Chapter 5 (Section 5.5).71In order for a composite concept to have a non-empty extension, the shared domain of its structuraland relational properties must contain a number of composite objects. This means that all structural andrelational properties must have the same components.103Example:ship, = (c 1 ,...,c1(), wherec 1 = propellerl3c2 = hull4c3 = motor9The composite concept definition is:SHIP = <P,B> = <S,R,B> whereS = (Speed, Maximum_Speed, Cargo . . .)R = {Docked(SHIP,PORT), Captain(SHIP,PERSON) . . .) 72B = Change_course, Change_Speed, Load, Unload . . .)Note that some component instances (concepts) can, in turn, be composite instances (concepts).The following postulate suggests that there is finite number of component "levels".Postulate 4:A composite concept can be decomposed in a fmite number of steps into primitive concepts73 .To illustrate the idea of an emergent behavioral property on the emergent structural and relationalproperties, consider shipl, in state:«0,30,Nil,Wheat, . .>,<Docked(shipl,Vancouver),Captain(shipl,Smith), . . .».A reasonable behavioral property would be that the value of the Speed property cannot be changed to a72Recall that R(X,Y) means that R:X-->p(Y) is a relational property.73A primitive concept is one which does not contain any component concepts: that is, its structural andrelational properties are simple.104value greater than zero unless the value of the Docked property is Nil (or simultaneously changed to Nil).For some emergent properties, there will be a formula that relates the value of the compositeproperty to the value of certain properties of the components. For example, the Weight of a ship is thesum of the Weight of the components. For other properties (e.g., Cargo), there will be no such formularelating properties of the composite to properties of the components.From these definitions, it is clear that composite potential concepts can form a composite conceptstructure which is distinct from the concept structure to which its components belong. A compositeconcept structure is defined as follows.Definition 27:Let CS = { C 1 ,...,CK } denote a concept structure. CS will be called a composite concept structureiff C 1,...,CK are composite concepts.Composite concept structures will not be explored further here. However, to illustrate thedefinition, consider a concept structure containing the class SHIP and various specializations. When SHIPis considered as a composite concept, as in the previous example, the consideration of extra emergentproperties defined on subsets of its extension can generate a collection of composite concepts (SHIP andits subconcepts, such as freighter, tanker, etc.) which constitute a composite concept structure.This concludes the formalization of the important elements of classical concept theory. In the nextsection, requirements for the translation of this model into a model of an IS for constructing "good"representations of knowledge are discussed. Subsequently, the representing (or object) model is defined.1054.3 ON DIRECT REPRESENTATION AND GOODNESSGiven the formalization of classical concept theory presented in the previous section and theresearch objective of developing a conceptual IS model for expressing knowledge according to usersconception of a problem domain, the issue at hand is how this model should be defined. The approachtaken here is to define a set of constructs which are in direct correspondence with the formally definedconstructs of the classical theory. Directness is operationalized in terms of a 1-1 mapping between theimportant elements of the classical view (as defined in the previous section) and those of the conceptualmodel or representation language.Directness is sought in order to provide a model containing representation mechanisms whichparallel or mimic the conceptual organization of knowledge about things (according to one theory). Thismodel should support the creation of specific representations which are "good". Goodness of representationhas been characterized in terms of four individually necessary and jointly sufficient conditions - mapping,tracking, reporting, and sequencing (Wand and Weber, 1988). These conditions essentially ensure that agood representation is:1. well-defined (mapping and tracking) , and2. well-behaved (reporting and sequencing).Well-definedness can be taken to mean, in the context of the terminology of the previous section,that an information system representation has the capability of capturing any state (mapping) and anyevent (tracking) of a cognitive representation of reality. This allows the state of a specific representationto parallel the state of knowledge about a domain.Whether an information system does actually track the state of knowledge is an issue of well-behavedness and depends on whether (i.e., reporting) and when (i.e., sequencing) changes to the state of740f course, the definitions in the previous section are a representation of, and not actual, mentalconstructs. Nevertheless, a distinction is made between the model of concepts or knowledge, and themodel of IS which deals with constructs for representing that knowledge.106knowledge are reported to the information system. This is certainly important with respect to anyimplementation, but is not of concern in developing the conceptual model. Consequently, only well-definedness is addressed in the formulation which follows.4.4 MIMIC: AN OBJECT-BASED INFORMATION SYSTEMS MODEL4.4.1 PreliminariesIn this section, MIMIC (Morphological Information systems Model of Instances and Concepts)is defined as a model to support representation of cognitive constructs. Five important constructs aredefined based on the five major elements of classical concept theory - instance, property, concept,specialization, and composition. As in the concept model, these are divided into primitive and derivedconstructs.The model will be referred to as an object model (or model of objects). One of the arguments infavor of object-oriented computing has been its so-called "naturalness", or correspondence to the waypeople structure knowledge (Mylopoulos, 1990). However, object constructs have not been clearly relatedto cognitive constructs. Under the assumption that objects represent knowledge about instances ofconcepts, MIMIC is presented as a prescription for what object-oriented approaches "should" contain tosupport the representation of cognitive constructs. A comparison of MIMIC to other characterizations ofthe object paradigm is given in Chapter 5 (Section 5.8).Examples are not provided here for each of the constructs as they are introduced, since they aredirectly analogous to those of Section 4.2, with the difference being that they deal with the externalsymbolic representation level, rather than the cognitive level (see Figure 4-1). Instead, Appendix 1develops a detailed example from a banking domain to illustrate use of the model.1074.4.2 Primitive ConstructsIn the knowledge model, instances and properties were defined as primitives, from which theremaining constructs were derived. Counterparts of these two basic constructs, called objects and attributesrespectively, are defined next.4.4.2.1 ObjectAn object is defined as a surrogate of an instance of a concept. That is, a given set of objects isin 1-1 correspondence with a set of instances. Recall (Definition 1, page 60) that an identification functionof a set 0 in a set T is a bijective function f:T-->0.Definition 28:Let T be a set of instances, 0 a set of symbols, and f an identification function of 0 in T. 0 willbe referred to as a set of objects representing T via f (or simply, 0 represents T). Furthermore,OE 0 will be referred to as an object representing to T iff f(t)=o.For example, T may be a set of instances representing students (i.e., T constitutes one's knowledgeof the existence of a set of students) and 0 may be a set of student numbers assigned to these instances.Objects are, therefore, symbols which represent the existence of instances of concepts. The followingpostulate assumes the existence of a set of objects to represent any set of instances of interest.108Postulate 5:For any finite set of instances, T, there exists a set of symbols (objects) 0 and an identificationfunction PT--40.Corollary:Let 0 denote a set of objects representing a set of instances T via the identification function 1.Then, there exists a bijective function V': p (T)-4 p(0) such that, for each Tie go (1), with fP(V)=Os,{f(t)hcps=0 * .This corollary means that there is a 1-1 correspondence between p (T) and p(0) via f' and is usedlater in the definition of relational attributes.4.4.2.2 Structural AttributeA structural attribute is a representation of a structural property. Intuitively, this means that thereis a 1-1 correspondence between sets of structural property functions and structural attribute functions,between sets of instances and objects constituting the domains of these functions, and between sets ofvalues of structural properties and surrogates values of structural attributes constituting the codomains ofthe functions.In defining the construct formally, the following notation is used. S= fsi ls i :T—W1 denotes astructural property of the set of instances T (e.g., Weight:PERSON-WEIGHT_VALUE), 0 denotes theset of objects representing T via f:T—*O (e.g., 0 contains identification numbers), and g:V -*U denotes abijective function such that U is a set of symbols representing values (e.g., U is a set of symbolsdesignating numbers). Finally, S *=-(s *ils*; :0—*U} denotes a set of functions defined on 0 such that IS*I=ISI.109The essence of the definition is as follows (see Figure 4-4). Consider any tE T such that s,(t)=v iE Vand g(v i)=u iE U. It is also the case that f(t)=oE O. S * will be called a structural attribute if, for each siE S,there exists S.iE S' such that s *i(o)=ui . Definition 29 expresses this formally.Figure 4-4: Structural AttributeS^V0^S *110Definition 29:S* is a (simple)'S structural attribute representing structural property S iff for each s,E S, 3 aunique s*,E S * such thats*,(f(t)) = g(s,(t)) V te T.A set of objects, 0, sharing the set of attributes S*° , will be referred to as a category of objects on 0 (cf.Definition 6, page 65).Next, the existence of structural attributes to represent structural properties is postulated.Postulate 6:For any structural property S, with domain T, there exists a structural attribute S* with domain0, such that 0 represents T (in the sense of Definition 28) and S * represents S (in the sense ofDefinition 29).4.4.2.3 Relational AttributeA relational attribute is a representation of a relational property. Intuitively, this means that thereis a 1-1 correspondence between relational property functions and relational attribute functions, andbetween things and surrogates (on each side of the relation). A relational attribute maps each object in aset to a set of other objects.75The definition can be extended to composite structural attributes (e.g., S *:0 1002—)U), which areanalogous to composite structural properties (e.g., S:T IOT2-4V) (see Definition 22, page 100).111The following notation is used. R=fr1 lr1 :T—>Q1 (where Qc ea (T1)) denotes a relational property ofthings in T with things in T 1. 0, 0 1 denote sets of objects representing T and T', respectively, via theidentification functions f:T-40 and f i :T 1 -->0 1 , and Q`c p(0 1). Then, there exists a bijective functionP:(2—>Q* which satisfies the Corollary to Postulate 5 (page 108). Finally, R* = {ejle1:0 1 --4(2*} denotes aset of functions defined on 0 with respect to 0 1 such that 'RI = IRI.Definition 30:R* is a (simple) 76 binary relational attribute representing the binary relational property R iff foreach riE R, 3 a unique eiE R* such thatr*i(f(t)) = fi P(ri(t)) V tE T (Figure 4-5).A set of relational attributes of 0, denoted by R'°, will be referred to as a category on 0.Postulate 7:For any relational property R, with domain T, there exists a relational attribute R' with domain0, such that 0 represents T (in the sense of Definition 28) and le represents R (in the sense ofDefinition 30)."The definition can be extended to define composite relational attributes.112Figure 4-5: Binary Relational Attribute1 R 00^ RA^0 4iExtended definitions can be given to cover n-ary relationships and distinguish mandatory fromoptional attributes. As these mirror the corresponding definitions of properties (Definitions 9 and 10), theyare not presented here.1134.4.2.4 Object State and Change4.4.2.4.1 Object StateAs with the instances being represented, the objects in a representation can also be described interms of their state. Object states are characterized by the active functions of the structural and relationalattributes of objects OE 0 (which identify things tE T). These functions, in turn, determine values ofsurrogates UE U (of ve V) or sets of objects qacQ* (of qcQ), when applied to objects OE O. The followingdefinitions for objects mirror corresponding state definitions of instances (Definitions 11-13).Recall that defining the state of a category of instances is useful for emphasizing that we thinkof instances by classifying them based on shared properties (see Definition 11, page 73). Therefore, objectstates will similarly be described by the attributes they share. That is, it makes sense to speak of the stateof an object only as a member of a category of objects.Definition 31:Let 0 denote a category of objects, and P*°={P*1 ,...,P*K) denote the set of structural/relationalattributes shared by O. The state of 0, designated 0(0), is a vector containing the active functionof each of the structural and relational attributes possessed by 0 applied to the instances in 077 :GO) = <P*k>kE [1,...,K) = <P*1 11 ,- ,P*KiK>78,where p .k,kE rk, and the index ikeAt a certain time, the state of an object of 0 is:'Each attribute in r° has a domain which is a superset of O. Consequently, in considering the stateof 0 (and in this notation), only the application of the active function of each of the attributes possessedby 0 to the objects in 0 is of interest.78The index ik should be read ik .114G(0)^<13*I i1(0),...,P*KiK(0)>.At a later time, the state of o may be:a'(o) = <P*In(0),...,P*Km(0)>, where i'k*ik for at least Ice (1,...,K}.Consequently, o(0) may also be written:a(0) = <G(0)>0E0 = <a(o 1),...,a(o10)>.That is, the state of 0 is the joint state of the elements (objects) of 0.Definition 32:The potential (or conceivable) state space, denoted E(o), of each object, of 0, is the Cartesianproduct of the codomains of the structural and relational attributes of 0. That is,E(o) =where the D's denote the codomains of the structural and relational attributes possessed 79 by 0.By this definition, each member o of a category 0 has the same possible state space.Definition 33:The possible state space, denoted E(0), of a category of objects, 0, is the set of vectors formedby taking the Cartesian product of the structural and relational attributes of 0. That is:E(0) = P*10...OP*K.This notion is important, since not all the conceivable states are possible. Attributes representproperties and not all potential functions are actually contained in a property. Therefore, not all potential79Possession of an attribute is directly analogous to possession of a property (see discussion followingDefinition 5, page 64).115functions are actually contained in an attribute set.4 .4 .2.4 .2 Object System ChangeTwo important kinds of change to the state of an object representation are described. First, thenotion of state gives rise naturally to the view of an object system event as a state change of an objector set of objects. An event is described by two states - before and after - and involves a change in theactive function of one or more attributes. The second kind of change is change to the domain of attributes:that is, to the set of objects possessing an attribute. This latter notion of change is dealt with first.Our knowledge of the world changes as we become aware of new entities. According to the modelof knowledge that was previously described, this "awareness" is expressed as the creation of new instancesto represent the existence of these entities. In addition, knowledge of the characteristics of entities isrepresented by the properties which they possess. In order for an instance to possess properties (and,therefore, to have values for properties), it must be an element of the domain of these properties.Since objects are intended to represent knowledge about instances of concepts, a mechanism isneeded by which the creation of a new instance is recognized through the creation of an object whichrepresents it, with this object being added to the domain of every structural and relational attribute itpossesses. Consequently, the notion of object domain expansion is defined.Definition 34:Let 0 designate a category of objects, A a nonempty set of objects such that An0=0, 0' = OVA,and Ps = (p*,1p* ; :0-4U) a structural or relational attribute of O. An object domain expansion isa change in the domain of Ps such that Ps =The creation of a new object will be accompanied by a domain expansion for each of the structural116and relational attributes it initially possesses. Similarly, since instances may be removed from a cognitiverepresentation, it is necessary to recognize that objects may be removed from an external representation.This is modeled by the notion of object domain contraction.Definition 35:Let 0 designate a category of objects, A a nonempty set of objects such that AcO, 0' = O-A, andP* = fp.,Ip* i :0—>U1 a structural or relational attribute of 0. An object domain contraction is achange in the domain of P* such that rThe remaining kind of change deals with the change of state of existing objects. Object events aredefined to describe changes in the active function of one or more attributes and, therefore, to describechanges in the state of sets of objects (and individual objects within these sets).Definition 36:Let if = <p* iii ,...,p*KiK> denote a vector containing the active functions of K structural/relationalattributes P",...,P*K (with common domain 0). An object system event with respect to 0, denoted* .e , is a change in the active functions of P*1 ,...,P*K, denoted:e*: <45(0),a'(0)> = <17,15">,where r = <p *In ,...,p*Kix> and en, # P*kik for at least one k=1,...,K.This definition describes an event in terms of a change in the state of the set of all objects in thedomain of any attribute P",...,P*K. However, the interest here is only in changes to objects in 0 =O ln...n0K, where Ok is the domain of Pk .Given the definitions of state and event at the object level, time is given the same meaning as in117the concept model (see Section 4.2.2.3.3). Time is dealt with further in Chapter 5 (Section 5.7).4.4.3 Derived Constructs4.4.3.1 Behavioral AttributeA behavioral attribute is a representation of a behavioral property. Hence, it consists of constraintson object system events with respect to one or more structural/relational attributes. The allowed changesof state of representations are not arbitrary, but mirror the allowed changes of state of a concept structure(see Definition 17, page 84).Behavioral attributes describe the allowable events with respect to a set of structural/relationalattributes. The following notation is used. P *1 ,...,P*K denote K structural/relational attributes representingstructural/relational properties P1 ,...,PK , respectively: that is, P* 1=fp* i lp* i :O l---)V1 1. The following propositionstates that there is an identification function which maps the Cartesian product of P 1 ,...,PK to the Cartesianproduct of P*1 ,...,P*K .Proposition I:There exists an identification function h:PThe function h can be constructed, given Postulates 6 and 7 which assume the existence ofstructural/relational attributes to represent structural/relational properties.Corollary:There exists an identification function h : (pig 1 0 ... opK) ..4 p (p*1 0 ... op*K) .118Using this information, behavioral attribute is formally defined as follows.Definition 37:Let b:131 0...OPK-3 p 0...0PK) denote a behavioral property. A behavioral attribute representingb is a function b *:P*10...OP*K—> p (P* ...OP") such that for each xe1310...CRK :b*(h(x)) = ho(b(x)).The essence of this definition is to mirror the definition of behavioral property, pointing out thatfrom a given state of a set of objects, only certain events are allowed.Postulate 8:For any behavioral property b, there exists a behavioral attribute b * such that b* represents b.In addition, the correspondence between properties and attributes means that any collection ofstructural/relational attributes has an associated set of behavioral attributes which constrain changes to theiractive functions.4.43.2 ClassThe class construct will be defined to mirror the definition of concept. In what follows, 0 denotesa "universe" of objects (i.e., a set of objects representing a universe of instances, T). P*0 denotes the setof structural/relational attributes possessed by the objects of 0. (i.e., ro represents PT). The definitionof class relies on the following theorem.119Theorem 4:Let C = <P,B> = <{P 1 ,...,Pm},{b1 ,...,b1(}> denote a potential concept in T. There exists a pair C *= <P* ,B *> = <{P.1 ,...,P*m },{b*1 ,...,b*K}> of sets of structural/relational, and behavioral attributesof 0, respectively, such that:for each Pme P, 3 a unique P*InE P* such that P*in represents Pm,for each bkE B, 3 a unique b*kE B * such that bak represents bk .Proof:The proof of the theorem follows directly from Postulates 6, 7, and 8 since, for each property ofT, there exists a corresponding attribute representing that property. For any collection of properties C, C *can be constructed. 111Since C* represents a potential concept, it will be referred to as a potential class.Definition 38:C* = <P*,B*> will be called a potential class (or potential object class) representing the potentialconcept C = <P,B>.Proposition 2:C * satisfiesa) e(C*)*0, andb) P`'e (P*0-0 such that O'De(C*) (where 0' is the domain of Pt').Proof:The potential class C * is a direct mapping of the potential concept C. Since the stated conditionsdefine C as a potential concept, they are preserved in the mapping. ■120Definition 39:Let C' = {13.1 ,...,13*K } 80 denote a potential class. e(c') = C* In...nC *1( will be referred to as theextension of C*.Theorem 5:Two potential classes cannot have the same extension.Proof:This follows directly from the proof of Theorem 1 (page 93), given the fact that a potential classis a direct mapping of a potential concept. ■Given the definition of potential class, the notion of class structure can be defined to correspondto concept structure. The definition uses a theorem about the existence of potential classes representingpotential concepts. Let 0 be a universe of objects representing a universe of instances T, ro be a set ofattributes representing the set of properties possessed by instances of T (i.e., PT), and CS = {C 1 ,...,CKdenote a concept structure over T.Theorem 6:There exists a set of potential classes CS' = {C *1 ,...,C*K} such that Csk represents Ck, k=1,...,K.Proof:From Theorem 4 (page 119), there exists a class representing each concept in CS. CS' can beconstructed to contain the set of such classes. ■8°The behavioral attributes are dropped from the notation here, since they are not relevant to thedefinition.121Definition 40:CS* = {C',...,C*9 will be called a class structure over O.4.4.3.3 SpecializationClass specialization is defined to correspond to concept specialization. The essence is to recognizethat certain classes refine others by possessing additional attributes.Definition 41:Let C *1 , C *2 denote two classes in a class structure (each is a set of attributes). Then, C •2 is aspecialization (subclass) of C*1 (C*2 IS-A C* 1) if C* 1cC*2.Theorem 7:Let C*° , C *1 , and C•2 denote three classes in a class structure. Then, if C *2 is a specialization ofboth C*° and C *1 , C *2DC*°uC *1 .Proof:Given the fact that classes in a class structure represent concepts in a concept structure, the proofmirrors that of Theorem 2 (page 96). ■Theorem 8:Let e(C*1), e(C*2) denote the extensions of C *1 and C*2, respectively, where C *2 IS-A C*1 . Then,e(C*2)ce(C*1).122Proof:Given that C *1 and C *2 are classes in a class structure representing concepts C 1 and C 2, the proofmirrors that of Theorem 3 (page 97). ■4.43.4 CompositionThe remaining construct of the object model represents the notion of composite concept. Thisconstruct is called a composite class. A composite class consists of a number of component classes and,additionally, possesses a number of emergent attributes.Definition 42:Let C denote a composite concept and C * denote a class representing C. C is called a compositeclass.The existence of a class representing any concept (including composites) follows from Theorem4 (page 119). The attributes of C are composite attributes representing the composite properties of C.A composite object is an n-tuple containing n objects of other classes. Each object correspondsto a component of the corresponding composite instance.This completes the definition of the major constructs of the MIMIC model. In the next subsection,these constructs are shown to support the creation of well-defined representations.1234.4.4 Well-definedness of MIMICProposition 3:The MIMIC model supports the creation of well-defined representations.To show this, it is necessary to show that(a) any state of interest of an instance of the concept model (i.e., any state of a concept structure) canbe represented by some state of a class structure in MIMIC, and(b) any event of interest in an instance of the concept model (i.e., any change of state of a conceptstructure) can be represented by a corresponding event in a class structure in MIMIC.MIMIC supports the correspondences: (1) Instances <---> Objects, (2) Properties <--> Attributes, and(3) Concepts 4---> Classes. The correspondences between instances and objects, structural/relationalproperties and structural/relational attributes, and concepts and classes together allow any state of interestof an instance of the concept model to be represented by a corresponding state of MIMIC. Thecorrespondence between behavioral properties and behavioral attributes allows any event of interest of aninstance of the concept model to be represented by a corresponding event of MIMIC.Appendix 1 presents a detailed example which demonstrates the use of the model in describingthree kinds of applications (transaction processing, reasoning, and simulation) in a domain. This bothshows the utility of the model, and its suitability as a basis for uniformly modelling knowledge aboutdifferent kinds of applications. In the next Chapter, a number of contributions and insights into conceptualmodelling offered by the MIMIC model are examined. This is followed in Chapter 6 by a comparison toseveral existing conceptual models.CHAPTER 5MODELLING INSIGHTS AND PRESCRIPTIONS5.1 INTRODUCTIONIn the previous chapter, a formal model (MIMIC) was developed for representing knowledge aboutthings and their structural, relational, and behavioral properties. Use of the model is demonstrated inAppendix 1. In this chapter, several contributions of MIMIC to conceptual modelling are discussed indetail and, where applicable, practical modelling guidelines are suggested. Consequently, this chaptercomplements Chapter 4 by using the constructs developed there to gain some insights into the semanticsof conceptual modelling. Subsequently, Chapter 6 compares MIMIC to several well-known approachesto conceptual modelling, demonstrating the representation power and uniformity of the model, as well asits usefulness as a framework for understanding other models.The following sections discuss problems (or unresolved issues) in conceptual modelling. Eachbegins by identifying a problem and reviewing its treatment in previous conceptual modelling research.Next, the way in which MIMIC deals with the issue is examined. Consequences of the basic cognitiveassumptions of the model, as well as of the chosen formalism, are derived and the resulting implicationsfor understanding and resolving the issue in question are discussed. Finally, where applicable, sectionsconclude with a prescription or guideline for performing conceptual modelling.5.2 ON CRITERIA FOR DEFINING A CLASS STRUCTUREAn important task in modelling or representing knowledge is organizing representations ofindividual things into categories or classes (e.g., Coad and Yourdon, 1991). This, of course, mirrors theimportance of categorization to everyday life (Lakoff, 1987; Smith and Medin, 1981). However, very fewguidelines exist to assist in this organization, and there do not appear to be any published measures of the124125quality81 of a class structure. Consequently, it is difficult to determine the value of possible classes suchas "the set of persons over 65" or "the set of persons who are both customers and employees".At one extreme, there is conceivably a class for each individual in the domain. Clearly, thisnullifies an important purpose of classification: namely, to abstract what is common about a group ofthings and, thereby, to provide economy of representation (see Chapter 3). At the other extreme, onemonolithic class may be defined to describe all individuals. However, this level of abstraction is toogeneral, and loses knowledge of important distinctions among subsets of the members of this class, sincewhat is common about all things is very little. In practice, people appear to favour intermediate levels ofabstraction or classification (Rosch, 1978).More specifically, the issue considered here is that existing conceptual modelling approaches donot provide a theoretical basis for deciding on an appropriate level of classification. This may lead to aproliferation of "classes", many of which do not contribute to the basic function of categorization as amechanism which abstracts common knowledge about a set of things. Two examples from the object-oriented programming and semantic data modelling literature are used to highlight one important aspectof prior treatment of this issue - the lack of guidelines for determining when to form subclasses of anexisting class. In particular, neither requires that subclasses possess additional attributes with respect tosuperclasses. As will be seen, this is in contrast with the nature of class specialization in MIMIC. Inaddition, several other necessary criteria for a good class structure in MIMIC are discussed.In the Smalltalk programming language (Goldberg and Robson, 1989), subclasses can be definedwithout adding new instance variables and without adding or changing methods. In fact, Goldberg andRobson state that "[n]ew variables may be declared and new methods may be added by the subclass" (p.58,italics mine), but Smalltalk does not enforce that this must be so. In Smalltalk, subclasses which do noten quality of a class structure is closely related to the questions of whether and why some classesare "better" than others.126add instance variables or methods contribute nothing to the organization of knowledge about a domain,since instances of the subclasses do not differ in any structural or behavioral way from instances ofsuperclasses.In the semantic data modelling area, SDM (Hammer and McLeod, 1981; see also Section 2.3.2of this thesis) provides a number of guidelines for defining subclasses, each of which is discussed hereusing examples provided by the authors. The first is by value of an attribute. An example isMERCHANT SHIP, a subclass of SHIP for which the value of the attribute Type (of SHIP) is"merchant". However, there is no requirement that the subclass be defined in terms of additional attributes.A second basis for defining subclasses in SDM is referred to as user-controllable. Such subclasses, also,are not based on added attributes or common values of attributes. An example is BANNED_SHIP, theinstances of which are assigned by users 82. The third criterion for defining subclasses is based on theintersection of two existing subclasses of a third class. The example given is BANNED_OIL_TANKER,which is the intersection of BANNED SHIP and OIL TANKER, where both of the latter are subclassesof SHIP. SDM also permits subclasses to be defined based on the union or difference of existing classes.In general, these are referred to as set-operator-defined subclasses. As with the previous criteria, there isno indication that the subclasses necessarily possess additional attributes. Finally, a class may be definedto consist of those members of an existing class that are currently the value of an attribute of anotherclass. An example is DANGEROUS_CAPTAIN, defined as the set containing all members of classCAPTAIN which are currently the value of the Involved_captain attribute of any instance of the classINCIDENT (i.e., DANGEROUS_CAPTAIN contains all captains involved in an incident). Again, thereis no requirement that the subclass must possess additional attributes.One notable characteristic of SDM's criteria for subclass definition is that they appear quite82Note that one could assign an attribute Status of class SHIP, one of the values of which is "banned".In that case, the subclass BANNED_SHIP could be derived as in the first example discussed. Therefore,it is not clear how this basis for defining subclasses differs in principle from the first.127arbitrary. That is, there is no evidence that the criteria are, in any sense, complete and others could easilybe proposed. For example, a subclass of an existing class could be defined to consist of the instances ofthe latter having values of an attribute in a certain range. Similarly, subclasses could be defined for whichcertain conjunctions (or disjunctions) of conditions, such as restrictions on attribute values, are met. Inshort, there are no guidelines for defining a reasonable number of useful subclasses, since the criteriadiscussed above are not based on any underlying principles.The examples show that, without appropriate criteria for defining subclasses, a proliferation ofclasses may result. That is, if specializations are arbitrarily defined on the basis of the criteria above (andperhaps others), the number of classes may be very large. More importantly, many classes may not addto the structuring and abstraction of knowledge.To illustrate this, consider a class SENIOR CITIZEN, defined as the set of all PERSONs suchthat Age ?. 65. Unless there are additional attributes possessed by the set of people satisfying thatcondition which are not possessed by PERSONs in general, the only knowledge captured by definingSENIOR CITIZEN as a class is that the value of the attribute Birthdate for its members has a restrictedrange relative to values for the more general class PERSON. This does not in fact constitute additionalinformation, since it is already embedded in the values of the birthdate attribute for the instances ofPERSON. That is, there is a subset of PERSON whose instances have a restricted range of values forBirthdate. Consequently, there could also be classes of people with ages greater than one, four, thirtynine, and so on. Without some guidelines or restrictions on the formation of subclasses, an explosion of"classes" of dubious value can be formed. Although this observation may seem obvious, it is one notpreviously made in discussions of subclass definition.In order to provide guidelines for deciding whether to define a subclass, it is useful to first drawa distinction between a set of objects and the extension of a class. A set of objects can be purely arbitrary(e.g., user controllable subclasses in SDM), while the extension of a class is determined by a common set128of attributes (i.e., intensionally). Thus, there is an asymmetry in that, while the extension of any class isa set of objects, a set of objects does not necessarily constitute the extension of a class. The view ofclasses in SDM is extensional in that a class is a set of objects.A foundation for criteria for defining specialized classes is provided by the basic assumptions ofclassification theory. The classical theory of concepts and associated theories of semantic memory suggestthat specialized concepts are different from more general ones by abstracting extra knowledge (e.g., Keil,1979; Smith, 1978). This was codified in Chapter 4 as the principle of non-redundancy, and is understoodto mean that the specialization permits additional questions to be answered in relation to the more generalconcept. In other words, knowing that an instance belongs to a category implies certain knowledge thatmay not be specified when the instance is classified, and which cannot be understood simply by knowingthat the instance belongs to a more general concept.To illustrate this notion of abstracting additional knowledge, suppose that EMPLOYEE is aspecialization of PERSON for which one of the added attributes is Department, whose value indicatesthe department an employee works in. In this case, it makes sense to ask questions such as "Whichdepartment does the employee John work in?" Clearly, this question might have different answers fordifferent EMPLOYEEs. This is not, in general, a sensible question to ask of PERSONs, since not allpersons are employees, and the question has no meaning for those who are not. On the other hand,suppose that a specialized concept is defined to contain only the instances of a more general concepthaving a certain value or range of values for one or more attributes. For example, one might think ofADULT as the specialization of PERSON for which the value of Age is greater than 18 years. By itself,this permits no additional questions to be answered with respect to the more general concept of PERSON,since the age of a person can be determined without reference to a "specialization" such as ADULT.Nevertheless, most people would agree that a concept such as ADULT is quite useful. However,according to the assumption stated earlier the usefulness stems, not from the knowledge that the age of129such individuals is greater than 18 years (or some other arbitrary number), but from the fact that societybestows on these persons additional properties. Hence, if John is an instance of ADULT, it makes sense(depending on the society) to ask questions such as "Does John have a driver's license?", "Which partydoes John intend to vote for in the upcoming election?", "To whom is John married?", and so on". Inother words, the essence of adulthood is that some persons possess added properties with respect to otherpersons. While the instances of ADULT do have a restricted range of values for the attribute Age (orBirthdate), this alone does not permit additional questions to be answered (or inferences made).To consider a more complex example, suppose that males and females in some country retire atdifferent ages. To define a subclass of PERSON called RETIRED_PERSON, one might specify acompound condition such as "Sex=Male and Age65 or Sex=Female and Age.60". Although thiscondition is a sufficient test to identify a person as retired, it misses the fundamental meaning of"retiredness". Retired people differ from people in general since they possess additional properties (e.g.,Company_pension), and may not be permitted to possess properties that some other persons possess (e.g.,Employer).These examples show that there are complementary roles of added properties and constraints onproperty values in the definition of subclasses. The characterization of class membership by values of anattribute may play an important role for humans when it comes to classifying new instances in the absenceof complete information. In fact, values of one attribute may often be the reason for acquiring certain otherattributes (as in ADULT). Hence, this may serve as a useful identification procedure (Armstrong et al.,1983). For example, an individual can be classified as a SENIOR_CITIZEN provided that we know thatthe person was born prior to a certain date. In addition, we can infer that the person possesses the addedproperties of SENIOR_CITIZEN (e.g., Government_pension) even if the values of these additional83In fact, there may be some difficulty in defining a minimum common age for which all theseproperties are defined, since minimum legal driving, voting, and marrying ages may not be identical.130properties are unknown at the time of classification. In fact, knowledge about a person's birth date maymotivate an effort to determine the values of the added attributes. To further illustrate the issue, considera class called ORDER, and the set of "all orders valued over $500". This set of objects does notautomatically constitute a class. However, orders meeting this condition may be subject to discounts orspecial payment terms. These additional attributes can be used to define a subclass. Furthermore, the rangeof values of the Amount attribute for members of the subclass is restricted to the subset of values greaterthan $500. This identifies an order as belonging to the subclass.The discussion earlier indicated that subclass definition has been handled in largely an arbitraryfashion in existing modelling approaches. It will now be shown that MIMIC imposes a clear minimalcriterion (i.e., a necessary condition) for defining subclasses that is consistent with abstracting addedknowledge in the manner just described and, therefore, is consistent with the model as a formalization ofthe classical theory of concepts. In addition, further criteria for a good class structure are reviewed.In MIMIC, a class structure CS contains a set of classes {C 1 ,...,CK}". Each class is intensionallydefined as a set of structural/relational attributes, and satisfies the condition that Ck does not equal theunion of the attributes of any other subset of classes in CS. It follows from this that a subclass mustpossess at least one additional structural or relational attribute with respect to union of the sets of structuraland relational attributes of its superclasses (Theorem 7, Chapter 4). That is, letting P, P' denote sets ofattributes a class C' = P' is a subclass of C = P only if PcP' (Definition 41, Chapter 4). It is theseadditional attributes which, according to the model, permit a subclass to be defined. This restriction isnot enforced in other treatments of class specialization. In addition, this minimal criterion is consistentwith the earlier description of what specialization means. That is, a subclass always provides the basis foranswering additional questions beyond those which can be answered with respect to all superclasses.The "*" notation (e.g., CS *) used in the previous chapter to distinguish the cognitive and object levelshas been dropped for simplicity, since the focus in this chapter is on one level only - the object level.13 1MIMIC' s view of specialization can prevent a needless proliferation of classes. Although manyclasses can still be formed from (random) permutations of attributes, the upper bound will be far smallerthan that possible under the looser conditions contained in modelling approaches such as SDM. Inaddition, subclasses possess additional meaning when defined by added attributes, in that the classdefinitions abstract further commonality of a subset of the extension of one or more superclasses.A practical methodological implication for systems analysis (conceptual modelling) emerges fromthis view. Attempts by users to specify specialized categories of things based on, say, values ofattributes85, can be followed up by asking "why?". Such probing would be aimed at eliciting additionalstructural, relational, and behavioral attributes associated with the subcategories. Inability to do so shouldlead to a re-examination of the need for the specialization. This constitutes a clear guideline for modellingwhich is derived directly from the foundations of the model. Furthermore, if a class is claimed to be aspecialization of two or more others, the analyst should identify what additional attributes distinguish itwith respect to the union of the attributes of all superclasses. If none can be identified, the subclass is nota good abstraction.A Case Against Behavior-based SubclassesThe MIMIC model does not permit the definition of subclasses based solely on added behavioralattributes. Recall that a class C = P, where P is a set of structural/relational attributes, can also bespecified C = <P,B>, where B contains all behavioral attributes constraining changes to any attribute inP. On first glance, one might argue that for a class C=<P,B>, a subclass C'=<P,B'> might well bedefined, possessing only additional behavioral attributes (i.e., BcB').However, according to the MIMIC formalism, the extension of a class is determined completely85This applies also to attempts to specify categories based on other criteria, such as set operations(intersection/union/difference) on two or more existing categories.132by the intersection of the domains of its structural and relational attributes, as are the behavioral attributeswhich constrain changes to the active functions of any structural/relational attribute. Consequently, twoclasses cannot differ only on the basis of behavioral attributes. Even if behavioral constraints were not"implied" by the set of structural/relational attributes defining a class, since they are defined on domainsof Cartesian products of structural and relational attributes (Definition 37, Chapter 4), the addition ofbehavioral attributes could not restrict the extension of a class. Since a basic outcome of classspecialization is that a subclass contains strictly fewer members than each of its superclasses (Theorem8, Chapter 4), behavioral attributes alone are not a basis for class specialization.This result is counter-intuitive. For example, one might argue that MANAGER is a subclass ofEMPLOYEE for which changes to the value of attribute Salary can exceed 10% (presumably for otheremployees it cannot) 86. However, the model prescribes that such a class can be defined only if there areadditional structural and/or relational attributes (e.g., Manages other employees). Thus, while addedbehavioral attributes may accompany a subclass definitions', they are not sufficient for defining asubclass.In a similar vein, one might argue that EMPLOYEE can be specialized as follows. EMPLOYEEswith Salary < $30000 receive 3% raises annually, whereas all other employees receive no raises (as partof a pay equity plan). This appears to specialize EMPLOYEE into two mutually exclusive subclassesbased on value of Salary, with only behavior differing between the two classes. On closer examination,however, it is clear that the information contained in such a distinction is captured by a single behavioralattribute - one which permits increases in salary (i.e., changes in the active function of Salary which resultin increases for one or more EMPLOYEEs) only for employees with Salary<30000, given any active86This could be interpreted to mean that EMPLOYEE has a behavioral attribute b:Salary--> p(Salary),while MANAGER has a behavioral attribute W:Salary—> p(Salary)."This could mean that MANAGER possesses the behavioral attributeb':Salary®Manages-3 p (S alary0Manages).133function of Salary. Note that it is the state of EMPLOYEEs with respect to Salary which determineswhether a raise may be given. Furthermore, all questions of interest about allowed behavior with respectto Salary can be answered by knowing the state of an EMPLOYEE with respect to Salary.In MIMIC, a behavioral attribute specifies allowed events given active functions ofstructural/relational attributes. Consequently, the restriction on raises can be modelled as a behavioralattribute, b:Salary—> (Salary). That is, if s l is the active function of Salary, then an event <s l ,s2> isallowed (i.e., s2E b(s 1 )) only if, for each eE EMPLOYEE, s 1 (e)<30000 s2(e)=1.03*s 1(e) and s 1 (e)?..30000s2(e)=s 1 (e). This attribute captures differences in behavior based on the current state of the instances ofa class. Since the distinction is naturally captured by modelling Salary as a set of functions, thisconstitutes a useful additional benefit of defining structural and relational attributes as sets of functions,rather than single functions.In this way, a precise meaning is given to what otherwise might be a loosely- or even ill-definedphrase such as "behavioral differences". The general notion of having different behavior is imprecise sinceit may mean either that allowed changes of state of objects in a class differ depending on the current stateof objects, or that objects behave differently by virtue of possessing different structural and relationalattributes. In MIMIC, differences in behavior based on the current state of instances do not constitutedifferent behavioral attributes, thereby providing a more precise view of behavioral differences.The MIMIC model suggests that structural and relational attributes are more fundamental thanbehavioral attributes as a basis for classification and class specialization, since behavioral constraints areonly implicitly contained in class definitions. This conclusion emerges from the chosen formalism (usingthe cognitive assumption that subclasses contain more information), and is not recognized in existingtheories of concepts (e.g., see Smith and Medin, 1981; Lakoff, 1987). In these theories, the notion ofclassification by common behavior is not clearly specified, perhaps due to a lack of formalization inspecifying what properties are. In MIMIC, classes may be specialized only by considering additional134structural and relational attributes. Since this restriction emerges from the formalism chosen (and not froman assumption of classical concept theory), it may be that another formalism (specifically, a differentdefinition of behavior) might permit subclasses to be defined based solely on behavioral differences.The inadequacy of behavioral attributes for class specialization again offers a clear modellingguideline or prescription. Specifically, if a user informally describes a specialized category which ischaracterized only by added behavioral attributes, the analyst should try to identify furtherstructural/relational attributes possessed by each subset of objects which "behaves differently". Suchprobing would be aimed at eliciting additional structural and relational attributes which motivate thespecialization. If further attributes do not exist, the differences in behavior resulting from different statesof instances of a class can be modelled as a behavioral attribute on the existing class (as in the exampleearlier of allowed salary increments being based on current salary).This constitutes a useful mechanism to aid in defining a class structure based on a cognitivemodel. However, the model contains several other necessary conditions for a class structure to beconsidered "good".The first is that a potential class abstracts the set of all attributes common to its instances(principle of maximal abstraction). This means, for instance, that a class EMPLOYEE is not defined tocontain only the attribute Works_in_department, although this may be a condition true only ofEMPLOYEEs. The point is that people who are employees also possess numerous other attributes, suchas Birthdate and Supervisor. Some of these are possessed by virtue of the fact that EMPLOYEEs arePERSONs (i.e., inheritance), but others, such as Supervisor, may simply have the same or a largerdomain as Works_ in _ department. The principle of maximal abstraction states that all such attributes areto be included in a class definition. This point does not appear to be considered in other conceptualmodels.135The second condition is that a class has a non-empty extension (principle of abstraction frominstances). Although this has not been explicitly considered by other models, this may simply be becauseit is such an obvious consideration. It is mentioned here merely to emphasize that classes are defined toreflect the premise that concepts are abstracted from instances.The third criterion deals with the nature of a class structure for representing some "universe" ofknowledge (principle of completeness). Specifically, all relevant properties which characterize the universeof knowledge and, therefore, which are part of any concept structure on that knowledge, should becontained in the class structure representing that knowledge. This means that every property is representedby an attribute attached to some class.These criteria are interesting because they allow for multiple views of the world: that is, multipleclass structures which satisfy the other principles ( this is principle of variety). This is discussed furtherin the next section.To summarize, some necessary criteria for defining a class structure have been provided, withparticular attention paid to a necessary condition for defining subclasses. That is, a subclass must possessat least one structural/relational attribute beyond the union of the attributes of its superclasses. This leadsto a clear modelling guideline for analysts in eliciting a classification structure for a domain: namely,search for added structural/relational attributes if a user specifies subclasses based on:a) values of an attribute of an existing class,b) intersection (union, difference) of the extension of two or more existing classes,c) added behavioral attributes.This recommendation indicates the importance of structural and relational attributes for classspecialization. While knowledge about things includes structure, relationships, and behavior, the lastelement alone is not a basis for developing category refinements and, if present, must be accompanied by136further structural or relational attributes.In the next section, the contribution of the model to resolving the debate over single versusmultiple inheritance is discussed.5.3 ON CLASS STRUCTURE - HIERARCHY VERSUS LATTICEThere are varying positions in both the AI and object-oriented literatures about whether modelsand systems should support a hierarchical class structure, in which a class has a single immediatesuperclass, or a more general lattice structure, in which a class may have several immediate superclasses(e.g., Goldberg and Robson, 1989; Stefik and Bobrow, 1986; Fikes and Kehler, 1985). An importantconsequence of this choice is the nature of the inheritance of attributes from superclasses to subclasses.Specifically, a hierarchical structure supports only single inheritance, while a lattice structure supportsmultiple inheritance.The issue of a hierarchical versus lattice class structure has important ramifications for conceptualmodelling, since it may affect the number and nature of classes used to model a domain. In this section,the problem is examined and the MIMIC model is used to justify the "naturalness" of a lattice structurefor organizing classes. First, though, two examples from the programming language domain are used toillustrate differing approaches to class specialization.In Smalltalk (Goldberg and Robson, 1989), classes are organized in a strict hierarchy. That is, eachsubclass has a single immediate superclass. Inheritance is single. In such a system, the class structure ofFigure 5-1 might be used to define a group of subclasses of VEHICLE, where Medium andMotorization are important criteria for distinguishing classes 88 .'Note that the subclasses must also possess additional structural/relational attributes, and that thecharacterization by Medium and Motorization is merely shorthand for this. In addition, this is onlyintended to be an illustrative example, and the class lattice could well be organized differently.137Figure 5-1: A Hierarchical Class StructureVEHICLELAND^WATER^AIRA A AMO? UL Y MWY UWY MAY UAVHere, it is not clear why Medium (i.e., land, water, air) is used to derive the first "level" ofspecialization, and Motorization (i.e., motorized, unmotorized) to derive the second, since thesedimensions are orthogonal. The structure above implies a decision about "importance" that appears to beunjustified: namely, that Medium is more "fundamental" than Motorization. In addition, there are noexplicit classes of MOTORIZED and UNMOTORIZED vehicles, although these might well be ofinterest for an application.By contrast, a system such as LOOPS (Stefik and Bobrow, 1985), classes are organized in alattice. Under this approach, the example above might have the class structure of Figure 5-2:Figure 5-2: A Lattice Class StructureVEHICLEMOTORIZED  UNMOTORIZED LAND WATER AIRMLV^MWV^MAY^UL V^UWV^UAV138Unlike the previous example, this recognizes a class of all MOTORIZED vehicles (as well asUNMOTORIZED) 89 . This cannot be done in a strict hierarchical system without choosing Motorizationover Medium as the primary basis for subclass definition, in which case the classes of LAND, AIR, andWATER vehicles are lost. Consequently, a lattice appears to be a more flexible mechanism for organizingclasses. Further indication of this in the context of MIMIC is given later.The same issue has been raised in the semantic and object-oriented data model areas (e.g.,Banerjee et al., 1987; Fishman et al., 1987; Hammer and McLeod, 1981). Most models support a classlattice with multiple inheritance.The approach taken in dealing with classification in MIMIC is derived from the principle ofabstraction from instances - the notion that concepts are defined based on shared properties of instances.However, there is no reason why the sharing of properties must be hierarchical (Smith, 1978; Quillian,1968). In line with the theory of concepts in which the model is grounded, the basic guideline governingthe specialization of classes in MIMIC is that a subclass must possess added attributes which permitadditional questions to be answered about objects. Since classes are defined as collections of attributes,attributes can be combined in different ways to yield different class structures, subject to the criteriadiscussed in the previous section. Furthermore, there is nothing to prevent a class from being derived fromtwo (or more) existing classes provided that it possesses added attributes with respect to those of allsuperclasses. This is a point which is not explicitly addressed in theories of concepts and semanticmemory, but emerges from the attribute-based definition of class in MIMIC.MIMIC defines a class as a set, P, of structural and relational attributes. If class C' = P' (or<P',B'>, recognizing the associated behavioral constraints) is a subclass of C = P (or <P,B>), then PcP'and BcB', and C' is said to inherit the attributes of C. That is, instances of C' possess (i.e., are in thedomain of) all the attributes of C plus some additional ones. Also, an instance of C' is an instance of C.89These classes may or may not be disjoint.139Now, let C" P" (or <P",B"> denote a distinct subclass of C, (i.e. Pc(P'nP")c(P'oP"). Then, by theprinciple of non-redundancy a class M = <Pm,Bm> is a subclass of both C' and C" if and only ifP'uP"cPm (implying B'uB"cBm). That is, M contains all the attributes of C' and C", plus some additionalones, and is said to inherit multiply from C' and C".This example illustrates multiple inheritance from an intensional point of view. However, multipleinheritance also has an extensional interpretation. Each attribute is defined over a domain of objects. Anobject will typically be in the domain of many structural and relational attributes. By considering variouscombinations of attributes, multiple class structures can be formed. The extension of a class is determinedby the intersection of the domains of its structural and relational attributes, as shown in Figure 5-3.Figure 5-3: Extension of a Classd(S1)d(R)d(82)Notationd(X) domain of attribute Xe(C) extension of classC = -1S1, S2}, {R}, B>Now, for any two classes C 1 and C2 with extensions e(C') and e(C2), respectively, there is a140(possibly empty) set of objects, e(M) = e(C 1)ne(C2). If e(M) is non-empty, it may denote the extensionof a class M only if there exists at least one structural or relational attribute P m with domain d(PM), suchthat Pm is not an attribute of either C 1 or C2 and e(M)cd(PM). Thus, class specialization is purely attribute-based.From the model, objects may be interpreted as having "roles" by their membership in severalclasses (Richardson and Schwarz, 1991; Pernici, 1990; Sciore, 1989). An object may simultaneouslybelong to several classes which are not in a single specialization path 9° (i.e., no class is a subclass of anyof the others in question). For example, a vehicle is both a MOTORIZED and a LAND vehicle. Thisallows one to consider only the attributes which are relevant for a particular application. The modelthereby supports various "views" of an object corresponding to its membership in several classes.There is also a second way in which MIMIC supports various views of an object. The principleof variety states that, for a given universe of objects and attributes, there may be many class structureswhich satisfy the other principles of conceptualization. For example, different individuals (or departmentsin an organization) may divide the same world (objects and attributes) into distinct class structures bestsuited to their needs. Hence, the model supports, not only different views of an object within a classstructure, but also different class structures for a given set of objects and attributes.Returning to the example of Figure 5-2, it is now clear that there is extra information in this classstructure with respect to that of Figure 5-1. The sets of classes {LAND, WATER, AIR) and(MOTORIZED, UNMOTORIZED) exhaust (and possibly partition) VEHICLE along different dimensions.Consequently, any subclass beyond this level must be a subclass of at least (and possibly exactly) oneclass from (LAND, WATER, AIR) and at least (possibly exactly) one from (MOTORIZED,UNMOTORIZED). If either of these sets of classes partitions VEHICLE, a class at the third level is a90A specialization path is a collection of IS-A edges linking class nodes A,B,...,K such that A IS-AB IS-A ... IS-A K. An object always belongs to each of the classes in a specialization path.141subclass of exactly one class from that set. This is captured in MIMIC by virtue of the fact that if, say,(MOTORIZED, UNMOTORIZED} partitions VEHICLE, then the intersection of the shared domain ofthe added attributes defining MOTORIZED with the shared domain of the added attributes definingUNMOTORIZED is the empty set. Therefore, any subclass of MOTORIZED cannot also be a subclassof UNMOTORIZED (and vice versa) since MOTORIZED and UNMOTORIZED share no instances.This approach to class specialization (and multiple inheritance) gives rise to another potentialguideline for modelling, which may be termed an instance and attribute search strategy. The analyst canwork with the user(s) to identify sets of objects and the structural and relational attributes which apply tothem. For example, specific objects could be compared to ascertain their common attributes. A provisionaldecision could be made to view these attributes as the definition of a class. Subsequently, further instancescould be classified and, if necessary, attributes added or removed from the provisional class definition.At that point, behavioral attributes can be determined based on the structural and relational attributesdefining a class. This may, in turn, uncover structural/relational attributes which were originally missed.Such a strategy could complement one of first specifying classes and then eliciting attributes for theseclasses. Motivating this guideline is an assumption that shared attributes are the fundamental basis forclassification and can support different class structures, which may change over time as needed. As aresult, identifying attributes first may be more "stable" than identifying classes first.The class structures which are possible depend on which of two assumptions is made about theadded attributes of subclasses in a multiple inheritance context. One assumption is that a subclasspossesses added attributes with respect to the attributes of each of its superclasses. The more restrictiveassumption, and the one enforced by MIMIC, is that a subclass must possess added attributes with respectto the union of the attributes of all its superclasses (principle of non-redundancy). The consequences ofthese assumptions in terms of their impact on the possible organization of a class lattice are nowexamined.142The issue here is best illustrated with a simple example. Consider a "world" of objects, 0, andthe structural/relational attributes P1, P2, and P3 which are possessed by any of the objects in 0. Assumethat the potential classes are:C l = {P 1 }C2 = {P2 }• = (1)3 1C4 = P2}C5 = {13 ', P3 }• = {P2 , P3 }• = {P l , P2, P3 }Under the first assumption, any combination of these classes is allowed. However, under thesecond, only certain class structures are possible. One class structure over 0 is CSA= {C 1 ,C2,C3 } : that is,classes containing only a single attribute. Given this class structure, no subclasses can be defined, sinceno combination of P 2, and P3 permits any additional questions to be answered with respect to the initialclasses. However, if, for example, C' and C 2 are the only classes defined to contain a single property, thenthe subclasses C' (an immediate subclass of C') and C6 (an immediate subclass of C 2) may be included,since each contains an added attribute with respect to its single superclass. This means thatCSB={C 1 ,C2 ,C5,C6 } is another class structure over 0. Alternatively, C7 may be defined as a subclass ofboth C l and C2 , since it has an additional attribute with respect to the union of the attributes of C l andC 2 (i.e., with respect to {P 1 ,P2 }). Therefore, CSC.{C 1 ,C2,C7 } is yet a third class structure over 0. The pointis that a class structure limits the classes which satisfy the principles of non-redundancy and completeness.This simple example indicates the dominant role of attributes and the notion of a class structurein determining how subclasses may be formed. Various class structures are possible, with the possiblesubclasses depending on the classes which are defined at the highest level of a structure (i.e., those withfewest attributes). No complete guidelines on the grouping of attributes to define classes can be offered143here. However, reasonable guidelines and restrictions on arbitrariness have been suggested based on somefundamental assumptions about the nature of concepts and the importance of categorization (specifically,the sharing of attributes in a non-hierarchical manner).In summary, MIMIC classes are formed as groupings of attributes. Class organization in thegeneral case can be expressed as a directed acyclic graph. The model provides an attribute-based approachto class definition and specialization/inheritance.5.4 ON THE MEANINGS OF "ISA"There is considerable ambiguity in research in the AI and database communities about the use ofIS-A relationships (also called subset hierarchies, generalization hierarchies, etc.) to capture worldknowledge. This is most evident in a paper by Brachman (1983), which describes a number of differentways in which the label IS-A has been used 91 .The general meaning of IS-A may be conveyed as follows. Let e(A), e(B) designate the extensionof classes A and B. Then, B IS-A A iff every member of B is also a member of A (e.g., Brachman, 1983;Mylopoulos et al., 1980). That is, e(B) is a proper subset of e(A). Figure 5-4 illustrates this with a Venndiagram.91This discussion focuses strictly on IS-A relationships between classes of objects and not on linksbetween objects and classes. For example, statements such as "STUDENT IS-A PERSON" are of interesthere, while those such as "John IS-A STUDENT" are not. The latter deal with the possession of attributesby objects.144Figure 5-4: Extensional Meaning of IS-AB IS-A ANotatione(A) extension of class Ae(B) extension of class BBeyond this, the single term IS-A, as used in conceptual and semantic data modelling (e.g.,Mylopoulos et al., 1980; Hammer and McLeod, 1981) to indicate that the extension of one class is a strictsubset of the extension of another class, is semantically overloaded, since one symbol is used to describeseveral kinds of subclass linkages with important differences in meaning, as shown next.In MIMIC, classes are defined based on shared attributes. In addition, it is recognized that someproperties may be acquired and lost over the lifetime of an object. This fact is used to derive four refinedmeanings of IS-A based on the temporal or permanent nature of the additional attributes defining asubclass92 .Although the representation level (i.e., MIMIC model) is being discussed here, everything that is saidapplies also to the conceptual level due to the mapping between the levels discussed in Chapter 4.145The cognitive premise on which the proposed refinements to IS-A are based is that instances(representations of individual things in the world) may acquire and lose properties through domainexpansion and contraction (Definitions 14 and 15, Chapter 4). This is reflected directly in MIMIC in thatobjects may acquire and lose attributes, thereby moving between classes. However, not all attributes maybe acquired/lost. Four cases exhaust the possibilities in this regard.First, membership in a (sub)class may be always. This means that an object, when created, belongsto and remains in the class in question as long as it exists. An example is PERSON. No objects (e.g.,from a superclass ANIMAL) become persons subsequent to their creation, and a person is always a personwhile in existence. In this case, the added structural/relational attributes are permanent93. That is, anobject is assigned to (i.e., becomes a member of the domain of) these attributes at the time it is created,and continues to possess these attributes as long as it exists. Height, Weight, and Birthdate, are examplesof permanent attributes of class PERSON.Second, subclass membership may be becoming. This means that an object starts out in asuperclass only, but eventually becomes (or may become) a member of a subclass and remains in thatsubclass as long as it continues to exist. An example is PARENT, since a PERSON is not a parent atbirth, but if he/she becomes a parent, he/she remains so. Another example is ADULT 94. In this case, anobject in some class may acquire (i.e., enter the domain of) certain attributes at some point subsequentto its creation. However, once these attributes are possessed by the object, they are retained for theduration of its existence. For both PARENT and ADULT, an instance of PERSON becomes an instanceof the subclass (i.e., PARENT or ADULT) if or when it acquires the attributes distinguishing the subclass93This does not mean that these attributes are unchanging, since the values (active functions) maychange over time.94There is a slight difference between PARENT and ADULT, since all PERSONs become ADULTs,but not all PERSONs become PARENTs. In other words, all PERSONs must assume the added attributesof ADULT, but need not assume the added attributes (i.e., become) PARENTs.146(e.g., Has_children for PARENT). Once these attributes are acquired, however, they are retainedpermanently.Third, subclass membership may be ceasing. This means that an object starts its existencebelonging to a subclass, but at some point ceases to be a member of the subclass, and stays out (but insome superclass of that class) for the duration of its existence. An example is CHILD. Every PERSONis initially a CHILD. However, at some point the person ceases to be a child and never becomes a childagain. In this case, an object is created with certain attributes, but loses some of these attributes at somepoint during its existence. Once these attributes are lost, they are not re-acquired. For example, everyPERSON has the added structural/relational attributes of CHILD when born (e.g., Legal_guardian), butloses some of these (i.e., the attributes which distinguish CHILD from PERSON) at some point, therebylosing membership in the class CHILD.Fourth, objects may happen to be in a particular subclass. This means that an object is createdbelonging to some class, but may belong and then not belong to the subclass in question several timesduring its existence. Examples include CUSTOMER and EMPLOYEE. PERSONs may move in and outof these classes several times over the course of their lives. In this case, a member of a superclass mayacquire and lose the added attributes of the subclass (perhaps several times) during its existence. Forexample, CUSTOMER is based on a relational attribute Customer_of with COMPANY, andEMPLOYEE is based on a relational attribute Employed-by with COMPANY.This analysis reinforces the view that a single notion of IS-A is inadequate to capture the variouskinds of subclass derivations that are possible when the temporal nature of class membership is taken intoaccount. The definition of subclasses in the MIMIC model is based on added structural/relational attributesand the assumption that attributes can be acquired and lost by objects. This provides a framework forexplaining and understanding the semantics of four forms of subclasses, since the cases can bedistinguished by the permanence of the added attributes of a subclass. It additionally recognizes that an147object may move between classes over its lifetime, an issue not dealt with by many conceptual models 95 .However, the modelling mechanisms for structural and relational attributes do not inherently indicate towhich of the four kinds an attribute belongs. Consequently, the specification of whether an attribute ispermanent, becoming, and so on, must be captured externally.A modelling guideline emerging from this analysis is that, when attributes are specified by a user,these should be determined to be permanent, acquirable only, losable only, or both acquirable and losable.This captures important information about whether objects may move between classes in a lattice.5.5 ON ASSOCIATIONS - RELATIONAL ATTRIBUTE VERSUS COMPOSITE CLASSAn important element of knowledge about a thing involves the associations (relationships) thething has with other things. In some cases, an association of two or more things may have properties ofits own, in which case it may be more valuable to regard the association (or composition) as a separatething. The issue is whether relationships with properties should be modelled differently from relationshipswithout properties.In the entity-relationship model (Chen, 1976), the relationship construct is used to model bothassociations with attributes of interest and those without attributes of interest. However, these two kindsof associations are not formally distinguished. In some cases, it is difficult to decide whether somethingshould be modelled as an entity or as a relationship. Even if relationships with attributes are modelled asentities, information about the allowed changes in the values of attributes of these associations cannot berepresented since the E-R model does not capture behavioral knowledge,.95There are some additional considerations here, since the acquisition or loss of attributes is a kind ofchange. In particular, if these attributes are relational, acquisition of an attribute depends on the existence(or creation) of certain objects in other classes (e.g., acquiring Parentof accompanies the creation of anew object of class CHILD). This is effectively a constraint on change, although not at the level ofchanges to the active functions of attributes. Incorporating such information is left as a subject for furtherwork.148In most modelling approaches, no distinction is made between structural and relational attributes.All are modelled as binary associations between entities or objects (e.g., Mylopoulos et al., 1990;Verheijen and Van Bekkum, 1982; Abrial, 1974). Such models have no notion of composition in the senseof emergent attributes (Section 4.2.3.4). Instead, composition is often equated with Cartesian aggregation(Hull and King, 1987; Smith and Smith, 1977), in which an object is considered as composed of itsattributes (e.g., PERSON is composed of attributes such as Height and Weight). Composition isrecognized in some object-oriented programming languages such as Loops (e.g., Stefik and Bobrow, 1986),and in data models such as ORION (e.g., Banerjee et al., 1987). However, these do not provide clearguidelines as to whether or not certain knowledge should be modelled by composite objects, nor is it clearwhether they enforce that a composite object must possess emergent attributes.The cognitive assumption underlying MIMIC' s treatment of composition is that part of knowledgeincludes knowing how things are linked to other things (Smith, 1978; Miller and Johnson-Laird, 1976).Furthermore, components can be considered either as distinct things or as parts of more complex things.The basic mechanism for expressing associations among objects in MIMIC is the relationalattribute. A simple relational attribute R is a set of functions mapping from a set of objects T' to a subsetof the power set of the Cartesian product of several other sets of objects T 2,...,TN (N.?..2): that is,(R. ( )), where Qcp(T20...OTN)). Relational attributes link an object to one or more other objectswithout ascribing any added information to this association. However, the model also provides amechanism for representing associations which can be viewed as objects in their own right. Suchassociations possess emergent (or composite) attributes: that is, attributes associated with the collectionof objects in the association. Composite objects model these associations and composite object classesrepresent the kind of association.A composite object is a concatenation of other objects of other classes, denoted 4 1 42,...,6 (tie T i),which possesses emergent (or composite) structural/relational attributes. The emergent structural149attributes forming part of the definition of a composite class are of the form S:H--)V, where V denotes aset of values, H denotes a subset of T 10... TN and is a domain of composite objects, and T 1 ,...,TN are theextensions of the component classes of the composite. Similarly, the emergent relational attributes formingpart of the definition of a composite class are of the form R:H—>Q, where QcTN+ 10...Orl (i.e., M othersets of objects). The emergent behavioral attributes are of the form b:1310...0PK--)p (P 10...OPK), where Pkdenotes the leh composite structural or relational attribute. These attributes are needed when there is someinformation or property that can be ascribed only to the association of two or more objects. An exampleof an emergent attribute is Grade, which characterizes neither a STUDENT nor a COURSE individually,but a certain student-course pair.Although not dealt with in theories of concepts, it seems reasonable to assume that the componentsof a composite object are linked via a relational attribute. This is embodied in the following postulate.Postulate 7:In a composite class (object), n "complementary" n-ary relational attributes link the n componentclasses (objects).That is, a composite of instances of T 1 ,...,TN is based on relational attributes such asR:T 1-4 g (Po ...or) 96 . For example, an ENROLMENT composite is based on an Enrolled relationalattribute of class STUDENT with class SECTION, as well as a complementary Has_enrolled attributeof class SECTION with class STUDENT.The model adopts a further important assumption.96For each of the other components, there is a similar relational attribute.150Assumption:A given collection of objects may, at any time, form only one composite object of a particularcomposite class (i.e., the object is a surrogate or identifier of a composite thing) via a singlerelational attribute.This assumption limits what may be modelled as a composite object. For example, there cannotbe two composites with parts John and UBC in a composite based on the Student relational attribute ofSTUDENT'. Again, although this consequence is not explicit in the classification literature, it does haveintuitive validity, particularly when physical objects are considered. For example, a given collection ofparts may belong to only a single automobile (at any time). Interestingly, this assumption has also beenadopted by some object-oriented data models which support composition (e.g., Banerjee et al., 1987).The assumption is embodied in MIMIC through emergent structural and relational attributes. Forexample, if Amount is an emergent attribute of class DEPOSIT, it cannot be that Amount ={a:ACCOUNTOTELLER-4POSITIVE_NUMBER}, since several deposits made be made on the sameaccount by the same teller. In other words, the relationship is not functional if DEPOSIT has only thecomponents ACCOUNT and TELLER. That is, if c 1 and t2 are components of DEPOSIT which form,say, two deposit objects with amounts 25 and 50, it would be required that a(c 1 ,t2)=25 and a(c 1 ,t2)=50.Consequently, the formalism 98 enforces the assumption that a given collection of objects can form onlyone composite of a particular class (at any time). In order, then, to model deposits to a single accountusing the same teller, an additional component class is needed, the members of which vary for a singlecombination of account and teller. This recognizes that the deposits are, indeed, different objects: that is,97However, there may be another composite of John and UBC which is, for example, based on theEmployed_by relational attribute of EMPLOYEE."In particular, the way in which composite objects and attributes are defined.1 5 1they have a different existence.In contravention of this assumption, one might argue that a composite class such as DEPOSITmay have parts ACCOUNT and TELLER, and that several composite objects (orders) may contain thesame components (e.g., several deposits on the same account by the same teller). However, the positiontaken here is that this composition is incomplete. Each deposit has a distinct existence and occurs at adifferent time99 .This view of composition has an implication for conceptual modelling activities. Each relationalattribute identified in modelling a domain should be examined to determine whether there is anyinformation about the association which is relevant. In such cases, a composite class is needed, with theclasses involved in the relational attribute constituting its components. The additional information aboutthe association can then be formalized as emergent structural/relational attributes. Subsequently, constraintson behavior with respect to these attributes can be identified.To summarize, the MIMIC model supports a distinction between simple associations, modelledas relational attributes, and associations which can be viewed as objects with emergent attributes. Thisdistinction depends on whether the domain of structural and relational attributes is a set of objects or theCartesian product of several sets of objects. Associations with emergent attributes are modelled ascomposite objects. Thus, a semantic difference between the two kinds of associations - one involvingattributes of the association and the other not - is captured. It can be argued that (almost) any associationmay have attributes (e.g., time at which the association began) and, hence, may be modelled as acomposite object. However, for the purposes of many applications, such attributes may not be relevant.99Consequently, one view is that the components of DEPOSIT should actually be ACCOUNT,TELLER, and TIME, where TIME is a class of objects whose extension is a set of time points.Philosophically, there may be problems in viewing time points as objects. Since there is no fundamentalprinciple in theories of concepts to resolve this issue, the best that can be said here is that treating timepoints as objects may merely be a surrogate for the fact that the deposits have different existence.152Relational attributes allow simpler modelling of situations in which no relevant attributes are "attached"to an association.5.6 ON THE IMPLICATIONS OF A UNIFORM FORMALISMIt is widely recognized that both structure and behavior are important for the complete modellingof knowledge about entities (e.g., Borgida, 1984; Brodie, 1984). Behavioral knowledge indicates how thestates of things may change over time. This must, in one form or another, be incorporated along with stateknowledge in information systems if they are to accurately track knowledge of the state of the things theyrepresent (Wand and Weber, 1988).In many conceptual modelling methods, behavior is modelled in a process-oriented way (and, insome cases, is not dealt with at all). For example, NIAM (Verheijen and Van Bekkum, 1982) capturesbehavior through information flows and processing. Object-oriented systems (languages and data models)encapsulate behavior with structure through methods. Methods implement mechanisms which describe howchanges to instance variables occur and, implicitly, determine which changes may (not) occur. By contrast,neither the E-R model (Chen, 1976; Teorey et al., 1985) nor most semantic data models (see King, 1989)deal with behavior. An exception to the procedural treatment of behavior is found in Telos (Mylopoulos,1991; Mylopoulos et al., 1990), which models behavior in terms of activities belonging to activity classes.Activities describe the "what" of change, specifying pre- and post-conditions which must be satisfiedbefore and after a change. However, activities also contains parts which come closer to describing the"how" of change.The issue which emerges here is that structure and behavior are usually modelled in quite differentways, increasing the complexity of models such as those mentioned. Since structure and behavior are bothimportant elements of knowledge about things, it would be simpler to have a uniform approach forrepresenting both. The notion of uniformity was first recognized in the Taxis model (Mylopoulos et al.,1531980) and plays a large part in Telos. However, the notion of uniformity discussed here is at a moreabstract level, since MIMIC is completely non-procedural.In the MIMIC model, both structural and relational attributes are defined as sets of functions (fromobjects to values or sets of things, respectively). This function-based approach to modelling knowledgeis very simple. It allows the description of state by applying active functions to objects. Furthermore,behavioral attributes are also modelled as functions. The domain of a behavioral attribute is the Cartesianproduct of a number of structural and/or relational attributes, and the codomain is the power set of thedomain. A behavioral attribute thereby specifies, for any given combination of the active functions of oneor more structural/relational attributes, which events or changes can occur. Intuitively, this approach makessense since structure, relationships, and behavior are all elements of knowledge about things. Furthermore,it is a parsimonious and implementation-independent approach to integrating static and behavioralknowledge. However, it is also restricted to describing the "what" of change and not the procedural detailsof "how" change is performed. In this regard, it is worth mentioning that this approach is somewhat relatedto the A.-calculus and functional programming (see Backus, 1978) in hiding the procedural details ofchange. According to Backus, a functional programming system "has a loosely-coupled state-transitionsemantics in which a state transition occurs only once in a major computation" (p. 619). These "majorcomputations" appear analogous to the MIMIC notion of an event conforming to a behavioral attribute,since the model does not contain mechanisms for describing procedurally how the change is brought about.The primary consequence of this view is that only knowledge about allowed behavior isrepresented. That is, behavioral attributes may be viewed as restrictions or laws which describe thechanges an object may or may not undergo (by virtue of belonging to a class and, therefore, possessingthe attributes defining that class) by restricting changes to the active functions of attributes of that class.Models specifying how changes occur (e.g., through control statements) commit to a particular view ofthe implementation of change (e.g., transactions in ACM/PCM and Taxis). MIMIC is more abstract than154these models in that behavioral attributes can accommodate many concrete descriptions of how changeoccurs. The model thus allows for a greater degree of freedom in later stages of system design andimplementation, as it does not impose a particular description of change mechanisms. That is, itsconstructs are completely free of implementation primitives.It may be argued that this begs the question of representing the "how" (procedures) of change.Since, in an implemented system, programs execute the changes which can occur (i.e., implementbehavioral attributes), a detailed description of how changes are to be performed is a prelude toimplementation. However, the intent of MIMIC is to focus purely on the problem domain, rather than theimplementation domain (cf. Mylopoulos, 1990). Consequently, the model does not specify how behavioris to be implemented. However, the functional approach to behavior does specify constraints which anyimplementation (of transaction mechanisms) must adhere to, without committing the analyst to a specificapproach to the implementation. It is thus valuable as a preliminary modelling step.In addition, it is worth noting that in discussions of methods, messages, and encapsulation inobject-oriented programming languages, there is an emphasis on hiding the "how" of behavior and creatinga protocol for communication between objects (e.g., message passing) that hides the implementation detailsof methods (e.g., Goldberg and Robson, 1989). MIMIC extends this idea uniformly (back) to theconceptual modelling phase of development by considering behavior only in terms of states before eventsand potential states after events (cf. Wand and Weber, 1988), without consideration of interveningprocesses.In summary, several existing modelling methodologies recognize that both structure and behaviorare important elements of knowledge to be captured during the conceptual modelling phase of systemsdevelopment. However, these approaches often introduce different mechanisms for modelling behaviorversus structure. Such mechanisms may, for example, use standard program control structures (sequence,iteration, and choice) that are closely linked to software (e.g., Brodie and Ridjanovic, 1984; Jackson,1551983). The MIMIC model, on the other hand, captures behavior through functions restricting changes instate. The uniform approach to modelling structure, relationships, and behavior is both intuitivelyappealing and simple: the former because a common approach is applied to static and dynamic knowledge,and the latter because it uses fewer modelling constructs. In practical terms, the model should be usefulas it completely removes implementation or software considerations from conceptual modelling, therebyallowing flexibility in the later stages of designing transactions and programs to enforce behavioralconstraints.5.7 ON THE MEANING OF TIMETime is important in conceptual modelling because knowledge about when certain changes occurrelative to others is important to users. Specifically, there are at least two critical uses of temporalinformation. First, in representing knowledge about an application, it is often necessary to capture the timeat which an event occurs (i.e., when a certain state is realized). For example, banks maintain records ofwhen account transactions occur, when loan payments are made, and so on. Second, temporal knowledgeis used to answer questions about intervals over which states or conditions are true. For example, theduration of account balances is essential knowledge in determining interest earned.Accounting for time in conceptual models is an issue which has received some attention and whichhas been criticized for inadequacies (e.g., Richter, 1985; Schiel, 1985; Kung, 1983; Bubenko, 1980). Theissues appear to be closely related to general questions about modelling temporal information inknowledge representation (e.g., Shoham, 1988; Allen, 1984; McDermott, 1982). However, this AI workfocuses on reasoning about temporal matters and, consequently, tends to develop detailed temporal logicsbased on either time points or time intervals as primitives. Hence, it is not examined in detail here.Problems in modelling time have been recognized. For example, McDermott (1982, p.101) statesthat "no one has ever dealt with time correctly in an AI program, and there is reason to believe that doing156it would change everything." In the conceptual modelling context, Kung (1983, p.141) states that"[a]lthough there are a large number of conceptual models, most of them fall into what is called snapshotapproaches", which do not adequately deal with time.It is not the intent of this research to propose a complete model of time. However, since the abilityto deal with temporal information is important to many IS applications and since knowledge of temporalrelations is part of our knowledge of the world, some treatment of time in conceptual models is crucial.This section shows that MIMIC's treatment of behavior through events implicitly incorporates a simpletreatment of time 100, and then discusses some consequences and contributions of that treatment and anextension of it.According to Schiel (1985), there are two views of time: absolute and relative. The absolute viewtreats time as an infinite sequence of points m independent of things. The relative view claims that timehas no meaning independent of things and events, as expressed succinctly by Shoham (1988, p.1):Of course, the passage of time is important only because changes are possible. In a world whereno changes were possible - no viruses infecting blood systems, no electrical charges changing, nochanges in program counters, not even changes in the position of the sun in the sky or the positionof the hands on our wrist-watches ... the very concept of time would become meaningless.This "time as change" perspective is implicitly adopted in the MIMIC model, but it is also argued that the formerand latter views can be closely linked.The basic view of time in MIMIC is derived from the primitive attribute constructs. A structural(respectively, relational) attribute is formalized as a set of functions from a domain of objects to acodomain containing values (respectively, sets of objects). A single active function from the set describesthe state of the domain with respect to that attribute. The state of a set of objects possessing m structuralmAny conceptual model which deals with behavior necessarily includes a rudimentary notion of time,according to a view which sees time as change. Examples of conceptual models which explicitly deal withtime include activity and behavior modelling (Kung and Solvberg, 1986), Telos (Mylopoulos, 1991;Mylopoulos et al., 1990), and the Set-function model (Bertziss, 1986).ioiTime may also be construed in terms of intervals as primitives (Shoham, 1988; Allen, 1983).157and n relational attributes is an (m+n)-tuple containing m+n active functions. The notion of change isincorporated in the model through the replacement of active functions (of one or more attributes) withother functions from the same attribute set. Such a replacement is termed an event. An event changes thestate of at least one object in the domain of each of the attributes affected. The model does not, at thislevel, deal with the spacing of events on some interval scale. Consequently, the only notion of timedirectly supported is that the passage of time is recognized by events, so that time intervals are notrecognized.This is consistent with the previously described view of the world (or knowledge of it) in which"time" has meaning only in that change occurs. MIMIC provides a natural mechanism for capturing thisby modelling attributes as sets of functions, whereby an active function describes the state of a set ofobjects with respect to the attribute in question and may be replaced by another active function to reflecta change in knowledge of the state of the world. If an attribute has a single function, no change mayoccur. Naturally, time has no meaning with respect to such an attribute.The model equates change in time with events. However, in general, events (in an informationsystem or in the real world) are not equally spaced on any interval. For example, a bank may have xdeposits to savings accounts in one day of operation and y in another day, where x*y. Furthermore, suchevents may be unequally spaced through the day. Since the spacing or intervals between events is oftencritical knowledge for planning or decision making 102, a mechanism to capture "distances" betweenevents is important in a conceptual model. Consequently, a refinement to MIMIC is needed in order torecognize time intervals.The notion of "unequally spaced" has meaning only in the sense that there is some standard or102Consider a situation where customers perform deposits and withdrawals on bank accounts. Thespacing between these events helps determine factors such as teller utilization and queue lengths.Consequently, this knowledge is critical in simulating different service options in order to decide on anappropriate level of customer service.158scale against which other events can be measured. Such a scale will hereafter be referred to as a clock.In the banking example above, deposits may be made at 9:14, 9:23, 10:01, and so on. For most people,time is measured by one or more physical (mechanical or electronic) clocks. Of course, such clocksgenerally provide a discrete (or continuous) approximation of continuous change based on the rotation ofthe earth. This approximation is adequate for day to day life, and certainly for business informationsystems needs. It is manifested in physical events such as the movement of hands on a clock face orchanges to values on a digital display. In addition, people appear to have a notion of absolute time sincewe often question whether a specific physical clock is telling us the "correct" time.Unfortunately, the theories of concepts discussed in Chapter 3 do not offer much insight into theconcept of time and the nature of temporal knowledge. Furthermore, while the formalization of classicalconcept theory in Chapter 4 does offer the simple relative view of time based on events discussed above,this alone is inadequate to model the spacing of events. Consequently, a simple extension of the modelis considered here which, while not directly based on cognitive research, illustrates one possible way ofintroducing an "absolute" notion of time which is uniform with respect to the constructs of the modelalready introduced and which allows the spacing of events on an interval scale to be measured.Two assumptions underlie what follows. The first and most important is that there is a conceptof CLOCK: that is, a standard by which other events can be measured. This assumption seems to beessential in models of time (Richter, 1985; Bunge, 1977). The second assumption is that the clock is insome sense "universal". This means that a given community of individuals can agree on a single commonclock, against which other (individual) clocks can be calibrated. This assumption should not cause toomuch trouble given the frequency with which individuals compare "personal" time (as measured by, say,a watch) with "actual" time (as decreed by some authority).159These assumptions give rise to the definition of a class which will be called CLOCK'', whoseextension is a set of clocks. For simplicity, this class may be assumed to contain only a single object (i.e.,the universal clock). CLOCK is defined in terms of a single structural attribute, along with a singleassociated behavioral attribute.The structural attribute is Time_value = ftv iltv i :CLOCK--)NUMBER}, where NUMBER is afinite"' set of values (e.g., integers). That is, each function in Time_value is a single pair (if the classis assumed to contain a single object) whose first element is the clock object and second element is avalue from the domain NUMBER. The behavioral attribute, Change_time, enforces the constraint:<tv 1 ,tv2> := tv2(c) = tv 1 (c) + 1 1°5,where c denotes the clock object. In other words, Changetime:Time_value—aime_value l°6 such thatfor any i, Change_time(tv,)=tv i+1 , where tv i+1 (c)=tv i(c)+1. This class and the events on it are intended tomodel our knowledge of time as represented by an ordinary clock. An event might be the discretemovement of a second hand, or a change of numbers on a digital display. This kind of event provides abase to which more interesting events can be associated when the relative spacing between pairs of events(such as changes to account balances) is important. In these cases, the number of "clock tick" events, eachdesignating an elapsed unit of time, between a pair of other events (e.g., two deposits on an account)provides a scale for measuring the distance between these events. Furthermore, the time at which aninstance of a class (e.g., person, deposit) is created may be an attribute of the class, the value of which103This class makes use of the constructs of the model (i.e., objects and attributes) and, therefore, isembedded in the model (actually, in any instance of the model) and not really an "extension" of it.'For the purposes of this exposition, finiteness is assumed in order to impose a restricted timehorizon and preclude a continuous notion of time. Given the domain of interest (i.e., businessapplications), this appears to be a reasonable restriction.105See Appendix 1 for an explanation of this notation for behavioral attributes.106The codomain of this attribute is a single element of the power set of Time_value: namely, the setTime_value itself.160is the state of the clock when the object is created.The usefulness of this approach is that it defines a CLOCK as a mechanism for recognizingintervals between events. When the spacing between events is important, there is information about anevent that is relevant knowledge. Consequently, records of events may be viewed as objects. This mayappear at first to be strictly an information systems issue, since records of transactions are extremelyimportant in IS applications for accounting and auditing purposes. However, there is a cognitive basis formodelling records of events as objects. Specifically, people abstract information about events whichenables them to answer questions later. For example, a person making a deposit to a bank account mhas a mental record of the event, and can later provide information such as the time and amount of thedeposit. This record is thus an instance of a concept, DEPOSIT, which is an abstraction of the commonattributes of cognitive records of deposit events.In this case, the time of an event may be a structural attribute of its record, which is assigned thevalue of the state of the clock when the event object is created. Of course, the creation of an object as aninstance of DEPOSIT accompanies an event (change in the active function) affecting the Balance attributeof class ACCOUNT, such that a particular instance of ACCOUNT has its value increased by the valueof Amount of the newly created instance of DEPOSIT.The constraints among these actions can be specified in more detail, although this will not be donehere since it is more important at the implementation level. At the conceptual level, it is enough to knowwhat the connection is. This involves enforcing a requirement that a given event (e.g., a change in theactive function of Balance of class ACCOUNT) be accompanied by the creation of at least one instanceof a specific event-record class (e.g., DEPOSIT, WITHDRAWAL, TRANSFER). Consequently, the factthat, for example, three DEPOSIT transactions (d 1 , d2 , d3) may not be equally spaced, can be capturedby comparing the "differences" in the times of occurrence (e.g., value of Time of occurrence attribute)1°7The deposit is simply an event, or change of state, of the balance of the account.161of consecutive deposit pairs. The term "difference" has meaning here since the value of theTime of occurrence is a number on an interval scale._ _In order to better understand the limited treatment of time which MIMIC offers, it is useful torecognize that there are two possible focuses when representing temporal knowledge. The first deals withwhat is presently true (representing knowledge about the state of a real or potential world). As aconceptual model, MIMIC handles this representation through its mechanisms for describing object states,and constraints on changes of state. In fact, the central purpose of the model is to provide thesemechanisms.The second focus in modelling temporal knowledge deals with representing past truths. Asdiscussed at the beginning of this section, there are two important uses of past truths. One is to provideanswers to questions about when events occur. In the MIMIC framework, this can be captured bymaintaining a record of the event as an object, one of the attributes of which takes on the value of theclock at the creation of the event record. The object continues to exist without changing state, and canalways be referenced to answer questions about when the corresponding event occurred. The second useof past truths is to answer questions about intervals over which assertions or states are true. This useillustrates an important limitation of MIMIC's treatment of time. Since MIMIC's framework for dealingwith time is not interval-based, it does not directly permit questions about time intervals (e.g., how longdid an account balance remain within a certain range?) to be answered. However, records of eventsprovide the basic information necessary to answer such questions, since intervals can be determined bycomparing the times at which the relevant events occurred. Nevertheless, this requires an extension of theMIMIC model to include a reasoning mechanism, and is beyond the scope of this thesis.To summarize, the intent of the preceding presentation is not to develop a comprehensive modelof time, as would be necessary to perform detailed temporal reasoning (e.g., Shoham, 1988), since theoriesof concepts generally do not deal with how knowledge of things changes (is updated) over time. The more162limited goal is to show that the fundamental constructs of MIMIC have a very basic model of time aschange, captured by the notion of an event. This, in turn, can be enhanced by introducing a clock torecognize that events are not necessarily equally spaced (and also to answer questions related to theordering of and distance between events). Thus, for this research, time is still viewed as change, but atthe finer level of clock change and relative time becomes, with the clock as a standard, absolute.5.8 ON THE OBJECT PARADIGM AND CONCEPTUAL MODELLING'As Chapter 2 indicated, much attention has recently been focused on object-oriented approachesto systems analysis and design (e.g., Booch, 1991; Coad and Yourdon, 1991; Bailin, 1990; Henderson-Sellers and Edwards, 1990; Wirfs-Brock and Johnson, 1990). Of particular interest here is that the objectparadigm has been applied to conceptual modelling and advocated as a natural approach for representingknowledge about a domain (Coad and Yourdon, 1991).Notwithstanding the interest in object-based approaches, there has been widespread disagreementabout the meaning of terms such as 'object' and 'object-oriented' (e.g., Nierstrasz, 1987; Stroustrup, 1987;Wegner, 1987; Stefik and Bobrow, 1986; Nygaard, 1986; Pascoe, 1986; Stoyan, 1984), particularly asapplied to programming. Only the concept of encapsulation seems to be universally accepted.Classification and inheritance have also been generally embraced, but with notable exceptions (e.g.,Lieberman, 1986). Other concepts, such as independence, homogeneity, message passing, composition andconcurrency, have varying degrees of support.The justifications offered for these characteristics tend to center around supporting softwarereusability, improving software reliability, and supporting incremental development (Meyer, 1989;Nierstrasz, 1987). At the same time, however, arguments have been made that many of the features of the108This section is based on joint research with Yair Wand, as described in more detail in the paper"The Object Paradigm - Two for the Price of One?", Proceedings of the First Workshop on InformationTechnologies and Systems (WITS' 91), Cambridge, MA, December 1991, 308-319.163object paradigm support world modelling in a natural manner (e.g., Mylopoulos, 1990; Goldberg andRobson, 1989; Stefik and Bobrow, 1986; Birtwistle et al., 1973). Hence, there is an apparent confusionof what we (see Footnote 108) call implementation and representation advantages'. The position takenin this thesis is that, since conceptual modelling is strictly concerned with capturing knowledge about adomain of interest (on which an IS is based), only the elements which support the development of goodrepresentations of a domain should be included in object-oriented conceptual models. In the context ofthis research, this means that only the object constructs which support the direct representation of cognitiveconstructs should be included in a conceptual model. Consequently, the remainder of this section examinesthe degree to which a number of object characteristics are supported by MIMIC.Classification/InstantiationIn most object-oriented systems, there is a clear distinction between instance objects and classobjects (e.g., Goldberg and Robson, 1989; Banerjee et al., 1987; Stefik and Bobrow, 1986). Class objectsare abstractions which describe a set of instances in terms of common characteristics (instance variablesand methods). Classes are useful for creating instances and contain the code (methods) for manipulatingthe state (instance variables) of instances. The instances are have individual identity (Khoshafian andCopeland, 1986) and are intended to be in one-to-one correspondence with entities from some domain.The MIMIC model clearly distinguishes objects from classes. Objects are in one-to-onecorrespondence with instances of concepts from some domain and possess attributes which representknowledge about these instances. Classes, which are in one-to-one correspondence with concepts from thatdomain, are defined in terms of a collection of attributes, including a characterization of allowed behavior.1°9In a similar vein, Mylopoulos (1990) states that "research on object-oriented databases shouldaddress world modelling or programming, but not both" (p.13).164EncapsulationIn most discussions of objects, class definitions encapsulate statics (e.g., instance variables) anddynamics (e.g., methods) (e.g., Nierstrasz, 1987). That is, a complete specification of a class includesdefinitions of its structure (hence, the structure of its instances), along with a description of how the statesof instances may change. Encapsulation provides a well-defined, implementation-independent interface foraccessing and manipulating object states.In MIMIC, a class encapsulates structural and relational attributes which, in turn, imply a set ofbehavioral attributes. These jointly represent the three kinds of knowledge defining concepts. Thebehavioral attributes specify how the values of the structural and relational attributes may change over timefor the objects which make up the extension of the class.Class Specialization and InheritanceIn most object-oriented systems, there is support for defining some classes to be subclasses orspecializations of others. The subclasses may possess added instance variables and methods, and often themethods of a subclass may override those of its superclass(es). There is no general agreement as towhether object-oriented systems should support multiple inheritance, in which a subclass has more thanone superclass and, therefore, inherits instance variables and methods from each. In any event,specialization and inheritance support code reusability and reduced redundancy.In MIMIC, a subclass must possess structural and/or relational attributes in addition to those of(each of) its superclass(es). Such added properties form the basis for defining new classes. In addition,the subclass may possess additional behavioral attributes. In the model, there is no notion of overridingthe attributes of a superclass. Furthermore, the notion of multiple inheritance follows naturally from theway in which subclasses are defined, since a new class may possess the properties which define two ormore existing classes.165CompositionThe idea of composite objects and classes has been recognized in some object-orientedapplications, particularly in the database area (e.g., Banerjee et al., 1987). Composite objects belong tocomposite classes. The latter are comprised of a number of component classes, and in addition, maypossess certain emergent instance variables and methods. Composite objects may be stored and retrievedas a unit, thereby reducing access time.In MIMIC, a composite class is defined in terms of (i.e., must possess) a number of emergentattributes. The domain of these attributes consists of composite objects, which are uniquely identified asa collection of component objects. Composite classes represent composite concepts, thereby reflecting theknowledge that some things are composed of simpler things.IndependenceIn many object-based environments, methods are the only mechanisms by which changes to thestate of objects can occur. That is, if there is no method to execute a particular change, such a changecannot be imposed, for example, by directly manipulating instance variables. Independence is supportedby encapsulation and enhances software reliability.In the MIMIC model, events are constrained by behavioral attributes. These attributes implicitlydetermine which changes can and cannot occur. Thus, representations are independent in the sense thatallowed changes to state are embedded completely in behavioral attributes, although these attributes mayspan several classes.CommunicationAt least two metaphors have been used in the object literature to describe communication. Messagepassing (Stefik and Bobrow, 1986; Robson and Goldberg, 1981) implies a direct request by one object166to another. This is the most widely used approach described in object-oriented programming and databases.A second approach involves communication through a public blackboard, or workspace, which is checkedby other objects in search of communications intended for (or applicable to) them (Tsichritzis et al., 1987).Much of the discussion of communication in the object-oriented programming literatureunderstandably focuses on implementation. However, communication can be viewed conceptually as avehicle for supporting object independence. A communication mechanism provides an orderly protocolwhich prevents objects from changing state arbitrarily and, thereby, supports independence.MIMIC includes only a very abstract notion of communication. Behavioral attributes constrain theallowed changes of state of objects. Any event (change in active function of one or morestructural/relational attributes) must conform to all behavioral constraints which affect these attributes. Themodel distinguishes constraints on changes to (1) several attributes within a (non-composite) class, (2)attributes across several classes, and (3) composite attributes. This may be viewed as a communicationmechanism in the abstract sense above: namely, in providing an orderly protocol which prevents objectstates from changing arbitrarily. There are no implications for a particular mechanism for communication,such as message passing.Uniformity (Homogeneity)Many applications of the object-oriented approach view every component of the system as anobject. For example, the syntax of Smalltalk recognizes only the sending of messages to objects. Thismeans that every possible value (e.g., a number) is an object and so are classes. However, the relentlesspursuit of homogeneity leads to an obvious problem of infinite regress (Nierstrasz, 1987). Hence, thenotion of an object's properties, in turn, being objects, must terminate at some level with primitive objectsthat do not have properties. Nevertheless, there is obvious value in thinking about the domain in termsof a single construct. When "everything is an object" and objects are independent, an application is167expected to be well-behaved. If object behavior is completely determined by its own definition and state,and the behavior of the system is determined by communication among objects, it should be possible topredict the state of a system at any time, given a starting state (for all objects in the system) and asequence of all subsequent communications. Hence, homogeneity is justified as a means of supportingobject system reliability.From a conceptual point of view, objects are viewed as representations of entities in the world(Coad and Yourdon, 1991, p.1; Digitalk, 1989 p.3). However, there is no compelling reason why objectstate variables and behavior, along with classes, should also be objects. MIMIC does not view classes orproperties as objects, since they do not represent identifiable, independent things in the domain of interest.It seems that the disparity between the implementation and representation views regarding homogeneitystems from fundamentally different assumptions made by each. A system, once implemented, exists as acomposite thing in the world, and further, as a composite thing. If knowledge about this thing and itscomponents are modelled, they can be viewed as objects. It is important that these objects are notnecessarily representations of any real thing in the application domain (unlike customers, students,accounts, and so on). Rather, they are implementation artifacts. In other words, from a representation pointof view, an object represents a thing or an instance in reality, while from an implementation perspective,an object is a component of the implemented system il° .To summarize, this section has compared the features of MIMIC with a variety of characteristicsadvocated by proponents of the object paradigm. There are many similarities, suggesting that object-basedconceptual models can serve as "natural" vehicles for representing knowledge. However, there are alsosome important differences, indicating that the roots of object-orientation in programming languages may11° Of course, one implemented, the information system and its components become also part ofreality. This issue is not pursued here.168hinder the development of object-based conceptual models if characteristics are adopted from programmingand applied to modelling the subject matter of an IS without explicitly considering their value inrepresenting knowledge about that subject matter.5.9 SUMMARYThis chapter uses the constructs of the MIMIC model developed in Chapter 4 to examine severalpoorly understood issues in conceptual modelling, including criteria for defining a class structure, thenaturalness of lattice class structures, the meaning of ISA, composition, the meaning of time, and therepresentation value of object-oriented models. In each of these areas, MIMIC's formalism and foundationin concept theory are used to examine the meaning of conceptual modelling constructs. In addition, anumber of specific guidelines for modelling are suggested. The analysis indicates that MIMIC's groundingin a theory of categorization, along with its formalization, provides insights into several issues which arenot well understood in conceptual models with a less clear theoretical and formal basis.CHAPTER 6A COMPARISON OF CONCEPTUAL MODELS6.1 INTRODUCTIONIn Chapter 5, the contributions of MIMIC to understanding and addressing several problems inthe conceptual modelling area were examined. In this chapter, the MIMIC model is used as a foundationto evaluate the "cognitive content" of four quite different approaches to conceptual modelling: theExtended Entity-Relationship (EER) model (Teorey et al., 1986; Chen, 1976), Telos (Mylopoulos, 1991;Mylopoulos et al., 1990), NIAM (Verheijen and Van Bekkum, 1982), and Object-oriented Analysis (OOA)(Coad and Yourdon, 1991). The motivation for this evaluation is MIMIC's grounding in the classicaltheory of concepts. Since MIMIC is a conceptual model for directly representing knowledge about things,it can be used to determine the degree to which other conceptual models support the representation ofcognitive constructs, according to the classical view of concepts. The specific objectives of this chapterare, first, to determine which constructs of the MIMIC model are supported in several conceptualmodelling methods, and, second, to examine the significance of constructs found in other models, but notsupported by MIMIC.There is a wide range of systems development methodologies which address, to a greater or lesserdegree, the conceptual modelling stage of IS development (e.g., see Bubenko, 1986; Brandt, 1983; Floyd,1986; Olive, 1983 for comparisons of several). Performing a useful comparison with a large number ofthese would be impractical. Instead, a detailed evaluation of four models with quite different origins isperformed here in an attempt to assess the degree to which each supports the representation of knowledgeabout a subject domain.The four methods were chosen for different reasons. First, the EER model is a well-known andwidely-used tool for conceptual database design. Although it has recognized problems (e.g., its inability169170to capture behavioral information), the EER model does serve as a well-understood starting point for acomparison of models. Second, Telos is explicitly intended for conceptual modelling (among other things),and is said to be based on knowledge representation principles (Mylopoulos et al., 1990). Since MIMICexplicitly adopts a knowledge representation approach based on concept theory, a comparison with Telosmay provide insight on the consequences of adopting different foundations for representing knowledgeabout things. Third, NIAM is a well-known example of European research in the conceptual modellingarea, addressing directly the notion of modelling an enterprise or slice of reality 111 . Since much of theimpetus for conceptual modelling has come from the European research community (e.g. Nijssen, 1976;Schmid, 1977; Bubenko, 1980) 112, consideration of some of the results of these efforts is necessary forany evaluation of models to be representative of work that has been done. Finally, the object paradigmand object-oriented analysis have attracted tremendous attention in recent years, in part because of claimsthat such approaches allow "natural" representations of a problem domain to be constructed. A comparisonof OOA with MIMIC may provide insight into the degree to which OOA may be called natural, accordingto the classical theory of concepts.6.2 CRITERIA FOR COMPARISONThe comparison and evaluation of conceptual models and systems development methods is anextremely difficult task (Sol, 1983). Evidence of this is found in a series of IFIP conferences on thecomparative review of information systems design methodologies (011e et al., 1982; 1983; 1986), whichtogether demonstrate a variety of approaches to comparing models. Among the impediments to performinga comparison are the variety of constructs and inconsistency of terminology among methods, the lack of111NIAM also covers other aspects of the development process which are not considered here.112These references capture but a small sample of conceptual modelling methods. Further reviews andcomparisons are found in (011e et al., 1982; 1983; 1986).171formalism in some models (which hinders reconciliation of constructs and terminology), and the diversityof scope of different approaches with respect to the phases of IS development addressed (e.g., analysisonly, analysis and design, analysis through to implementation). Illustrating the first two difficulties, it isunclear whether terminology such as entities (Chen, 1976; Jackson, 1983) and objects (Verheijen and VanBekkum, 1982; Mylopoulos et al., 1990) mean the same thing across models, particularly if these termsare not formally defined. Likewise, the similarity between entity sets in the EER model (Teorey et al.,1986) and classes in Telos (Mylopoulos et al., 1990) is difficult to assess. These difficulties are consideredexplicitly in the comparisons which follow.Sol (1983, p. 4) suggests a number of approaches to evaluating methods, including:1. Comparison to an idealized methodologyThis approach begs the questions of where the "ideal" is to be obtained and how such a judgmentis to be made. If such an ideal existed, it seems that other methods, and hence a comparison,would not be needed.2. Accumulation of important features from several existing approaches to use for comparisonThis presumes the "goodness" of existing methodologies and their features and relies on asubjective evaluation of the importance of the features selected.3. Definition of a meta-model or framework within which methods can be comparedSuch a model may be useful in reconciling terminology and construct differences among methodsbeing compared. However, the success of an evaluation will depend heavily on the quality andexpressiveness of the meta-model. In addition, since "meta-model" may be closely related to"idealized method", this approach may encounter the same problem stated in point (1).With respect to the second point, a number of attempts have been made to enumerate a set offeatures for comparing and evaluating modelling approaches. In general, the criteria tend to focus on the172capability of models to capture static knowledge, behavioral knowledge, and constraints on states andbehavior (Wand and Weber, 1989; Borgida, 1984)113. An example of such a checklist in the context ofdata modelling is given by Brodie (1984). However, his set of criteria includes a number of issues, suchas exception handling and query facilities, which are related, not to modelling the domain, but tomodelling a database. Since these are essentially implementation-oriented, they are not discussed here.Nevertheless, the emphasis on capturing structure, behavior, and the constraints on both, is appealing andinfluences the present evaluation.This comparison draws from the first and third approaches above. The primary interest is inevaluating the mechanisms or constructs a model provides for representing knowledge about domainentities (i.e., things which constitute the subject matter of a proposed information system) 114. SinceMIMIC is explicitly derived from a theory of the structure and organization of knowledge about domainentities, it will be treated as a "benchmark" for comparing and evaluating the other models in terms oftheir support for cognitive constructs. Each model is assessed in terms of mechanisms provided forrepresenting existence, attributes (structural, relational, and behavioral), classes, class organization(specialization), and composition. In addition, constructs of any model which are not supported by MIMICare described and the significance of these differences analyzed.Two caveats are mentioned before proceeding. First, most conceptual models do not preciselydefine their constructs and, furthermore, use widely varying terminology. As a result, it is often necessaryto provide an interpretation of the meaning of some characteristic of a model in comparison to one ofMIMIC. Second, the value of the comparison is bounded by the utility of classical concept theory. The'This may constitute a meta-model in the sense described in point (3)."'Consequently, the analysis is restricted in two important senses. Since two of the models considered(Telos and NIAM) address other aspects of systems development, only the parts dealing with conceptualmodelling are considered. In addition, no attention is given to guidelines for using a model, although suchprescriptions are a crucial part of the success of any model.173limitations of the classical view as a theory of the structure and organization of knowledge (see Chapter3) result in limitations for MIMIC. However, since all conceptual models examined here are concernedwith representing knowledge about well-defined organizational domains (for which the classical theoryof concepts provides suitable representation primitives), comparison to the MIMIC model is justified.6.3 EXTENDED ENTITY-RELATIONSHIP MODEL (Teorey et al., 1986; Chen, 1976)The entity-relationship (E-R) model was developed as a tool for logical data design which "adoptsthe more natural view that the world consists of entities and relationships" (Chen, 1976, p. 6). The mainconstructs of the model are entities (and entity sets) 115, relationships (and relationship sets), andattributes. The model has been extended (EER) to include hierarchical links between entity sets(generalization/specialization) and to better represent n-ary relationships (e.g., Teorey et al., 1986). Thiscollection of constructs is used to capture structural knowledge about things in a domain of interest,primarily through a graphical technique which produces entity-relationship diagrams. In this section, theuse of these constructs is discussed, illustrated through examples, and compared to constructs of MIMIC.In the EER model, entity sets denote collections of entities, where an entity "exists in our minds"(Chen, 1976, p.11). The entity construct resembles 116 the object construct in MIMIC. Both entities andobjects represent knowledge of the existence of things in some domain117. An example of an entitywould be a symbol such as John, designating a particular human.115This reflects Chen's original terminology. Most later discussions (e.g., Teorey et al., 1986) drop theterm set, and use the term entity to describe either an individual or set of individuals, depending oncontext. However, it should be made clear that the model does distinguish instances from sets of instances.116Throughout this discussion, terms such as "resembles" and "is similar to" are used (rather than, say,"corresponds to"), since it is generally not possible to determine a direct correspondence betweenconstructs of different models.117To be more precise, according to the original E-R model, an entity is a mental construct. However,any description of or information about an entity is a representation and, hence, the ER model practicallydeals with representations of mental constructs.174Attributes in EER are used to characterize or capture information about entities 118 by associatingentities with values from some domain. An attribute is defined as a function from a set of entities to eithera set of values or the Cartesian product of several such sets (Chen, 1976, p.12). Hence, attributes may besingle- or multi-valued. Examples include Weight and Birthdate, which apply to entities in the setPERSON. Each entity in an entity set possesses a value for each attribute of the entity set at any time(e.g., Weight(John)=70). However, the notion of time and mechanisms for changes to values are notincorporated in EER 119  An EER attribute is analogous to a structural attribute in MIMIC, with twoimportant differences. First, a structural attribute is a set of functions (not a single function) from a domainof objects to a codomain of values (e.g., Weight = [w i lwi :PERSON-->POSITIVE_NUMBER)). At anytime, a single function from this set describes the actual state of knowledge. As shown in Chapter 5, timeis understood completely with respect to such changes in the active functions of attributes. Consequently,MIMIC inherently captures the permanence of values for objects (e.g., Birthdate) with attributes thatcontain a single function, and for which time has no meaning. This distinction cannot be captured in EER.The second difference is that MIMIC requires that structural attributes be single-valued, whereas in EER,attributes may be multi-valued. The MIMIC treatment reflects a position that there is a fundamentaldifference between structure and relationships to other objects. While relationships may link an object toseveral others, an object may be linked to only one value via a structural attribute.The third major construct in the EER model is the relationship. A relationship denotes anassociation between two or more entities of the same or different entity sets 120. An example would beCUSTOMER Holds account ACCOUNT. Relationships may be mandatory or optional, and binary or118Attributes may also apply to relationships, as discussed later.119If the EER model was extended further to accommodate change, a model of an attribute as afunction might include time as a domain parameter, as inWeight:PERSONOTIME-->POSITIVE_NUMBERS (Section 4.2.2.3.3).120Relationships in EER are grouped into relationship sets.175n-ary. In addition, cardinality constraints enforce conditions on the connectivity of entities in a relationship(e.g., 1:1, 1:N, M:N). A Holds account relationship is 1:N (from CUSTOMER to ACCOUNT) if acustomer may hold several accounts, but each account is held by only a single customer.Relationships in EER may reflect either of two distinct constructs in MIMIC. The first is therelational attribute. A relational attribute is a set of functions mapping from objects in one class to setsof objects from one or more object classes (e.g., Holdsaccount = fhi lhi :CUSTOMER-->Q1, whereQc to (ACCOUNT)). As with structural attributes, one function from the set is active at any time, therebyproviding a treatment of time that is absent in the EER model, including an implicit specification of thepermanence of attribute values. Mandatory/optional attributes are captured by excluding/including,respectively, the null set from the codomain of the attribute. Since R= , where Qc (T 20...OTN),a relational attribute is labelled binary if N=2 (note that T2 may be the same as T i) and N-ary if N>2.Furthermore, the connectivity of a relational attribute may be constrained by appropriate restrictions onthe codomain. For example, in modelling a society which does not allow polygamy, the codomain of therelational attribute Married to is restricted to a subset of the power set of PERSON which contains onlysingletons. As for M:N (and 1:1) connectivity, since every relational attribute has an "inverse", both theattribute and its inverse may have a codomain containing only singletons (for 1:1 linkages), or a largersubset of the power set (for M:N linkages). In other words, the EER model deals with connectivity moreexplicitly than MIMIC, but the latter permits connectivity information to be captured implicitly throughconstraints on the codomain of a relational attribute.Relationships in the EER model do not, however, always correspond to relational attributes ofMIMIC since the former may possess attributes. In that case, they appear to be more similar to the notionof composite objects in MIMIC. Since the relationship construct is used to model both relationships withattributes and those without, it is semantically overloaded with respect to representing the elements ofclassification theory. MIMIC, however, clearly distinguishes the two cases. Relationships without attributes176are captured simply through relational attributes. On the other hand, relationships possessing attributes aremodelled as composite objects. Composite objects are objects and, therefore, possess their own attributes.In addition, each component in a composite is connected to the other components by a relational attribute.For example, ENROLMENT may be considered a composite class (having component classes STUDENTand COURSE) with emergent structural attribute Grade. The instances of this class are specific student-course combinations. The component classes are additionally linked by the relational attributesEnrolled_ in (of STUDENT) and Hasenrolled (of COURSE). Since there is this duality betweencomposites and relational attributes, it is not surprising that the EER model uses the relationship constructto represent two distinct, but related elements of knowledge.MIMIC provides a basis for resolving the ambiguity in the EER model about whether to modela phenomenon as an entity or as a relationship (Teorey et al., 1986). Simply, a relational attribute whichhas emergent attributes with respect to the collection of objects involved in the relationship is modelledas a composite object (in EER terms, entity) whose components are the objects involved in the relationalattribute. If there are no emergent attributes associated with the collection of objects involved, a relationalattribute captures the pertinent knowledge.In the EER model, entities are grouped into entity sets. An example of an entity set in EER wouldbe EMPLOYEE, containing entities {John, Jane, Mary ...}. Although entities in an entity set possess thesame attributes, the construct is primarily extensional, and does not fully reflect the intensional notion ofa class in MIMIC. A class such as EMPLOYEE consists of a set, P, of structural and relational attributes,and an associated set, B, of behavioral attributes (i.e., EMPLOYEE = P, where PCB), where the attributesin P are defined on domains of objects (e.g., (John, Jane, Mary ...), (John, Paul, George ...), (John,Jane, Frank ...)). Thus, a class is more explicitly based on a notion of shared attributes than is an entityset. In addition, classes also have an extensional interpretation, given by the intersection of the domainsof the attributes in P. Attributes appear to play a less important organizational role in EER descriptions177than in MIMIC.In MIMIC, classes are organized in a class structure, which imposes certain constraints on theclasses it contains. These constraints are based on several cognitive principles, and constitute a set ofminimal conditions for the "goodness" of a set of classes EER imposes no such constraint on thedefinition of a collection of entity sets.In line with the theory of concepts on which the model is based, MIMIC incorporates bothstructural and relational attributes as part of class definitions and, therefore, as part of the knowledge aboutthe objects in these classes. This is in contrast with EER, in which relationships are not well-tied to entityset definitions. The presence or absence of relationships in an EER diagram does not appear to influencethe extension of an entity set, whereas the presence or absence of relational attributes explicitly affects aclass definition in MIMIC, and will generally affect the extension of that class.As indicated above, a MIMIC class encapsulates structural and behavioral knowledge. Behavioralattributes specify allowed changes to objects, given any active functions for specified structural andrelational attributes. Perhaps the most significant shortcoming of the EER model in representing knowledgeabout a domain is its inability to capture knowledge about how things change over time. Without a notionof behavior, the EER model is also unable to capture temporal knowledge.A further construct of the EER model allows entity sets to be arranged in a hierarchy. Two casesare recognized. A generalization hierarchy partitions an entity set into a collection of mutually exclusiveand collectively exhaustive subsets. An example would be LOAN and ACCOUNT as subclasses ofPRODUCT in a banking environment in which these are the only products offered. A subset hierarchyproduces potentially overlapping subsets of an entity set. An example would be CUSTOMER andEMPLOYEE as subclasses of PERSON in a context in which employees may be customers. In thediscussion of Teorey et al. (1986), no mention is made of a more general lattice (versus hierarchy) ofentity sets. Also, the model does not indicate that specializations must possess additional attributes or178relationships.The MIMIC model contains a more refined mechanism for capturing IS-A associations.Intensionally, a class is a specialization of another if it possesses one or more additionalstructural/relational attributes, whose shared domain is a subset of the extension of the existing class.Consequently, the specialized class has an extension which is a proper subset of that of the superclass. Forexample, SAVING may be a subclass of ACCOUNT with the added structural attribute Interest rate.Due to the nature of class definition in terms of attributes, a class may be a specialization of severalsuperclasses. This leads to a lattice structure for classes. For instance, CHEQUING may also be a subclassof ACCOUNT (with added attributes such as Issued_ cheques), and CHEQUABLE SAVING a subclassof both CHEQUING and SAVING with additional attributes with respect to both (such asMinimum_balance). If there are no added structural or relational attributes (e.g., if there are onlydifferences in behavior between CHEQUABLE SAVING, and CHEQUING or SAVING accounts),CHEQUABLE SAVING would not be defined as a class in MIMIC. Instead, differences in behaviordepending only on the state of an object (as opposed to the attributes it possesses) can be incorporated intothe behavioral attributes of CHEQUING or SAVING as needed (Section 5.2).In addition, the disjointness of subclasses is captured implicitly in MIMIC if the added attributeswhich distinguish two or more subclasses of an existing class (e.g., LOAN and ACCOUNT as subclassesof PRODUCT) have disjoint domains. The subclasses are collectively exhaustive if the union of thedomains of the additional attributes is a superset of the extension of the superclass. This contrasts withthe explicit mechanism provided in EER. Furthermore, MIMIC recognizes criteria on which objects maymove between classes in a lattice (Section 5.4). EER does not provide a mechanism to recognize thatentities may move between entity sets.In sum, EER appears to lack the ability to express the following elements of concept-basedknowledge. First, there are no mechanisms to capture behavioral knowledge or to deal with time. Second,179there is an ambiguity with respect to modelling relational attributes and composites. Third, there is nointensional notion of a class. Fourth, there are no criteria by which a collection of classes may be judged"good" (i.e., no class structure). Finally, the semantics of specialization are less precise in EER than inMIMIC. Consequently, the EER model may be viewed as a "strict subset" of MIMIC. It does not appearto possess any representational elements which MIMIC doesn't, and does not capture some importantelements of knowledge. MIMIC also serves as a higher level framework within which the capabilities andlimitations of EER can better be understood in a well-defined way.6.4 TELOS (Mylopoulos, 1991; Mylopoulos et al., 1990)The Taxis project has produced several languages and tools to model large-scale, data-intensiveapplications from a knowledge representation perspective (Nixon, 1984 contains a collection of earlypapers on various aspects of the project). The project has evolved from a database description languagecalled Taxis, through a non-procedural conceptual modelling language, RML (Requirements ModellingLanguage), to a more abstract knowledge representation language called Telos (Mylopoulos, 1991) 121 .There are many similarities among these languages, along with some important differences (see Section2.2.1). In comparing this work to MIMIC, attention is focused on Telos, since this language is most recentand, more importantly, is explicitly intended for conceptual modelling.One of the fundamental constructs in Telos is the token. Tokens are intended to be in directcorrespondence with, and therefore surrogates of, things in a domain of interest122 (Mylopoulos, 1991;Borgida, 1984; Greenspan and Mylopoulos, 1984). An example would be the symbol John designating121In addition, CML (Conceptual Modelling Language) had a brief existence as either a refined RMLor a preliminary Telos (Borgida et al., 1988).122Using MIMIC terminology, it is more accurate to say that tokens represent knowledge of theexistence of things in the world. However, this distinction is not explicitly made in descriptions of RMLor Telos.180a specific person. In MIMIC, objects are surrogates which represent the existence of instances of concepts.Tokens and objects, therefore, have corresponding purposes in the respective languages.The second fundamental construct in Telos is the attribute123. Attributes represent binaryrelationships between entities and, therefore, consist of binary relationships between tokens, such as [John,Weight, 70] 124. Attributes belong to attribute categories, such as characteristic and association.Characteristic properties are unchanging (e.g., Birthdate), whereas association properties may change overtime (e.g., Address).Attributes appear to substitute for two constructs in MIMIC: structural and relational attributes.Structural attributes link objects with values. Relational attributes link objects to sets of other objects.Values are not objects as they do not possess attributes. Both structural and relational attributes in MIMICmay be, in Telos terminology, characteristic or association. This is implicitly reflected by whether anattribute contains a single function (characteristic/unchanging) or more than one function(association/changing). Telos does not distinguish structural and relational attributes, since both objects(e.g., John) and values (e.g., 70 kg) in MIMIC are treated as tokens in Telos. Therefore, Telos does notcapture a distinction between things (which possess properties) and values (which do not).Telos tokens belong to classes. A class is defined in terms of the attributes which are applicableto all instances and is, therefore, an intension. In MIMIC, objects similarly belong to classes. A MIMICclass is an intension, or specification of conditions for membership, consisting of sets of structural,relational, and behavioral attributes. Behavioral attributes impose constraints on the allowed changes tostructural and relational attributes for the objects possessing these attributes. Since Telos does notdistinguish structural and relational attributes and, furthermore, does not encapsulate behavioral knowledge123In Telos, all constructs are expressed as propositions. However, the discussion here deals withspecific "kinds" of propositions, such as tokens and attributes.124This proposition is an instance of the proposition [PERSON, Weight, WEIGHT]. Consequently,Weight may be viewed as a function from a class of tokens, to another class of tokens.181in class definitions 125, the correspondence between Telos and MIMIC notions of class is not precise.Furthermore, Telos does not provide criteria for evaluating a collection of classes as good. By contrast,the notion of class structure is integral to the definition of the class construct in MIMIC.Classes in Telos are organized in a specialization/generalization lattice. Specialized classes refineone or more existing classes and may add attributes and/or restrict the range of values which attributesof the superclass(es) may assume. A specialized class inherits the attributes of the classes from which itis derived, and every instance of a class is an instance of each of its superclasses. An example would bePERSON with attributes (Name, Address, Birthdate, ...) and a subclass CUSTOMER which inheritsName, Address, and Birthdate, and may possess other attributes, such as Holds_account. Although itappears that tokens may move between classes in Telos, the model does not provide a taxonomy of"kinds" of subclasses for understanding when movements between classes may or may not occur (cf.Section 5.4).Classes in MIMIC are also organized in a lattice. However, the definition of class structure ensuresthat a subclass can only be defined by adding attributes to an existing class. For the example above, thesubclass CUSTOMER must possess at least one additional structural/relational attribute such as therelational attribute Holds_account, linking CUSTOMER to ACCOUNT. As in Telos, a MIMIC subclassmay have several superclasses. Furthermore, the extension of a subclass is a proper subset of the extensionof each of its superclasses. In addition, if the subclass has more than one superclass (e.g.,CUSTOMER_ EMPLOYEE as a subclass of both CUSTOMER and EMPLOYEE), it must possess atleast one structural or relational attribute with respect to the union of the structural and relational attributesof all superclasses (Section 5.3). Telos does not appear to enforce this constraint.An important construct of MIMIC which does not appear to be supported by Telos is composition.While a Telos object is an aggregation of attributes whose values are, in turn, objects which possess125Behavior is treated separately in Telos, as discussed later.182further attributes, this collection of objects is not treated as a whole, which is linked by some relationalattribute and possesses emergent attributes.Earlier it was pointed out that Telos does not encapsulate behavioral attributes in class definitions.Instead, a class/instance framework is used to deal with change 126. Knowledge about change (behavior)is expressed in terms of activities which belong to classes. Activity classes are a mechanism for describingchange, including the addition of tokens to and the removal of tokens from classes, as well as changes tothe values of properties of tokens. Activity classes are defined in terms of inputs and outputs of theactivity (e.g., PERSON and CUSTOMER for an activity in which a person becomes a customer), pre-and post-conditions which must be satisfied before and after the activity occurs (e.g., the potentialcustomer must be in class PERSON before the activity and must have the property Holds_account afterthe activity), and parts which describe the actual changes at a general level (e.g., open an account). Partsdescribe the "what" rather than the "how" of change. Each activity is an instance of an activity class.Activity classes are arranged in a specialization hierarchy with inheritance. For example,OPEN CHEQUING ACCOUNT may be an activity class specializing the class OPEN ACCOUNTwith new pre-conditions (e.g., customer must already hold a savings account) and parts (e.g., issue chequesto accounts).In contrast, MIMIC integrates behavior as part of the description of knowledge about thingsthrough behavioral attributes. A behavioral attribute specifies the changes which are permitted to theactive function of one or more structural/relational attributes given any combination of active functionsfor these attributes. At first glance, there seems to be little connection between behavioral attributes andactivities. However, since pre- and post-conditions may be used to describe states necessary for an activity126Telos has been referred to as object-oriented (Mylopoulos et al., 1990). However, the frameworkdoes not include the most commonly used indicator of object orientation: encapsulation (Nierstrasz, 1987),since structural and behavioral knowledge about classes of entities are handled through separatemechanisms.183(pre-conditions) and constraints on the states which may result from an activity (post-conditions), they areanalogous to the input to (i.e., a function) and output from (i.e., a set of functions) a behavioral attributefunction in MIMIC. The parts of an activity also describe, in a non-procedural way, the nature of thechanges which occur. Nevertheless, MIMIC behavioral attributes are more abstract than Telos activities.Closely related to behavior is the treatment of time in each model. The model of time in Telosis based on time intervals (Allen, 1983). A time interval is associated with each proposition (token orattribute) indicating a duration for which the proposition holds. MIMIC handles time only implicitlythrough the occurrence of events. That is, the passage of time is recognized by events, and behavioralattributes impose constraints on which events are allowed. By introducing a "clock" object, the time ofevents relative to a standard enables comparisons of the distance between events to be made, and for theduration of states to be determined (Section 5.7).One important feature of Telos is not included in the MIMIC model. Specifically, Telos classesmay also be instances of other classes - the latter termed metaclasses. This "uniformity" is one of the mostemphasized features of the model (Mylopoulos et al., 1990). For example, a metaclass PERSON_CLASSmay include instances, such as PERSON, EMPLOYEE and CUSTOMER, which are classes. Thisallows, for example, statistical and aggregate information to be attached to classes (e.g., Average_age ofEMPLOYEE, CUSTOMER, and other instances of PERSONCLASS) 127. There is deliberately nocounterpart to this feature in MIMIC, since the model is intended only for representing knowledge aboutthe subject matter of an information system. Meta-classes represent "knowledge about knowledge" aboutthe domain. Considering classes as objects (and, therefore, members of metaclasses) is appropriate onlyif what is being modelled includes knowledge about knowledge. In other words, MIMIC holds thatconcepts and instances of concepts differ, and need to be appropriately distinguished in the model by12.7At least some of the information that is captured by the properties of metaclasses is implicitlycarried by the objects of a class. For example, Average_age is implied by (and can be computed given)the ages of each instance of a class.184differentiating classes from objects. This important difference between the models may be due to the largerscope of Telos, which is intended not only for modelling the subject domain (e.g., knowledge aboutentities in an organization), but for the information system, usage, and development domains (Mylopouloset al., 1990).To summarize, Telos supports many of the elements of the cognitive model of MIMIC. However,a few features are not supported and Telos contains one very significant departure from the MIMIC model.Like MIMIC, Telos supports the representation a domain in terms of instances which belong to classesthat are defined intensionally. Similarly, it supports class specialization and inheritance. In addition, bothstructural and behavioral knowledge can be modelled, although in a manner different from that of MIMIC.Furthermore, the importance of time is recognized.Telos does not, however, introduce the notion of class structure - a collection of classes whichsatisfy certain cognitive principles. In addition, it does not use a uniform, function-based approach to thedescription of structure, relationships, and behavior. Structural and behavioral knowledge is representedin separate class hierarchies, and structural and relational attributes are not distinguished. Telos also adoptsa quite different approach than MIMIC for representing behavior, using pre-conditions, parts, and post-conditions. Consequently, behavior modelling is more detailed than in MIMIC, in which behavior isspecified only in terms of which events may occur, given a particular state (with respect to one or morestructural/relational attributes). In addition, Telos does not have a mechanism to model composite things,which consist of parts and possess emergent properties.The most significant difference between the models is that Telos stresses uniformity in the use ofpropositions and multiple levels of classification. Telos views classes as objects and introduces metaclassesto abstract the commonality of classes. MIMIC does not support this (although it could be extended to do185so) 128 because of the stance that the primary domain to be modelled does not include knowledge aboutknowledge and, therefore, classes are to be treated differently from objects.6.5 NIAM (Verheijen and Van Bekkum, 1982)NIAM is a language (primarily graphical) for representing knowledge about a domain, termed theobject system. Knowledge is captured in terms of information structure and information flow,corresponding roughly to static and dynamic knowledge. In this section, the features of NIAM areexamined to determine the model's degree of support for representing knowledge constructs.The simplest construct in NIAM is the object. Objects are of two kinds: non-lexical and lexical.A non-lexical object is a thing in the domain of interest (e.g. the person john_smith) 129"°. A lexicalobject is a string which can be spoken and refers to a thing in the domain of interest (e.g., "John Smith").Both non-lexical and lexical objects are classified into types. A non-lexical object type (NOLOT) is a setof non-lexical objects (e.g., PERSON). A lexical object type (LOT) is a set of lexical objects (e.g.,PERS ON_NAME).The non-lexical/lexical object distinction does not correspond well to the object construct ofMIMIC. Some non-lexical objects, such as symbols denoting persons, would be modelled as objects inMIMIC. On the other hand, other non-lexical objects, such as symbols designating dates, would bemodelled as values in MIMIC. Furthermore, lexical objects, such as strings designating names, alsocorrespond to MIMIC values. In short, NIAM does not clearly support the MIMIC object construct. To128For example, classes could constitute the domain of other structural and relational attributes.Collections of attribute with such domains could then form metaclasses.129Actually, a non-lexical object in a NIAM description of a domain is a representation of a thing, andnot the thing itself.130In this discussion, non-lexical objects are indicated by words in italics to distinguish them fromlexical objects, which are enclosed in double quotes.1 86serve as a more direct model of knowledge, non-lexical objects must be used only to represent instancesof concepts (thereby corresponding to MIMIC objects) and lexical objects must be used only to representvalues.The essence of the information structure component of NIAM is a collection of LOTs andNOLOTs linked by bridge and idea types. A bridge type denotes a binary association between a NOLOTand a LOT (e.g., PERSON Has_name PERSON_NAME). An idea type denotes a binary associationbetween two NOLOTs (e.g., EMPLOYEE Employed_by EMPLOYER). Bridges and ideas are membersof these types (e.g., john_smith Has_name "John Smith", john_smith Employed_by ubc).If lexical and non-lexical objects (and types) are constrained to represent values and instances ofconcepts, respectively, bridge types can be viewed as serving a similar purpose as structural attributes inMIMIC, since a bridge type links a NOLOT with a LOT. Idea types may be viewed as similar to binaryrelational attributes since an idea type links two NOLOTs. However, n-ary relational attributes, linkingobjects of one class with objects of several other classes, are not supported by NIAM.NIAM does not fully support the MIMIC class construct, since a NOLOT is substantially differentfrom a MIMIC class. A NOLOT is a set of non-lexical objects (e.g., EMPLOYEE = (John MaryJane)), and is not defined intensionally. Even if the collection of idea and bridge types involving aNOLOT is taken as a definition of the NOLOT (which is not done in NIAM), behavioral knowledge isnot encapsulated, but is dealt with using other mechanisms (which are discussed later). Furthermore,NIAM does not provide a mechanism for evaluating the quality of a collection of NOLOTs.NIAM does support subtype links between NOLOTs. Subtypes inherit idea and bridge types ofsupertypes and may (not must) be involved in additional bridge and idea types. It is unclear, however,whether a NIAM subtype can have multiple supertypes. Furthermore, NIAM does not seem to account forthe movement of objects between types. Subtype links serve a similar function as subclasses in MIMIC.However, the MIMIC subclass construct has clearer semantics, in that a subclass must possess added187attributes and its extension is a strict subset of that of (each of) its superclass(es).NIAM does not support a notion of composite NOLOTs having emergent properties and, therefore,does not have a mechanism corresponding to composition in the MIMIC model.Several kinds of constraints on information structure diagrams are introduced in NIAM. Identifierconstraints are similar to cardinality constraints of the ER model. They determine whether a member ofone type can be linked to one or more members of another type via a bridge or idea. The MIMIC modelcaptures this information in two ways. First, a structural attribute always links an object to a single value.A relational attribute may link an object to several sets of one or more objects (from the same or differentclasses). If the codomain is restricted to a set of singletons, a 1-1 mapping is implicitly determined. Forexample, the codomain of a relational attribute, Married_to, can be constrained to contain only singletons.Other conditions can equally well be handled (e.g., pairs, singletons and pairs, and so on). For example,the codomain of Child of can be constrained to contain only pairs.Subset constraints impose the condition that the objects involved in one idea or bridge type area subset of those involved in another. For example, if PAPER Presented by AUTHOR and PAPERWritten_by AUTHOR, then for any paper, its presenters must be a subset of its authors. MIMIC doesnot have a mechanism to explicitly enforce this, since it constitutes knowledge about knowledge about thesubject matter. In other words, knowledge about the subject matter contains specific details about theauthors and presenters of papers. That this conforms to the constraint "All presenters of a paper are authorsof that paper" is an abstraction from the data, which can be recognized from a MIMIC representation, butis not enforced as an explicit constraint of the model.Equality constraints impose the condition that the population of objects in one binary associationis the same as that of another involving the same two object types. For example, if Starts on andEnds on associate CONFERENCEs with DATEs, a given conference must have both (or neither). Thisis not explicitly dealt with in MIMIC, but any two (or more) attributes (e.g., structural) must have values188(i.e., the model does not deal with incomplete information).Uniqueness constraints deal with a combination of role occurrences which uniquely identify a non-lexical object. For example, a customer is uniquely identified by any account which s/he holds, if anaccount is held by no more than one customer. This is related to the concept of a key in relationaldatabases. In MIMIC, an object in a class is uniquely identified by a surrogate. It may also be that somecombination of values of attributes also distinguishes an object from all others, but this is not relevant tothe purpose of the model, since implementation considerations are beyond its scope.Disjoint constraints are used to express the knowledge that two subtypes of an object type aremutually exclusive (e.g., subtypes ACCOUNT and LOAN of CUSTOMER). In MIMIC, two subclassesof a class are disjoint if the intersection of the common domain of the additional attributes of one withthe common domain of the additional attributes of the other is an empty set. That is, the restriction isimposed (i.e., can be recognized and enforced in a representation) implicitly by the extension of classesand not by any explicit rule, since this again constitutes knowledge about knowledge.Total role constraints enforce that every object of a certain type participates in a given role in abinary relationship. Essentially this is similar to a prohibition of null values for an attribute or relationship.In MIMIC, the class definitions are such that no member of a class has a null (or not applicable) valuefor a structural attribute 131 . Null values are, in general, permitted for relational attributes (e.g.,Married to), but this can be constrained for particular relational attributes by omitting the null set fromthe codomain of a relational attribute if all objects in a class are to be linked to other objects via theattribute (e.g., Child_of).The interesting thing about most of these constraints, and their treatment in NIAM versus MIMIC,is that they reflect knowledge about knowledge about specific things. Like Telos, NIAM captures some1310therwise, either the attribute is not truly part of the class definition or the object in question doesnot belong in the class. Values may be unknown, but MIMIC does not address representing incompleteknowledge.189metaknowledge by adding explicit constraints. However, MIMIC explicitly deals only with representingbase knowledge about things in a domain (where the domain does not include knowledge aboutknowledge). Constraints such as those supported by NIAM are, however, recognized implicitly, in thatthey can be satisfied in a specific representation. For example, a problem description for a bank containsthe information that accounts and loans are non-overlapping, since the shared domain of the extraattributes of each class is disjoint with that of the other (e.g., accounts do not have the attribute Term,and loans do not have the attribute Overdraft).A second component of the NIAM model deals with change. This is handled in a process-orientedmanner through functions and information flows. Information flows contain information on the objects ofan information structure diagram. Functions transform information flows and, consequently, change thestate of a system. An information flow diagram contains a number of functions, an information base(which is based on an information structure diagram), and a number of information flows (streams ofdata).Although it is impossible to formally compare this view of behavior to the way in which MIMICdeals with change, it is clear that the NIAM model is much closer to traditional data processing(implementation or software-oriented) views of information systems. Information flow diagrams are verysimilar to the data flow diagrams of structured analysis (DeMarco, 1979) 132. The view of change inMIMIC, on the other hand, is completely non-procedural. Behavioral attributes describe the events whichmay occur, with no attention to how changes are carried out. The behavioral component of NIAM isperhaps more useful as a system design tool than a knowledge modelling tool, since NIAM functions andinformation bases have direct counterparts in software (programs and files).In sum, NIAM support for the representation of most cognitive constructs (as modelled by132This can be seen by comparing information base with data store, function with transform,information flow with data flow, environment with source/sink.190MIMIC) appears to be lacking. First, there is no direct counterpart to the MIMIC object. Second, thereis no distinction between structural and relational attributes. Third, behavior is modelled procedurally.Fourth, the notion of a class as an intension encapsulating structure, relationships, and behavior, is missing.Fifth, the issue of the "quality" of a set of NOLOTs is ignored. Sixth, the notion of specialization is notas precise as that of MIMIC. Finally, composition is not supported.6.6 OBJECT-ORIENTED ANALYSIS (Coad and Yourdon, 1991)Object-oriented analysis (OOA) has emerged as a modelling technique said to be based onprinciples guiding the way people organize knowledge (Booch, 1991; Coad and Yourdon, 1991).Unfortunately, there is not a standard approach to object-oriented modelling. In this section, the practicalmethod advocated by Coad and Yourdon (1991) is analyzed in terms of its support for the concept theorybased constructs of MIMIC.The basic construct in OOA is the object, which is a collection of attributes and services 133 .Objects correspond to things in the subject domain, including "structures, other systems, devices, thingsor events remembered, roles played, operational procedures, sites, and organizational units" (p. 60).Without going into the details of each, it should nonetheless be clear that the object construct issufficiently general to represent both physical things (e.g., structures, devices) and abstract entities (e.g.,events remembered, organizational units). Thus, an OOA object is very similar to a MIMIC object.However, MIMIC uses objects to explicitly represent the existence of instances of concepts as distinctfrom the properties possessed by these instances. OOA does not appear to make this distinction.Objects in OOA possess attributes. According to Coad and Yourdon, "an attribute is some data(state information) for which an Object in a Class has its own value" (1991, p.119). Attributes are single-"'Service is a synonym for method or activity, and is a mechanism for describing behavior (changesto attribute values), as discussed later.191valued, and resemble structural attributes in MIMIC. However, unlike structural attributes, OOA neitherformally defines the construct nor specifies whether values are objects.OOA also introduces a notion called instance connection, which consists of a mapping (along withcardinalities) from an object to other objects. This construct is analogous to the relational attribute ofMIMIC, which maps objects to sets of other objects. However, relational attributes may be n-ary (i.e.,connect attributes from n sets), whereas instance connections are strictly binary. In addition, theimportance of instance connections to the definition of classes in OOA is not specified.Behavior is modelled in OOA by what is called a service. A service describes a mechanism bywhich objects change state. The description of services is highly procedural (algorithmic). Hence, unlikethe abstract descriptions of allowed change that constitute MIMIC behavioral attributes, services describehow objects change state (not simply which changes may occur).Attributes and services together are used to define classes in OOA. A class may be viewed as atemplate, or abstraction of a set of objects sharing a collection of attributes and services. As in MIMIC,a class is intensionally defined, has an associated extension, and encapsulates structure and behavior.However, part of the class description includes instructions for creating new instances. This use of classesto create instances is borrowed from Smalltalk (Goldberg and Robson, 1989), and is very much animplementation consideration. Furthermore, OOA does not develop a notion comparable to the MIMICclass structure, for assessing the quality of a collection of classes.OOA also introduces two structures134 for organizing classes. The generalization-specializationstructure captures IS-A linkages between classes. A specialized class inherits the attributes and servicesof the more general classes from which it descends. Thus, a lattice of classes is supported. This notionis similar to the specialization construct in MIMIC. However, MIMIC offers different criteria for definingsubclasses. OOA generally requires that a specialized class add attributes or services, except when it134This term is not used in the same sense as class structure in MIMIC.192specializes two or more existing classes. As discussed in Chapter 5, MIMIC does not allow specializationbased solely on added behavioral attributes. Furthermore, a subclass derived from two or more existingclasses not only inherits attributes of both, it must possess additional ones. Finally, MIMIC considersconditions under which objects may move between superclasses and subclasses, while OOA does not.The final construct in OOA is the whole part structure 135. A whole object (or class) is composedof several parts. OOA allows for optional and mandatory parts. Three variations - assembly/parts,container/contents, and collection/members - are used. It is not clear whether the whole must possessemergent attributes and services (although the examples used suggest this). The whole-part constructclearly parallels the composite class (or object) in MIMIC. However, MIMIC provides a precise construct,defined in terms of emergent attributes, and further requires that the components be linked by relationalattributes.In sum, OOA provides some support for almost all of the cognitive constructs represented inMIMIC. The notable omission is the notion of a class structure which meets certain conditions ofgoodness. However, the constructs provided are not precisely defined in OOA, and some MIMICconstructs, such as relational attributes, specialization, and composition, capture more knowledge than theircounterparts in OOA. Furthermore, the treatment of behavior in MIMIC is more abstract (i.e., only interms of allowed state changes) than in OOA, since the latter introduces algorithmic specification of howchanges occur. A consequence of the precision of MIMIC is that time can be handled formally, while thesubject is not treated at all in OOA.MIMIC may be viewed as a higher-level, formally defined companion of OOA, giving precisemeaning to constructs that are only casually introduced in OOA. This is not a criticism of OOA. On thecontrary, a casual description is probably very useful for a practical methodology that is intended to be13500A also discusses a term called subjects as a mechanism for organizing a large model intosegments. However, this does not add to the knowledge content of a representation, but merely itspresentation, and is not discussed further here.193directly used in building domain descriptions.6.7 SUMMARYThis chapter has used MIMIC to evaluate the "cognitive content" of four other conceptual models.The examination highlights the difficulty of reconciling terminology and construct differences - aprerequisite for comparing and evaluating different approaches. Direct comparison was, in some cases,impossible, and otherwise required assumptions to be made about the meaning of constructs in the othermodels.Nevertheless, the basic conclusion of the analysis is that EER, Telos, NIAM, and OOA supportto varying degrees the elements of concept theory on which MIMIC is based. Both EER and NIAM havesignificant gaps in representing important knowledge. EER fails to incorporate behavioral modelling, whileNIAM does not distinguish structural and relational knowledge, does not encapsulate behavior withstructure, has only a weak notion of specialization, and does not handle composition. Neither EER norNIAM deals with time. Telos captures many of the important elements of concept theory, but does notappear to support either encapsulation or composition. Furthermore, it introduces metaclasses to modelknowledge about knowledge, a task beyond the intended scope of MIMIC 136. OOA deals to some extentwith each of the concept theory-based constructs of MIMIC, but in a less precise manner. As aconsequence of the lack of formal treatment in OOA, it fails to capture some important semantics that arereflected in MIMIC, such as the meaning of class specialization, and the nature of time. In short, thecomparison demonstrates that MIMIC may be viewed as a framework, or metamodel within which thesimilarities and differences of other models can be better understood.Perhaps the most telling limitation of the models surveyed here is that none consider the qualityof a class structure. One of the primary contributions of MIMIC is the use of several basic "principles of136NIAM also represents knowledge about knowledge, but to a much lesser degree.194conceptualization" to derive a set of minimal conditions for a given collection of (potential) classes to be"good". The conditions which define potential class and class structure allow knowledge about a domainto be represented in an effective (complete) and efficient (non-redundant) manner, while recognizing thatmany organizations of classes for a given domain of knowledge may satisfy these conditions.Finally, MIMIC provides a simple and implicit view of time that does not require the introductionof additional constructs or a complex logic of time. This is not the case for any of the other modelsconsidered, since Telos introduces a detailed temporal logic, while the other models examined do not dealwith time. While the simplicity may limit the expressiveness of the model for dealing with time, it doesfocus on and operationalize the single notion of time as change (specifically, as change in active functionsof structural and relational attributes).CHAPTER 7CONCLUSIONS AND FURTHER RESEARCH7.1 THESIS SUMMARYConceptual modelling is a critical early activity in information systems development, during whichusers' knowledge about the things which constitute the subject matter of a proposed information systemis represented in an implementation-independent manner. Unfortunately, many existing systems analysismethods (and conceptual models) are not explicitly based on theories about the ways in which peoplestructure and organize knowledge about things. Instead, many contain constructs which are more suitablefor modelling the implementation or software domain. This has contributed to problems ofincomprehensibility, redundancy, and duplication of effort in systems development.This thesis helps fill the conceptual modelling "gap" by developing a conceptual informationsystems model based on a theory of concepts (or classification). More specifically, the work attempts toanswer the following general research questions (Chapter 1):1. Can a theory of concepts serve as a foundation for defining a uniform model ofknowledge that supports direct representation across several kinds of IS applications?2. Does this model offer insights and guidelines for conceptual modelling relative to otherconceptual models?These questions were, in tum, operationalized in terms of three basic research objectives:1. Define the model,2. Demonstrate the model's value as a tool for exploring open problems in conceptual modelling,3. Evaluate the model relative to several existing conceptual modelling approaches.195196To achieve these objectives, a theory of concepts - the so-called classical view - was firstdescribed in detail. Five fundamental constructs - instance, property, concept, specialization, andcomposition - were identified (Chapter 3) and defined formally (Chapter 4). This formalism, along withthe objective of providing direct representation, provided the basis for defining a set of correspondingconceptual modelling constructs, resulting in the MIMIC model (Chapter 4). Use of these constructs ona hypothetical, but representative, problem domain served to highlight how the model may be used andits uniformity in representing knowledge for several kinds of applications (Appendix 1). Subsequently, thecontributions of the model to resolving several open problems in conceptual modelling were explored(Chapter 5). This was followed by evaluating the constructs of four existing conceptual models withrespect to those of MIMIC. The comparison indicated the model's generality and representation power andprovided a basis for understanding and comparing the constructs of other models (Chapter 6).7.2 CONTRIBUTIONSThis research has been directed toward developing a classification theory based, formal conceptualmodel. Hence, the most significant contributions are theoretical. However, the work has also yielded anumber of practical contributions, primarily in the form of implications for conceptual modelling activitiesand methodologies.7.2.1 Theoretical ContributionsAs discussed in Chapter 2, previous conceptual modelling research and practice has producedmany methodologies with varying "ad hoc" constructs which have not been adequately motivated ordemonstrated to be useful. The primary contribution of this work is the development of MIMIC - a197uniform, formal model of knowledge about things'''. Unlike many existing models, MIMIC is explicitlyand formally based on a theory of the structure and organization of knowledge about entities, and isintended for modelling knowledge about the subject matter of an information system. As a result, anumber of insights into conceptual modelling semantics are gained.The model introduces the notion of potential class, based on the principles of abstraction frominstances and maximal abstraction, and of class structure - a collection of potential classes satisfying theprinciples of non-redundancy and completeness. A class structure is a complete representation someuniverse of knowledge, in which no class is simply a combination of other classes in the structure.Different views of the world can be supported by defining different class structures on a given set ofobjects and attributes. An "asymmetry" between structural/relational versus behavioral attributes isidentified. The former provide the basis for defining classes, while allowed changes are implied by thebehavioral attributes . The naturalness of a lattice class organization is explained, and the notion of roleswithin a class structure is supported by the membership of objects in several classes. The meaning of IS-Arelationships is refined in terms of the temporal or permanent nature of attributes. Guidelines are givenfor modelling phenomena as either relational attributes or as composites. In addition, the merits ofuniformity in modelling structure and behavior are discussed. Furthermore, the model's position on themeaning of time, and a simple approach to modelling time are explored.An additional theoretical contribution comes in the form of insights into the ongoing debate over137 In order to develop this model, the constructs of classical concept theory had first to be formalized.In the process, a number of potential refinements to the theory emerged. The notion of a lattice of classesis a natural consequence of the formalization of properties, but is not traditionally associated with theclassical view. The definitions of potential concept and concept structure use a few basic assumptionsabout the purposes of classification to contribute to an understanding of why certain concepts are formedinstead of others. The notion of class structure further supports alternate conceptualizations of the world.The inability of the classical view to support alternate world views has been a criticism recently levelledagainst the theory (Lakoff, 1987). These insights are viewed as contributions to the reference discipline,but are not discussed further here since they go beyond the focus of the thesis.198the meaning of objects. Existing research has provided diverse, and sometimes conflicting, views on whatthe object paradigm is or should be. MIMIC is offered as an "object model", and may contribute toresolving the debate by highlighting that traditional justifications of the elements of the object paradigmhave mixed implementation and representation advantages. MIMIC provides a model of objects that isbased solely on the objective of directly representing knowledge about things.A third theoretical contribution, which also has practical implications, emerges from thedemonstration of the model's applicability by using it to uniformly represent knowledge for three kindsof applications (transaction processing, reasoning, and simulation) involving the same things. The exampledemonstrates that a single modelling framework can be used to develop integrated representations: thatis, representations in which a single thing is modelled by one object which participates in several classesof applications. This suggests that reductions in redundancy and duplication of development effort can beachieved using the model.Finally, the model provides a foundation for a program of future research. Although this mightnot generally be considered a contribution of a piece of research, in this case the model clearly identifiesa number of important related research issues, and provides a clear foundation for being able to addressthem properly. This is considered further in the last section.7.2.2 Practical ContributionsAn important practical contribution of this research emerges from the insights afforded by themodel. A number of guidelines for conceptual modelling are provided which may form the basis for amethodology for eliciting knowledge. For example, a specialization of an existing class must possessadditional structural or relational attributes. Therefore, attempts to define subclasses on the basis of eithervalues of attributes or behavioral attributes can be caught and corrected. In addition, identification ofinstances and attributes may be a useful complement to a more traditional strategy of identifying classes,199since the latter may be more volatile. Furthermore, refinements in the meaning of IS-A relationships allowmore knowledge to be captured in defining specialized classes. Finally, relational attributes can serve asa signal to look for information about the association, leading to the definition of composite classes. Thesemodelling prescriptions may prove useful in developing representations which are more easily understoodby users 138 .A second practical contribution is that MIMIC serves as a metamodel against which otherconceptual models can be compared (cf. Sol, 1983). This contributes to an understanding of the strengthsand weaknesses of other methodologies from a cognitive point of view, and thereby, can support theselection of a methodology for a given application.7.3 LIMITATIONSThe boundaries of this research are clearly marked by two factors. The first is the scope of thetheory of concepts on which the model is based, and the second is the focus of the model on representingknowledge at the complete exclusion of considerations related to the implementation of software and data.These factors impose a number of limitations on the work.First, by focusing on concept theory, other kinds of "knowledge" or cognitive structures, such asbeliefs and goals, are ignored. Consequently, concept theory does not provide a complete theory ofknowledge and the model developed is, in its current form, not applicable as a general knowledgerepresentation language. For example, the model does not recognize incompleteness or ambiguitym .138Clearly, it remains as future research to demonstrate or refute this hypothesis. This is discussed inthe last section.139Consequently, the model is not useful in explaining how people make default assumptions andreason, given uncertain knowledge.200While MIMIC can be extended to accommodate uncertainty140, the decision not to do so was based onthe fact that the chosen theory of concepts did not warrant its inclusion. Within the scope of applicationsof interest, this limitation does not impair the intended usefulness of the model.Second, MIMIC does not capture metaknowledge (knowledge about knowledge). By contrast withmodels such as Telos (Mylopoulos, 1991; Mylopoulos et al., 1990), MIMIC supports only therepresentation of what can be called base knowledge about things in a domain. Again, the model couldbe extended to capture metaknowledge141 : however, such an extension could not be justified usingconcept theory. Furthermore, since the domain of interest is the subject matter of a proposed informationsystem (e.g., an organization), the inclusion of metaknowledge would not contribute to directlyrepresenting knowledge about the things in that domain.Third, the model is far removed from implementation concerns. The most obvious manifestationof this is the completely non-procedural treatment of behavioral properties. Consequently, it is not clearhow the functional description of behavioral constraints should be transformed to a procedural design andimplementation. Similarly, the explicit implementation of structural and relational attributes as "large" setsof functions is not practical. However, these issues open the door to one path of further research involvinga direct implementation of the model, as discussed in the next section.Finally, the model is strongly shaped by the particular theory of concepts in which it is grounded.A model based on the quite different prototype- or exemplar-based theories would differ in important waysfrom MIMIC and might, for example, lead to different conceptual modelling guidelines. Since such modelshave not yet been proposed, it remains to be seen how they would compare with MIMIC.l 'As an illustration, structural properties could be defined to map from domains of objects tocodomains containing value-certainty pairs. For example, the property Weight could be defined asw ilw,:PERSON-->WEIGHTOCERTAINTY}, where CERTAINTY = {0,..., 100} and indicates the degreeof certainty (or belief) one has about a fact.'For example, classes could be treated as objects which, in turn, possess attributes, and so on.2017.4 DIRECTIONS FOR FUTURE RESEARCHOne of the contributions of this thesis is the provision of a formal, grounded basis for a significantprogram of future research which builds on the model and the results obtained from it. Threemethodologically different, but complementary, research directions are mentioned here.First, the model provides a vehicle for testing the much-vaunted "naturalness" of the objectparadigm. It has been widely claimed that object-oriented approaches more naturally reflect the way peoplestructure and organize knowledge about the world. However, the lack of agreement on what is meant bythe term "object" prevents appropriate tests of naturalness. MIMIC is proposed as an "object model" whichprovides a small set of constructs for representing knowledge according to a specific theory of concepts.Hence, people's ability to understand (or create) representations using these constructs can be evaluatedrelative to existing conceptual modelling approaches. This work can be done in either an experimental orfield setting.Second, a direct implementation of the MIMIC model may help to reduce the "semantic gap"between conceptual modelling and implementation constructs. Traditionally, systems analysismethodologies have been heavily influenced by software constructs, such as procedural programminglanguages and data structures. In contrast, a direct implementation of the model would provideimplementation primitives based on cognitive constructs. This may offer advantages such as greater easeof learning and using a system. In particular, an implementation may facilitate the creation of end-userdeveloped applications if users are able to build applications using constructs which parallel the way theyorganize knowledge about things in the domain. Appendix 1 hints at directions for implementation byinformally describing a number of operations to build and maintain a representation.Finally, the model suggests a number of guidelines for performing conceptual modelling: however,these do not yet constitute a coherent methodology or comprehensive set of instructions for using MIMICto represent knowledge. Such a methodology will be crucial for the success transfer of the model to202practical IS development applications. For example, although the notion of class structure providesminimal criteria evaluating the quality of a collection of potential classes, much work remains to be doneto provide further criteria for choosing among competing class structures Similarly, further research isneeded to determine a practical way of expressing behavioral knowledge.BIBLIOGRAPHYAbbott, R., "Knowledge Abstraction", Communications of the ACM, 30(8), August 1987, 664-671.Abrial, J., "Data Semantics", in J. Klimbie and K. Koffeman (eds.), Data Management Systems,Amsterdam: North-Holland, 1974, 1-59.Allen, J., "Maintaining Knowledge About Temporal Intervals", Communications of the ACM, 26(11),1983, 832-843.Allen, J., "Towards a General Theory of Action and Time", Artificial Intelligence, 23, 1984, 123-154.Armstrong, S., L. Gleitman and H. Gleitman, "What Some Concepts Might Not Be", Cognition, 13, 1983,263-308.Backus, J., "Can Programming be Liberated from the von Neumann Style?", A Functional Style and itsAlgebra", Communications of the ACM, 21(8), 1978, 613-641.Bailin, S., An Object-oriented Requirements Specification Method", Communications of the ACM, 32(5),May 1989, 618-623.Banerjee, J., H.-T. Chou, J. Garza, W. Kim, D. Woelk, N. Ballou, and H.-J. Kim, "Data Model Issues forObject-oriented Applications", ACM Transactions on Office Information Systems, 5(1), January1987, 3-26.Barsalou, L., "Context-independent and Context-dependent Information in Concepts", Memory andCognition, 10:1, 1982, 82-93.Berztiss, A., "The Set-Function Approach to Conceptual Modelling", in (011e et al., 1986), 107-144.Best, J., Cognitive Psychology, St. Paul, MN: West Publishing, 1986.Birtwistle, G., O. Dahl, B. Myhrhaug and K. Nygaard, SIMULA Begin, Philadelphia:Auerbach Press, 1973.Bobrow, D. and T. Winograd, "An Overview of KRL, A Knowledge Representation Language", CognitiveScience, 1(1), 1977, 3-46.Booch, G., Object-oriented Design with Applications, Redwood City, CA: Benjamin/Cummings, 1991.Borgida, A., "Features of Languages for the Development of Information Systems at the ConceptualLevel", in (Nixon, 1984), 21-57.Borgida, A., S. Greenspan, and J. Mylopoulos, "Knowledge Representation as the Basis for RequirementsSpecification", Computer, April 1985, 82-90.203204Borgida, A., M. Jarke, J. Mylopoulos, J. Schmidt, and Y. Vassiliou, "The Software Development Processas a Knowledge Base Management System", in J. Schmidt and C. Thanos (eds.), Knowledge BaseManagement Principles, Springer-Verlag, 1988.Bourne, L., B. Ekstrand and R. Dominowski, The Psychology of Thinking, Englewood Cliffs: Prentice-Hall, 1976.Bracchi, G., P. Paolini, and G. Pelagatti, "Binary Logical Associations in Data Modelling", in (Nijssen,1976), 125-148.Brachman, K. and J. Schmolze, "An Overview of the KL-ONE Knowledge Representation System",Cognitive Science, 9, 1985, 171-216.Brachman, R., "What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks",Computer, October 1983, 30-36.Brandt, I., "A Comparative Study of Information System Design Methodologies", in (011e et al., 1983),9-36.Bretl, R., D. Maier, A. Otis, J. Penney, B. Schuchardt, J. Stein, H. Williams and M. Williams, "TheGemStone Data Management System", in (Kim and Lochovsky, 1989), 283-308.Brodie, M., "On the Development of Data Models", in (Brodie et al., 1984), 19-47.Brodie, M. and E. Silva, "Active and Passive Component Modelling: ACM/PCM", in (011e et al., 1982),41-91.Brodie, M. and D. Ridjanovic, "On the Design and Specification of Database Transactions", in (Brodieet al., 1984), 277-306.Brodie, M., D. Ridjanovic, and E. Silva, "On a Framework for Information Systems DesignMethodologies", in (011e et al., 1983), 231-242.Brodie, M., J. Mylopoulos and J. Schmidt (eds.), On Conceptual Modelling, New York: Springer-Verlag,1984.Brooks, F., "No Silver Bullet: Essence and Accidents of Software Engineering", Computer, April 1987,10-19.Bruner, J., J. Goodnow and G. Austin, A Study of Thinking, Wiley: New York, 1956.Bubenko, J., "Information System Methodologies - A Research View", in (011e et al., 1986), 289-318.Bubenko, J., "Information Modelling in the Context of System Development", in S. Lavington (ed.),Information Processing 80, Amsterdam: North-Holland, 1980, 395-411.205Bunge, M., Treatise on Basic Philosophy (Volume 3), Ontology I: The Furniture of the World, Boston:Reidel, 1977.Bunge, M., Treatise on Basic Philosophy (Volume 4), Ontology II: A World of Systems, Boston: Reidel,1979.Chen, P., "The Entity-Relationship Model: Toward a Unified Model of Data", ACM Transactions onDatabase Systems, 1(1), March 1976, 9-36.Coad, P. and E. Yourdon, Object-oriented Analysis, Englewood Cliffs, NJ: Prentice-Hall, 1991.Collins, A. and E. Loftus, "A Spreading-Activation Theory of Semantic Processing", PsychologicalReview, 82(6) 1975, 407-428.Crutchfield, R., "The Creative Process", in M. Bloomberg (ed.), Creativity: Theory and Research, NewHaven, CT: College and University Press, 1973, 54-74.Davis, G. and M. Olson, Management Information Systems: Conceptual Foundations, Structure, andDevelopment, New York: McGraw-Hill, 1985.DeMarco, T., Structured Analysis and System Specification, New York: Yourdon Press, 1979.Digitalk, Smalltalk/V Mac Object-oriented Programming System, Los Angeles: Digitalk, Inc., 1989.Fikes, R. and T, Kehler, "The Role of Frame-based Representation in Reasoning", Communications of theACM, 28(9), September 1985, 904-920.Fishman, D., D. Beech, H. Cate, E. Chow, T. Connors, J. Davis, N. Derrett, C. Hoch, W. Kent, P.Lyngbaek, B. Mahmoud, M. Neimat, T. Ryan and W. Shan, "Iris: An Object-oriented DatabaseManagement System", ACM Transactions on Office Information Systems, 5(1), January 1987, 48-69.Floyd, C., "A Comparative Evaluation of System Development Methods", in (011e et al., 1986), 19-54.Gane, C. and T. Sarson, Structured Systems Analysis: Tools and Techniques, Englewood Cliffs, NJ:Prentice-Hall, 1979.Glass, A. and K. Holyoak, "Categorization", chapter 5 in Cognition, New York: Random House, 1986,149-180.Greenspan, S. and J. Mylopoulos, "A Knowledge Representation Approach to Software Engineering: TheTaxis Project", in (Nixon, 1984), 1-12.Goldberg, A., Smalltalk-80: The Interactive Programming Environment, Reading, MA: Addison-Wesley,1984.Goldberg, A. and D. Robson, Smalltalk-80: The Language, Reading, MA: Addison-Wesley, 1989.206Gustafson, M., T. Carlsson, and J. Bubenko, "A Declarative Approach to Conceptual InformationModelling", in (011e et al., 1982), 93-142.Hammer, R. and D. McLeod, "Database Description with SDM: A Semantic Database Model", ACMTransactions on Database Systems, 6(3), September 1981, 351-386.Haugeland, J. (ed.), Mind Design, Cambridge, MA: MIT Press, 1981.Henderson-Sellers, B. and J. Edwards, "The Object-oriented Systems Life Cycle", Communications of theACM, 33(9), September 1990, 142-159.Hornick, M. and S. Zdonik, "A Shared, Segmented Memory System for an Object-oriented Database",ACM Transactions on Office Information Systems, 5(1), January 1987, 70-95.Hull, R. and R. King, "Semantic Database Modelling: Survey, Applications, and Research Issues", ACMComputing Surveys, 19(3), September 1987, 201-260.Jackson, M., Systems Development, London: Prentice-Hall International, 1983.Keil, F., Conceptual and Semantic Development, Cambridge, MA: Harvard University Press, 1979.Keil, F., "The Acquisition of Natural Kinds and Artifact Terms", in W. Demopoulos and A. Marras (eds.),Language, Learning, and Concept Acquisition, Norwood, NJ: Ablex, 1986, 133-153.Kent, W., Data and Reality, New York: Elsevier, 1978.Kent, W., "Limitations of Record-based Information Models", ACM Transactions on Database Systems,4(1), March 1979, 107-131.Kerckhoffs, E., G. VanSkeenkiste and B. Zeigler (eds.), AI Applied to Simulation, San Diego: SCSSimulation Series, 18(1), 1986.Kerschberg, L. (ed.), Expert Database Systems: Proceedings from the First International Conference,Menlo Park, CA: Benjamin/Cummings, 1986.Khoshafian, S. and G. Copeland, "Object Identity", in (Meyrowitz, 1986), 406-416.Kim, W. and F. Lochovsky (eds.), Object-oriented Concepts, Databases and Applications, Reading, MA:Addison-Wesley, 1989.King, R., "My Cat is Object-oriented", in (Lochovsky and Kim, 1989), 23-31.King, R. and D. McLeod, "A Unified Model and Methodology for Conceptual Database Design", in(Brodie et al., 1984), 313-327.Kung, C., "An Analysis of Three Conceptual Models with Time Perspective", in (011e et al., 1983), 141-167.207Kung, C. and A. Solvberg, "Activity Modelling and Behavior Modelling", in (011e et al., 1986), 145-171.Lakoff, G., Women, Fire and Dangerous Things: What Categories Reveal About the Mind, Chicago:University of Chicago Press, 1987.Lieberman, H., "Using Prototypical Objects to Implement Shared Behavior in Object-oriented Systems",in (Meyrowitz, 1986), 214-223.Liskov, B and J. Guttag, Abstraction and Specification in Program Development, New York: McGraw-Hill, 1986.London, K., The People Side of Systems, New York: McGraw-Hill, 1976.Lyngbaek, P. and W. Kent, "A Data Modelling Methodology for the Design and Implementation ofInformation Systems", in K. Dittrich and U. Dayal (eds.), Proceedings of the 1986 InternationalWorkshop on Object-oriented Database Systems, Pacific Grove, CA: IEEE Press, 6-17.Mattessich, R., "Social and Physical Reality in Accounting: Onion Model vs. Pygmalion Syndrome",Working Paper, Faculty of Commerce and Business Administration, The University of BritishColumbia, 1989.McCloskey, M. and S. Glucksberg, "Natural Categories: Well-defined or Fuzzy Sets?", Memory andCognition, 6(1978), 462-472.McDermott, D., "A Temporal Logic for Reasoning About Processes and Plans", Cognitive Science, 6,1982, 101-155.McNeile, A., "Jackson System Development", in (011e et al., 1986), 225-246.Medin, D. and E. Smith, "Concepts and Concept Formation", Annual Review of Psychology, 35, 1984,113-138.Meyer, B., "Eiffel: An Introduction", TR-EI-3/61, Interactive Software Engineering, Inc., July 1989.Meyer, D., "On the Representation and Retrieval of Stored Semantic Information", Cognitive Psychology,1, 1970, 242-300.Meyrowitz, N. (ed.), OOPSLA' 86 Conference Proceedings, Sigplan Notices, 21(9), September 1986.Meyrowitz, N. (ed.), OOPSLA' 87 Conference Proceedings, Sigplan Notices, 22(12), December 1987.Meyrowitz, N. (ed.), OOPSLA' 88 Conference Proceedings, Sigplan Notices, 23(11), November 1988.Miller, G. and P. Johnson-Laird, Language and Perception, Cambridge, MA: Harvard University Press,1976.208Minsky, M. "A Framework for Representing Knowledge", in P. Winston (ed.), The Psychology ofComputer Vision, New York: McGraw-Hill, 1975, 211-275.Mylopoulos, J., "Object-orientation and Knowledge Representation", in D. Meersman and W. Kent (eds.),Object-Oriented Databases: Analysis, Design, and Construction, Amsterdam: North-Holland, 1990.Mylopoulos, J., "Conceptual Modelling and Telos", to appear in P. Loucopoulos and R. Zicari (eds.),Conceptual Modelling, Databases, and CASE: An Integrated View of Information SystemsDevelopment, New York: McGraw-Hill, 1991.Mylopoulos, J., P. Bernstein and H. Wong, "A Language Facility for Designing Data IntensiveApplications", ACM Transactions on Database Systems, 5(12), June 1980, 185-207.Mylopoulos, J., A. Borgida, M. Jarke, and M. Koubarakis, "Telos: A Language for RepresentingKnowledge about Information Systems", ACM Transactions on Information Systems, 8(4), October1990, 325-362.Newell, A. and H. Simon, Human Problem Solving, Englewood Cliffs: Prentice-Hall, 1972.Newell, A. and H. Simon, "Computer Science as Empirical Enquiry: Symbols and Search",Communications of the ACM, 19, March 1976, 113-126.Nierstrasz, 0., "What is the 'Object' in Object-oriented Programming?", in D. Tsichritzis (ed.), Objectsand Things, Centre Universitaire d'Informatique, University of Geneva, March 1987, 1-13.Nierstrasz, 0., "A Survey of Object-oriented Concepts", in (Kim and Lochovsky, 1989), 3-21.Nijssen, G., "A Gross Architecture for the Next Generation Database Management Systems", in G. Nijssen(ed.), Modelling in Database Management Systems, North-Holland, 1976, 1-24.Nixon, B. (ed.), Taxis' 84: Selected Papers, Technical Report CSRG-160, University of Toronto, June1984.Nygaard, K., "Basic Concepts in Object-oriented Programming", SIGPLAN Notices, 21(10), October 1986,128-132.Olive, A., "Analysis of Conceptual and Logical Models in Information Systems", in (011e et al., 1983),63-85.011e, T., H. Sol and A. Verrijn-Stuart (eds.), Information Systems Design Methodologies: A ComparativeReview, Amsterdam: North-Holland, 1982.011e, T., H. Sol and C. Tully (eds.), Information Systems Design Methodologies: A Feature Analysis,Amsterdam: North-Holland, 1983.209011e, T., H. Sol and A. Verrijn-Stuart (eds.), Information Systems Design Methodologies: Improving thePractice, Amsterdam: North-Holland, 1986.Osherson, D. and E. Smith, "On the Adequacy of Prototype Theory as a Theory of Concepts", Cognition,9, 1981, 35-58.Pascoe, G., "Elements of Object-oriented Programming", Byte, August 1986, 139-159.Peckham, J. and F. Maryanski, "Semantic Data Models", ACM Computing Surveys, 20(3), September1988, 153-189.Pernici, B., "Objects with Roles", in F. Lochovsky and R. Allen (eds.), Conference on InformationSystems, Cambridge, MA, April 1990, 205-215.Posner, M. and S. Keele, "On the Genesis of Abstract Ideas", Journal of Experimental Psychology, 77(3),1968, 353-363.Pressman, R., Software Engineering: A Practitioner' s Approach, New York: McGraw-Hill, 1987.Quillian, R., "Semantic Memory", in M. Minsky (ed.), Semantic Information Processing, Cambridge, MA:MIT Press, 1968.Reed, S., "Pattern Recognition and Categorization", Cognitive Psychology, 3, 1972, 382-407.Reiter, R., "Towards a Logical Reconstruction of Relational Database Theory", in (Brodie et al., 1984),191-233.Rentsch, T., "Object-oriented Programming", Sigplan Notices, 17(9), September 1982, 51-57.Richardson, J. and P. Schwarz, "Aspects: Extending Objects to Support Multiple, Independent Roles", inJ. Clifford and R. King (eds.), Proceedings of the 1991 International Conference on Managementof Data, SIGMOD RECORD, 20(2), June 1991, 298-307.Richter, G., "Clocks and their use for Time Modelling", in A. Sernadas, J. Bubenko, and A. Olive (eds.),Information Systems: Theoretical and Formal Aspects, Amsterdam: North-Holland, 1985, 49-66.Robson, D., "Object-oriented Software Systems", Byte, 6(8), August 1981, 74-86.Robson, D. and A. Goldberg, "The Smalltalk-80 System", Byte, 6(8), August 1981, 36-48.Rosch, E., "On the Internal Structure of Perceptual and Semantic Categories", in T. Moore (ed.), CognitiveDevelopment and the Acquisition of Language, New York: Academic Press, 1973, 111-144.Rosch, E., "Principles of Categorization", in E. Rosch and B. Lloyd (eds.), Cognition and Categorization,Hillsdale, NJ: Erlbaum, 1978, 27-48.210Rosch, E. and C. Mervis, "Family Resemblances: Studies in the Internal Structure of Categories",Cognitive Psychology, 7, 1975, 573-605.Roth, E. and E. Shoben, "The Effect of Context on the Structure of Categories", Cognitive Psychology,15, 1983, 346-378.Schank, R. and R. Abelson, Scripts, Plans, Goals and Understanding, Hillsdale, NJ: Erlbaum, 1971.Schiel, U., "The Time Dimension in Information Systems", in (Semadas et al., 1985), 67-76.Schmid, H., "An Analysis of Some Constructs for Conceptual Models", in G. Nijssen (ed.), Architectureand Models in Data Base Management, Amsterdam: North-Holland, 1977, 119-148.Schriver, B. and P. Wegner (eds.), Research Directions in Object-oriented Programming, Cambridge, MA:MIT Press, 1987.Sciore, E., "Object Specialization", ACM Transactions on Information Systems, 7(2), April 1989, 103-122.Shipman, D., "The Functional Data Model and the Data Language DAPLEX", ACM Transactions onDatabase Systems, 6(1), March 1981, 140-173Shoham, Y., Reasoning About Change: Time and Causation from the Standpoint of Artificial Intelligence,Cambridge, MA: MIT Press, 1988.Sibley, E., "The Evolution of Approaches to Information Systems Design Methodology", in (011e et al.,1986), 1-17.Sigplan Notices, Special Issue on the Object-oriented Programming Workshop at IBM Yorktown Heights,21(10), October 1986.Simon, H., Models of Thought, New Haven, CT: Yale University Press, 1979.Smith, E., "Theories of Semantic Memory", in W.K. Estes (ed.), Handbook of Learning and CognitiveProcesses, Vol. 6, Hillsdale, NJ: Erlbaum, 1978, 1-56.Smith, E., "Concepts and Thoughts", in R. Sternberg and E. Smith (eds.), The Psychology of HumanThought, Cambridge, MA: Cambridge University Press, 1988.Smith, E. and D. Medin, Categories and Concepts, Cambridge, MA: Harvard University Press, 1981.Smith, E., E. Shoben and L. Rips, "Structure and Process in Semantic Memory: A Featural Model forSemantic Decisions", Psychological Review, 81, 1974, 214-241.Smith, J. and D. Smith, "Database Abstractions: Aggregation and Generalization", ACM Transactions onDatabase Systems, 2(1), June 1977, 105-133.211Sol, H., "A Feature Analysis of Information Systems Design Methodologies: MethodologicalConsiderations", in (011e et al., 1983), 1-7.Stefik, M. and D. Bobrow, "Object-oriented Programming - Themes and Variations", AI Magazine, 6(4),Winter 1986, 40-62.Stoyan, H., "What is an 'Object-oriented' Programming Language?", in J. Fry, R. Panko and R. Sprague(eds.), Proceedings of the Seventeenth Annual Hawaii International Conference on SystemsSciences, Volume I, 1984, 152-162.Stroustrup, B., "What is 'Object-oriented Programming"?", in J. Bezevin, J.-M. Hullot, P. Cointe and H.Lieberman (eds.), ECOOP' 87 Proceedings, Lecture Notes in Computer Science, 276, New York:Springer-Verlag, 1987, 51-70.Su, S., "SAM*: A Semantic Association Model for Corporate and Scientific Statistical Databases",Information Science, 29, 1983, 151-199.Takagaki, K., A Formalism for Object-based Information Systems Development, Unpublished Ph.D.Dissertation, Faculty of Commerce and Business Administration, The University of BritishColumbia, Vancouver, Canada, March 1990.Takagaki, K. and Y. Wand, "An Object-oriented Information Systems Model Based on Ontology", in F.Van Assche, B. Moulin, and C. Rolland (eds.), Proceedings of the IFIP 8.1 Working Conferenceon the Object Oriented Approach in Information Systems, Quebec City, Canada, 1991, 275-296.Teorey, T., Y. Yang and J. Fry, "A Logical Design Methodology for Relational Databases Using theExtended Entity-Relationship Model", ACM Computing Surveys, 18(2), June 1986.Tsichritzis, D. and F. Lochovsky, Data Models, Englewood Cliffs: Prentice hall, 1982.Tversky, A. and D. Kahneman, "Judgment Under Uncertainty: Heuristics and Biases", Science, 185, 1974,1124-1131.Verheijen, G. and J. Van Bekkum, "NIAM: An Information Analysis Method", in (011e et al., 1982), 536-589.Wand, Y., "A Proposal for a Formal Model of Objects", Chapter 21 in (Kim and Lochovsky, 1989), 537-559.Wand, Y. and R. Weber, "An Ontological Analysis of Some Fundamental Information Systems Concepts",Proceedings of the Ninth International Conference on Information Systems, Minneapolis,December 1988, 213-225.Wand, Y. and R. Weber, "An Ontological Evaluation of Systems Analysis and Design Methods", in E.Falkenberg and P. Lindgren (eds.), Information Systems Concepts: An In-depth Analysis,Amsterdam: North-Holland, 1989, 79-107.212Wasserman, A., P. Freedman and M. Morcella, "Characteristics of Software Development Methodologies",in (One et al., 1983), 37-62.Wegner, P., "Dimensions of Object-based Language Design", in (Meyrowitz, 1987), 168-182.Winograd, T. and F. Flores, Understanding Computers and Cognition, Reading, MA: Addison-Wesley,1987.Wirfs-Brock, R. and R. Johnson, "Surveying Current Research in Object-oriented Design",Communications of the ACM, 33(9), September 1990, 104-124.Wittgenstein, L., Philosophical Investigations, translated by G.E.M. Anscombe, New York: MacMillan,1958.APPENDIX 1MODELLING AN EXAMPLE WITH MIMICA.1 INTRODUCTIONThis appendix presents a small example which demonstrates the constructs of MIMIC. Elementsof the problem are introduced gradually to illustrate different components of the model in succession. Theexample is taken from the banking industry and considers the activities of a branch of a commercial bankin the provision of some services to individual (as opposed to corporate) customers. The description isnot intended to be complete, or necessarily representative of any specific bank. Instead, the aim is toshow how knowledge about important entities, such as customers and accounts, is represented usingMIMIC, and to highlight some of the important activities in maintaining knowledge about these entities.In addition to considering transaction processing applications, support for simulation and reasoningactivities is briefly illustrated in order to demonstrate the usefulness of the model across several kinds ofapplications.In order to construct the example and illustrate the features of MIMIC, it is necessary to firstdefine a number of operations to create instances of the basic constructs of the model (e.g., objects,attributes, classes). These will be used to create and maintain a representation of the problem domain.For ease of reference, the next section restates the constructs of MIMIC. Section A.3 then describes theoperations needed to create a specific representation. Section A.4 demonstrates how the operations areused to develop a representation of the banking example. Finally, Section A.5 describes how the modeluniformly supports representations across several kinds of applications.A.2 REVIEW OF MIMIC CONSTRUCTSMIMIC consists of a number of constructs which correspond to elements of the classical theoryof concepts. The fundamental constructs in MIMIC are objects and attributes. An object is a surrogateor symbol designating the existence of an instance of a concept. Attributes are divided into three kinds.A (simple)142 structural attribute represents a (simple) structural property, and consists of a set offunctions mapping from a common set of objects to a common set of values. A (simple) n-ary relationalattribute represents a (simple) n-ary relational property, and consists of a set of functions mapping froma common set of objects to the power set of the Cartesian product of n-1 other sets of objects. Abehavioral attribute represents a behavioral property and consists of a function whose domain is (thecross-product of) one (or more) structural/relational attributes and codomain is the power set of thedomain. Behavioral attributes specify allowed events (changes in the active functions of thestructural/relational attributes involved). Events cause the state of a representation to change to reflectchanges in the state of knowledge about the domain. MIMIC further recognizes that objects may acquireand lose attributes through the notions of domain expansion and domain contraction, in which objectsare added to and removed from, respectively, the domain of a structural or relational attribute.The model also provides for the organization of knowledge through classes. A potential classrepresents a potential concept and consists of a set of structural/relational attributes with a non-emptycommon domain. A class structure is a collection of potential classes for which every attribute of interest'The model also defines composite attributes.213214belongs to at least one class, and in which no class is simply the union of the attributes of other classesin the structure.Given these modelling mechanisms, the objective of this appendix is to show how they can beused to develop a representation of knowledge about a specific problem. In order to do this, however,it is necessary to first define a number of operations which enable objects, attributes, classes, and so on,to be constructed and which allow the state of a description to change in accordance with changes in thestate of knowledge about the application.A.3 OPERATIONS TO CONSTRUCT A REPRESENTATIONThe MIMIC model consists of a number of constructs for describing the state of knowledge aboutan application, and for constraining how states may change. However, in order to represent a specificinstance (e.g., the banking example mentioned in the introduction), operations are needed to createobjects, attributes, and classes - and to allow states to be modified. In what follows, the operations aredescribed by first giving a simple syntax, then listing the conditions that must hold in order for theoperation to occur (pre-conditions), and finally describing the consequences of the operation (effects).Since the objective of this exposition is simply to illustrate the use of MIMIC, the operations aredefined in a somewhat informal manner. Consequently, although they provide a basic foundation for afuture implementation of the model, they are not described with the object of providing a detailedblueprint for implementation. Furthermore, the focus here is only on mechanisms for constructing arepresentation and allowing its state to change. An implementation would obviously have to also provideadditional mechanisms for querying a representation to extract information from it.A.3.1 Creating Objects 143The object is the basic element in a representation created using MIMIC. Objects are simplysurrogates which designate the existence of instances of concepts. In constructing an example, objectsmust be created to represent the instances of concepts that are of interest. The operation to do this iscalled MAKEOBJECT. Let 0 designate the set of objects in the representation (i.e, that have alreadybeen created: initially, 0 = }), and o designate an arbitrary symbol.Syntax MAKEOBJECT(o)Pre-condition oe 0 (the object has not already been created)143The model also uses the notion of values. Since values are based on notions such as characters andnumbers, they can be assumed to be supported in any environment. Hence, it adds nothing to thediscussion here to consider operations for creating values.215Effect0^Ou{o} (the object is added to the existing set of objects)This operation can be used to create both simple and composite objects, since there is norestriction on the nature of the surrogates. Specifically, a surrogate in 0 could be a concatenation of otherelements of 0, in which case, it would be a composite object. However, to keep the discussion moremanageable, the notions of composite objects, attributes, and classes will not be considered in detail.Note that a more complex operation could be considered here, in which objects are classified asthey are created (e.g., MAKEOBJECT(o,C), where C designates the name of a class, but not necessarilythe only one, to which the object is assigned). This presupposes that all objects will be classified whencreated and that classes are defined before objects are created. However, rather than explicitly treatclassification as part of the MAKEOBJECT operation, it will be considered through the assignment ofattributes to objects and the creation of classes.A.3.2 Creating AttributesThe creation of objects simply reflects knowledge of the existence of things. However, it isequally important to be able to describe properties of things. Therefore, operations are needed to createattributes. These are divided into operations for creating structural, relational, and behavioral attributes.The operation to create a structural attribute is called MAKESTRUC. The purpose of theoperation is to create a table designating (the active function of) a structural attribute'. Let S u and Scdesignate the sets of (the active functions of) all unchangeable and changeable (respectively) structuralattributes that have been created (initially Su={ }, Sc= { }), and 0 designate the set of all objects created.Let s = ko i,vi> i=1 ,...,1) denote a set of I object-value pairsi45, and type denote a variable which canassume one of two values: u (for unchangeable) and c (for changeable) 146 .SyntaxMAKESTRUC(s,type)"Since a structural attribute is defined in MIMIC as a set of functions, more is needed before themeaning of a changeable structural attribute (whose size is greater than one) is fully operationalized. Thisis handled later in the discussion of behavior. In other words, the set of functions defining a structuralattribute is not enumerated when the attribute is created using the MAKESTRUC operation, unless theattribute is unchangeable (e.g., Birthdate).145The active function of an attribute is referred to using a lower case letter (s), while the upper caseequivalent (S) will be used to refer to the attribute more generally as a set of functions."The distinction between changeable and unchangeable attributes is made explicit here since anoperation to construct an attribute creates only the active function. Unless the attributes are subdividedinto those which may and may not change, there is no immediate way of determining whether an attributesvalues may vary over time. The distinction was not needed in developing the model in Chapter 4 since,at that level, the "changeability" of an attribute is implicit in the number of functions in the set.216Preconditions O iE 0 i=1,...,I (each first element of the pairs in s is an existing object)o i#0,, V i,JE I, i#j (no object appears in two pairs, so that s is a function)Effect If type=u, Su^Suu{ s } (function is added to the existing set of unchangeable structural attributes)If type=c,^Scu{s} (function is added to the existing set of active functions of changeable attributes)In this operation, the (active) function is expressed as a set of pairs, where the og' s jointlyconstitute the domain of the attribute. The MAKESTRUC operation provides for the creation of simpleor composite structural attributes.The operation to create a relational attribute is called MAKEREL. The purpose of the operationis to create a table designating the active function of a relational attribute (see Footnote 144). Let R u andRc designate the sets of (the active functions of) all unchangeable and changeable (respectively) relationalattributes that have been created (initially Ru= { } , Rc={ }), and 0 designate the set of all objects created.Let r = {<01002i_> ,/} a set of I object-objectaip rs147, and type denote a variable which can assumeone of two values: u (for unchangeable) and c (for changeable).Syntax MAKEREL(r,type)Preconditiono 1i ,o2iE 0, i=1,...,I (the objects involved have already been created)V i,jE I, i#j (no object appears as the first element in two pairs, so that r is a function)Effect If type=u, Ru^Ruu{r} (function is added to the existing set of unchangeable relational attributes)If type=c, Rc Rcu{r} (function is added to the existing set of active functions of changeable attributes)As already noted, the operations do not allow the meaning of structural and relational attributesto be fully captured, since attributes are formally defined in MIMIC as sets of functions. However, thesesets can be characterized implicitly by providing an operation for defining behavioral attributes. Thisoperation is called MAKEBEH. Behavioral attributes constrain events (changes in active function), andwill be expressed here using sentences in first-order predicate logic. Let F denote a formula of the form:147This applies to binary attributes. For n-ary relational attributes, the second element of each pair isa set of n-1 objects.217F: <pi ,p2> := a sentence in first order logic,where p i and p2 denote functions in an attribute P. This interpreted to mean that a direct transition in theactive function of P from p i to p2 is permitted only if the sentence to the right of ":=" is true whenevaluated'''. Let F denote the set of formulas that have been created (initially F = ( )).As an illustration, suppose that an attribute Age is defined as the set of functions, Age =The behavioral constraint may be expressed as:F: <apai> := V of 0 1 , ai(o)= ai(o)+1 (where O lc_0).This means that an event <a i ,ai> (i,je 1,...,K), i#j) can occur only if F is true when evaluated usingfunctions a ; and aj (i.e., ages change in increments of one unit). In F, a i and aj are variables for whichthe specific functions involved in an event (e.g., a 2, a8) are substituted in determining if the event ispermissible (events are discussed in more detail in Section A.3.4).Syntax MAKEBEH(F)PreconditionEach term in F refers to one or more structural/relational attributes (so that the truth of the sentence isdetermined by the active functions of these structural and relational attributes) 149EffectF Fu{F}The MAKEBEH operation establishes F as a logical constraint (or pre-condition) on events. Thatis, no event may occur if it violates F. Note that the operation to create F's does not decide whether thesentence is a "good" description of knowledge about behavior. That is the job of the analyst.A behavioral attribute is formally defined in MIMIC as a function. The operationalization abovecan be given such a functional interpretation. Specifically, if p i and pi denote functions in astructural/relational attribute P=Ip 1 ,p2,...,p0, PP E b(p) (or <pi ,pi> is possible) if and only if F is true whenevaluated with respect to a specific p i ,pie P (where b denotes the behavioral attribute function). In otherwords, F implicitly describes (but does not enumerate) the function b that constitutes a behavioralattribute.148This does not mean that an indirect transition from p i to p2 is prohibited (e.g., p i -* p3^1)8 -3 p2)•149This is left somewhat vague. The meaning becomes clearer when specific examples are consideredin Section A.4.218A.33 Creating ClassesThus far, operations have been defined to create objects and attributes. The MIMIC model alsoprovides for the organization of knowledge through classes. Consequently, an operation is needed toconstruct classes by aggregating attributes. This operation is called MAKECLASS. Its purpose is toestablish a collection of attributes as a class. Moreover, the operation explicitly places a new class in anexisting class lattice (which is expressed as a graph).In the following, S=SuuSc and R=RuuRc. Let C designate the existing set of classes (initiallyC=0), denote the active functions of structural/relational attributes P 1 ,..,PN, and G =f<C 1 i,C21> i=1 ,....1 1 denote a class lattice (initially G={ }). G is interpreted to mean that C 11 is a subclass ofC2; (i=1,...,1). Let dom(p°) denote the domain of attribute p° (i.e., the set of first elements of the pairs inpn)150 .Syntax MAKECLASS(Cs ,p 1 ,...,pN) (Cs is a symbol designating the new class name)Preconditions p 1 ,...,pN exist: that is, each p° belongs to S or R (the sets containing the active functions of existingstructural and relational attributes, respectively)dom(p 1)n...ndom(pN)#0 (the class has a non-empty extension)0 ps ,^SuR and p so {p 1 ,...,pN}, such that dom(p s)Ddom(p l)n...ndom(pN) (the class contains all attributespossessed by all members)0 a subset of classes {C 1 ,...,CK} of C such that ok=1,..,KCk =^(the class is not simply theaggregation of attributes of some subset of existing classes)Effects Cs^{p l ,...,ps }C Cu{Cs }For each CE C such that CcC * , <C s,C> is added to GFor each Cc C such that C *cC, <C,C s> is added to GThis operation both creates classes and adds them explicitly to the class lattice. Since the latteris implied when is a class is defined anyway, it need not be listed as an effect, but is included here to150Some liberty is taken here in reference to attribute names and symbols designating the activefunctions of the attributes (P's versus p's). Hence, dom(p°) could equally well be written dom(P°). TheMAKECLASS operation applies to the attributes, which initially are "known" only in terms of the activefunctions.219improve clarity.Each class created using the MAKECLASS operation is a potential class in the sense used inChapter 4. In addition, the constraint that the collection of classes constitute a class structure can beimposed by requiring that the operation be repeated until all attributes that are defined are assigned to atleast one class. This exposition assumes that all attributes are defined before any classes are. In practice,there may be some iteration between defining objects, attributes, and classes. In that case, an operationmay be needed to add newly defined attributes to a class. Since that issue depends on the approach takenin analyzing a problem, it is not pursued here.In practice, it will also be necessary to define operations to "destroy" objects or remove them fromthe representation. Since the interest here is only in showing how a representation may be created, suchoperations are not discussed.A.3.4 Supporting ChangeA representation, once created, is useful only if it changes to reflect changes in the state ofknowledge about the domain. Two kinds of change are relevant here. First, objects may acquire and loseattributes. Consequently, objects will have to be added to the domain of attributes. The operation toachieve this is called DOMEXP. Likewise, objects will have to be removed from the domain ofattributes. The operation to achieve this is called DOMCON. The second kind of change involveschanges of state that occur when objects take on new values for structural or relational attributes. Thesechanges will be effected through MAKEVENT operations.Domain expansion is operationalized as follows. Let p denote the active function of a structuralor relational attribute P, P denote the set of (the active functions of) all existing structural/relationalattributes, and A denote a non-empty set of I pairs f<o i,x i> i=1 ,...,1 1, where the xi 's are either values (if pbelongs to a structural attribute) or sets of objects (if p belongs to a relational attribute). The DOMEXPoperation adds I pairs to the active function of an attribute.SyntaxDOMEXP(p,A)Pre-conditions pc Po ic 0, i= 1,...,IThe 'Vs do not belong to any pairs in pEffectp puAUsing this framework, an object could join a class by a series of DOMEXP operations, one foreach attribute defining the class which was not previously possessed by the object (e.g., a PERSON maybecome an EMPLOYEE by acquiring the added attributes which define EMPLOYEE).The DOMCON operation has the opposite effect of DOMEXP. It removes one or more pairs220from the active function of an attribute, reflecting that the objects involved lose the attribute in question.Let p denote the active function of a structural/relational attribute P (i.e., p is a set of object-value pairs),dom(p) denote the domain of p, and A a non-empty set of I objects {o 1 ,...,o1 }.SyntaxDOMCON(p,A)Pre-condition o ic dom(p), i=1,...,IEffect p = p-^(the xi 's are values or sets of objects associated with the objects being removed)Next, the notion of an event is operationalized to provide a mechanism for changing the state ofa representation. The operation MAKEVENT is defined as a state change generator. Unlike operationsto create objects, attributes, and classes, MAKEVENT is not used in creating an initial representation, butis used to maintain the state of the representation as changes occur in the domain.In MIMIC, an event changes the active function of one or more structural/relational attributes.For simplicity, the operation is characterized here in terms of one attribute only. More complex changescan be constructed using a series of these simpler MAKEVENT operations. Let p designate the activefunction of an existing structural/relational attribute P, dom(p) denote the domain of p, Pc denote the setof all changeable structural/relational attributes, and E a set of I pairs {<o i,xi> i=1 ,...a}, where the x i 's areeither values (if p belongs to a structural attribute) or sets of objects (if p belongs to a relational attribute).Let p' designate the function formed by replacing each pair in p which has the same first element as a pairin E (i.e., an o) with the corresponding pair in E (i.e., <o i ,xi>).Syntax MAKEVENT(p,E)Preconditions O IE dom(p), i=1,...,Ipc Pc (the attribute is changeable)For each FE F (i.e., each behavioral attribute), F is true when p and p' are "substituted" into FEffectp' replaces p as the active function of PTo illustrate this, suppose p = ko 1 ,y 1>,<o2,v2>1 and E = {<o2 ,v3>}. The operationMAKEVENT(P,E) produces:221p' = {<o 1 ,v 1 >,<o2 ,v3>}which becomes the new active function of P. The event can then be designated <p,p'>.Using this notion of event, it is now possible to see how the logical sentence F, which expressesa behavioral attribute, implicitly describes the set of pairs (i.e., the function) that is a behavioral attribute,and also determines the set of functions that constitutes a structural or relational attribute. In effect, Fdetermines a set of pairs {<P,{Pj}ieJi>icr} (where j=1,...,IJ i1 for each i). The set of pairs is a function(where p and the pa 's denote active functions before and after a MAKEVENT operation, respectively).This means that an event <p,p'> can occur only if there is a pair <p,{...,p',...}> in the functional equivalentof F.The set of functions constituting the attribute P, then, is the set of all functions which appear(again, this is implicit) in F (in the above case, D^D1 9 • • •^•This concludes the description of the basic operations needed to create and maintain arepresentation. Note that the operations are intended to be used at the object level first, while the"schema" (consisting of attributes and classes) is created later (since attributes presuppose objects andclasses presuppose attributes). The next section shows how these are used to create a representation ofknowledge about things in a banking environment, which provides the basis for several kinds ofinformation systems. In building the example, objects are first created, then attributes and classes.A.4 CONSTRUCTING THE EXAMPLEA.4.1 OverviewThe subject matter of the representation constructed here is a bank. Attention is focused on theobjects of interest, such as customers, employees, accounts, and loans. In addition, the effect of eventson the state of objects is demonstrated by looking at changes that result from withdrawals from accounts.The exposition here is partial in two senses. First, only enough detail is given to illustrate how theoperations defined in Section A.3 are used to create a representation of domain knowledge. Second, onlya few instances are considered when, in reality, a bank would have many more.A.4.2 ObjectsObjects are created to represent the existence of instances of concepts. The major concepts ofinterest here include persons, customers, employees, various kinds of accounts, and loans. These termsare used very loosely at this point so that the reader gains an informal idea of the "kinds" of objects thatare being created. While users might, in practice, identify classes of objects before indicating specificinstances, the presentation here will begin by creating objects and attributes since classes can only bedefined when these are determined. Definitions of classes (in terms of the attributes they possess) aregiven in Section A.4.4, and give formality to terms such as customer and savings account.On examining this hypothetical subject matter, a number of instances are identified. These includethe persons John, Mary, Jane, Bill, Sally, Frank. Objects to represent instances are created through aseries of MAKEOBJECT operations. Initially, 0={ } (the set of objects is empty). From this startingpoint222MAKEOBJECT(John) results in 0 = {John} 151 ,MAKEOBJECT(Mary) results in 0 = {John, Mary},and so on. After repeating the operation four more times0 = {John, Mary, Jane, Bill, Sally, Frank}.Other objects to be created represent instances of accounts and loans. The objects are createdthrough repeated MAKEOBJECT operations. Eventually, the set of objects is as follows:0 = {John,Mary,Jane,Bill,Frank,S100,S101,S102,S103,S104,C200,C2014301,L302,1303}Note that no mention has been made of the attributes possessed by the objects, and only very intuitivereference to "classes" such as person. In practice, the analyst would probably acquire information aboutclasses, attributes, and objects in an iterative and interactive manner.A.4.3 AttributesThe objects of interest each possess a number of attributes. Once the objects are created, it ispossible to create the attributes they possess. For example, a Name attribute is constructed as follows.Let Name denote the set{<.John,' John Doe'>, <Mary, 'Mary Williams'>, <Jane,'Jane Doe'>, <Bill, 'Bill Wilson'>,<Sally, 'Sally Smith'>, <Frank, 'Frank Stokes'>}.Name is created as a changeable structural attribute using the MAKESTRUC operation. Initially, S c= { }(the set of active functions of changeable structural attributes is initially empty). Performing the operationMAKESTRUC(Name,c) results in S c = {Name}.The operation is repeated to create a number of other structural attributes: Address, Birthdate,Experience, Balance, Interest_rate_paid, Term, Principal, and so on. Each time the operation invoked,a new function is added to either the set Sc or Su. For example, Birthdate is added to Su. Initial activefunctions of several of the attributes listed above are shown next using a tabular representation 152 .Performing the MAKESTRUC operation on each of these functions producesSc = (Name, Address, Experience, Balance, Interest_rate_paid, ...),Su = {Birthdate, Principal, Term, ...}.151Throughout this example, objects will be designated by italicized words.152These active functions will, in the case of changeable attributes, be replaced by new ones as eventsoccur (see Section A.4.6).AddressJohn 123 Main StreetMary 456 Walnut CrescentJane 123 Main StreetBill 456 Walnut CrescentSally 789 Crabtree RoadFrank 159 Maple DriveExperienceJohn 7Mary 25Sally 2BalanceS100 500S101 100S102 250S103 1000S104 10000C200 10C201 150BirthdateJohn 19 09 1950Mary 03 12 1963Jane 15 05 1948Bill 16 09 1960Sally 21 04 1965Frank 27 06 1970223Note that these attributes do not all share the same domain. This is relevant to the definition of classesthat is given later.224Objects also possess relational attributes linking them to other objects. For example, a Spouseattribute is constructed using:MAKEREL(Spouse,c), whereSpouse = {<John, Jane>, <Mary, Bill>, <Jane, John>, <Bill, Mary>, <Sally, Nil>, <Frank, Nil>}.Since initially Rc= { } and RU={ } , MAKEREL(Spouse) results in R c = {Spouse). The MAKERELoperation can be repeated to create the active functions of other relational attributes, including Holds,Handles, and Held_by. These are listed below in tabular form.HoldsJohn {S100, C200 L301)Mary {S101, 5102}Bill {S103,C201}Sally {L302}Frank {S104,L303}HandlesJohn {S101, S102, S103, S104, C201}Mary {L301, L302, L303}Sally {S100, S101, S102, S103, S104,C200, C201}Held_byS100 JohnS101 MaryS102 MaryS103 BillS104 FrankC200 JohnC201 BillL301 JohnL302 SallyL303 Frank225Repeating the MAKESTRUC operation for these functions results inRc = (Spouse, Holds, Handles, ...), andRu = {Held_by,... ) .There are also a number of behavioral constraints, associated with the structural/relationalattributes listed above, which restrict allowed changes in active functions. Some restrictions representlogically necessary constraints (e.g., changes to years of experience must follow a pattern of incrementsby one). Others may be viewed as corresponding to "business rules" of the organization. That is, theyreflect conventions by which the bank conducts its activity (e.g., maximum withdrawals without priornotice on savings accounts).Behavioral attributes are created using the MAKEBEH operation. Let F denote the set ofrestrictions that have been created. Initially, F=0. Behavioral constraints are created by invokingMAKEBEH.In order to identify behavioral attributes, it is useful to look at structural/relational attributes, andthe restrictions on changes to their active functions. For example, the attributes Name and Address haveno general restrictions. That is, it is assumed that any string (of a "reasonable" length) may serve as thevalue of Name(o) or Address(o) for an object of 0, and that changes of Name and Address areunrestricted. On the other hand, Birthdate contains a single function. Hence, there are no behavioralattributes, as the notion of a change in the active function is undefined.There is, however, an assumed restriction on changes to the active function of Spouse. A personwho has a spouse will, after an event involving a change in the active function of Spouse, either have thesame spouse or have no spouse. That is, a married person cannot have another spouse without first beingin a state of having no spouse.This restriction is expressed more precisely as a constraint on changes to the active function ofSpouse. Letting:si designate the active function of Spouse,s2 designate another function of Spouse (s 2 and s2 are variable here), anddom(Spouse) designate the domain of Spouse,the restriction is:F1 : <s 1 ,s2> := V x,ye dom(Spouse) (x#37), s 1 (x) = y^s2(x) = y v s2(x) = Nil.The behavioral constraint is created by invoking the operationMAKEBEH(F 1 ).Since initially F={ ) (the set of behavioral constraints is empty), MAKEBEH(F 1) results in F = (Fii•If an event <s l ,s2> (a change in the active function of Spouse brought on by invoking aMAKEVENT operation as described in Section A.4.6) satisfies this disjunctive condition, it is a permittedevent.Similarly, for the structural attribute Experience, there is the obvious restriction that changes inyears of experience for an employee occur in increments of 1. The constraints will not be listed for allattributes here. However, as a further illustration, a constraint on changes to the structural attributeBalance is detailed. Assume that a customer may withdraw no more than the greater of $1,000 (or the226account balance, if less than $1000) or 50% of the account balance of a savings account in a singletransaction. Although such a constraint may appear somewhat artificial, it does resemble commonly usedrestrictions on withdrawals made without advanced notice. Letting:b 1 denote the active function of Balance,b2 denote another function of Balance, anddom(Balance) designate the domain of Balance,the constraint is:F2 : <b 1 ,b2> := V XE dom(Balance), b2(x) min {max { b i (x)-1000,0},0.5*b l (x) } .The constraint is imposed by performing MAKEBEH(F2), which results in F = {F I ,F2 }. Theoperation is repeated for each of the behavioral constraints identified in the analysis, resulting in a set ofrestrictions F = {F 1 , F2 ,...}.A.4.4 ClassesOnce all structural, relational, and behavioral attributes of interest have been created, groupingsof attributes can be formed to define classes. To this point in the example, only vague reference has beenmade to the fact that objects are of various kinds (customers, accounts, etc.). The MAKECLASSoperation introduced in Section A.3 allows a class to be formally defined as a set of attributes.The first class defined here is PERSON. Let C denote the set of classes and G the class lattice.Initially, C={ } and G={ }. PERSON is determined to consist of the attributes Name, Address, Birthdate,and Spouse. The operation to define the class is:MAKECLASS(PERSON, Name, Address, Birthdate, Spouse).The results are that PERSON = {Name, Address, Birthdate, Spouse} and C = {PERSON}. Nothing isadded to G at this point (the lattice is simply a single node). Next, the class CUSTOMER is created byinvokingMAKECLASS(CUSTOMER, Name, Address, Birthdate, Spouse, Holds),resulting inCUSTOMER = {Name, Address, Birthdate, Spouse, Holds}C = {PERSON, CUSTOMER}G = <CUSTOMER,PERSON>} .Next, the class EMPLOYEE is defined by invokingMAKECLASS(EMPLOYEE, Name, Address, Birthdate, Spouse, Experience, Handles)resulting in227EMPLOYEE = (Name, Address, Birthdate, Spouse, Experience, Handles)C = (PERSON, CUSTOMER, EMPLOYEE)G = {<CUSTOMER,PERSON>, <EMPLOYEE, PERSON>}.Note that if the operation MAKECLASS(CUSTEMP, Name, Address, Birthdate, Spouse, Holds,Experience, Handles) is attempted in order to define a class CUSTEMP as a subclass of both CUSTOMERand EMPLOYEE, it violates the precondition (of MAKECLASS) that a class cannot simply be the unionof the attributes of existing classes. Therefore, the operation would not be performed unless additionalattributes were specified as parameters.The operation can be repeated to create the remaining classes of interest, including PRODUCT,LOAN, ACCOUNT, SAVING, CHEQUING, and so on. For a quick summary, the operations to createthese classes are shown below, and the final contents of C and G are indicated. Some attributes whichare listed were not described among the attributes mentioned earlier in explaining attribute creation.MAKECLASS(PRODUCT,Held_by)MAKECLASS(ACCOUNT,Held_by,Balance)MAKECLASS(CHEQUING,Held_by,Balance,Overdraft,Issued_cheques)MAKECLASS(SAVING,Held_by,Balance,Interest_rate_paid)MAKECLASS(LOAN,Held_by,Interest_rate _charged,Term,Principal,Remaining_balance)When these operations are performed, the result is:C = {PERS ON,CUSTOMER,EMPLOYEE,PRODUCT,ACCOUNT,CHEQUING,SAVING,LOAN}G = {<CUSTOMER,PERS ON>, <EMPLOYEE,PERSON>, <ACCOUNT,PRODUCT>,<LOAN,PRODUCT>, <CHEQUING,ACCOUNT>,<SAVING,ACCOUNT> } 153.A.4.5 Domain ChangesThe representation thus far is static. To be useful, it must change to reflect changing knowledge.One way that knowledge changes is through the recognition and classification of new instances. TheMAKEOBJECT operation allows new objects to be created, while the DOMEXP operation allows newobjects to be added to the domain of existing attributes. For example, suppose that an object Dave iscreated using MAKEOBJECT, and that the object is required to possess the attributes Name, Address,Birthdate, Spouse, Holds. If the object Dave is to be assigned the value 'Dave Parsons' for the attributeName, the attribute is updated by invokingDOMEXP(Name, { <Dave, 'Dave Parsons'>).As a result of this operation, the Name attribute is:153The lattice here is actually two disjoint lattices, since no persons are products.228NameJohn John DoeMary Mary WilliamsJane Jane DoeBill Bill WilliamsSally Sally SmithFrank Frank StokesDave Dave ParsonsThe DOMEXP operation can be repeated for each of the other attributes possessed by Dave,adding a row to the active functions of each. When Dave is added to the domain of these attributes, theobject is implicitly classified as a CUSTOMER (and a PERSON) since it possesses the attributes definingboth classes.Similarly, objects may be removed from the representation to reflect that instances no longer existfrom the point of view of the application. For example, if Sally pays off the loan she holds, she may nolonger be considered a CUSTOMER. The operationDOMCON(Holds, {Sally})removes the pair <Sally, {L302}> from the active function of Holds, resulting inHoldsJohn (S100, C200 L301)Mary (S101, S102)Bill {S103, C201}Frank (S104, L303)Note that this means that Sally is no longer a CUSTOMER, but remains in the representation as aPERSON. If, for example, the person Sally dies, further DOMCON operations would be required toremove the object Sally from the domain of the attributes Name, Address, Birthdate, Spouse.A.4.6 EventsA banking environment produces a variety of changes that must be tracked. For example, thereare changes to CUSTOMER attributes such as Address and Holds. A significant group of changes invalues are those to account balances brought on by deposits to and withdrawals from accounts. Forexample, suppose that the active function of the attribute Balance (of ACCOUNT) is:229b1S100 500S101 100S102 250S103 1000S104 10000C200 10C201 150Any changes to the active function must satisfy the behavioral constraint given earlier:F2: <b1,b2> := V XE dom(Balance), b2(x) min {max { b i (x)-1000,0 } ,0.5*b i (x) } •Changes are brought about by invoking the MAKEVENT operation. Two examples are considered here.In the first, the event is permitted as it does not violate F2. In the second, the event is denied as it violatesF2.Example 1 A withdrawal of $350 is attempted from account 5100 (which has a current balance of $500).Using the notation introduced in Section A.3, E = {<S100,150>}. The operationMAKEVENT(130 1 ,E)is invoked in order to create the event. However, in order for the event to be created, it must satisfyF2: <b1,b2> := V xe SAVING, b2(x) minfmax{b 1(x)-1000,0},0.5*b 1(x)},where b1 is the table listed above and b 2 is the function produced by replacing the row <S100, 500> inb 1 with <S100, 150>. Since this condition is satisfied if the MAKEVENT operation succeeds, theoperation takes place and b2 becomes the active function of Balance.Example 2 A withdrawal of $6000 is requested from account 5104, so that E = {<S104,4000>}. Theoperation MAKEVENT(b 1 ,E) is invoked in order to create the event. However, since b 2 is the functionproduced by replacing the row <S104,10000> in b 1 with <S104, 4000>, the change would violate F2.Consequently, a precondition of the MAKEVENT operation is not met and the operation does notsucceed.In Chapter 5 (Section 5.7), it was mentioned that records of events can be considered as objects.This means that when a MAKEVENT operation takes place, an additional effect can be specified. This230is to create a new object. Subsequently, a number of DOMEXP operations can be triggered to add theobject to the domains of the attributes it possesses. These attributes will, in turn, have been created usingMAKESTRUC and MAKEREL operations. Similarly, sets of these attributes can be specified usingMAKECLASS operations to create event record classes. For example, the operationsMAKESTRUC(Time,u)MAKESTRUC(Amount,u)MAKEREL(From_account,u)MAKEREL(By_teller,u)can be invoked to create attributes which allow representation of the time and amount of a withdrawal,the account from which the withdrawal is made, and the teller who processes the withdrawal. The secondparameter takes the value u since attributes of event records are unchanging Initially, each of theseattributes may contain no pairs. Pairs are added as withdrawals occur (i.e., as MAKEVENT operationsoccur). The class WITHDRAWAL may be formed by invoking the operationMAKECLASS(WITHDRAWAL,Time,Amount,From_account,By_teller).In the same manner, other classes of event records can be formed for kinds of other events (e.g., deposits,transfers, loan payments).A.5 UNIFORMITY OF THE MODELThis section demonstrates that a representation created using MIMIC can be used for at least threekinds of applications: transaction processing, reasoning, and simulation. The differences among the threeare argued to be in the nature of the changes that occur. In transaction processing, the objects, attributes,and instances in a representation reflect instances representing things that exist, and domain changes andevents occur in accordance with knowledge about changes in the real world. This would be the case whenevents such as deposits and withdrawals reflect actual actions of customers, as assumed in the descriptionsof the previous section. In reasoning (or expert system) applications, a common objective is to determinewhether a sequence of events that leads to a specified state is possible given the behavioral constraintscontained in the representation. In simulation, the interest is in examining the effect of hypothetical eventson certain parameters of a real or hypothetical system. In other words, the three kinds of applicationsdiffer in terms of the nature of events (real/possible/hypothetical). In addition, they differ in terms of themanner in which operations to create events occur (Wand and Weber, 1988). Transaction events aretriggered by input from a user interface. Reasoning events are generated by a software-based inferenceengine which tries to determine whether certain combinations of events are possible. Simulation eventsare generated by a software-based mechanism which invokes changes according to some random or pre-specified temporal pattern.The objective of transaction processing is to accurately track the state of knowledge about thedomain of interest by recording actual changes in the state of things in the domain. Events such as thewithdrawals discussed in the previous section support such tracking activity. Hence, use of MIMIC tosupport transaction processing is not considered further. The remainder of this section is devoted toshowing how the constructs of the MIMIC model can support reasoning and simulation activities in thebanking example introduced earlier.A potential reasoning application for the example used here might involve a customer's applicationfor a loan. Consider expanding the original description of the domain as follows. A loan application may231be considered an object, and is created using the operationMAKEOBJECT(L_a_/),where L_a_1 is a surrogate (identifier) designating a specific loan application. The MAKESTRUC andMAKEREL operations are used to create the attributes Amount, Status, and Applicant (which mayinitially be empty sets). The operationMAKECLASS(LOAN_APPLICANT, Amount, Status, Applicant)creates the class LOAN_APPLICANT. The attribute Status is assumed to have the codomain {accepted,rejected, undetermined), reflecting three possible status values of an application. In order to classify theobject L_a_l as a loan application, the DOMEXP operation is invoked three times to add the object tothe active function of each of the three attributes defining the class. This example assumes that, whenevera new application (L an) is created, the pair <I, _a _n ,und eter mine d> is added to the active function ofStatus using a DOMEXP operation. The assumption plays an important role in triggering the reasoningprocess, as it can trigger an examination of loan eligibility criteria expressed as behavioral constraints.In a similar manner, a class LOAN_APPLICANT can be defined as a subclass of CUSTOMER,with additional attributes that include Capability, Commitment, Risk, and Application. In this example,the first three of these attributes are each assumed to have the codomain (high, moderate, low,undetermined). When a loan application is made, a DOMEXP operation is performed on each of thesethree attributes to add the customer (i.e., the value of Applicant(L_a_n)) to the class LOAN_APPLICANT.The role of the reasoning mechanism (the details of which are not of concern here) might be toregard the value 'undetermined' as unstable, and to identify allowed events which would change the activefunctions of the attributes in question to produce more stable values (e.g., accept, reject) for the newlycreated instances. That is, when a DOMEXP operation is invoked which adds an object with an'undetermined' value to the active function of an attribute, the reasoning mechanism is also triggered, andchecks the constraints on changes to the active function in question. To illustrate this, let:n denote an object of class LOAN_APPLICATION,a(n) denote the object of class LOAN_APPLICANT that is the value of Applicant(n),s1 denote the active function of Status (s 1(n)=undetermined),s2 denote an active function of Status such that s2(n)=accept,c denote the active function of Capability (c(x)=undetermined),m denote the active function of Commitment (m(x)=undetermined),r denote the active function of Risk (r(x)=undetermined).Suppose that a constraint on events <s 1 ,s2> is as follows:F3 : <S I ,S2> := c(a(n))=highv((m(a(n))=moderatevm(a(n))=low)Ar(a(n))=low).Informally, this means that the status of an application may change from 'undetermined' to 'accept' if andonly if the capability of the applicant is 'high' or if the commitment is 'moderate' or 'low' and the riskis 'low'. In order to determine if F3 is satisfied (and the event <s 1 ,s2> possible), it is necessary todetermine the values of c(a(n)), m(a(n)), and r(a(n)). Consequently, if the specification of constraints or"rules" is complete, there will also be F's which describe conditions under which each of the attributesCapability, Commitment, and Risk change active functions so that values for new applicant objectschange from 'undetermined' to either 'high', 'moderate', or 'low'. For example, changes to Capability232may depend on the existing attributes Income (of CUSTOMER) and Balance (of ACCOUNT). Thespecific conditions can be incorporated into behavioral constraints. For example, for the active functionto change so that the value of Capability for an individual changes from 'undetermined' to 'high', it maybe required that the salary of the application to be at least $50,000 and the account balance at least$10,000. This might be expressed as:F4: <Ci, C2> := Income(a(n))>_50000vE tEmcwamBalance(t)10000,where, for a(n), c l(a(n))=undetermined and c2(a(n))=high.Other rules could be similarly expressed using the MAKEBEH operation. For example, valuesassigned to Commitment(x) may depend on values such as Number_dependents(x) andHousing_expenditures(x). The point here is not to describe an inference mechanism, but simply toillustrate that the MIMIC model supports the representation of knowledge for reasoning applications andthe operations described earlier allow this knowledge to be represented for a specific example.The third type of information systems activity supported by the model is simulation. A bankingenvironment provides many areas in which simulations may be used to support decision making. Thisexample considers the effect of the number of tellers who serve customers on statistics such as tellerutilization and customer waiting time.Some knowledge that is important in such a simulation might be of interest only for the simulationapplication and, therefore, not otherwise represented. This knowledge can nevertheless be expressed bydefining new objects, attributes, and classes. Furthermore, a simulation can make use of knowledge aboutthe current (actual) state of entities in the representation (e.g., accounts held by a customer).A critical part of any discrete event simulation is the generation of events. The simulation eventsthat are of interest for this particular problem are potential events (withdrawals, deposits, transfers).Records of these are distinguished from those of actual transactions by their membership in a newlydefined class, S_TRANSACTION. In addition, changes in active functions (i.e., events) during asimulation run will affect only the attributes of classes defined for the simulation (e.g., QUEUE). Hence,the historical state of the representation of organization entities (e.g. CUSTOMERs) will not change duringa simulation run. Note that this is not a consequence of the MIMIC model, but must be enforced bymechanisms in the software that drives the simulation.To illustrate the use of the model in a simulation context, the example and its representation aredescribed as follows. The primary classes of entities of interest for the simulation are the existing classesCUSTOMER, SAVING, and CHEQUING, along with three new entity classes: TELLER (a subclass ofEMPLOYEE), QUEUE and SERVING. In addition, there are two classes of records of simulation events.The instances of TRANSACTION represent instances of service to a customer by a teller, while theinstances of WAIT represent instances of customers waiting in queues. These classes are defined next.First, class QUEUE is considered. QUEUE is defined to consist of a single attribute, Contains(indicating the customers in each queue), which is defined with the operationMAKEREL(Contains,c).Initially, Contains={} (each queue is empty). The class is defined usingMAKECLASS(QUEUE,Contains).This class has a behavioral attribute constraining changes to the active function of Contains. Letting:233c 1 denote the active function of Contains,c2 denote another function of Contains,x, y denote instances of QUEUE,the restriction is:F5: <C1,C2> := (Ci(X)-15.C2(X)Ci(X)+1)A(C2(31)=C1(Y) VyE QUEUE, y#x).This constraint is established by invoking MAKEBEH(F5), and requires that the contents of exactly onequeue changes by exactly one element in any event on Contains.The class SERVING has a number of instances equal to the number of tellers in the simulation.An instance of this class can really be viewed as a "queue" of 0 or 1 elements (depending on whether theteller is available or busy, respectively). Two attributes are defined:MAKEREL(Teller,u),MAKEREL(Is_serving,c).Initially, Teller = ( ) and Is_serving = { }. The class definition is:MAKECLASS(SERV1NG,Teller,Is_serving).The instances of this class are in one-to-one correspondence with the instances of TELLER used in thesimulation. For example, if the single teller case (with teller t) is being simulated, there is one instanceof SERVING, g, for which Teller(g)=t.Next, the transaction classes are defined. A single class, TRANSACTION, is defined to representsimulation transactions. Objects in this class are records of (i.e., represent knowledge about) individualsimulation transactions. The primary attributes of interest are the customer and teller involved in thetransaction, along with the time at which the transaction begins and the time at which it ends. These lasttwo attributes, respectively, represent times at which (1) there is a change in the active function ofContains of QUEUE (reducing queue size) and at which (2) there is a change in the active function ofIs_serving of SERVING. Consequently, there are two events relating to each instance of this class. First,the attributes are defined:MAKEREL(For_customer,u)MAKEREL(By_teller,u)MAKEREL(Start_time,u)MAKEREL(Stop_time,u).Initially, all four attributes contain the empty set. The class is defined using:MAKECLASS(TRANSACTION,For_customer,By_teller,Start_time,Stop_time).The remaining transaction class of interest involves the waiting of customers in queues. Eachinstance of this class represents the wait of a customer in a queue. The attributes of interest involve thespecific customer, the queue, the time of entry, and the time of departure, and are defined as above (eachinitially contains the empty set). The class definition is:MAKECLASS(WAIT,Customer,Queue,Time_in,Time_out).234The values of the last two attributes for an instance of WAIT are, respectively, times at whichthere is a change in the active function of Contains (increasing queue size), and a change in the activefunction of Is_serving. Furthermore, for each instance of WAIT, there is an instance of TRANSACTIONwhose value for Start time is the same as the value of Time out of that instance of WAIT. Neither ofthese two event classes has behavioral attributes, as the instances are unchanging.It is also necessary to have a way of determining the time required to serve a customer. This canbe achieved by defining a class TELLER as a subclass of EMPLOYEE, with the added structural attributesMean_service_time, which represents the mean time for a teller to perform an activity, andSd_service_time, which represents the standard deviation (and possibly added relational and behavioralattributes). The example assumes that, for each teller, the actual time required to serve a customer isnormally distributed around the mean. Each time a customer arrives at a teller for service, a value forservice time can be obtained by sampling from the normal distribution using the parameters whichdescribe the teller in question.This extension of the example allows a simulation to be supported and statistics to becaptured'. Statistical data are not considered as attributes of individual or composite entities (e.g.,waiting times of entities in queues). Instead, statistics can be calculated at the completion of a simulationrun by examining the attributes of events. The description above permits two important statistics to besupported. First, the waiting time of a customer in the queue is simply the difference between the timethe customer leaves the queue and the time he/she enters the queue. For each entry in a queue, these twodata are the values of the attributes Time_out and Time_in for an instance of IN_QUEUE. The averagewaiting time is simply the sum of these waiting times divided by the number of instances of IN_QUEUE(the latter is equal to one half of the number of changes in the active function of Contains of QUEUE).Second, the utilization of a teller, t, is simply the sum of the differences between the Stop_time andStart_time attributes for each instance, s, of S_TRANSACTION for which By_teller(s)=t, divided by thetotal duration of the simulation period.The extensions of the example provided here allow the progress of customers through a simulationto be recorded. In order to run a simulation, arrivals of customers need to be generated. Just as the userinterface was not considered in constructing a representation for transaction processing activities, thesoftware to generate simulation events is beyond the scope of interest here. However, in general sucharrivals would be generated by a piece of software which may simulate arrivals by sampling from somestatistical distribution, and then triggering events in the system by invoking DOMEXP, DOMCON, andMAKEVENT operations as required by the values sampled.To conclude, this appendix shows the way in which different kinds of applications may besupported within a single representation (or system) using the MIMIC model, highlighting the similaritiesand differences between such applications. In all three cases considered (transaction processing, reasoning,simulation), knowledge about the structure, relationships, and potential behavior of things must berepresented. The same model constructs (object, attribute, class) can uniformly represent that knowledge.The differences between the applications are highlighted by what is outside the scope of MIMIC: namely,the mechanisms for generating events. In transaction processing applications, actual events are reportedthrough an interface with the real world system that is modelled by the information system. In reasoningapplications, the effects of possible events (as constrained by behavioral attributes) are explored by amechanism which seeks a certain goal state. In simulation applications, hypothetical events are generatedaccording to some pre-specified criteria. In each of these three cases, the mechanisms for "generating"events are embedded in code, but this code is not described using the constructs of MIMIC.1540f course, statistics could also be kept for transaction processing activities.APPENDIX 2GUIDE TO NOTATIONThis appendix summarizes the important notation of Chapter 4 in the order in which itis introduced. The terms are divided by level: that is, cognitive and object.Cognitive Level T^a set of instancesV a set of valuesS^a structural property: {s i ls i :TV}s i^an element of the structural property SST a set of structural properties shared by the instances Tg (T)^the power set of the set of instances Tp (100...or)^the power set of the Cartesian product of T1 ,...,TKQ^a subset of p^...cirK)q an element of QR^a relational property: fri lri :TQIr. an element of the relational property RRT^a set of relational properties shared by the instances TP a structural or relational propertypkik^the ik function of the property Pka(T) the state of the set of instances T: <p i ii ,...,pKiK>a(t)^the state of an instance tE T: <p l ii (t),...,pKiK(t)>E(t) the potential state space of each tE TE(T)^the possible state space of a set of instances Te an event: <6(T),6'(T)>b^a behavioral property: b:P 10...OPK—> p (P 10...0PK)C a concept (potential or realized), denoted:P^pl,...,pK= <S,R,B>= <P,B>CS^a concept structure: {C 1 ,...,CK }235236Object  L evel 0^a set of objectsU a set of value surrogatesS*^a structural attribute: { s* ils* ; :0-->U}ssi^an element of the structural attribute S *S*0^a set of structural attributes shared by the objects 0p (0) the power set of the set of objects 0p (0 10...00K)^the power set of the Cartesian product of 0 1 ,..., OKQ s^a subset of p (0 10...00K)q* an element of Q*R*^a relational attribute: {ej lr*i :0-3Q*}r an element of the relational attribute R*R*T^a set of relational attributes shared by the objects 0Ps^a structural or relational attributep*kik the ik function of the attribute P* k6(0)^the state of the set of objects 0: <p* lii ,...,p* lac>a(o) the state of an object of 0: <p* in (t),...,p*KiK(o)>E(o)^the potential state space of each of 0E(0) the possible state space of a set of objects 0e^an event: <6(0),6'(0)>b*^a behavioral attribute: b*:P* 10...OP*K ---> p (P* 10...OrK)C *^a class (potential or realized), denoted:p*^p* 1 p*K= <S*,R * ,B *>= <P*,B*>CS*^a class structure: {C*1 ,...,C*K }

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0086718/manifest

Comment

Related Items