Моделирование бизнес-процессов / Моделирование бизнес-процессов / I D E F / idef5

finish time. These attributes are catalogued in a Proto-Characteristic Pool 8, as shown in Figure 3-11.

Proto-Characteristic Pool

The following fields are used to describe the Proto-Characteristic Pool:

•Characteristic # The unique identifying number assigned to each characteristic is documented in this field. The characteristic number is important because it can be used as a means of traceability to the characteristic in the future.

•Characteristic Name The name of the characteristic is recorded in this field.

•Supported By The names of the team members responsible for the identification of the proto-characteristic are recorded in this field.

8When a proto-characteristic matures into an characteristic during ontology development process, the characteristic is recorded in a Characteristic Pool. The design of a Characteristic Pool is the same as that of a Proto-Characteristic Pool, as shown in Figure 4-9.

49

•Kinds Used In This field consists of the list of all kinds that possess this characteristic.

3.4.4The Role of IDEF5 Schematics in Ontology Visualization

The IDEF5 languages are used during the invocation of the IDEF5 procedure to assist with the development and visualization of the ontology. The purpose of IDEF5 schematics is to serve as an aid for the construction of ontologies; they are not the primary representational medium for storing the ontologies (refer Subsection 4.1.2 for more details). The elements of the Schematic Language9 that are used to illustrate the IDEF5 procedure in this section are as follows: 1) A kind is represented by a circle containing a label, 2) A first-order relation is represented either by an arrow with a label or by a rectangle with rounded corners containing a label, and 3) A secondorder relation is represented by an arrow with its arrowhead at its back end. The use of Classification Schematics, Relation Schematics, and Composition Schematics are briefly illustrated in this section.

3.4.5Using Classification Schematics for Ontology Development

The following example demonstrates how a Classification Schematic feature helps visualize the subkind-of relation between different kinds in a domain. A source statement “plans may be broadly classified as project plans, process plans, and manpower plans,” can be considered. Suppose that based on this source statement, team members individuated kinds as plan, project plan, process plan, and manpower plan during data analysis. A Classification Schematic is designed to explicitly display the subkind-of relation between various proto-kinds/kinds in a domain, as shown in Figure 3-12.

Figure 3-12. Classification Schematic

9The IDEF5 Schematic Language is described in detail in Subsection 4.1.

50

3.4.6Kinds Versus Properties

A common problem in ontology development is distinguishing between kinds and properties. Properties, by definition, are characteristics that hold of kinds. An example of a property may be (an object) being red. However, in some circumstances, it may be useful to objectify (make objects of) the properties and treat them as kinds in their own right. To illustrate the nature of the problem, the tolerance of a mechanical part used to make an assembled product can be considered. For the manufacturing engineer performing the assembly, the tolerance is simply a property that must hold for all parts supplied to him. If the tolerance does not hold, it is rejected; otherwise, it is accepted. For the part designer, however, tolerances are of greater significance. Thus, the designer finds it useful to classify different kinds of tolerances (dimensional tolerance, positional tolerance, geometrical tolerance, etc.) and to study the characteristics of each kind of tolerance. The designer will, thus, find it useful to model tolerance as a kind rather than as a property. In general, the decisions between kinds and properties are a function of the granularity (detail) level of the ontology development effort. The level of granularity is significantly influenced by the purpose, viewpoint, and context of the project (see Subsection 3.1.2).

3.4.7Coining Terms

Closely associated with the discovery of proto-kinds is the task of unambiguously identifying each of these proto-kinds; in practical terms,this means that each individuated candidate kind must be bestowed a name. Giving names in ontology development is not as trivial a task as it may first appear. Names are used as referential pointers to the real world individuals being described. They must, thus, connote a meaning that closely mirrors the individuals that are referenced. For many real world individuals (especially the phenomenological naive ones), widely accepted names already exist and will be used as such. For example, domains of certain engineered products, such as automaking, have hardened and have fairly stable ontologies. (On the other hand, ontologies of new technological fields, such as “virtual reality,” are in constant flux.) It may be necessary, at this stage, to invent new names for certain individuals. This is often true for new conceptual groupings of individuals, as illustrated in Figure 3-13. The strategy suggested in IDEF5 is to coin a term to describe the individual and record the fact that the individual’s name was coined rather than discovered to avoid later confusion.

Conceptual objects are often discovered during interviews with domain experts. For example, during development of a fastener selection expert system for an automobile manufacturer, a domain expert had conceptualized a set of systems for fastener usage in various parts of a car body. These systems were not recorded in the literature, and the expert had never given them

