SWIM-INFO-009 Preservation of meaning

Last updated:  AUGUST 26th, 2019

Page Table of Content

Requirement

Title

Preservation of meaning

Identifier

SWIM-INFO-009

Requirement

If an information definition contains a concept with the same name as an AIRM concept or a synonym from the AIRM concept’s list of synonyms, it shall preserve the meaning of the AIRM concept.

Rationale

This requirement ensures that the definitions that are agreed in the AIRM are used consistently by information definitions.

This removes the risk of semantic misalignment, possible reinterpretations and drift of meaning between different information definitions.

Verification

Consistency

Examples/Notes

Note: The preservation of meaning requirement does allow some differences in the definitions of the concepts. For example, a definition in an information definition may have to be “rewritten” to take account of different terms used in the information definition as compared to the AIRM. To illustrate this:

The AIRM’s “Runway” concept has a property called “associatedAerodrome” that is defined as “The aerodrome the runway is associated with”. An information definition uses the term “AirportHeliport” rather than “Aerodrome”. As “AirportHeliport” is a synonym of “Aerodrome”, the meaning shall be preserved. However, the information definition could rewrite the definition as “The AirportHeliport the runway is associated with.”

Note: An information definition may add data capture rules and constraints to the definition of a concept without breaking the meaning.

Note: Preservation of meaning is not to be taken to intend preservation of structure. Therefore, the structure of concepts in an information definition may be different from the structures found in the AIRM.

Note: If a concept does not use the same name (or a synonym) as an AIRM concept, SWIM-INFO-010 applies.

Level of Implementation

Mandatory Conditional

Guidance

This requirement promotes the overall consistency of terms and definitions used in the ATM network. This will make the achievement of semantic interoperability easier.

The requirement focuses on "meaning". Therefore, an information definition's concepts do not need to follow the same structure as in the AIRM . The figure below illustrates some example of different strutures:

  • the information definition can use a class-attribute structure (2) where the AIRM has a class only structure (1).
  • the information definition can make use of generalisation and composition (3) in contrast to the AIRM's flatter structure (1).

Definitions and names used in the information definition need not be exactly the same as those in the AIRM, some flexibility is allowed. For example:

  • the definition in the information definition can be rewritten e.g. the AirportHeliport example in the specification itself and illustrated below where (4) shows the information definition is rewritten with regards to the AIRM (1).
  • the definition in the information definition can made more specific/restrictive with respect to the semantics of the AIRM e.g. by introducing business rules.

The main issue to be resolved here is what to do when the requirement is not met. For example, what should be done when an information definition uses the term "Flight" which has the same definition as the AIRM's definition of "FlightLeg" as opposed to "Flight".

Best Practice

When this requirement is not met, the difference should be noted in the verification report. The semantic correspondence should still be established to make the correct interpretation of the concept clear.

Verification Support

Consistency

Check that:

[  ] The information definition uses definitions that are consistent with the AIRM when the concept's name is the same as that in the AIRM.