Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata
Page Table of Content

Requirement

 Requirement [+]

Title

Forms of semantic correspondence

Identifier

SWIM-INFO-014

Requirement

A semantic correspondence shall be:
  • a mapping from a concept in the information definition to a concept or concepts in the AIRM; or
  • a declaration that the concept in the information definition is out-of-scope of the AIRM; or
  • a reference to a change request for the AIRM that intends to change the AIRM to cover the concept from the information definition; or
  • a declaration that no semantic correspondence has been established for the concept.

Rationale

This requirement ensures that the expression of semantic correspondence becomes verifiable.

It allows gaps with the AIRM to be identified so that they can be managed. A reference to the change request is designed to allow an information definition to cause an evolution of the AIRM.

Verification

Completeness

Examples/Notes

Note: There are several methods for documenting a semantic correspondence. For example, this requirement can be satisfied in a tabular format using the unique identifier of the concept in the information definition and the unique identifier of the related AIRM concept.

Semantic correspondences could also be represented using:

  • UML trace relationships; or
  • metadata fields attached to the concept in the information definition that contains the unique identifier of the AIRM concept.

Example: The following is an example of a semantic correspondence written in tabbed-outline format.

+ concept:

…name: Airspace

…semantic correspondence:

……mapping:

………trace: urn:x-ses:sesarju:airm:v410:ConsolidatedLogicalDataModel:SubjectFields:AirspaceInfrastructure:Airspace:Airspace


Note: This requirement ensures that the documentation of semantic correspondence is complete. It is important to ensure that there are no gaps in the documentation as gaps are difficult to interpret.

Level of Implementation

Mandatory

Guidance

The specification gives four types of semantic correspondence. The first of these is the best outcome of the semantic correspondence analysis:

  • a mapping from a concept in the information definition to a concept or concepts in the AIRM.

However exceptions are available. The specification also allows:

  • a declaration that the concept in the information definition is out-of-scope of the AIRM. This gives a clear statement that the concept being mapped is not found in the AIRM and that it will not be in the AIRM. For example, the concept is:
    • not an ATM related piece of information
    • technology-specific or protocol-specific data
    • only a container of other ATM data for the purpose of a specific data exchange
  • a reference to a change request for the AIRM that intends to change the AIRM to cover the concept from the information definition. This is used when a gap has been identified in the AIRM and a request has been made to fill the gap. This obviously covers concepts that are new or have not yet been captured but which are in the AIRM’s scope.
  • a declaration that no semantic correspondence has been established for the concept.  This is used when none of the other outcomes are correct. It could, for example, be that the information definition itself is not clear enough to be able to use any of the other three options. Obviously, this should be used with care. It means that a user cannot be sure about the semantics of this un-mapped concept.

The semantic correspondence document may contain a mixture of the four types. Each of the information definition's concepts must have a semantic correspondence. For example, the figure below contains six mappings. It shows how each concept in the information definition (to the left) has a mapping.

The specification does not set out a method for choosing the correct option. Sometimes the semantic correspondence author will need to chose the correct option with care. Somethings should be kept in mind when doing this:

  • remember that concepts are being analysed, not structural elements such as xsd:choice or xsd:sequence. There is no need to look at structural elements.
  • the textual definitions of concepts are analysed.
  • there is no need to consider syntax.


Best Practice

The option to use out-of-scope or change request may not be obvious. In this case, the best practice is to use the change request option. This will allow the AIRM change control board to consider the input and whether the AIRM's scope needs to be changed.

AIRM Community

Change requests are managed on the AIRM Community Area. You can access the area at http://ost.eurocontrol.int/sites/airm/SitePages/Home.aspx (registration is required).

Verification Support

Completeness

Check that:

[  ] Each semantic correspondence statements contain one of the four options allowed by the specification.

Examples

This example shows how to embed a mapping into an XML schema document using the annotation element. It shows how the trace (or multiple traces) should use the AIRM's unique identifier as required by SWIM-INFO-019. Further mapping examples are available on the Understanding and recording mappings page.

Example of SWIM-INFO-014
<xs:annotation> 
 <xs:documentation>  
  <semanticCorrespondence>   
   <mapping>    
    <trace type="informationConceptTrace">-AIRM unique identifier-</trace>
    ...
    <trace type="narrowingTrace">-AIRM unique identifier-</trace>   
   </mapping>  
  </semanticCorrespondence> 
 </xs:documentation>
</xs:annotation> 

This example shows how to embed an out-of-scope declaration into an XML schema document using the annotation element. It shows how the rationale, required by SWIM-INFO-015, is added as an attribute.

Example of SWIM-INFO-014
<xs:annotation> 
 <xs:documentation>  
  <semanticCorrespondence>   
   <outOfScope rationale="container"/>  
  </semanticCorrespondence> 
 </xs:documentation>
</xs:annotation> 

This example shows how to embed a reference to a change request into an XML schema document using the annotation element. It shows how the change request number is captured as an attribute.

Example of SWIM-INFO-014
<xs:annotation> 
 <xs:documentation>  
  <semanticCorrespondence>   
   <changeRequest number="100"/>  
  </semanticCorrespondence> 
 </xs:documentation>
</xs:annotation> 

This example shows how to embed a no semantic correspondence established declaration into an XML schema document using the annotation element. It shows how the rationale, required by SWIM-INFO-015, is added as an attribute.

Example of SWIM-INFO-014
<xs:annotation> 
 <xs:documentation>  
  <semanticCorrespondence>  
   <noSemanticCorrespondence rationale="incomplete mapping"/>  
  </semanticCorrespondence> 
 </xs:documentation>
</xs:annotation>