The opportunity

It is not clear in which order to read traces when there are more than one in a single semantic correspondence statement. Some traces are, in fact, qualifiers of other traces. Is it possible to somehow differentiate the traces and apply a reading order?

Discussion

The discussion has been split into parts to make easier to follow.

Assumptions

The traces are to be read by humans/machines

The traces are to be created by humans/machines

Different types of traces

Source and target of traces

The usual start point depends on the requirement being fulfilled.

Reading order of traces

General reading order is:

1. "information concept" trace
2. "additional" traces

or

1. "data concept" trace
2. "data type" trace
3. "additional" traces

All traces have an AND relationship.

Level of semantic correspondence

Advance users may like to add extra detail concerning the level of semantic correspondence achieved. The requirements talk about "equivalent or wider meaning"

Annotating traces

It is possible to add a further notes to the mapping (or trace?). This comes in handy for example when e.g. tracing legacy interfaces that have data type constraints leading to loss of Information.

Representing traces in XSD

<xs:annotation>
  <xs:documentation>
    <semanticCorrespondence>
      <mapping note="loss of info because of legacy">
        <informationConceptTrace degree="specialised">-AIRM unique identifier-</informationConceptTrace>
        <additionalTrace>-AIRM unique identifier-</additionalTrace>
      </mapping>
    </semanticCorrespondence>
  </xs:documentation>
</xs:annotation> 

<xs:annotation>
  <xs:documentation>
    <semanticCorrespondence>
      <mapping note="loss of info because of legacy">
        <trace type="informationConceptTrace" degree="specialised">-AIRM unique identifier-</informationConceptTrace>
        <trace type="additionalTrace">-AIRM unique identifier-</additionalTrace>
      </mapping>
    </semanticCorrespondence>
  </xs:documentation>
</xs:annotation> 

Example of tracing exercise

However it should be consistent with the information given at the AIRM homepage. Links to the according pages will also help.

Background

Existing qualifier names

Different artefacts have used different trace "qualifiers".

Example 1

1. "Data Traces", which, for the case of SWIM-INFO-017, refer to the Data Type constraints. They must be unique, and may already also contain the full definition (as the best matching AIRM concept with the correct data type constraint will be chosen), so they are logically first in line.
2. "Definition Traces" which point to the comprehensive or even normative definition (when available) or to the best matching wider AIRM concept (in both SWIM-INFO-016 and SWIM-INFO 017). They must be present and must be unique, so they are next in line (top of the line for SWIM-INFO-016 actually).
3. "Context Traces" that add qualifiers (i.e. implement SWIM-INFO-018). These are optional, and their order should not have semantic significance.

Example 2

The Donlon example at https://ext.eurocontrol.int/swim_confluence/display/SWIM/Donlon+TOBT+Setting+Service+Description#DonlonTOBTSettingServiceDescription-InformationDefinition is almost the same. It uses:

1. AIRM Semantic Trace
2. AIRM Definition Trace. This seems to be in line with what Stefan mentioned above.
3. AIRM Context Trace. This appears to add the qualifiers as mentioned by Stefan above.

Example 3

Looking at the ISRM (Information Service Reference Model) it has:

1. Main CLDM mapping. The mandatory and unique CLDM mapping indicating the AIRM element having the type of data as the OuA construct. E.g. a “time” for TSAT;
2. Context CLDM Mapping. One or more optional additional CLDM mappings helping achieving a more accurate semantic definition by giving more context to the main CLDM mapping. E.g. the “TARGET” planning status for TSAT;
3. IM Definition Mapping. An IM mapping allows referencing a unique IM element containing a normative definition (typically from ICAO) for the OUA construct. Can be optional or mandatory depending on contexts as explained in next chapters.

Example 4

EUROCAE ED-254.

The mappings to the AIRM have the following keywords:

1. SemanticTrace
2. DefinitionTrace
3. ContextTrace (which can be further defined as ContextTrace_1, ContextTrace_2, etc)

Keyword: DefinitionTrace.

Value: URN of an AIRM information or data concept

Usage Notes: This will normally point to a resource in the AIRM Information Model, i.e. an AIRM information concept.
However, occasionally (e.g. when mapping the definition of certain containers), it may necessary to refer to the definition part of a (CLDM) data concept.
In this case, the data type of the AIRM trace target is not part of the trace semantics.

Keyword: SemanticTrace

Value: URN of an AIRM data concept

Usage Notes: When there is no accompanying DefinitionTrace, it is understood that both SWIM-INFO-016 and SWIM-INFO-017 are implemented by this trace (see note on SWIM-INFO-017)

Keyword: ContextTrace / ContextTrace_n

Value: URN of an AIRM information or data concept

Usage Notes: The first form is the standard

When more than one context traces is required on an element, the second form is used.

The EUROCAE document does not formally associate business semantics with data entities, i.e. all data entities are implicitly traced to “OutOfScope: container”.

The mappings of individual data fields are therefore self-contained, there is no “trace cascading”.

How many qualifiers

Can’t we survive on:

2 categories:

• “trace” (1 or more to either AIRM-CM or AIRM-LM; note that the URN shows whether CM or LM)
• “trace_qualifier”

In the schema trace and trace_qualifier could then be differentiated.

2 best practices:

• Order best practice: “widest first”
• Qualifier best practice: “Trace qualifier directly after qualified trace”

Adding notes to mappings

It is maybe worth noting here that sometimes you want to put a comment on a mapping, so I am allowing this as an extra annotation. This comes in handy for example when tracing legacy interfaces that have data type constraints leading to loss of Information.