Chapter 7

Some Visual Languages Implemented in Constraint Graphs

Figure 39

• The coreference arc is the unlabeled dotted line that appears on the right-hand side of the concept node. As with relation, it both starts and ends on the concept node.
• Context is a Constraint Graphs context that inherits from the concept node. This is perfectly acceptable since concept<node, context<node, Context<context, and Context<concept forms a consistent type lattice:

The important attributes of the Conceptual Graphs definition are given in Table 4. Since the definition of Conceptual Graphs dictates that all concepts have rectangular surrounds, the shape attribute is set as constant for concept. This prevents sub-type concepts from overriding the attribute and changing the shape: to do so would interfere with the readability of the map. Likewise, other shape and connector attributes are also tagged as constant.

Table 4 also mentions one constraint. ParentOfIndividual is applied to the coreference arc because the coreference arc cannot be specialized in the Conceptual Graphs framework.

In Sowa's Conceptual Graphs, the ontology (or type lattice) is not included. Instead, the Conceptual Graphs are assumed to be accompanied by a separate semantic net that specifies the type lattice. In contrast, the Constraint Graphs version smoothly integrates these two separate graph structures into a single graphing space. This is very natural for the Constraint Graphs structure. So, a Constraint Graphs implementation of Conceptual Graphs might be considered an extension of Conceptual GraphsGraphs' graphical notation (but not an extension to Conceptual Graphs theory, since Constraint Graphs does not implement the whole theory -- just the syntax and some of the semantics).

In modeling Conceptual Graphs, the "standard" level designations need to be extended. In the "standard" designations, there are two human roles: visual language designer and end user. In Conceptual Graphs, it makes sense to divide the end user role further into a user responsible for the semantic net, and a more tradition Conceptual Graphs user who is only responsible for the domain. Thus, there are three roles:

• visual language designer (responsible for the Conceptual Graphs definition, Figure 39)

• ontology designer (responsible for the domain ontology or semantic net, Figure 40)

• end user (responsible for using the ontology to construct meaningful expressions, Figure 41)

Table 5 gives the suggested level settings for each of the roles.

Figure 41 shows an example of a Conceptual Graph as represented by the Constraint Graphs program. The graph expresses the sentence "No student read the book the teacher wrote." The Constraint Graphs ontology used is shown in Figure 40. This ontology is taken from Appendix B of Sowa's 1984 book (Sowa 1984). The user who constructed Figure 41 had to add the new types WRITE<ACT, READ<ACT, and BOOK<ENTITY. The ontology of Figure 40 is very straightforward. To avoid clutter, the type hierarchy omits the isa arc between concept and relation and their immediate subtypes (all of the rectangles and ellipses that aren't at the "from" end of an isa arc).

The Constraint Graphs program is capable of informing the user of all legal links between arbitrary nodes. A little experimentation with this feature quickly points out a few problems with the ontology which appears in the appendix of Sowa's 1984 book. For example, Sowa defines the LOC (location) relation as [T]->(LOC)->[PLACE]as it is in Figure 40 (T is concept in the figure). Constraint Graphs can infer all the possible arcs that a particular component may participate in. If the user requests this information for TIME_PERIOD, Constraint Graphs will infer TIME_PERIOD may be at the "from" side of either coreferent or LOC:

