Gerry's Home Page Preliminary Materials Chapter 1 Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 Chapter 8 Chapter 9 Chapter 10 Chapter 11 Bibliography Appendix

Sec 10.3

10.3      Defining Interpretive Critics

Interpretive critics. Interpretive critics in the Lunar Habitat Design Environment (Lhde) built on Hermes play much the same role as critics in Janus and triggers in Phidias, as discussed in Chapter 7. In Lhde the critics are not active the way that Janus’ critics were, although a different design environment built on the Hermes substrate could make use of the same mechanisms as Janus to activate critics associated with a design unit whenever an instance of that unit is created or moved in a design construction. In Lhde and Phidias II (which is also built on Hermes), critics are tied to user interface buttons to provide Phidias-style triggers. Interpretive critics can be used whenever a user has them evaluated by means of any interface mechanism. That is, designers can define and evaluate interpretive critics very freely, without necessarily having them tied to design units in a palette component or to predefined buttons in a construction interface. Interpretive critics are, thus, more general than the critics and triggers of the related systems they were inspired by.

Interpretive critics are defined using the Hermes language. They can take advantage of all of the expressive power of the language. Basically, a critic is any expression in the language that analyzes the state of the hypermedia database. Typically, a critic looks for certain features in a graphical construction and displays a message or takes some other action depending on whether the feature is found or not. The message can include design rationale or examples explaining the reasoning behind the critic definition. It might, for instance, include a selection of items from the design rationale, through which the designer can browse, e.g.:

privacy check of habitats and deliberation of privacy issue

By using the Hermes language, interpretive critics can be more general, more expressive, and more complex than Janus critics. They are not restricted to spatial relations of individual design units in the palette or to a single construction area. They can analyze, for instance, multiple habitats in the database, evaluate global characteristics of designs (like number of parts or absence of particular parts), and make their analysis dependent on other conditions in the database. Examples of complex critics are the privacy critics described in Chapter 9 and the academic advising critic discussed in Appendix B.

Because the whole language can be used and the whole database accessed, critics can be made dependent upon information in other designs, in an issue base, or in a distinct specification component (as indicated in Chapter 8). The critics can play an important role in integrating diverse pieces of information in the system.

Critics in Hermes are called interpretive because of the synergy which they engender between the Hermes language and the mechanism of interpretive perspectives. This is best explained with an example. Suppose Desi defined a critic named refrigerator access as:

if refrigerators are too near doors then refrigerator access message

Now, if Desi had defined too near as closest distance is less than 5 feet but Archie had modified too near to be closest distance is less than 3 feet, then the refrigerator access critic will be “interpreted” differently in Archie’s perspective then in Desi’s. Since the language allows critics to be built up to arbitrary levels of complexity, a critic like the academic advising critic (in Appendix B) may be dependent upon the definition of many sub-expression, which may be defined differently in different perspectives. The point in the example is that Desi and Archie have different interpretations of what it means for something in the kitchen to be too close to something else. In another domain (e.g., molecular chemistry or astronomy) the term too near might need to be redefined more drastically. The perspectives mechanism assures that the evaluation of an interpretive critic will always interpret the terms and sub-expressions of the critic’s definition within the context of the current active perspective.

Comparison with Janus critics. Hermes critics are defined in the high level representations made available through the language. That is, they can be defined using vocabulary that is close to the problem domain, without needing to think in the explicit functional manner of the Lisp syntax used by Modifier. All of the critics used in systems like Janus and Modifier can be concisely stated in the Hermes language. Following are definitions of terms used for defining these critics:

next to:     closest distance is less than 4 inches

far from:    closest distance is more than 30 inches

close to:    central distance is less than 60 inches

near:        closest distance is less than 12 inches

set off from:     close to and not next to

work triangle distances:    list of closest distance in feet among sink, stove, refrigerator

Using these terms, the equivalent of Janus’ critic rules can be concisely and readably defined as follows in the Hermes language:

all stoves are set off from sinks

no stoves are next to refrigerators

all stoves are far from all doors and windows

all dishwashers are next to sinks

all refrigerators are far from all windows

