Requirement

Title

Establish semantic correspondence

Identifier

SWIM-INFO-013

Requirement

An information definition shall document a semantic correspondence for each of its concepts.

Rationale

Documentation of semantic correspondence is the evidence that an information definition is an AIRM conformant information definition.

Verification

Completeness

Examples/Notes

Note: This requirement covers information concepts and data concepts.

Note: This requirement allows an information definition to:

  • be accompanied by a standalone resource containing the statements of semantic correspondence; or
  • have statements of semantic correspondence embedded in it; or 
  • be accompanied by a reference to an already existing set of semantic correspondences.

Note: The forms that a semantic correspondence can take are given in SWIM-INFO-014.

Note: 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 technically and procedurally implemented.

Example: A statement that the “container’s traces” are considered as part of the concept mappings (as discussed in SWIM-INFO-018).

Level of Implementation

Mandatory


Guidance

Documenting semantic correspondences

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. The requirement allows an information definition to:

Standalone resource

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 AIRM matching concepts.

In this example, the traces contain information not required by the specification. It adds 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.

The important thing here is that the mapping artefact is a standalone document.



Embedded

The specification also allows the semantic correspondence statements to be embedded into the information definition.

The figure below is taken from an old SESAR deliverable. It shows how the code attribute in the OtherInformation 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. The example uses UML. However, it is also possible to embed the trace in XML schemas (see SWIM-INFO-014 for an example of this).

Reference

Both of the above options assume that the semantic correspondence document is being created for a new 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 information definition.

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.

Consider having a running example/scenario in the requirements. Make the examples be consistent with the scenario. Scenario is based around the need to define a service (new and legacy).  Be careful in use of terminology e.g. message. Need a controlled vocabulary. Bring it in from the specs and use hyperlinks.

Should this be in the service SPEC supporting material?

The scenario approach would help a great deal here.

Ensuring the documentation is understandable

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 technically and procedurally implemented.

Example: A statement that the “container’s traces” are considered as part of the concept mappings (as discussed in SWIM-INFO-018).


At the moment the target audience is humans/organisation needing to show conformance - obviously tooling can be developed by organisations. Tooling section may be added e.g. on ontology matching tools.

Verification Support

Completeness

Check that: