Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


1.  Creation of case attribute definitions. General attributes are used by the ES as input data, conclusions, or output results. Once the information about an attribute has been collected, it has to be organized in a written definition. Table 3 describes the contents to be included in an attribute definition.

TABLE 3
Attribute Definition Content
 
Information Description
 
Name The standard term naming the attribute.
Description Brief explanation of a case particular represented by the attribute.
Value type The value class, which may be a specific example of the attribute: numerical, logical, etc.
  The units for numerical values, e.g., centimeters, seconds, volts, red blood cells, etc.
  Numerical value accuracy, i.e., 4 decimals.
Value range A list of possible descriptive values.
  A range of numerical values.
  A description of the syntax or admissible structure of a value.
Number of values per case The number of values for the attribute: one or many.
Source The method by which the case attribute is to be located, i.e., the sources from which an attribute value is to be obtained, the order in which each source is to be consulted, and the circumstances in which it should be consulted.
  The action to be taken by the system if it is unable to determine the case attribute, e.g., if unavailable, continue without information or end with an informative message.
Details on how to obtain information For user inputs, the information-related text and diagrams to be displayed.
  For inputs from other sources, include details on the source and data format.
  For input data, a description of how to check input data validity, if necessary.
  For inferred attributes, cross-references for descriptions of relevant tactical knowledge.
  Default values, where applicable
Input data accounting If the input is not always reliable, a description has to be given of how the system can deal with "unreliability."
Use Notes that describe how the ES will use the attribute, what are the bases for inference to control the sequence of actions to be executed by the system, etc.
  Cross-references to other inputs in the design document that describe attribute use.
Output results format If the output is shown to a user, the format of the text and diagrams to be used to report the attribute to the user.
  If the output is to be transmitted to a file or device, details on the destination and output format for numerical attributes, accuracy, and format with which the values are to be printed.
Support material References to knowledge acquisition documents and sessions that supply information about the attribute.

It is very important to develop a standard format for attribute definitions that shows what information has been obtained and what further information has to be obtained in future knowledge acquisition sessions. As shown in Table 3, different details about different attributes are required. For example, one definition of an input information may contain a question for the user, whereas the definition of another input information may contain a database query. There is sometimes a tendency to pass over information that does not fit the standard format given in the table. This has to be avoided as far as possible. The definition of an attribute should include all the information obtained about the attribute. If details are found that do not fit the standard format, the format should be modified. When developing a standard format for definitions, it is important to try to foresee what information will be useful when we start to implement and verify the ES. For example, a space may be left in the definition for (1) the name used for the attribute in the knowledge base and (2) a list of cases in which the attribute is important, if the attribute does not figure in each case. Additionally, we have to specify whether the ES is capable of using the attribute routinely as planned.

A well-designed definition will be a useful guide both for design and implementation and for future knowledge acquisition sessions.

2.  Attribute classification. Typically, each attribute refers to a specific item of information about a particular type of concept, process, or other conceptual entity. These standard objects can be used to organize attributes. Here, we have to (1) identify the type of concept described by each attribute; (2) group attributes that supply information about a similar concept type; (3) name each concept type and add this name to the project concept dictionary, if not already defined; and (4) revise the attributes of each concept type, checking whether these attributes can be further classified and categorizing the concept types to identify as many classificational levels as required.

An intermediate representation has to be selected to illustrate how the attributes that will be used by the ES have been organized. If the organization is simple, a list of concept types will suffice. If the attributes have been organized in a multilevel classification, classificational hierarchies are a possible option. Additionally, it is important to define each identified concept type, specifying which attributes are relevant for this concept type. If the concept type is part of a multilevel classification, its definition should contain cross-references to both more general and more specific concept types.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.