Mapping

Class structures describe the structure of the objects representing concepts, abstractions,

and other items within a problem space. In other words, class structures provide

blueprints for building the data structures and scripting the behaviors of objects within

an object-oriented system. Class structures in the cognitive mapping domain would

describe a variety of objects spanning a range of granularity. Class structures describing

“fine-grained” objects serving as fundamental building blocks of a social causal mapping

system would represent an individual’s concepts and assertions of causality (i.e., nodes

and arcs, respectively). Those fundamental class structures must also describe methods

to create, store, link, dispose of, and otherwise process nodes and arcs. Higher-level

class structures would describe the building of “coarse-grained” objects from “finegrained”

fundamental objects (e.g., aggregating nodes and arcs into causal maps).

Methods associated with these higher-order objects would prescribe processes for

analyzing large numbers of maps, such as identifying equivocalities and feedback loops

within and between individual causal maps.

A thoughtful, coherent set of class structures can facilitate efficient software design and

coding in many ways. Perhaps the most useful way to do so is by designing the class

structures so that they integrate and cooperate with each other. This can be achieved

in object-oriented design through hierarchies of interrelated classes in which commonlyused

data and method structures are encoded in high-order “super-classes” that allow

related lower-order “sub-classes” to re-use, or inherit, those structures. This and other

applications of hierarchical classes structures will now be explored in the context of social

causal mapping.

Hierarchies of Classes in Object-Oriented Design

Class hierarchies are based on what’s commonly called an “is-a” relationship. Objects

exhibit an “is-a” relationship with their classes, just as someone’s pet dog “is-a” member

of the canine family. Likewise, two classes can also be linked through an “is-a”

relationship, just as a canine “is-a” type of mammal and a mammal “is-a” type of animal.

“Is-a” relationships are transitive, so it can be said that a particular dog “is-an” animal.

Hierarchies of sub-classes and super-classes facilitate the creation and encoding of

object-oriented software by allowing designers to conceptualize the given problem

space at various levels of abstraction. This approach is similar to—but not exactly like—

the common example of the taxonomies of animal species. For example, the generalized

notion of “mammal” arises from the abstraction of common characteristics of groups such

as lions, dogs, weasels, and humans: all are mobile, have seven vertebrae in their necks,

nurse their young, and have hair. In turn, the term “animal” is a more abstract concept

encompassing fish, birds, reptiles, mammals, and other mobile life forms. The abstract

notions of “mammal” and “animal” are useful because they help biologists construct

taxonomies that succinctly structure knowledge about related forms of life. A diagram

depicting a hierarchical, taxonomic structure of animal classifications is displayed in

Figure 3.

Object-oriented design extends the notion of taxonomy beyond the hierarchical positioning

of related groups and objects into an efficient approach to designing information

systems. This approach relies upon inheritance, in which the characteristics of higherlevel

classes are imparted to—or inherited by—their lower-level counterparts. Inheritance

is particularly helpful in object-oriented design. It promotes the re-use of design

structures, thus enhancing efficient program coding and consistency of design across

the software and information system. It also helps ensure that important general

structures and methods are not forgotten in the implementation of specialized subclasses.

Inheritance typically takes two steps. The first step involves grouping data structures

and methods that are common to a set of classes within one class (e.g., the super-class

CognitiveMap). Data structures and methods that are particular to one or more but not

all members of that group are relegated to unique sub-class structures (e.g., the subclasses

CausalMap, CategoricalMap, and AssociativeMap). The second step involves

identifying the relationships between a super-class and its sub-classes. This step is

typically accomplished with a software statement. The Java clause “class CausalMap

extends CognitiveMap” is an example of how a super-class/sub-class relationship could

be identified by a software statement.

Hierarchies of Classes for Social Causal Mapping

The similarities among the data structures and methods among causal, categorical, and

other cognitive maps suggest that these classes can be arranged in one or more

Dogs Cats Fin whales

Carnivores Cetaceans

Mammals

Dolphins

Animals

Birds

Waterfowl Raptors

Ducks Geese Hawks Eagles

Figure 3. Hierarchies of super-classes and sub-classes in the animal kingdom

hierarchies of sub-classes and super-classes. Three hierarchies are of immediate interest:

one concerns the maps themselves (i.e., a hierarchy of cognitive maps), while two

concern their constituent components (i.e., nodes and arcs).

A Hierarchy of Cognitive Maps for Social Causal

Mapping

The general notion of cognitive maps can be abstracted from causal, categorical, and

other similar types of representations. All are directed graphs composed of nodes and

arcs, and all exhibit functionalities (i.e., encoded in their methods) that can contribute to

the five OMIS functions conceptualized in Stein and Zwass (1995). It is these elements

and characteristics that are common to and drawn from causal, categorical, and other

related maps that are used to construct the super-class of cognitive maps (i.e., Class

CognitiveMap). A diagram of these hierarchical relationships is displayed in Figure 4.

Cognitive map sub-classes (e.g., CausalMap, CategoricalMap) would inherit data and

method structures delineated in Class CognitiveMap, but would also contain unique

characteristics as well. For example, the Class CausalMap would contain a method to sum

the “+” and “-” values in a chain of causal node-arc-node segments. Class CategoricalMap

would not need that function because categorical arcs do not exhibit “+ or “-” values.

Indeed, the differing natures of the nodes and arcs within the causal and categorical maps

suggest that separate class hierarchies are needed for nodes and arcs. These two

hierarchies are explored next.

Figure 4. Hierarchies of super-classes and sub-classes for social causal mapping

Cognitive Maps

Associative

Maps

Categorical

Maps

Causal

Maps

Workflow

Diagrams

Political

Maps

Synonymous

Terms

Content

Analysis

Hierarchies of Node and Arc Classes for Building