refrigerators are close to doors

sinks are near windows

the minimum work triangle distances are less than 23

In Modifier, the critic rules are meant to be available to and modifiable by the end-user. However, they are written in Lisp. Thus, a designer wishing to modify a critic rule in Modifier must be at least somewhat familiar with the complexities of Lisp doctrine, including its non-intuitive Polish notation. In addition, conventions of Modifier’s property sheets must be understood and used to make explicit computational decisions. For instance, the Hermes critic,

all stoves are set off from sinks

appears in Modifier’s property sheets as:

not_next_to (stove , sink )      apply to: all

near (stove, sink)               apply to: one

The parentheses of Lisp in Modifier’s critics are replaced in Hermes by an implicit nested phrase structure that is familiar to people from natural language. This nesting is unambiguously determined at definition time through the tacit use of the interface to the language discussed above. Figure 10-4 shows the explicit phrase structure for the critic rule just discussed. Note that this diagram not only expands the definition of set off from (which has been abstracted in the rule statement), but also indicates the clauses at least one and in kitchen, which are computationally important but are implicit in the expression that the user sees and manipulates. That is to say, both the structure of the critic and substantial contents of it are kept implicit and are hidden from the user’s explicit understanding, in much the sense that the explicit phrase structure of normal speech is not usually an object during ordinary communication.


Figure 10-4. Phrase structure of a Hermes critic rule.

The critic rule can be read from the leaves of the tree: all stoves are set off from [at least one] sinks [in kitchen]. Phrases in brackets are implicit. The phrase set off from can be expanded as: central distance is less than 60 inches and not closest distance is more than 4 inches.


The point of this diagram is not to show how complex interpretive critics are internally, but on the contrary to show how rules that are inherently quite complex can be expressed in apparently relatively simple expressions (like, all stoves are set off from sinks), which hide much of the complexity that the user ordinarily does not need to be concerned with.

Analysis of the privacy critics. The privacy critics developed in the scenario of Chapter 9 provide a good example of a complex definition in the Hermes language. A close look can reveal both some of the advantages of using the language and also some of the difficulties.

The task of the privacy critic is to determine if public areas of a lunar habitat are too near to private areas. So first the notions of privacy and nearness must be operationalized and applied to areas within habitats. A privacy values scale from 1 to 9 is established and these Number values are given names from very public (1) to very private (9). Links of type privacy rating are attached to various parts of the habitats and connected to nodes with appropriate privacy values. The Measure term too near is defined as:

closest distance is less than 5 feet

Now it is possible to define public and private areas:

public area: parts that have privacy ratings that are less than somewhat public

private areas: parts that have privacy ratings that are more than somewhat private

These are Computed Associations or Predicates. They look at all the parts of whatever DataList they are applied to. These parts are then Filtered by checking if they have privacy ratings links and furthermore if the nodes connected by such links lead to values greater or less than the values named somewhat private or somewhat public. Any parts found that have at least one such link will be returned by these expressions.

It would be more efficient to make these definitions for immediate parts (i.e., top level parts of the habitats) rather than all parts (including subparts, all the way down to primitive graphical polygons). That would save considerable traversal of the hierarchies of graphical objects making up the habitats. However, that would require that the person defining the expression knew that all the relevant public and private parts were defined as top level parts of the habitats. If the designer defining this expression had also constructed the habitat graphic this would be possible. For the sake of generality that has not been assumed in this discussion.

Note that a given part might have multiple privacy rating links (even in the same perspective). The definitions above only require one such link meeting the Filter condition. Thus, a given part could be returned as both a public area and a private area. Such an anomaly would quickly show up as a problem area in the critic results. In general, the ability of the definitions to deal reasonably with such multiple-definitions is an aspect of robustness in the Hermes language. It is discussed in Appendix B under the topic of defeasible reasoning.

The next step is to create a display of problem areas, that is, private areas that are too near to public areas. This can be accomplished with the following definition of problem areas:

private areas that are too near public areas of that (last subject) with those items

