Graphical Notations

A visual walkthrough of the diagram language used to express facts, objects, labels, and business rules in FCO-IM models.

The Three Core Symbols

Every FCO-IM diagram is built from three fundamental graphical elements: Fact Types, Object Types, and Label Types. Each element plays a distinct role in representing how real-world concepts communicate meaning.

Connecting these elements are Roles — the small squares that sit inside or on the boundary of a fact, representing the position a concept plays within a sentence. Understanding roles is the key to reading any FCO-IM diagram.

Facts

A Fact Type captures a statement about the world. To build up a model, we start with the simplest possible assertion:

F1: <Country Name> is a country.

This gives us one fact type — Country — with a single role. The role is the placeholder for Country Name, which is a Label Type: it holds an atomic value such as "The Netherlands" or "Germany". Sample population tuples are displayed beneath the fact expression in the diagram.

Roles

Roles are the connective tissue of an FCO-IM diagram. Each small square represents a slot inside a fact where a concept is substituted. In the expression "<Country Name> is a country", the angle-bracket placeholder is a role: it is the position filled by any valid Country Name value.

When a fact connects two concepts — such as a capital city and a country — it will contain two roles, one for each concept. Roles are numbered uniquely within a model, making them unambiguous reference points for constraints and expressions.

Object Types

When a fact is nominalized — treated as a thing in its own right — it becomes an Object Type, drawn as an oval. Adding the fact "Amsterdam is the capital of The Netherlands" introduces two new concepts:

• Capital — a fact type that links Country and City
• City — a label type for city names

Because Country now participates in a relationship (it has a capital city), it is promoted to an Object Type in the diagram — an oval containing its identifying role.

Uniqueness Constraints

A uniqueness constraint (UC) is drawn as a bar spanning one or more roles. It asserts that the combination of values in those roles must be unique across the entire population of a fact.

For example, every Country must be uniquely identifiable, and every City must also be unique. We place a uniqueness constraint over role r1 (Country) and over the role inside City.

Totality Constraints

A totality constraint (TC) states that every instance of an object type must participate in a given fact. It is drawn as a filled black dot at the object end of a connecting line — reading: "every X must have a …"

In our model, every country must have exactly one capital city. Two constraints capture this: a totality constraint (every country must participate in Capital) and a uniqueness constraint over role r2 (each country appears only once in the capital population).

Reading rule
Read a totality constraint from the dot outward: "Every Country must have a Capital." Read a uniqueness constraint from the bar inward: "In Capital, each Country occurs at most once."

Subtypes

An Employee is a specialization of Person: every employee is a person, but not every person is an employee. This is expressed as a subtype relationship, drawn as an arrow from the subtype to the supertype.

Starting from the fact "John Doe lives in Paris, USA", which introduces Person and City of Residence, we then add "John Doe works in New York", introducing Employee as a subtype of Person and connecting it to a new fact type Employee for City.

Value Constraints

A value constraint (VC) limits the allowed values within a role. For example, if an employee may work for a maximum of three towns, we express this as a numbered sequence:

F5: <Employee> works in city <#city>: <Town Name>, <Country Name>.

The #city placeholder may only take the values 1, 2, or 3. This constraint is displayed on the role as a small annotated bar or inline annotation, restricting the population accordingly.

Graphical Element Identification

All elements in an FCO-IM diagram can carry explicit identifiers, which is useful for traceability and reference. By default these are hidden, but they can be toggled on in the diagram style preferences:

• Fact types, object types, and label types each have a unique name.
• Roles carry a unique role number (r1, r2, …).
• Fact expressions are prefixed with F (F1, F2, …).
• Object expressions with O (O01, O02, …).
• Totality constraints also receive their own identifier.

Identifiers are primarily a tool for documentation and cross-referencing. In most working diagrams they are turned off to keep the picture clean, and switched on only when producing formal specifications.

Summary

With the six elements covered on this page — Fact Types, Roles, Object Types, Label Types, Uniqueness Constraints, and Totality Constraints — you can read and interpret the vast majority of FCO-IM diagrams encountered in practice.

Additional constraint types exist for more advanced scenarios, such as set constraints, exclusion constraints, and frequency constraints. These build naturally on the foundation described here and are covered in the full FCO-IM documentation. Graphical identifiers and value constraints bridge the gap between diagram and formal specification, and can be toggled on demand in CaseTalk.

The diagram language deliberately stays close to natural language: if you can parse the fact expression, you can read the diagram. That alignment between text and picture is one of FCO-IM's most practical qualities.