Part 1 of this post focused on the structural relationship between information elements. It discussed how a well-formed data model must reflect the ontology of the information that is processed and exchanged including its principal modalities, how messages are projections from the data model, how subject matter can be organized into layers of entity-relationship models supported by an underlying architecture framework, how a logical data model is refined from a conceptual data model.

Part 1 also hinted that interoperability requires that each information element in the data model is rigorously defined. This is the focus of Part 2. It will be shown that a well-formed data dictionary requires a mathematically coherent structure, and that this structure strengthens the structure of the data model.

Information elements that need to be defined

Semantically, we are interested in the definitions of entities and their properties.

It has been shown that an entity is an identifiable, enduring thing in the real-world. At least, it is enduring over the time frame of interest. Theoretically, it would possible to define an entity type solely by declaring all of its properties, but this is rarely practical. It is more convenient to declare only the properties whose values we need to process and communicate in the system. Therefore, an engineering definition of the entity type is usually required together with a declaration of its properties of interest. We will, of course, take advantage of generalization and specialization in the model. It will be remembered that in UML a type can be a class or a data type. Entity types are modeled in UML as classes.  An instance of a class is an identifiable thing (such as a particular robot). In contrast, the instance of a data type is a value (such as 1000 m altitude).

In UML, a type owns properties whose notation includes the property name and the property type. In UML it is conventional (but not enforced) to express a property as an association if the property type is a class and express a property as an attribute if the property type is a data type. To illustrate this, the figure below shows an entity type (RobotType) owning two properties. The first property is the attribute ‘speed: SpeedType’, where ‘speed’ is the attribute name and ‘SpeedType’ is the data type (an attribute type in the UML notation for an attribute). The second property is an association named ‘carries’ with the class ‘PayloadType’.

RobotType with two properties

The importance here is to recognize that a data dictionary is not only interested in the definition of types (specifically entities and attribute types) but in the complete definition of properties, whose notation includes the property name also. It will be remembered that an attribute name can be different at each end of a message projection. Therefore, a strong understanding of the semantics of property names is important to interoperability. A common mistake is to assume that an attribute name is simply an alias for the attribute type in the context of the owning type and therefore somewhat arbitrary. When Shakespeare’s Romeo asked himself ‘What is a name?’ he also concluded that a name was of no importance, but in the end it led to his untimely death. In UML, an attribute name can denote a world of engineering information that must be addressed in a data dictionary.

Mathematics of properties

Here we will explore the semantics of an attribute name through set theory and predicate logic.

In set theory, the set of all elements described by a model (M) may be called the M-set, whose subsets are collections of instances of the UML types in the model (classes and data types). Thus we can think of a specialized type as defining a subset of instances of the generalized type through the axiom of separation.

The axiom of separation states that for every set A and every given property, there is a subset C containing exactly the elements of A that have that property.  A property is expressed by the formula ϕ of the first-order language of set theory. Given any formula ϕ(x, y1, … , yn), and sets A, B1, … , Bn, it is possible to form a subset of all those elements of A that satisfy the formula ϕ(x, B1, … ,Bn).

This subset is denoted by C = {a ∈ A : ϕ(a, B1, … , Bn), … }.

The first order language of set theory is based on predicate logic in which ϕ is a predicate and (a, B1, … , Bn) is the argument of the predicate. In a UML data model, the predicate ϕ is represented by a UML property name (such as an attribute name or association name), the element a of set A is an instance of the subtype C that owns the property, and B1, … , Bn are the related property types. In the case of attributes, these would be data types, and in the case of associations these would be classes.

In the figure below we have a set defined by Class C which is a subset of a set defined by Class A because it extends Class A with two properties V and π.  The first denotes an attribute and the second denotes an association.

M-set with subsets specified by types

It is clear from this the property name always has semantic importance as it defines the nature of the mapping from one type to another. In conclusion, a data dictionary structure needs to separate out the semantics of types from the semantics of property names.

An example of a property we have used before is the attribute ‘speed: SpeedType’ owned by RobotType. In predicate logic this may be written as ‘speed(x, SpeedType)’ where x is an instance of an unspecified class or ‘speed(a, SpeedType)’ where it is important that the property only applies to Class A. In practice, we can think of ‘speed(x, SpeedType)’ as an a-priori property because it can be defined without prior knowledge (or a prior declaration) of the entity type that owns the property. We all have an independent understanding of the attribute of speed. Conversely, we can think of ‘cruisingSpeed(a, SpeedType)’ as an empirical property of a given entity type A (such as VehicleType) where the entity type and its owned property are semantically coupled. We cannot conceive of the attribute cruisingSpeed without first conceiving a vehicle entity type.

Categorical frameworks for data types

In Part 1 we discussed data type abstraction, which has a lot of utility in the specification of attributes. When we partition attribute types into conceptual and logical forms, we must restate our property ‘cruisingSpeed(a, SpeedType)’ as:

• cruisingSpeed(a, SpeedObservableType) in the CDM, and for example
• cruisingSpeed(a, EarthFixedENUVelocityKnotsMeasurementType) in the LDM

It is important to our understanding of an observable type and a measurement type that the refinement options must not affect the semantics of the attribute name. However, a different choice of observable type would, for example:

• fuelAmount(a, MassObservableType) does not mean the same as
• fuelAmount(a, VolumeObservableType)

In Part 1, we also touched upon the notion that we might be able to faithfully translate between one logical message attribute and another logical message attribute if and only if:

• the attribute name can be substituted for a semantically identical attribute name, and
• for all possible values there is a morphism from measurement type X to measurement type Y (denoted as f: X → Y) and vice versa (g: Y → X).

The structure of morphisms is handled in mathematics by category theory, which is a useful way of understanding the relationship between observables and measurements. We can think of an observable type as a category (in fact, a 2-category) of measurement categories. Within a measurement category are measurement types that share a common mathematical structure. Understanding data types in the context of category theory helps us understand the possibility and limitations of message translation.

Category theory is a general theory of structures and systems of structures, which serves as an alternative to set theory as a foundation for mathematics.

Mathematically, an ordinary category C is specified by:

• A set Ob(C), whose members are objects of C
• For every pair X, Y of objects, there is a set Hom(X, Y) called the morphisms from X to Y in C.

The morphisms of an ordinary category are often called functions. In higher category theory, an ordinary category is called a 1-category with 1-morphisms. A 2-category has, in addition, 2-morphisms between the 1-morphisms. 2-morphisms are often called functors. This pattern continues to an n-category, which has n-morphisms between (n-1) morphisms. Note that a set (with no morphisms between elements) is called a 0-category (set theory itself can be described by a 1-category).

Observable types and measurement types as categories

The figure above shows the general case of when an observable type can be refined into various categories of measurement type, such as quantity vector measurements, scalar quantity measurements, and enumeration sets of nominal properties. In fact, we are interested in defining both the measurement types and the morphisms between measurement types and between categories of measurement types. For example, a Euler angle is the parameter of a transformation matrix (a function) between two vector measurement types based on different axes. A popular example would be the roll, pitch, and heading Euler angles that specify the transformation between a north-east-down (NED) axis system and a vehicle body axis system.

Not all functions and functors are lossless. A lossy morphism is called ‘a forgetful morphism’. For example, the functor from vector measurements to scalar measurements is forgetful because the direction information is lost. The same applies to the functor between scalar measurements and enumeration sets of nominal properties. For example, when a temperature quantity value is to be converted into a nominal temperature value such as cold, warm, or hot.

A categorical map of observable types and measurement types therefore provides a structural understanding of the transformability of data types in the data model.