The idea here is to select one private area of a habitat at a time and for each one to then iterate through all the public areas of the same habitat and list the public areas that are too near to the selected private area. Both private areas and public areas are Associations that operate on the same habitat (DataList) when the overall problem areas Association is applied to a habitat or a list of habitats.

The Filter syntax option used in the definition of problem areas has the following form: Measure [Quantifier] DataList [in Graphic]. The Measure has already been defined and stored with the name too near. The optional [Quantifier] defaults to an implicit “at least one”. The DataList that the private area is to be measured to is each public area of whichever habitat is currently being operated on by the problem areas Association. To define a DataList consisting of these public areas, the deictic variable, that (last subject), is used to refer to the habitat to which the problem areas Association is applied. This deictic refers to the most recently defined “subject” to which operators are being applied, namely the “subject” of the problem areas Association. Here the term “subject” refers to the DataList that is the input to the evaluation of an expression. A stack of recent subjects is maintained in order to implement this deictic variable. The parenthetical explanatory phrase, “(last subject)”, departs from the tacit feel of the language in order to alert the reader to think explicitly about the computational structure of operator application in this case because a reference is being made to some term outside the immediate expression—namely to the subject to which this expression will be applied.

The optional [in Graphic] phrase defaults to in that (last subject), which, again, refers to the “subject” of the problem areas Association. That means that the measurement of distance between the private area and the public area is computed within the graphical habitat. Unless a graphical object is explicitly named as the context for distance measurements, the assumption is made that the last explicitly named subject should serve this role. The necessity of naming (tacitly or explicitly) a graphical context for measurements arises from the generality of the Hermes language, which can be referring to any object in the database, rather than to the content of a unique construction area as assumed in Janus and Phidias.

 Finally, in the definition of problem areas the deictic variable those items refers to the most recently enumerated items, namely the public areas that are enumerated for each private area and that satisfy the Filter condition. During the testing of the Filter condition, the successful enumerated items are stored on a special list that can be referenced by the special deictic variable “those items”. Thus, the with those items phrase following the Filter phrase retrieves the list of public areas that are too near a given private area and adds them to the result list of the critic following that private area and indented under it.

Now that the computational heart of the privacy check critic has been defined, the critic can be assembled. First, a privacy message is defined to be displayed in the case that no problem areas are found for a given habitat. This is simply a Character node with the contents:

“Public and private areas are separated.”

This node can be named privacy message or it can be linked to the privacy check critic itself. If it is named, the critic is defined as:

name with either name of problem areas or privacy message

If it is linked with a link of type message, then the critic is defined as:

name with either name of problem areas or message of this (expression)

In the latter case, the reference to the privacy message is replaced by a computation, message of this (expression), using the deictic variable this. The variable this (expression) refers to the current object itself, so message of this (expression) follows the message link from the definition of this critic to the Character node whose content is the required message. Again, the use of parentheses signals the need for some explicit reflection by the reader.

The privacy check critic uses the implicit if / then construction, either / or, in which the first phrase is used if it produces any results, otherwise the second phrase (in this case, simply displaying the message) is used. The principal work done by the definition of privacy check is to display the names of graphical objects, rather than displaying them as graphics. Privacy check is a Computed Association that is applied to a DataList of one or more habitats. So it first displays the name to the habitat to which it is being applied, then (indented under that name, because of the with conjunction) it computes the list of problem areas of that habitat and displays the names of all the items in the resultant list (including the names of the public areas that are indented in the list under the private areas). If the resultant list was empty for a given habitat, the privacy message is displayed instead.

In the scenario, a variation on privacy check named privacy display was defined:

name and privacy ratings of problem areas

This critic displays the privacy ratings as well as the names of all items in the list computed by the problem areas Association.

Recall from Chapter 3 that the lunar habitat designers eventually settled on a concept of privacy gradient in the transcribed session. That meant that they wanted the arrangement of the habitat to change gradually from private areas to public areas. To operationalize this notion, one could introduce a test to see if any two areas that are near each other differ by more than a value of, say, plus or minus two. This introduces explicit arithmetic computations into the definitions of a critic. It also introduces a complicated comparison of each habitat part with all the other parts of the habitat. The following set of definitions can be used to compute habitat parts that are incompatible in this sense of a privacy gradient.

