Working towards the next version of the SWIM Supporting Material

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
RequirementTrace requiredTrace

Purpose

Excerpt
-includeSITCOM Task StatusSITCOM Task Statusnopaneltrue

Table of Contents

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

Note
  • Can we survive with just using these names that are inspired by the words in the spec?
  • Can we merge the two types of "concept" traces into one name?
This guidance is provided in order to allow you to better understand mappings from an information definition to the AIRM and how to record them in the information definition. 

The guidance applies to:

The different forms of semantic correspondence are outlined in SWIM-INFO-014 Forms of semantic correspondence. This guidance applies to mappings (the first option in the requirement). Mappings contain one or more traces. Therefore, this guidance covers the different types of traces.


Table of Contents


Different types of traces

The table below outlines the names, definition and relevant requirement to be used for the different types of trace that constitute a mapping statement. The names are inspired by the words from the SWIM Information Specification's requirements. This approach makes it clear which requirement is being satisfied by the trace.

RequirementTrace nameDefinition
SWIM-INFO-016 Mapping of information concepts
requires one concept trace
"information concept" tracetrace from the information concept in the information definition to the AIRM concept that has an equivalent or wider meaning
SWIM-INFO-017 Mapping of data concepts
requires one concept trace and one data type trace
  1. "data concept" trace
  2. "data type" trace
  1. trace from the data concept in the information definition to the AIRM concept that has an equivalent or wider meaning
  2. trace to the data type in the AIRM that has an equivalent or wider meaning
SWIM-INFO-018 Additional traces to clarify the mapping
allows any number of additional clarifying traces
"
additional
narrowing" tracetrace to an AIRM concept to fully describe the narrowing of the concept being mapped

Source and target of traces

The usual start point depends on the requirement being fulfilled.

Trace nameSourceTarget"information concept" traceLikely sources: information exchange requirements

Best place to start: Conceptual Model.

If not found there, use Contextual Model or Logical Model

  1. "data concept" trace
  2. "data type" trace
Likely sources: service message

Best place to start: Logical Model.

If not found there, use Contextual Model or Conceptual Model for the "data concept" trace"additional" tracesource depends on the trace being clarified

Should be in the same model as the trace being qualified.

Info

The Interoperability Architecture provides good advice. Basically, trace to the adjacent box by default.

Reading order of traces

General

Info

The Interoperability Architecture provides good guidance on the best place to start when looking to establish a mapping. Basically, the best place to start is usually the adjacent box within the grid.

The best start point when identifying a suitable AIRM concept depends on the type of information definition being traced. This can also give an indication on the type of trace to be used. The table below gives some general guidance on this.

Type of information definitionGeneral guidance
information exchange requirements

The best place to start in order to identify a suitable AIRM concept is the AIRM Conceptual Model. However, information exchange requirements can vary in the level of detail included. Therefore, if no suitable AIRM concept is found in the AIRM Conceptual Model, the AIRM Logical Model may be useful.

For the most part, it is expected that information exchange requirements involve "information concept" traces and so fall under requirement 16.

Narrowing traces (requirement 18) can be added as needed. It is usual that these trace to the same part of the AIRM as the "main" trace.

Info

The specification doesn't rule out tracing to the AIRM Contextual Model but this is not a good practice.

service payload /

information exchange model

Service payloads and information exchange models can include concepts that are of different level of granularity. For example, they may contain standardised "messages" such as NOTAM and METAR. They also contain concepts such as "Aerodrome" or "Airspace". These in turn may have attributes/properties such as the "ICAO location indicator".

Although it is difficult to give generic advice that is applicable in all cases, the following guidance is applicable:

  • Standardised "messages" are captured in the AIRM Conceptual Model. Mapping of such messages tend to be involve "information concept" traces and so fall under requirement 16. If no suitable AIRM concept is found in the AIRM Conceptual Model, the AIRM Logical Model may be used.
Note

It is an AIRM design decision to allow messages to be added at the service level. The AIRM Logical Model does not impose any message structure. However, the existence of the standardised messages is captured as part of the operational language in the AIRM Conceptual Model.

  • The best place to start when mapping concepts that have no associated data type is the AIRM Logical Model. Concepts of this nature may, for example, be modelled as classes in UML models. These tend to involve "information concept" traces as they do not have a "data type" associated with them. This means that they fall under requirement 16 . If no suitable AIRM concept is found in the AIRM Logical Model, the Conceptual Model may be used.
  • Attributes/properties will have a "data type" and therefore fall under requirement 17, requiring a "data concept" trace and a "data type" trace. If no suitable AIRM concept is found in the AIRM Logical Model, the Conceptual Model may be used.

Note

The AIRM has internal traces to ensure consistency between the AIRM Conceptual Model and the AIRM Logical Model.


Narrowing traces (requirement 18) can be added as needed. It is usual that these trace to the same part of the AIRM as the "main" trace.

Info

The specification doesn't rule out tracing to the AIRM Contextual Model but this is not a good practice.

Reading order of traces

The standard requires multiple traces to be added to a mapping. The general reading order is:

  1. "information concept" trace
  2. "additionalnarrowing" traces (0..*)

or

  1. "data concept" trace
  2. "data type" trace (1)
  3. "additionalnarrowing" traces (0..*)

All traces have an AND relationship.

Info

