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.

Excerpt Include
Task Status
Task Status
nopaneltrue


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 SWIM Information Definition Specification assumes that we are not yet in an environment that is fully supported by semantic technologies. Therefore, humans are the more realistic target for the semantic correspondence statements. This leads to the following statements about traces:

  • The traces are to be read by humans
and
  • but may be read by machines (machine processable).
  • The traces are to be created and inspected by humans.
Nothing
  • There is nothing to stop machines creating the mappings
- still needs
  • but any such mappings will still need human inspection.
  • The maintenance and migration of traces can be managed by machines (or humans) based on scripts.

Info

We are not using full blown semantic technology language so humans are a more realistic target e.g. URNs can only be parsed as strings.

The need for a machine readable list of mappings has been recorded in the AIRM CCB to ease the migration of mappings between versions of the AIRM. "Machine This can be summarised as the need for "machine processable" maintenance of traces.

Use case -

  • understand what has been mapped to - semantic sense. Not quite there yet.
  • maintenance of mappings - can be scripted

    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?
    • The use of the word "concept" as a qualifier name could be misleading. The background section below contains alternative suggestions.

    The table below uses the words from the SWIM Information Specification's requirements.

    RequirementTrace requiredTrace nameDefinition
    SWIM-INFO-016 Mapping of information conceptsrequires 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 mappingallows any number of additional clarifying traces"additional" tracetrace to an AIRM concept to fully describe the narrowing of the concept being mapped
    Info

    Names based on the target of the trace rather than any interp. of the trace type.

    Classes = information concept

    Attibute = data concept and data type

    Codelist = additional / narrowing trace

    Source and target of traces

    Info

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

    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

    Info

    The spec doesn't rule out mapping to contextual model. but this is not good practice

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

    Best place to start: Logical Model.

    Info

    Classes have one trace - 016

    Attributes have two traces - 017

    "data type" trace is dependent on "data concept" trace.

    If not found there, use Contextual Model or Conceptual Model for the "data concept" trace

    Info

    The spec doesn't rule out mapping to contextual model. but this is not good practice

    Note: AIRM has internal traces that are inherited by any mapping.

    "additional" tracesource depends on the trace being clarified

    Best place to start: Should be in the same model as the trace being qualified.

    Provide value to the two mappings above. It is dependent on them.


    Reading order of traces

    Info

    Structure of traces - capture the dependencies between the types of traces. Can't have an "additional trace" alone or "data type" trace. The root trace is mandatory. Need to add these rules in the best practice.

    see struts from programming languages

    General reading order is:

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

    or

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

    All traces have an AND relationship.

    Info

    "narrowing" trace instead of "additional" trace


    Level of semantic correspondence

    Advanced users may like to add extra detail concerning the level of semantic correspondence achieved. The requirements talk about "equivalent or wider meaning". The table below contains the old AIRM Rulebook names and the skos equivalents.

    Definition being traced to is...Annotations that can make this more explicitor in skos
    Equivalent
    1. ExactCopy: Definition of concepts in the information definition and the AIRM are exact copy of each other.
    2. SyntacticallyEqual: Definitions are only different due to syntax corrections (grammar, spelling) but are otherwise equivalent.
    3. 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.
    1. 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.
    2. -
    3. skos:closeMatch: is used to link two concepts that are sufficiently similar that they can be used interchangeably in some information retrieval applications.
    WiderSpecialised: 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.
    Info

    We could allow both columns with namespace identifiers - codelist entry. Could even map to an URL to give the word.

    skos is preferred but SESAR legacy is still supported.

    Note

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

    Note

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

    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

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

    Info

    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>

    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>

    "additional" trace


    <additionalTrace>

    <trace keyword="additionalTrace>

    Full example

    If we apply all of this:

    Info

    element names are preferred. It can be used more easily in rules.

    contains some semantic hints even if the attributes are not added.

    see if "degree" has a skos name instead.

    Code Block
    languagexml
    <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> 

    or:

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

    Info

    This is probably handled as a separate activity after the current task is completed.

    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 is mentioned above.
    3. AIRM Context Trace. This appears to add the qualifiers as mentioned 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.


    Perhaps we need to look at what "aspects" of the AIRM model are mappable to first -  and also possible the level of alignment (eg exact, broader, etc aka SKOS-like).

    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.