Clearly, LOC is not appropriate since a TIME_PERIOD should not have a location. This same problem applies to ATTRIBUTE, MEASURE, STATE, and all of their subtypes. It would make good sense to introduce a common supertype for ENTITY and EVENT to anchor the LOC relationship to, instead of anchoring it to T (concept). For example CYC (Cycorp 1996) defines "SpatialThing" as the supertype of "PhysicalEvent" and "PartiallyTangible" (which roughly correspond to Sowa's EVENT and ENTITY, respectively).

The implementation of Conceptual Graphs covers only the fundamental syntax and some of the semantics (type lattice constraints) of the Conceptual Graphs formalism. This level of support presented no particular difficulty to the Constraint Graphs framework, once it was recognized that relations could be modeled as arcs instead of nodes (as described at the beginning of this section). However, since much of the syntax of Conceptual Graphs is captured in node labels, a deeper modeling of Conceptual Graphs would involve several ad-hoc constraints to constrain the syntax of node labels (which has turned out to be not particularly difficult either – see Section 7.3.4). Furthermore, label syntax can interact with graphical syntax in the Conceptual Graphs implementation: an individual marker in a concept node label should preclude that node being used as a type (as the destination end of an isa arc). Even this can be handled using ad-hoc constraints, although not particularly elegantly. A more elegant method of constraining label syntax, and allowing label syntax to interact with graphical syntax, would be desirable; though it is not clear that such a method exists.

It may be feasible to model the full semantics of Conceptual Graphs using only minimal extensions to Constraint Graphs. This is described in the "future work" section (Section 9.3.3).

7.3 KDraw

KDraw (Gaines 1991b) is an interactive, visual, term subsumption language. It is based on the (textual) CLASSIC language (Borgida et al. 1989). KDraw has 6 main types of nodes, and eleven relationship types as depicted in Figure 42. All of the KDraw types (below the heavy line in Figure 42) belong to level 3. The fundamental KDraw node types are concept, primitive, individual, constraint, role, and rule. KDraw has eleven relations. The termination rules for these are shown in Table 6.

Figure 42

Two of the relations are particularly interesting: this is the first example of subtypes of the isa arc being used in language definition. The considerable semantics (rules) associated with the isa arc (isa arcs cannot form cycles, isa arcs are binary, etc.) are automatically inherited by the subtype isa and instance-of arcs.

Figure 43 shows an actual Constraint Graphs schema for the component types in KDraw. Node labels all begin with upper-case letters; arcs (relationships) are pictured as all lower-case letters. The surrounds (shapes) of nodes are similar in shape and style to those used in KDraw. Note that although role has no surround, it is a node and should not be confused with an arc. Constraint Graphs allows nodes with no surrounds (as in the present case) and arcs with surrounds (as in the Conceptual Graphs example) - it's up to the visual language designer to avoid the potential confusion that might arise.

Arcs in KDraw are all unlabeled (they are only labeled here for clarity), and for most part, are binary directed arcs (arrows) unambiguously distinguished by the (visual) type of their terminal objects. The cases where arcs types are not unambiguous are those in which the arc types have both terminals at concepts: isa, disjoint, and coreferent. These are visually disambiguated by isa being a directed arc, disjoint being an undirected arc, and coreferent being a bidirected arc.

Of course, each of the objects shown in Figure 42 must be constrained to conform to the graphical syntax of KDraw. This is done in the Constraint Graph schema of Figure 43. For nodes, this is trivial, for the arcs alone suffice to control the syntax. (Any nodes could stand alone and unattached without violating any KDraw rules, though they wouldn't be very meaningful.) The only predicates applied to nodes are regular expression constraints, which apply to the labels the end user puts on the various Constraint nodes. For the most part, arcs can be constrained by merely connecting their terminals to the appropriate type object. These terminals are (almost) precisely those shown in Table 6. Complications in the actual definition (Figure 43) arise due to the need to introduce additional types:

• to encapsulate the "polymorphic" has-role relationship,
• to handle the natural inheritance of visual attributes from Concepts to Individuals through instance-of arcs without giving Individuals all the semantics of Concepts (to be detailed below),
• to avoid cycles in the isa hierarchy when defining the isa KDraw relation, and
• to limit the syntax of labels on KDraw constraint nodes.

The next four sub-sections describe these issues in more detail.

7.3.1 "Polymorphic" Relations

Several different, otherwise unrelated, node types may appear on the "from" side of an arc connecting to a Role node type. A Rule, Concept, Primitive, and Individual may all connect to a Role. (But we can ignore Primitive because it is just a subtype of Concept.) There is no way to draw the prototype (defining) has-role arc with three tails and one head without distorting its meaning (its arity is meant to be two, not four). One way to get around the problem is to define three different has-role arcs: has-role-rule, has-role-concept, and has-role-individual. But this is not very elegant and seems to be contrary to the "natural" way of thinking about this relation.

A more natural solution is to encapsulate the commonality between rules, concepts, and individuals: they are all "things with roles". One can therefore define a supertype of all three called Objects-with-role. This is exactly what's done in Figure 43. The new type Object-with-role functions as the "from" terminal for the has-role arc, and Rule, Concept, Primitive, and Individual inherit the ability to have a role from Object-with-role.

7.3.2 Natural Attribute Inheritance

A second problem has to do with natural inheritance. Note that, in Figure 43, Individual is not a subtype of Concept, but if the Individual George is an instance of Child, it might be reasonable for the user to expect George to inherit the attributes of Child. In particular, one might expect that the visual attributes will be inherited: If one shades Person by giving it a fillColor attribute, then one expects the attribute to be inherited by Child through the isa arc and then to be inherited by George thought the instance-of arc, as it is in Figure 43.

Naively, one may consider making instance-of a simple subtype of isa, but this will not work. If instance-of were a simple subtype of isa, then George, in Figure 44, would inherit the ability, for instance, to be associated with a if-then arc, and this is not allowed (concepts have rules, individuals do not have rules). Thus, when the user shows the "Arc from" menu, the choices would be disjoint, coreferent, has-role, if-then, isa, and instance-of. But the only choices should be has-role and instance-of.

On the other hand, not making instance-of a subtype of isa means that individuals will not inherit visual attributes from the concepts that they are instances of. It seems there is no solution to the dilemma.

The problem lies in the modeling. Logically, there are two type lattices involved, not just one. One type lattice is used to determine arc termination eligibility, and is called the KR (Knowledge Representation) ontology. The other is used in attribute inheritance, and is called the domain ontology. The two ontologies are completely coincident except for the instance-of arc, which is in the domain ontology, but not the KR ontology. In the software, this scheme is supported by ontology filters as described in Section 5.3.

In practice, all that need be done is tag the prototype instance-of arc with the domain ontology filter as it is in Figure 45 where only the domain ontology is highlighted in the filter box. By default, all isa arcs are tagged with the universal ontology filter (where all ontologies are highlighted). This effectively solves the problem: attribute inheritance will occur though instance-of arcs because they are in the domain ontology, but instance-of arcs will not be considered when the system is performing type inferences, such as in arc termination eligibility. Using ontology filters neatly solves the problem without undue work on the user's part because different type lattices are normally highly coincident.

By the way, in Figure 43, the instance-of arc is drawn from Individual to Proto-Concept, and not to Concept, because Concept has its shape attribute tagged as constant. If Individual were to inherit this shape attribute from Concept, it could not override the shape to be its distinct rectangular shape. Therefore, the prototype instance-of arc must be drawn between Individual and some supertype of Concept that does not have a constant shape - Proto-Concept.

7.3.3 Avoiding isa Cycles

A KDraw isa arc may be drawn between any two concepts. Naively, one would just draw the prototype KDraw isa from the prototype Concept, back to the prototype Concept. But this is a cycle, and cycles are not allowed in type lattices. Fortunately, there's always a simple way out of the kind of dilemma: Just create a supertype of the target component, and connect the "circular" arc between the target and its supertype. This strategy has been used in Figure 43 to solve the problem of cycles.

7.3.4 Limiting the Syntax of Labels

Unlike most node labels in KDraw, constraint labels must conform to a very specific syntax. There are three types of constraints: cardinality constraints, subset ("in") constraints, and superset ("includes") constraints. Each of these types requires a specific syntax of their node labels. This is easily accommodated by the ad-hoc constraint "NameRegularExpression", which is a parameterized function object in the Constraint Graph's standard constraint library.

To attach the ad-hoc constraint, "NameRegularExpression", to a component, the user brings up the component's attribute dialog box (Figure 45) and selects the attribute "constraints". The "value" part of the dialog changes to an edit button, which the user can press to bring up a constraint editor. Figure 46 shows the constraint dialog for KDraw's Min/Max-Constraint (cardinality) node. To edit parameters of the "NameRegularExpression" constraint, the user chooses "NameRegularExpression" from the left-hand panel and then presses the "Edit Constraint" button. This brings up the NameRegularExpression parameter dialog box shown in Figure 47.

Ad-hoc constraint parameter dialog boxes are custom to each constraint. Figure 47 shows the one for "NameRegularExpression". It is just a multi-line edit box where the user may enter any number of regular expressions, one per line. The constraint merely checks to see that the component's name conforms to at least one of these regular expressions. Figure 47 shows the regular expressions needed to describe a KDraw Min/Max-Constraint. The first two expressions are required to accommodate the default names that might be assigned to the node upon creation. Including these two expressions allows the user to create the node without immediately specifying the actual constraint. The remaining three lines allow the user to express "at most n", "at least n", and "exactly n" cardinalities, respectively.

Of the three languages covered in this chapter, KDraw presents by far the greatest challenge to Constraint Graphs. Although KDraw was studied as a model for the initial theory and framework design, its actual implementation in the framework caused several iterations back to the theory and specification stages. For example, the "multiple ontologies" problem (Section 7.3.2) was unanticipated in the initial design and was only recognized when testing of the KDraw implementation yielded unexpected results.

7.4 Summary

This chapter has demonstrated the Constraint Graphs implementation of a variety of visual languages. These languages range from the simple to the complex, progressing though greater and greater challenges for Constraint Graphs. The example languages serve to demonstrate not only the features of the Constraint Graphs system, but also several strategies that can be used by visual language designers to implement languages in the Constraint Graphs system.

Figure 47

The first example, the gIBIS language for argument, is a very simple language. Its Constraint Graphs definition is described in detail, starting with the hidden, top-level abstractions and how they are used as the core to describe the concrete elements of the gIBIS language. The language syntax revolves around legal arc types, and these types are constructed to provide a usefully constrained user interface for the end user by specializing menus and specifying type inferences the system may make. Ad-hoc constraints are used to prevent unwanted subtyping. Constraint Graph's Levels are demonstrated by using them to hide details of the definition from the end user. Finally, the outcome of the gIBIS definition is explained by stepping through some of the operations that an end-user might perform in creating an actual gIBIS argument.

The second example, Sowa's Conceptual Graphs, is somewhat more complex than gIBIS. This example is used to describe Contexts, and to present a more complex example of the use of Levels. The Conceptual Graphs definition also serves to demonstrate more of the power of the inheritance relationships: inheritance is used by the end user to create a domain ontology. In contrast, the end-user in the gIBIS example merely unwittingly uses a discourse ontology created by the visual language designer.

The third example, KDraw, is a visual, executable, knowledge representation language, and is by far the most complex of the three languages. The KDraw definition demonstrates the use of abstract types to implement "polymorphic" relations, the use of ontology filters to create multiple type lattices in the same graph, the use of abstract types to avoid cycles in type lattices, and the use of ad-hoc constraints to limit the syntax of component labels.

The implementation of the three concept mapping languages in this chapter serves to both test and demonstrate the applicability of Constraint Graphs to implementing concept mapping languages. All of the current features of Constraint Graphs are exercised in the implementation of these languages. The value of implementing these languages in Constraint Graphs lies not only in the implementation per se, but also in the understanding of the target language that comes with the exercise of implementation itself. For example, testing with the implementation of Conceptual Graphs quickly pointed out some problems with Sowa's published ontology (Section 7.2) and the implementation of KDraw revealed an otherwise hidden structure of arc types. While the arc-centric structure of Constraint Graphs can be seen as unnatural with respect to the original conceptualizations of KDraw and Conceptual Graphs (which are both node-centric – see Section 9.3.2), the implementation in an arc-centric paradigm appears to be quite useful and insightful.

Chapter 6 index Chapter 8

Constraint Graphs: A Concept Map Meta-Language (PhD Dissertation), Department of Computer Science