Requirement
|
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:
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.
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).
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.
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.
Check that: