This requirement basically requests the semantic correspondences. A semantic correspondence is the relation between a concept in an information definition and the AIRM.
This requirement ensures that the relations are documented. This allows them to be shared e.g. by being added to the SWIM Registry. The requirement allows an information definition to:
It is a best practice to only use one version of the AIRM when documenting semantic correspondences.
The Aeronautical Information Exchange Model (AIXM) performed its initial semantic correspondence analysis using a spreadsheet. The figure below shows what this looked like. The left hand side of the diagram shows the concepts exported from the AIXM UML model. The concepts are AerialRefuelling, AerialRefuellingAnchor, AerialRefuellingPoint, AerialRefuellingTrack, AuthorityForAerialRefuelling. The right hand side of the diagram contains an export of the matching AIRM concepts.
In this example, the traces contain information not required by the specification. The spreadsheet contains the “Degree of Correspondence” column that is ExactCopy (when the definition in the information definition is an exact match of each AIRM concepts), or Restriction (when the information concepts has a narrower definition than the AIRM concept). This extra detail can be seen as evidence that SWIM-INFO-016 and SWIM-INFO-017 are really followed.
However, the important thing here is that the mapping artefact is a standalone document.
The specification also allows the semantic correspondence statements to be embedded into the information definition.
The figure below is taken from a SESAR deliverable. It shows a snippet of a larger UML diagram. It shows how the code attribute in the OtherInformation class traces to the Aircraft.icaoAircraftAddress in the AIRM. The unique identifier of the AIRM (see SWIM-INFO-019) has been used to fill in the tagged value for the concept being traced.
It is also possible to embed the trace in XML schemas (see SWIM-INFO-014 and the complete example for further examples of this approach).
<xs:annotation> <xs:documentation> <semanticCorrespondence> <mapping> <trace>-AIRM unique identifier-</trace> </mapping> </semanticCorrespondence> </xs:documentation> </xs:annotation>
Both of the above options assume that the semantic correspondence document is being created from scratch for an information definition. However, a key principle of SWIM is the promotion of reuse. Therefore, the specification allows this requirement to be satisfied by a reference to an existing set of semantic correspondences.
This means that if a service payload is composed of elements entirely built on an exchange model (such as FIXM, AIXM, IWXXM) then the requirement may be satisfied by making reference to that model's existing semantic correspondence document.
However, if the service payload has additional constructs with respect to the exchange model, the semantic correspondence document must be created for the additional constructs. In other words, the semantic correspondence document may actually be a blend of new and references documents.
The specification does not give details on the syntax and method for the semantic correspondence statements. However, it notes that it is important to ensure that the syntax used for mappings is self-explaining or appropriately explained. To this end, extra information can accompany the information definition in order to ensure that the mappings can be understood without having to read external documentation or make assumptions on how the mappings are implemented.
It is important to remember that the target audience for the semantic correspondence statements is a human reader.
Tools can be developed by organisations in support of the creation of the semantic correspondence statements. One such development has been explored by the BEST project. It is hoped that more tools will become available over time.
[ ] The information definition has a semantic correspondence statement for each concept.