Joseph Goguen

Meaning and Computation Lab

Dept. of Computer Science and
Engineering

Jacobs School of Engineering

University of California at San Diego

This note concerns formal notation for conceptual spaces, conceptual
morphisms, and conceptual blending, in the sense developed in *An Introduction to Algebraic Semiotics, with
Applications to User Interface Design*, hereafter refered to as
"*the paper*". Here, we expand and correct certain aspects of the
discussion there; also, instead of the notation developed there, we use the
notation of the OBJ algebraic
specification language, which is executable, though we use that capability
mainly to check the syntax of our theories and morphisms, i.e., as a type
checker for algebraic semiotics. For much more detail on OBJ, see the manual,
*Introducing OBJ*. OBJ3 is
available on UCSD CSE Unix machines at

If you are outside UCSD, you can ftp both OBJ3 and BOBJ via

`ftp://www.cs.ucsd.edu/pub/fac/goguen/`

The main code in this note runs under both OBJ3 and BOBJ, but an alternative version is described that only runs under BOBJ. The OBJ source files linked at the end of this note also include some test cases, to show how certain features work in practice.

Readers of this document should refer to the paper, especially the large diagram on page 20, and they will also need some of
the definitions given in the paper, especially those on pages 18 to 22. We
will refer to any diagram having the shape of the one below (from on page 19
of the paper) as a **diamond diagram**, and in such a diagram, refer to the
composition of the two morphisms on its left as its **left morphism**, to
the composition of the two morphism on its right as its **right morphism**,
to the middle upward morphism as its **center morphism**, to the triangle
on its left as its **left triangle**, and to the triangle on its right as
its **right triangle**. The extent to which these two triangles commute
will be an important part of our analysis.

Before we go further, please note that the names used in our formal
descriptions are arbitrary, in the sense that changing them does not in any
way change the formal meaning of the descriptions. This is because these
descriptions only concern formal structure, and do not even try to capture
*meaning* in any real human sense. However, we do try to choose names
that will help the reader's intuition.

Since it helps to consider concrete examples, let's look at how to blend
the two concepts "boat" and "house", as in the paper. We first specify the
builtin data types that are used in this example. These are the Booleans
(which are imported via the phrase `pr BOOL`, though it is actually
unnecessary, since `BOOL` is imported into every module by default),
and an enumerated type for what we shall call "media," having just two values,
land and water:

Next, we give theories for the three conceptual spaces that define this
example, beginning with the base space; all of these import the `DATA`
theory, as indicated by "`pr DATA`". Note that this base space not
only has sorts for the two kinds of thing in the example other than media, but
it also has a "generic element" for each sort, where the generic element has
the same name as its sort, but without the initial capitalization. (Of
course, this is an arbitrary convention, chosen to be helpful to human
readers, as are the names chosen for the sorts, elements, relations, and the
space itself.)

We now give the theory and three morphisms (three because the center morphism must be included, since we consider the base theory to be "auxiliary", in the technical sense of the paper) for our first blend of the two given spaces and three given morphisms:

For the `HOUSEBOAT` space with its morphisms, the two triangles
commute for all three sorts in the base space (noting that the sort
`Medium` is required to be preserved in any case, because it is a data
sort), and similarly the two generic constants `object` and
`person` are preserved (but not the constant `medium` - we left
it out of the new `BASE` space because commutativity would be
impossible if it were there, see the discussion in Section 3
of the Appendix), in that each maps to the same element of the blend space
via the three different paths. Similarly, each of the two relations in the
base space map to the same relation in the blend via the three different
paths. Moreover, for each pair of elements in the base space for which a
relation holds, the corresponding elements in the blend space satisfy the
corresponding relation, which means that all three paths preserve these two
axioms in the same way. Thus we have commutativity in the strong sense for
this blend. Since the `BASE` theory is auxiliary here, strong
commutativity is not required, and although strong commutativity holds for
this blend with the new base space, it does not hold with the original base
space. In summary, this blend has strong commutativity for everything except
the constant `medium`, and thus strong commutativity for the new base
space, but it has weak commutativity for the original base space.

Now let's consider a second blend. Here are its space and three morphisms:

Note also that all of the mappings in the morphism `M4` above are
defined by default: this works because everything that appears in the
`BOAT` theory also appears in the `BOATHOUSE` theory, with the
same name, so that `M4` is really an inclusion morphism.
Unfortunately, current implementations of OBJ do not type check the mappings
of elements in views; if this check were performed, the second `op`
line of the view `C` would fail, since it should map `person` to
`r:Universal>Person(boat)`.

