The mixfix notation is a way writing/entering the predicate text of a fact type. For example, for the fact type "[Person] drives [Car]", the mixfix notation for this predicate is "... drives ...". Here the ellipses represent the "object holes" where the object types for the first and second roles would be placed when reading the fact type. Similarly, for the ternary fact type "[Student] receives [Grade] in [Course]", the mixfix notation for the predicate is "... receives ... in ...".

The most typical fact type pattern in ORM is what I call a simple binary fact type. This fact pattern is in the form of "[Object] predicate [Object]" with no predicate text preceding the first role or following the last role. In mixfix, this always looks like "... predicate ...".

However, sometimes predicate text needs to be entered before/after the roles. Adjusting our "drives" example above, the mixfix for the fact type might be "... drives ... erratically while yammering about trivial nonsense on a mobile phone" or "with a foot constantly on the brake ... drives ...".

The Visio for Enterprise Architects (VEA) fact editor figures out the predicate text for you because you specifically annotate the object types. For simple facts, the fact editor has combo boxes for each role in the fact. Alternatively, or if you have a non-simple fact type, you can use the freeform mode of the fact editor and then denote object types as Capitalized words or in [brackets], and the editor assumes the rest is predicate text.

Mixfix notation comes into play when you are editing the predicate text via the database properties sheet for the predicate. If you enter no ellipses for a binary fact type, VEA assumes it is a simple fact pattern when assembling the reading(s) of the fact type.

For non-simple fact types, you need to place ellipses in the readings to let VEA know where to place the objects when assembling the fact reading(s). For example,

It gets a little trickier with ternary or higher arity facts. Although there are n! readings per fact (where n is the number of roles) the database properties sheet for these predicates allows for one reading per role of the fact. Further, the first object hole of each possible reading has a distinct role. For example, given our ternary above, the first reading has to have Student in the first role position, the second reading has to have Grade in the first role position, and the last reading has to have Course in the first role position. The second and third role positions of each reading are open to either of the two unused object types (in any order). The way you specify the order of the remaining object types is to use a "%N" notation in place of the ellipses. Here N is the object type corresponding to the Nth role of the reading used when the fact type was created. In our ternary example, %1 would correspond to Student, %2 would correspond to Grade, and %3 would correspond to Course.

The first reading is a special case in that if you use ellipses for the object holes, VEA will assume the order of the object types are sequential (e.g. 1, 2, 3) based on the order they were entered when the fact was created.

Keep in mind that ellipses and the numbering notations described here can be applied even if the fact type is simple; VEA will know what to do... for the most part. If you have a ternary (or higher arity) fact type and do not supply alternate readings that have the expected object type ordering, you will see an "invalid reading" message in the verbalizer window and in any VEA reports. Most of the time, this limitation is not a problem but if it is, you can always supply the readings as you see fit; the Orthogonal Toolbox will render the readings as you intend in its XML extract functionality.