We are often concerned with three kinds of data model. The first kind is the conceptual data model (CDM). In a conceptual model, the instances of classes are entities in the real world; for example, real robots, real payloads, real tasks, real environments. In the CDM, we are concerned with definitional properties of these entities, which are captured as class attributes and associations.

The second kind is the logical data model (LDM). In a logical model, the instances of classes are software objects. Logical classes can represent the existence and state of a real-world entity in the CDM or they can be messages about those entities. In the LDM, we are concerned with system data.

The third kind is the physical data model (PDM) that realizes the logical model for a chosen software environment. In the PDM, we are concerned with communication.

It is easy when designing software to overlook the distinction between the CDM and LDM, and regard the conceptual model as an incomplete or preliminary logical model rather than an entirely different kind of model. However, the difference is important when modeling quantities.

The formal definition of a quantity is, the property of a phenomenon, body, or substance, where the property has a value with magnitude.

We can describe a quantity both conceptually and logically, where in both cases the definition is semantically complete. For example, the conceptual definition of mechanical force is provided in ISO 80000-4:2006 as

F = dp/dt

Therefore, a conceptual model of an aircraft class might include the owned attribute ‘thrust: MechanicalForce’ where the phenomenon is ‘aircraft thrust, and the quantity is mechanical force. In general, we would refer to aircraft thrust as the measurand, whose quantity is mechanical force. At this conceptual level, it is possible to devise equations for the aircraft, based on thrust, drag, lift, and weight, for example: ‘Aircraft:: thrust: MechanicalForce’, ‘Aircraft:: drag: MechanicalForce’, ‘Aircraft:: lift: MechanicalForce’, and ‘Aircraft:: weight: MechanicalForce’.

The principal concern of the logical model would be how to express the value of force so that the state of the aircraft can be tracked in memory or as a message. It is one of the puzzling truths about science that it is impossible to express the value of a quantity without recourse to an arbitrary reference. The conceptual model describes an innate reality; the logical model describes the arbitrary means to express that innate reality.

For example, to express the magnitude of mechanical force, a measurement unit is required, such as newton, pounds force, or foot pounds per second squared. To express the direction of force requires a coordinate system whose axes (component unit vectors) are snapped to the axes of a datum (such as the axes of the aircraft structure).

It is common in software to refer to the numerical part of the value specification as the ‘value’. Mathematically, this is not strictly correct.  Remember that 1 ft lb/s² = 4.448222 N, i.e. both sides of the equation represent the same value. Similarly:

where on the left-hand side, force is expressed in compact form using coordinate reference system (CRS) A, and on the right-hand side, force is expressed using CRS NED, v.

Therefore, we should think of the role of the logical model as defining the mathematical structure of the value and, possibly, the morphisms between structures.

The taxonomy of the mathematical structures of quantities is shown below, where the focus is on vector and scalar quantities. Here, force is a true vector that is expressed in a spatial reference system. It may be morphed into another vector space via a transformation tensor. In category theory, this transformation tensor is termed a 1-morphism. The conversion from vector spaces to another ordinary mathematical category is termed a 2-morphism.

Taxonomy of property types

In the logical model, we may substitute the conceptual data type ‘MechanicalForce’ with one of many logical data types, for example, ‘MechanicalForceVehicleCartesian’ based on a Cartesian coordinate system anchored to a vehicle coordinate datum and the unit of Newton.

It has been common practice in many logical data models to define a unique CRS for every quantity type. For example, one CRS for force, another for position, another for velocity, and so on. However, if we focus on the mathematical structure, and not of the quantity itself, then it is possible to devise a common CRS in Euclidean space for the position vector, its differential, and for a generalized true vector q. This allows all vectors to be tied to the same CRS.

For a Cartesian system, this can be trivial, but consider the case where we wish to relate the geodetic position of an aircraft in a WGS 84 ellipsoid CRS, to its course and speed in the local tangent plane whose origin is carried with the geodetic position, to the inertial acceleration of aircraft. For this, a mathematically coherent structure for CRS and their transformation tensors is essential.

We shall end by returning to the CDM. An often-claimed benefit of the conceptual model its ability to span many logical models and many systems. This is true, if we consider metrology. We may define a measurement as, the method by which the value of a measurand is determined.  This epistemological detail can be very important, particularly when relating two values from different measurement sources and the only documentation that integrates the two is the data model. For example, the value of the measurand ‘Aircraft:: altitude: EllipsoidalHeight’ may be determined by a barometric altimeter, radar altimeter, satellite radio navigation, and so on. It is tempting to convert data defined by one LDM into data defined by another just by looking at the value structure and performing the required CRS and unit conversions. However, it is critical that the full semantics of the CDM is understood; that we are really comparing the same entities and the same properties. This requires a rigorous data dictionary.