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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Page Table of Content

Requirement

Title

Additional traces to clarify the mapping of narrower concepts

Identifier

SWIM-INFO-018

Requirement

The mapping of a concept to an AIRM concept that has a wider meaning shall contain additional traces to AIRM concepts to fully describe the narrowing of the concept being mapped.

Rationale

This requirement accounts for the diversity in data modelling strategy.

Verification

Correctness

Examples/Notes

Note: This requirement requires additional traces to those required by SWIM-INFO-016 (for information concepts) and SWIM-INFO-017 (for data concepts).

Note: In practice, additional traces need to be provided for all qualifiers in the definition of a concept in an information definition that are absent in the definition of an AIRM concept. This ensures that the mapping is precise.

Example: An example is an information definition that contains a data concept called “Target Startup Approval Time” that is a time.

Three traces are needed for this mapping to be unambiguous. The first two traces are those required by SWIM-INFO-017 and the third is an additional trace to ensure the mapping is unambiguous:
  • one trace to the AIRM concept called “StartUp”;
  • one trace to the AIRM data type called “DateTime”; and
  • one additional trace to the “CodePlanningStatusType” value “TARGET” in order capture the “Target” qualifier in the concept. This is required as “StartUp” has a wider meaning than “Target Startup”.

Note: It is laborious to repeat traces established for concepts that contain the concept being traced. Therefore, the concept being traced can treat its container’s traces as part of its own mapping.

Example: To continue the example: An information definition contains a data concept called “Startup Approval Time” and a contained concept (e.g. modelled by specialisation in UML) called “Target Startup Approval Time”. In this case, the first two traces will be established for “Startup Approval Time” and can be treated as part of the mapping of the “Target Startup Approval Time” concept.

Note: SWIM-INFO-019 requires the use of the AIRM’s unique identifiers in traces.

Level of Implementation

Mandatory

Guidance

Additional traces

This requirement applies to information concepts and data concepts. It applies when the "main" trace (see SWIM-INFO-016 and SWIM-INFO-017) is to an AIRM concept that has a wider meaning. The purpose is to add traces in order to make the mapping as precise as possible. The diagram below shows where multiple traces have been added to a single mapping.

These additional traces make clear why the information definition's concept is regarded as narrower than the AIRM concept.

The specification uses the example of "Target Startup Approval Time" (TSAT). The figure below is taken from the AIRM. It includes the three elements needed from the AIRM in order to "build" the TSAT. These are: StartUp, DateTimeWithPlanningType and CodePlanningStatusType.

The following table explains that these are used:

Information Definition Concept

AIRM Concept

Explanation

Name

Definition

Name

Definition

TSAT

The time provided by ATC taking into account TOBT, CTOT and/or the traffic situation that an aircraft can expect to receive start-up/push-back approval.

StartUp


The start up of the aircraft engines by the flight crew upon the ATC approval.

This is the "main" trace

StartUp.time (of type DateTime)Time at which the aircraft starts up.This is the data type trace.

CodePlanningStatusType.TARGET

Target

Additional trace necessary to qualify the semantics of the StartUp. Namely, it represents which planning status is associated with the StartUp.


If any of the additional traces is missing, then the semantics of the information definition would not be described accurately in terms of AIRM concepts, as the semantic would miss some building block.

As a rule of thumb, the need for additional mappings may occur when the information definition's concept is:

  •  a mixture of format aspects and operational aspects
    • e.g. “ICAO Departure Aerodrome designator” is a compound of
      • ICAO format for aerodrome designator
      • the flight departure operational phase
  • a complex acronym, hinting at a complex-looking definition
    • e.g. EOBT, SOBT, CTOT, TSAT are compounds of
      • a time quantity;
      • an operational phase of flight (Off-Block, Takeoff,....);
      • planning horizon (estimated, scheduled, computed, target,...);

Verification Support

Correctness

Check that:

  • Each additional trace to fully describe the narrowing of the concept being mapped is to the correct AIRM concept.

Examples/Best Practice

The example below shows how the multiple traces can be embedded into an XML schema. The third trace is an additional trace needed to make the semantic correspondence specific. This is extracted from the complete example.

Example of SWIM-INFO-018
<xs:element name="tobt" type="don:TargetOffBlockTime" id="donlon003" minOccurs="1" maxOccurs="1">
 <xs:annotation>  
  <xs:documentation>The  Target Off-Block Time value to be set. TOBT is the time that an operator / handling agent estimates that an aircraft will be ready, all doors closed, boarding bridge removed, push back vehicle present, ready to start up / push back immediately upon reception of clearance from the TWR.
  </xs:documentation>  
  <xs:documentation>   
   <semanticCorrespondence>    
    <mapping>     
     <trace>urn:x-ses:sesarju:airm:v420:ConceptualModel:Subjects:Flight:FlightEvent:TargetOffBlockTime</trace>     
     <trace>urn:x-ses:sesarju:airm:v420:LogicalModel:Subjects:Flight:FlightEvent:OffBlockReady@time</trace>     
     <trace>urn:x-ses:sesarju:airm:v420:LogicalModel:Subjects:Common:Codelists:CodePlanningStatusType@TARGET</trace>    
    </mapping>   
   </semanticCorrespondence>  
  </xs:documentation> 
 </xs:annotation>
</xs:element>
  • No labels