Notation for Conceptual Blending
Formal Notation for Conceptual Blending

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

/net/cat/disk1/goguen/obj and the newest version of OBJ, called BOBJ, is also available on CSE UCSD Unix machines, by using the command java -cp /net/cat/disk1/bobj0.9/bobj.jar bobj.BOBJ

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


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:

obj DATA is pr BOOL . sort Medium . ops land water : -> Medium . endo An important convention in OBJ is that constants are considered operations with no arguments. The keyword obj indicates that a theory defines data, i.e., things with a fixed interpretation; in contrast, all the theories below use the keyword th, indicating a "loose" interpretation for their sorts and operations.

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.)

th BASE is sorts Object Person . pr DATA . op object : -> Object . op person : -> Person . op medium : -> Medium . op use : Person Object -> Bool . op on : Object Medium -> Bool . eq use(person, object) = true . eq on(object, medium) = true . endth Other important conventions are that relations are represented by Boolean valued functions, and that a relation holds of two arguments if the value of the function is true for those arguments; this can be expressed by equations, as in the above theory (see also Section 1 of the Appendix). A different kind of convention relates OBJ notation to algebraic semiotics by assuming that the "top" sort of a theory is the first sort mentioned in it; however, OBJ notation cannot directly express which sorts, if any, are secondary, tertiary, etc. It also cannot directly express priorities on constructors, but that is less relevant here because there are no constructors other than constants. Next we give theories for the two input spaces: th HOUSE is sorts Object Person . pr DATA . op house : -> Object . op resident : -> Person . op live-in : Person Object -> Bool . op on : Object Medium -> Bool . eq live-in(resident, house) = true . eq on(house, land) = true . endth th BOAT is sorts Object Person . pr DATA . op boat : -> Object . op psngr : -> Person . op ride : Person Object -> Bool . op on : Object Medium -> Bool . eq ride(psngr, boat) = true . eq on(boat, water) = true . endth For historical reasons, what are called "morphisms" in algebraic semiotics are called "views" in OBJ. Here are the two morphisms that are given as part of the setup for blending "house" and "boat", again using OBJ notation: view M1 from BASE to HOUSE is op object to house . op person to resident . op use to live-in . op medium to land . endv view M2 from BASE to BOAT is op object to boat . op person to psngr . op use to ride . op medium to water . endv A feature of OBJ is that if a morphism preserves something with exactly the same name, then that need not be explicitly mentioned. Moreover, everything in DATA is automatically preseved, because it is a shared subtheory. For example, each of the above morphisms is assumed by this convention to map the sort Object in the BASE theory to the sort Object in its target theory. The same holds for the operation on, which is not mentioned in either M1 or M2. This convention makes it tricky to represent cases where there is some thing with the same name in each the source and the target space of a morphism, but we do not want this thing to be preserved. The solution is to define a subtheory of the source theory that does not include the unpreserved things, and then define the view from that subtheory. In fact, the generic element medium cannot be preserved by the central morphism of any blend, because of the inconsistency of the way it is mapped by M1 and M2; for this reason, we will actually use the following subtheory of the base space given above: th BASE is sorts Object Person . pr DATA . op object : -> Object . op person : -> Person . op use : Person Object -> Bool . op on : Object Medium -> Bool . eq use(person, object) = true . endth There is an obvious inclusion view from this to the previous base space, i.e., the new base space is a subtheory of the old one. Because of another OBJ feature, the name "BASE" from here on refers to the new space, rather than to the earlier one of the same name. We also need new morphisms M1 and M2 from the new base space to HOUSE and BOAT, respectively; these are the same as the old ones, except that they omit the generic element medium. view M1 from BASE to HOUSE is op object to house . op person to resident . op use to live-in . endv view M2 from BASE to BOAT is op object to boat . op person to psngr . op use to ride . endv Actually, we can argue that the first base theory is wrong, because media are attributes of objects, rather than generic elements of conceptual spaces; in particular, two different objects in the same space could very well have two different media (we will see an example below), which would not be possible if there were one fixed medium for the whole space (see also the discussion in Section 1 of the Appendix).

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:

