Motivation describes the motivation for our project. There, we recognise that there are many different views of systems structure, expressed in many different languages, and that these different views need to be related together. However, our experiences, over fifty years, tells us that the languages get in the way of this "relating together". They make rigid distinctions between things that are not fundamentally different, e.g. programs and data, procedures and interfaces, types and instances, processes and transactions, etc. Worse still, the strong distinctions made by each language are inconsistent with the distinctions made by other languages. We therefore want to get away from these distinctions and start from an extremely simple semantics.

We have developed a very simple modelling style that matches our motivation and enables us to relate together the many interacting views of system structure that were referred to above. The primitive semantics of this modelling style has just one type of object - a system, and one type of relationship connecting such objects - a role of a system as a component in another system. We show that this modelling style can cope with the full range of mathematical and business problems, and can be related to other modelling styles.

The basic concepts for our modelling style are described in Basic Concepts. Here, in this document, we describe the human view of, and interface to, the style, and encapsulate this in a modelling language. Another document, Programming Manual describes the language in more detail and adds features that make it easier to use.

Formats of Interface

In Basic Concepts, we showed how the graph C, held in our electronic store, models the current state of reality (or at least part of it). In the heads of humans, there is another model of the current state of reality (or at least part of it). Our electronic model only remains useful while the two models continue to be consistent with each other. The human-interface provides a correlation channel between these two models; the view presented at the human-interface faces in two directions; it is a representation of a small part of C and it is also a representation of a very small part of the real world, as seen by the humans.

Of course, there might, also, be other correlation channels linking the graph C model to non-human parts of the real world, e.g. sensors on machines.

We can see at least three possible formats that could be provided at the human-interface. Below we illustrate these three formats using one particular example - electricity utilities, with their customers, and their electricity generation and storage capabilities, all connected by their electricity transmission capabilities.

Italics are used, above, to show where systems are acting as role identifiers.

The remainder of this document concentrates, mainly, on the third of the above formats - the textual representation format.

Textual Labels

C, held within our electronic store, needs no textual labels. However, its representation at the human-interface does need such labels, for two reasons:-

Note, that the second reason does not apply to the first two formats in the previous section, only to the third; we are able to dispense with the labels cs-transmission, sg-transmission and gc-transmission in the first two representation formats, but not in the third. The first two formats are inherently graph structured, so can show directly where the same system appears in multiple places; the third, textual, format is inherently tree structured, so cannot represent the multiple positioning of cs-transmission, sg-transmission and gc-transmission, without giving them labels.

Note, also, that we do not need to give labels to the systems with roles identified by customers, storage and generation; this is because their roles are sufficient to tell humans their purpose (thus obviating the first reason above) and they each appear in only one place (thus obviating the second reason above).

A textual label can be thought of as a special form of identifier. Within C, identifiers are used to identify component systems performing roles within containing systems. If we think of the human-interface as a special example of a containing system, then labels can be thought of as identifiers for systems (that are visible at the human-interface) within that containing system.

Textual Human-Interface

We introduced our electronic store and contextual interpreter in Basic Concepts. With some relatively modest enhancements we can have a basic textual human-interface, providing a narrow correlation channel between humans and electronic store.

Our human-interface has three parts:-

The control unit ensures that, at any one time, one, and only one, of the following is happening:-

Remember, that in Basic Concepts, we defined the effect of the contextual bind operation with the diagram:-

Path Identifiers

Note, that, in the previous section, we used a dot notation (x.a and y.e) for path identifiers; this notation is defined as follows:-


is used as short hand for:-

      ≺ ≺head≻≺a≻, ≺tail≻≺ ≺head≻≺b≻, ≺tail≻≺ ≺head≻≺c≻, ≺tail≻≺NULL≻ ≻ ≻ ≻

(we have used the head/tail structuring for these path identifier systems; there is nothing sacrosanct about this choice; we could have used some other structuring)

It is very important to recognise, here, that, in C, the path identifier, a.b.c., is a system, just like its constituent role identifiers, a, b and c; it, too, could have a label at the human-interface; so, we could have said:-

      ≺fred a.b.c≻

is used as short hand for:-

      ≺fred ≺head≻≺a≻, ≺tail≻≺ ≺head≻≺b≻, ≺tail≻≺ ≺head≻≺c≻, ≺tail≻≺NULL≻ ≻ ≻ ≻

when providing the component structure a.b.c of the path identifier that is labelled 'fred'; other uses of this path identifier a.b.c could then simply use the label, i.e.:-


Path identifiers of length one present a problem; we need to distinguish between the path identifier of length one (effectively x.null) and the role (x). We could solve this problem by putting .null on the end of all path identifiers; rather than doing this, we put .¿ on the end of any path identifier of length one.

Note that in all the textual representations in this document, until half way through the last section, we used labels (such as fred above) for path identifiers rather than the path identifiers themselves (such as a.b.c above). In Programming Manual we use the path identifiers themselves, unless otherwise stated.

In Programming Manual we sometimes use the dot notation (eg x.a) when one or more of its constituent parts (e.g. x and a) are path identifiers rather than role identifiers; this is only valid if the human-interface knows the expansion of x and a in terms of role identifiers, and so can concatenate these expansions; otherwise, the human-interface would not be able to reify the path identifier in C.

Dictionary of Labels

It is the control unit, described in the previous section that provides the vital role in the human-interface; it converts between the representations, that are input and output at the human-interface, and their reifications, which are parts of C; to do this, it needs a dictionary that matches labels at the human-interface with systems within C.

The electronic store can hold representations of all systems, so it can hold representations of the systems that are the characters a, b, , 1, 2, 3, .; it can hold a representation of the system that is the string 12a, built from the representations of systems, 1, 2 and a; it can hold representations of any such string system. Thus, our dictionary could be included within C, and held in our electronic store.


In a high level language program, the association, between an identifier (e.g. i, j, k, fred, ...) and a variable, is scoped by the block structuring etc. of the language. Our equivalent of this association is the association between a role and the component system having that role. Our scoping of this association is very different from that of the high level language; firstly, the role may be taken by quite different component systems in different containing systems; secondly, each association can only be changed by a bind operation and remains valid until another bind operation changes it. There, is no block structuring within the sequence of bind operations that are interpreted by an interpreter, though this effect could be programmed into the sequence.

The scoping problem, described in the last paragraph, just pertains to C. However, we have another scoping problem at the human-interface that does not directly impact on C. In the previous section, we introduced the idea of labels, used at the human-interface, but discarded on entry to C. We could give global significance to these labels, so that each system in C has its own label; this would imply the existence of a very big dictionary; to avoid this we need to look at the label problem in more detail.

We can roughly divide the labels into three categories:-

The above suggests a pragmatic approach to the dictionary requirement. The control unit could use two directories, one containing the globally significant labels, the other containing labels significant to a particular design problem; the latter should contain the labels that link the design problem with other parts of C as well as the labels used within the problem. The second category, identified above, labels with no meaning, could be catered for with labels beginning with a standard prefix, such as @.


In Basic Concepts we said that the electronic store holding C must appear as a uniform persistent store; the interface to C must hide the fact that C is implemented across many machines; C presents a hyper-space image; the human-interface should be a user of this image and so need not concern itself with the problems of persistence.