Planning A Class Hierarchy
Planning a class hierarchy for your G2 knowledge base is an important part of completing your application. Following are some general guidelines:
G2 allows you to change user-defined classes and class hierarchies as needed. Such changes automatically propagate to all existing subclasses and instances. However, you may also have to change other parts of the KB to be consistent with the new class definitions, and this is sometimes difficult. Careful thought in laying out user-defined classes and class hierarchies can save significant time later on.
- Try to plan as many of your classes at one time as possible. The hierarchy you develop depends on the interrelationships of your classes. One of the first steps to planning a class hierarchy is to list the most important properties that each of your prospective classes will have.
- Use factoring to build a provisional class hierarchy based on the properties. In factoring, you develop classes by grouping all common properties as high up in the class hierarchy as you can. For instance, the classes
invertebrates group all animals with and without spines into two high-level classes. Subclasses beneath these specify additional groups with common properties.
- Consider the probable patterns of referencing objects when deciding which kinds of properties should be the basis for your hierarchy. For instance, in a taxonomy, the class basis is structural. If, in your application, you are more likely to reference objects by some other property, say habitat, your high level classes should reflect this. You might have high-level classes such as
land-animal, air-animal, and
water-animal instead of the structural categories.
- Multiple-inheritance allows you to classify entities under two or more major classifications. Don't neglect its potential to help you to represent complex structures of information.
Copyright © 1997 Gensym Corporation, Inc.