51

names. Rather, he carried the ideas with him internally and used them without names. The term world class systems was coined to describe these conceptual ideas (see Figure 3-13).

Concept name: world class system

Figure 3-13. Coining Terms

The Proto-Kind Pool is provided in IDEF5 to record proto-kinds (see Figure 3-9). As seen in Figure 3-9, each proto-kind is tagged to the supporting source document for traceability purposes. As a further aid to identifying proto-kinds, the IDEF5 ontology library (see Appendix B) provides a catalog of generic kinds that commonly occur in engineering and business domains. These kinds may be used for effectively organizing the captured ontology knowledge about different kinds of objects and phenomena.

3.4.8Other Guidelines

Other useful guidelines for developing proto-kinds are as follows.

•Identify and record special cases. Special cases are instances of objects that do not seem to fit the pattern of other instances of the object. For example, a particular fastener in a handbook may have a special heat resistant property not present in other fasteners. All special cases are catalogued separately in the source material catalog.

•Group objects together to form new kinds and categories, wherever appropriate. It may be helpful to abstract away from a group of objects and form new proto-kinds by extracting the properties from the object group. Such abstractions often serve to enhance the conceptual clarity of the ontology.

•Group the objects to isolate systems and subsystems. Systems are collections of objects that fulfill a common purpose. Systems may not have any distinguishing characteristics but often provide a useful framework for organizing knowledge about relations.

52

•Use the IDEF5 classification and other relation schematics to aid the conceptual analysis of kinds. The classification schematics and the composition schematics are particularly useful in the development of kinds.

Figure 3-14 summarizes some of the key activities associated with developing proto-kinds.

Figure 3-14. Developing Proto-Kinds

3.4.9Develop Proto-Relations

The objective of this task is to identify and characterize the proto-relations between the protokinds. A proto-relation is the result of a preliminary attempt at individuating a relation, and it expresses associations between the proto-kinds. The identification and characterization of relations is often the most difficult part of knowledge acquisition. The identification of protorelations refers to the activity of recognizing the existence of, or becoming attuned to, a particular proto-relation in the domain. Characterization follows identification and refers to the activity of identifying and specifying the properties of a proto-relation in a manner that will allow the relational knowledge to be used for making useful inferences at some time in the future. Thus, recognizing that a tool post is On-top-of the lathe bed is the act of discovering and asserting its existence and giving it a name. Characterizing it will involve making assertions such as the On- top-of relation is transitive.

Several mechanisms are provided in IDEF5 to guide the relation knowledge acquisition process. They are:

•The IDEF5 Statement Pool is the richest source of information for relation discovery and characterization. Source statements assert the existence of relations either implicitly or explicitly.

53

•The IDEF5 Relation Library provides a catalog of relations that commonly occur in business and engineering domains. These libraries can be reused and tailored to the requirements of particular ontology development efforts within a wide range of domains.

•The IDEF5 Relation Schematics (including Composition Schematics) facilitate the display of relations in a graphical form.

•The IDEF5 Elaboration Language, which provides a structured text format for capturing complex relation knowledge at any level of complexity, can express everything that can be recorded using the Schematic Language; it can also express knowledge that is beyond the scope of the Schematic Language. For example, the expression z = a + b + c + d, where z, a, b, c, and d are integers, can only be expressed in the IDEF5 Elaboration Language10.

The development of proto-relations will involve the following activities.

•Record meaningful associations between proto-kinds. Such meaningful associations often indicate the existence of proto-relations. A useful source for extracting such associations is the Source Statement Pool (Subsection 3.2.3.3). A Proto-Association Chart is a two-dimensional matrix with relevant proto-kinds listed on both axes. An X is marked in cells where the existence of a possible proto-relation is indicated, as shown in Figure 3-15.

•Categorize the proto-relations as being system-accidental or system-essential and recall that system-essential relations have to necessarily hold, given the existence of instances of the participating kinds.

•Identify the properties of the proto-relation. The IDEF5 relation library and the IDEF5 elaboration language are used to facilitate this process.

•Examine the nature of the participating proto-kinds. Relations often have restrictions on the types11 of arguments. For example, the assertion A Reports-to B implies that both A and B refer to instances of people, or to instances of organizational roles, or

10The IDEF5 Elaboration Language is described in Section 4.2.

11The term “type” is used here in a general sense. See Subsection 2.1.2 for a discussion of kinds and types.

54