The following rules apply to the traces:

  • The root trace is mandatory. This is either an  "information concept" trace or a "data concept" trace.
  • A "data type" trace is mandatory when the root trace is a "data concept" trace.
  • "Narrowing" traces cannot exist in their own right.

The number of traces

The important thing when creating a mapping is to add sufficient traces to ensure that the semantics are understood. There is no need to add further traces.

If you find that too many traces are required to ensure that the semantics are understood, there may be a problem somewhere in fully understanding the meaning of a concept. In that case a change may be needed to the information definition and/or the AIRM.

Level of semantic correspondence

Advance Advanced users may like to add extra detail concerning the level degree of semantic correspondence achieved. The skos standard calls this the "semantic relation" between concepts.

The requirements talk about mapping to the concept with "equivalent or wider meaning". The table below outlines the skos sematic relation term that can be used in order to make the level of semantic correspondence explicit. It also contain the equivalent terms that were used in SESAR.

Info

The skos names are preferred. Skos has rich support in semantic technologies.

However, existing SESAR documents use different names and it is important that readers can understand those traces - the table therefore includes those.

Definition being traced to is...
Annotations

Skos annotations that can make this more explicit

or in skosEquivalentExactCopy

Term used in SESAR documents

Equivalent

skos:exactMatch: is used to link two concepts, indicating a high degree of confidence that the concepts can be used interchangeably across a wide range of information retrieval applications.

skos:closeMatch: is used to link two concepts that are sufficiently similar that they can be used interchangeably in some information retrieval applications.

exactCopy: Definition of concepts in the information definition and the AIRM are exact copy of each other.

SyntacticallyEqual

syntacticallyEqual: Definitions are only different due to syntax corrections (grammar, spelling) but are otherwise equivalent.

Rewritten

rewritten: The definition of the concept in the information definition has been rewritten to reflect information definition specificity. However, the meaning is the same, i.e. the definition still describes exactly the same concept as the AIRM.

Widerskos:
exactMatch
narrowMatch:
is

used to
link two concepts, indicating a high degree of confidence that the concepts can be used interchangeably across a wide range of information retrieval applications.
  • -
  • skos:closeMatch: is used to link two concepts that are sufficiently similar that they can be used interchangeably in some information retrieval applications.
  • WiderSpecialised
    state a hierarchical mapping link between two concepts.specialised: The definition in the information definition is a special case of the definition found in the AIRM
    .narrowMatch:
    used to state a hierarchical mapping link between two concepts
    .
    Note

    We only need additional narrowing traces if the main trace is "specialised" or "narrowMatch"

    Note

    Traces cannot be annotated as "generalised" as this breaks the requirement.

    Info
    titleFrom old AIRM rulebook
    AIRM_Rule 60

    The 'Definition:Adapted' AIRM::TaggedValue shall be completed in order to indicate the level of semantic correspondence with the source definition. The list of values is:

  • ExactCopy: Definition of source and target are exact copy of each other.

  • SyntacticallyEqual: Syntax corrections (grammar, spelling)

  • Rewritten: The definition has been rewritten for improved quality. The meaning is the same, i.e. the definition still describes exactly the same entity as the target definition

    .

  • Specialised: Source definition is a special case of the target definition.

  • Generalised: Source definition is a generalised case of the target definition.

  • AIRM_Rule 116

    A data or information construct is considered to be in semantic correspondence with the AIRM if one of the following conditions holds:

    1. The definition of the construct is an exact copy of the definition of a specific AIRM element, or it is syntactically equal, or is rewritten or is specialised as described in AIRM_Rule 60.

    2. It can be demonstrated that the definition of the construct can be decomposed into several elementary concepts, each corresponding to an AIRM element as per previous bullet. This decomposition must be comprehensive, i.e. cover all parts of the definition.

    Annotating traces

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

    Representing

    Recording traces in XSD

    How should the different traces be represented in the XSD examples we use?The table below gives two alternatives for recording the traces in XSD.

    Info

    Using element names is the preferred option as it can be used more easily in rules. The element name contains semantic hints even if the attributes are not added.

    However, the attribute option is also supported as there are a lot of traces developed that do not use element names. Support for this option should be deprecated in the future.

    Trace nameElement nameAttribute
    "information concept" trace<informationConceptTrace><trace keyword="informationConceptTrace>
    1. "data concept" trace
    2. "data type" trace

    <dataConceptTrace>

    <dataTypeTrace>

    <trace keyword="dataConceptTrace>

    <trace keyword="dataTypeTrace>

    "additionalnarrowing" trace


    <additionalTrace>

    <narrowingTrace>

    <trace keyword="additionalTrace>narrowingTrace>

    info

    XSD Example

    If

    this is a best practice, the attribute option is probably preferable - the attribute can be optional and the name of the element is always <trace>

    Full example

    If we apply all of this:we apply the guidance above we get the following in XML Schema notation.


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

    or:

    Code Block
    languagexml
    <xs:annotation>
      <xs:documentation>
        <semanticCorrespondence>
          <mapping note="loss<mapping>
            <note>loss of info because of legacy">
            legacy</note>
    		<trace type="informationConceptTrace" degreesemanticRelation="specialised">-AIRM unique identifier-</informationConceptTrace>trace>
            <trace type="additionalTracenarrowingTrace">-AIRM unique identifier-</additionalTrace>trace>
          </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 qualifiers

    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”.

    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.