4.1.7 SHALLOW DATA FOR SET PROCESSING

A graph of extracted features connected by links representing topological relations is a feature graph. Figure 24 (a) is a feature graph of Figure 12. The feature graph's dimensionality can be reduced by extracting the individual features and their parameters from the graph structure. Essentially, the links connecting the features can be thought of as added dimensionality, while objects standing on their own stand in a lower dimension. Figure 24 represents the how the feature graph of (a) can be reduced to the lower dimension representation of (b). The latter representation has not necessarily lost its connectivity information. Such information can be included as parametric data within the individual object.

Figure 24 Reduction of Dimension: a) Feature Graph b) Flattened Representation

The Sink Detection Rule depends on values of a rib feature and its adjacent base, specifically the root thickness and base thickness respectively. With the severance of links, the adjacent base thickness must be obtained from the rib under scrutiny; part of the flattening process requires that values of one object be transferred to another.

PIMES evaluations are geared toward whole groups of features at a time in the set processing style of Fourth Generation Languages (4GL). 4GLs are distinguished from their predecessors in that they act upon sets or lists. Examples of 4GL-type languages are Sequential Query Language (SQL), and Information Builders' Focus. In contrast, imperative, Third Generation Languages (3GL) such as Pascal or C act on a single data entity at a time [Kim 87].

The 4GL can be thought of as having built-in do loops. Operations that occur on a list are performed on every item within the list. Generally, there is much more detail required for 3GL programming that 4GL programming, but this occurs at a cost of flexibility. Entities within the 4GL set can not explicitly be dealt with on an individual basis.

Figure 24 represents a feature graph and the procedural algorithm required to do a comparison of values. Figure 25 illustrates the flattened data structure and the declarative 4GL operation that can be used.

Figure 25 Procedural Mode: Feature Graph Data Structure (a) and Algorithm (b)

Figure 26 Declarative Mode: Flattened Data Structure (a) and Deductive Rule (b)

Functional extensions to SQL generally offer statement processing conditional on the state on the system. But direct conditional processing of individual elements within a list is not offered. It must be noted that such conditional processing of elements is achieved with great overhead through the use of temporary elements and loop constructs offered by extensions to the 4GL. In effect, the 4GL can be rigged to behave as a 3GL. But this adds unnecessary complexity to the system and undermines the simplicity of maintenance, debugging, and operation that 4GL's afford.

Efficient use of 4GL requires representations different from those that would be suitable for 3GLs. It can be shown that the computational efficiency with respect to a single representation depends on the processing system used; within a given processing system, some representations simply do not work as well as others [Larkin & Simon 87].

The set processing capability of PIMES and 4GLs makes the programming environment declarative. The computer handles the detailed processing of single entities; the 4GL can be thought of as having built-in do loops. An operation specified to be performed on a list is performed by the computer on every item within the list.

One consequence of the declarative environment within PIMES is that instances must be "flattened" in such a way as to make all property values available on the same level. Figure 27 illustrates (a) objects available for examination by a 3GL and (b) their flattened representation more suitable for use by 4GL. Note that the depth is removed and properties are moved up to the same layer. Also, additional properties are added to explicitly describe the relations that are no longer available implicitly. Relational databases achieve such flattened breadth through the use of a "join". A join connects records across different tables and eliminates requirements for the hierarchy of information found in some database management systems.

The Assembly representation of Figure 27 is an entity created for the purposes of computational evaluation. Conceptually there are assemblies, and the concept of assemblies becomes key in such areas as design-for-assembly and design-for-the-environment. In the environmental scenario, material type becomes an important consideration for recycling or reclamation. The type of join becomes of concern in this scenario as well. For example, two plastics of the same nature may become preferable in an assembly over two plastics of different natures in terms of recycling. A snap join may be preferable to a weld in terms of disassembly for recycling.

Figure 27 Flattening of Object Representations for use by 4GL.