to a combination of an organization role instance and a person instance. Thus, knowledge of the participating proto-kinds will focus attention on a more restricted set of possible relations that may exist between instances of these proto-kinds.

Kn

Note: Proto-kinds are denoted K1, K2, ... , Kn.

Figure 3-15. Structure of a Proto-Association Chart

The proto-relations that are identified are recorded in the Proto-Relation Pool12, as shown in Figure 3-16.

Proto-Relation Pool

•Proto-Relation # The unique identification number assigned to the proto-relation is recorded in this field. This field is important to enhance traceability of the protorelation that is individuated by a member of the ontology development team.

12When a proto-relation matures into a relation during ontology development process, the relation is recorded in a Relation Pool. The design of a relation pool is same as that of Proto-Relation Pool, as shown in Figure 3-17.

55

•Proto-Relation Name The name of the proto-relation is documented in this field.

•Supported By This field involves source data items (terms, statements) that support the individuation process of the relation during the ontology development process.

•Participating Kinds The set of all kinds between which this relation holds is documented in this field, which is important because it helps in characterizing the relation itself.

•Comments Any additional descriptive remarks about the proto-relation important for future reference should be recorded in this field.

Each proto-relation has a Proto-Relation Specification Form (Figure 3-17), in which a brief description of the proto-relation, examples of use, and other relevant comments can be documented.

Proto-Relation Specification Form

Proto-Relation #: PR #1

Proto-Relation Name: Determines

Description: To fix conclusively or authoritatively.

Examples of Use: A project planner determines all the precedence constraints that must be maintained in the system.

Comments: Individuated by B. Caraway

Figure 3-17. Proto-Relation Specification Form

3.4.10Role of Relation Schematics in Ontology Development

The IDEF5 Relation Schematics allows ontology developers to visualize and understand relations between relevant proto-kinds or kinds in a domain. Consider the source statement: a manpower planner develops a manpower plan in which resources are allocated to perform the

56

required activities. Based on this source statement, suppose that the ontology development team individuated the following kinds: manpower planner, manpower plan, resource, and activity . The relations between these kinds are visualized using the relation schematic shown in Figures 3-18 or, alternatively, Figure 3-19.

Figure 3-18. First-order Schematic

Develops

Performs

Figure 3-19. Alternative Syntax for the Schematic in Figure 3-183.4.11 Role of

Composition Schematics in Ontology Development

The IDEF5 Composition Schematics allows ontology team member(s) to visualize part-of relations between relevant proto-kinds or kinds in a domain. Consider the following source statements: A project plan is comprised of project goals, an activity list, and the manpower allocation plan and The activity list includes a major activity list and a minor activity list. Based on these source statements, team members individuate the following kinds: project plan, project goal, activity list, manpower allocation plan, major activity list, and minor activity list. Figure 3-20 illustrates the use of a composition schematic to display part-of relations in this (project planning) domain.

Figure 3-20. Composition Schematic

57

3.5Refine and Validate Ontology

The objective of this phase of ontology development is to refine the proto-characteristics, kinds, and relations, and to affirm their authenticity by converting them to properties/attributes, kinds, and relations, respectively. The refinement process is essentially a deductive validation procedure. The ontology structures are “instantiated” (tested) with actual data, and the result of the instantiation is compared with the ontology structure. If the comparison produces any mismatch, every such mismatch must be adequately resolved. Refinements (if any) to the initial ontology are incorporated to obtain a validated ontology.

3.5.1Kind Refinement Procedure

The kind refinement procedure is summarized in the following (roughly, but not necessarily, sequential) steps:

•Make instances of the proto-kinds. The examples may be constructed from the available source data (source data log); otherwise, new data must be gathered for the purpose of constructing these examples. The examples must be reasonably representative, with at least one exception case included, if possible. Each of the proto-kind instances created is populated with properties and/or attributes (this may involve converting proto-characteristics to properties/attributes). Classification schematics and kind characterization forms are used to support the kind instantiation process.

•Record information that cannot be recorded in the kind instances, determining whether this additional information is really necessary, and, if so, refining the structure of the kind to include the information.

•Check whether two instances of the same kind have different defining properties, and in such cases, check whether the viewpoints are different. If not, the inconsistencies will have to be resolved by refining the ontology.

•Convert the proto-kinds (along with their proto-properties) to kinds after all the kind instances have been validated using Steps 1 through 3. The validated kinds are listed in the Kind Pool.

A Kind Specification Form (Figure 3-21) is designed to document all relevant features of a kind after it is promoted from a proto-kind.

58