Common Logical Data Model: Basis for Global ITS Innovation
As long as a system is able to transform data
conforming to a physical data model into the
format defined by the logical data model,
agreement can be reached fairly quickly. This
is even true if the transformation results in a
loss of accuracy as long as the logical data
model is able to represent the resultant
accuracy (which is generally needed anyway).
The result is that agreement on a logical
model is often much easier because the only
systems that need to perform this
transformation are those that have a need to
span multiple physical data model
standards—and for that subset of systems,
having a common reference is better than
dealing with each physical model separately.
F OCUS ON L OGICAL AND C ONCEPTUAL D ATA
M ODELS
Standardizing on physical data models
requires
a
complete
interoperable
specification. This is often challenging
because in many cases, stakeholders have
already developed a solution that they need
to migrate to the new solution. These
discussions can become quite contentious as
different stakeholders debate the merits of
various proposals and consider the costs for
converting their own systems.
Conceptual data models avoid this
discussion completely. They only need to
define what terms mean and how terms
relate to one another while allowing for
synonyms with various levels of similarity.
The only real debate point is in the real
meaning of terms within different
communities; but even here, the meaning of
terms can be scoped to specific contexts
when needed (although it is highly desirable
to standardize as much as possible).
F OCUS ON L OW -H ANGING F RUIT
Another benefit of focusing on the
conceptual and logical data models is that
they do not need to be completely defined
for a benefit to be provided to the
community. As a simple example, the
industry frequently reports geographic
locations using latitude and longitude
reported in tenths of microdegrees. This is
often but not always based on the WGS-84
coordinate system and accompanied with an
elevation reported in decimeters or
centimeters.
Logical data models begin to define
preferred units of data and factors to ensure
that data can be semantically understood
but do not define how data is exchanged. For
example, the conceptual model might define
that a vehicle has a location that identifies
the point-of-reference on the vehicle, but it
does not have to define where the point of
reference is or the units used to express this
location. The logical data model would
extend the definition by designating the
point of reference on the vehicle and the
units used to express the location but would
not define how this information is
transmitted. The physical data model would
define how the data is transmitted.
This should be easy to address within the
logical data model. There are known ways to
translate locations among different
coordinate systems (as long as timestamps
are known for the data and recognizing
some loss of accuracy). The logical data
model would therefore need to allow for
identifying the coordinate system used, the
timestamp on the data and the accuracy of
the source data; it would then support
- 43 -
March 2020