For this blend, even with the second (smaller) base space, neither triangle
commutes in the strong sense, because the boat ends up in the house, as
reflected by the generic element `object` being mapped to `boat`
in the blend by the right morphism (which is the composition of morphisms
`M2` and `M4`), but being mapped to `boathouse` by the
left morphism (the composition of `M1` with `M3`); as a result,
the central morphism cannot preserve the element `object`, because
there is no consistent place to map it. Similarly, since `M4`
preserves `psngr`, the central morphism cannot preserve the generic
element `person`, and the some goes for the generic `use`
operation. On the other hand, the generic relation `on` goes to the
same place under all three maps, although its axiom is not preserved.

Notice also that in the morphism `M3`, the map of `resident`
to `boat` would not type check, whereas it does with
`r:Universal>Person(boat)`. Therefore we really should define a
different, even more restricted subtheory of the original `BASE` space,
on which everything commutes in the strong sense, and therefore weakly
commutes on the older base space. (This discussion differs from that in the
paper, which gave a space that did not include all possible material from
`BOAT`, e.g., the constant `psngr` and the relation
`ride` which holds of the passenger; but otherwise this blend is the
same.)

There is a third blend which is similar to (in fact, symetrical with) the
above `BOATHOUSE` blend, in which the house ends up riding in the
boat. (As noted in the paper, there are real world examples of this blend,
where a boat is used to transport prefabricated houses across some body of
water, e.g., for a new housing development on a nearby island.) This blend
has similar (in fact, symmetrical) commutativity properties to those of the
`BOATHOUSE` blend discussed above. It is left as an interesting
exercise for the reader to write OBJ code for this blend.

There is a fourth blend, the meaning of which is less familiar than the
first three, but the preservation and commutativity properties of which are
very good, corresponding to the fact that this concept is a very pure blend of
its input spaces, even though its physical existence is dubious. This concept
is that of an amphibious RV (recreational vehicle): a vehicle that you can
live in, and that you can ride in on land and on water. Here all aspects of
`HOUSE` and `BOAT` are realized, without any surprising
transpositions, like a house riding a boat. It is left as an interesting
exercise for the reader to write OBJ code for this blend. (The paper says
that this blend has worse preservation and commutativity properties than the
previous three, but this is an error.)

There is also a fifth blend, the meaning of which is even less familiar; it was discovered by Fox Harrell during his recent experiments with implemeting an algorithm to compute all blends for a given pair of input spaces over an input space. It involves a livable boat for transporting livable boats. In addition, these experiments emphasized that every blend can have each of the three choices of medium for its principal object, which leads to a number of variation of the blends described above, though several of them do contradict the way we normally use the words "house" and "boat". It seems that these can be eliminated by axiom preservation.

The OBJ code in this note has evolved, first running under OBJ3 and later under BOBJ; it did not always run the first time, because OBJ caught some bugs in the initial versions, which provides another important motivation for using a formal notation: it is all too easy to make simple, or subtle, errors when only informal notation is used.

It is interesting to notice that, depending on how we choose to handle truth values in OBJ, we can implement either the assumption that relations not declared true are false by default, or the assumption that it is not known whether they are true or false. (Of course, we can in any case write an equation that explicitly declares a relation to be false on some arguments.)

It is exciting that our intuitive sense of the relative purity of these four blends corresponds precisely to the extent to which their triangles commute, since this is the criterion given for measuring the quality of blends that is suggested in the paper.