In the Chapter 9 scenario, the designers ended up with a critic called privacy gradient catalog. It goes through all habitats in the database, selecting those for which privacy ratings links are attached to some parts. For those habitats, it displays their name and an analysis of how they meet the defined privacy gradient considerations:

name with privacy gradient critique of habitats that have parts that have privacy ratings

For each habitat that has privacy ratings, the privacy gradient critique is displayed. This is similar to the privacy display, above, in that it computes problem parts using a privacy gradient listing Association, or else displays a privacy gradient message. Here are the definitions to handle this:

privacy gradient critique: either privacy gradient listing or privacy gradient message

privacy gradient listing: name and privacy ratings of parts that have privacy ratings with their problem parts

privacy gradient message: “The parts of this design are arranged along a privacy gradient.”

The privacy gradient listing Association iterates through the parts of a habitat and for each part lists (indented) their problem parts. The definition of problem parts is the tricky part. It uses three further definitions: too near, other parts, and are incompatible. The Measure, too near, is the same as it was in the privacy check critic, except that in the current perspective it has been modified from 5 feet to 3 feet:

problem parts: name and privacy ratings of other parts that are too near that (last subject) and that are incompatible

too near: closest distance is less than 3 feet

other parts: parts of inverse parts that do not equal that (last subject)

are incompatible: have privacy ratings that are more than privacy ratings of that (last subject) + 2 or are less than privacy ratings of that (last subject) -2

The definition of other parts requires some explanation. Within the privacy gradient listing expression, the Association problem parts must be applied to parts (of a habitat). The definition of problem parts centers on the definition of other parts. However, what is wanted is “other parts” of the habitat, not other parts of the selected part of the habitat, which is what would result from the application of problem parts to parts. Therefore, within the definition of other parts, the computation must get back to the habitat by tracing backwards the part link between the habitat and its part. This is accomplished by the construction, inverse parts. Once the computation is back at the habitat, it can find the other parts by navigating all the parts (i.e., graphical content) links of the habitat. Of course, the computation of “other parts” should exclude the part from which the computation began in order to avoid comparing that part with itself. This is accomplished with the Filter, that do not equal that (last subject), in which the deictic variable that (last subject) refers to the last “subject” of application, namely the original part iterated in the privacy gradient listing expression.

The definition of the Filter, are incompatible, uses the same that (last subject) variable in order to compare each of the other parts with the original part. This Filter also introduces explicit arithmetic in order to judge whether the privacy ratings of these two parts differ by more than 2 on the privacy scale. This comparison completes the operationalization of the idea of a privacy gradient as it occurred in the lunar habitat design transcript.

The definition of privacy gradient catalog with all its preliminary definitions is a relatively formidable task. If one undertakes figuring it out from scratch, it might well seem that the task is easier to do in a traditional programming language. This seems especially true to people who are experienced in programming. It may well be that such a task pushes the Hermes language to near its limits. On the other hand, a design environment built on the Hermes substrate might support reuse and modification sufficiently to make the Hermes alternative preferable. First, much of the defining could have been done in the seeded set of language definitions, providing a well thought-out collection of building blocks for complex tasks involving privacy. If this was not available in the original seed, a reseeding process could take place when the privacy issue is raised as an important concern. Then an experienced programmer or a Hermes local developer could step in and provide a set of privacy-related definitions for everyone to use.

As stated at the outset of this chapter, the Hermes language has been developed to push its approach to supporting a mix of tacit and explicit understanding as far as possible and to explore its limits. The privacy gradient critique expression provides an important test of these limits. On the one hand, it shows that the task that appeared extremely challenging back in Chapter 3 can in fact be accomplished using the Hermes language. On the other hand, it shows that such a task may strain the limits of the language. The limits of the language are explored further by examples in Appendix B. More thorough experience will have to await the building of robust design environments on the Hermes substrate and their use by a community of designers.

Go to top of this page

Return to Gerry Stahl's Home Page

Send email to

This page last modified on January 05, 2004