th HOUSEBOAT is sorts Object Person . pr DATA . op houseboat : -> Object . op resident : -> Person . op live&ride : Person Object -> Bool . op on : Object Medium -> Bool . eq live&ride(resident, houseboat) = true . eq on(houseboat, water) = true . endth view M3 from HOUSE to HOUSEBOAT is op house to houseboat . op live-in to live&ride . endv view M4 from BOAT to HOUSEBOAT is op boat to houseboat . op psngr to resident . op ride to live&ride . endv view C from BASE to HOUSEBOAT is op object to houseboat . op person to resident . op use to live&ride . endv A careful discussion of blending should distinguish between a space (at the top) and three morphisms (to it) forming a diamond diagram (over given three spaces and two morphisms), which is a potential blend, and a space and three morphisms which really are a blend. We therefore call the former a blendoid. For example, the completely empty conceptual space is unlikely ever to be a blend, because nothing is preserved, even though everything commutes. We now define a blend to be a maximal blendoid, not just as a theory, but in terms of the commutativity and preservation properties of the theory and three morphisms together. (A precise, but difficult, mathematical definition is given in Appendix B of the paper.)

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:

th BOATHOUSE is sorts Object Person . pr DATA . op boathouse : -> Object . op boat : -> Object . op live-in : Person Object -> Bool . op on : Object Medium -> Bool . eq live-in(r:Universal>Person(boat), boathouse) = true . eq on(boathouse, land) = true . eq on(boat, water) = true . op psngr : -> Person . op ride : Person Object -> Bool . eq ride(psngr, boat) = true . endth view M3 from HOUSE to BOATHOUSE is op house to boathouse . op resident to r:Universal>Person(boat) . endv view M4 from BOAT to BOATHOUSE is endv view C from BASE to BOATHOUSE is op object to boathouse . op person to boat . op use to live-in . endv Here r:Universal>Person(boat) is a retract, a polymorphic function builtin to both OBJ3 and BOBJ which changes the sort of the term in its argument from that the first sort after the ":" to become that of sort after the ">", in this case boat, Universal, and Person, respectively, where Universal is a builtin sort that contains all other sorts. Without this change of sort, it would be impossible for the boat to live in the boathouse. In fact, as discussed in Section 5 of the Appendix, this signals the presence of a metaphor, in which a boat is considered a person. Note that in the last equation, the boat is not viewed as a person.

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.

Appendix: Five `Tricks of the Trade'

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.

1. Functions vs. Relations

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 vto go on either land or water, we would have to modify the DATA object, to

obj DATA is pr BOOL . sort Medium . ops land water land-or-water : -> Medium . endo and then write the equation eq medium(v) = land-or-water .

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

r == true . where r indicates a relation with some particular arguments, and == is OBJ's builtin polymorphic equality function. The above expression will be false when r is either false or undefined, thus implementing what is known in AI as the closed world assumption. Similarly, not r == false . will return true when r is either true or undefined. (These rather sophisticated representations are not needed in the examples discussed above, because only very simple reasoning is required to check that the axioms are preserved.)

2. Partial Preservation

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).

4. Conjunctive Relations

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.

th BOATHOUSE is sorts Object Person . pr DATA . op boathouse : -> Object . op boat : -> Object . op live-in : Person Object -> Bool . op on : Object Medium -> Bool . eq live-in(~setsort~(Person, boat), boathouse) = true . eq on(boathouse, land) = true . eq on(boat, water) = true . op psngr : -> Person . op ride : Person Object -> Bool . eq ride(psngr, boat) = true . endth However, as the BOBJ output linked at the bottom of this page shows, this approach does not behave as we desire.

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

th BOATHOUSE is sorts Object Person . pr DATA . subsort Object < Person . op boathouse : -> Object . op boat : -> Object . op live-in : Person Object -> Bool . op on : Object Medium -> Bool . eq live-in(boat, boathouse) = true . eq on(boathouse, land) = true . eq on(boat, water) = true . op psngr : -> Person . op ride : Person Object -> Bool . eq ride(psngr, boat) = true . endth However, this is too strong, because it allows every object to be seen as a person, for example, the boathouse, which we do not want seen as a person in this example.

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