To analyze "real" examples like that described above (though of course it is not "really real," but is an idealized model of some key aspects that are especially relevant to the blend in question), within the rigorous mathematical framework of algebraic semiotics (and OBJ), it is necessary to apply some `tricks' in writing the conceptual spaces and their morphisms. The purpose of this appendix is to explain in some detail some of the tricks that were used in the preceeding discussion.

A first challenge in writing formal definitions of conceptual spaces is how
to represent relations, and the facts that a certain relation holds, or does
not hold, on certain arguments. In OBJ, relations are not directly available,
so one must represent them with functions. The most obvious way to do this is
to use a Boolean valued function, with an equation to assert that the relation
is true of certain arguments, and also to assert that it is false certain
arguments. Then we can assert that an object can go on land or water just by
giving two equations with right side `true`. By using variables, we
can even make such assertions for an infinite class of arguments.

An alternative approach is to have an "attribute" function `medium :
Object -> Medium` which returns the medium of an object. Under this
approach, for a vehicle `v`to go on either land or water, we would have
to modify the `DATA` object, to

Perhaps the most interesting aspect of this issue is the light that it
sheds on the role of axiom preservation. Under the attribute approach, it is
not legitimate for blending to add media to an object. For example, if
`medium(v) = land` in a source space and that axiom is preserved by a
morphism `M`, then we cannot have `medium(v) = land-or-water` in
the target space. However, if the axiom is `medium(v, land) = true` in
the source space then `M` can preserve that axioms, and `medium(v,
water) = true` can also hold in the target space. This approach is taken
in the blending example, except that the relation there is denoted
"`on`" instead of `medium`.

So we conclude that the attribute function representation of relations is
less flexible, and less suitable for our purposes, than the Boolean-valued
function representation. (Of course, if an attribute axiom such as
`medium(v) = land` is not preserved by a morphism from an input space
into a blend space, then the blend space is free to do whatever it wishes with
that attribute; but intuitively, it seems that in the land-or-water case, the
axiom actually is preserved.)

A more sophisticated point is that in the Boolean-valued function approach, instances of a relation can be unknown, when there are no equations that give them a truth value. Hence there is an implicit three valued logic here, even though the explicit logic is two valued. In addition, there is a systematic way to treat unknown instances as false, by using conditions of the form

A second challenge is to use a notation that was intended for total preservation to represent partial preservation; we showed above how to do this using an OBJ view from subtheory, instead of the original source theory. The justification for this is that every partial morphism from the original theory corresponds to a total morphism from a subtheory of the source theory.

**3. Strong and Weak Commutativity**

We can use the trick of Section 2 above to reduce any instance of weak commutativity to a corresponding instance of strong commutativity over a subtheory of the source theory, and in fact, this is what we did in the main discussion above, by replacing the base space by a subtheory.

However, because we are trying to model "real" phenomena of blending, we
should give some further justification of our choice to make `M1`,
`M2` and `C` partial. Let us consider the second blend. Here
one can argue that `C` really should map the generic constant
`object` to the main object of `BOATHOUSE`, which is
`boathouse`. Actually, this argument is right for our conventional
boathouse concept, and `C` can perfectly well do this, but its
restriction to the subtheory will still be the morphism that we have given
above, so there is no problem here. (But it should be noted that there is an
alternative conceptualization where the focus of attention is on the boat
instead of the house, so this choice is somewhat arbitrary.) Of course, the
situation here is that the composition of `M1` with `M3` maps
`object` to `boathouse`, whereas the composition of `M2`
with `M4` maps `object` to `boat`, so that commutativity
would fail for the right triangle if all the morphisms were defined on
`object`, even though the left triangle would commute (or vice versa if
we took the other choice for `C`).

Our fourth trick appears in our first blend, the `HOUSEBOAT` blend.
Here we combined the two relations `live-in` and `ride` into a
single relation, `live&ride`, which plays the role of the generic
`use` relation. Although this example does not require it, it would be
possible to provide a "fine structure," showing that the `live&ride`
relation implies each of the `live-in` and `ride` relations. It
would then also be possible to map `live-in` and `ride` in the
input theories to the corresponding relations in the blend theory, although
this would result in less preservation and commutativity. For this reason,
the way we have set things up seems preferable.

**5. Metaphors and Metafunctions**

The classic literary definition of **metaphor** is that one thing is
said *to be* another thing (not just *like* another thing, which
would be a simile). Thus, in a strongly typed language, metaphors produce
type errors! Indeed, this presumably explains why they are considered to be
literary and even exotic rather than literal, although cognitive linguistics
has shown that metaphor is far more pervasive and fundamental in everyday life
than was previously realized, to the extent that they should not be considered
exotic at all. In any case, we need some way to accomplish what in the theory
of programming languages are called "coercions" (or sometimes "casts") for
data items. OBJ provides three of these, though only one of them is fully
satisfactory for our purposes, and that is the one used in the body of this
note. A second approach uses the builtin "metafunction"
`~setsort~ ` of BOBJ (but not OBJ3), which changes the sort
of the term in its second argument to become that of its first argument, in
this case `boat` and `Person`, respectively.

A third approach achieves a similar effect by declaring `Object` to
be a subsort of `Person`, as in the following:

I thank Fox Harrell and Lisa Tolentino for discussions of these ideas, which helped to clarify some of them (though they may still not be in their final form). Thanks also to Kai Lin for fixing BOBJ so that it could run this code.

To BOBJ source code for this webpage (it includes some test cases not shown on this page).

To BOBJ output for that source code.

To CSE 271 homepage

To CSE 171 homepage

Maintained by Joseph Goguen

Last modified: Fri Jul 25 15:24:51 PDT 2003