Versions Compared

Version Old Version 30 New Version 31
Changes made by

WILSON Scott

WILSON Scott

Saved on

Key

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

Insert excerpt
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 but may be read by machines (machine processable).
  • The traces are to be created and inspected by humans. There is nothing to stop machines creating the mappings 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.

Note

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. This can be summarised as the need for "machine processable" maintenance of traces.

Different types of traces

The table below outlines the names and definition to be used for the different types of trace. 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.

Trace nameDefinitionRequirementTrace required
"information concept" tracetrace from the information concept in the information definition to the AIRM concept that has an equivalent or wider meaningSWIM-INFO-016 Mapping of information conceptsrequires one concept 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-017 Mapping of data concepts

requires one concept trace and one data type trace

"narrowing" tracetrace to an AIRM concept to fully describe the narrowing of the concept being mappedSWIM-INFO-018 Additional traces to clarify the mappingallows any number of additional narrowing traces

Source and target of traces

Info

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

The usual start point depends on the type of information definition being traced.

Type of information definitionBest place to startTrace name
information exchange requirements

The best place to start 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 there, the AIRM Logical Model may also be useful.

Info

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

"information concept" trace

service message / information exchange model

The best place for "atoms" to start is the AIRM Logical Model. e.g. Aerodrome

Standardised "messages" (part of operational language) tend to be in the AIRM Conceptual Model. e.g. METAR

=> AIRM design decision to allow messages to be added at service level. AIRM logical model does not impose message structure.

Info

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

The best place to start for Classes/XSD element is requirement 16 - have one trace - 016Attributes

The best place to start for Attributes/XSD attribute is requirement 17 - have two traces - 017

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

requirement 18 applies in all cases.

--

Difference between information and data concepts

  • How are they defined? Has a data concept a “higher priority” than an information concept (because of the second mandatory trace)?
  • Is everything at first an information concept and by adding a data type it becomes a data concept? How about using Attributes (like for urn:aero:airm:1.0.0:LogicalModel:Subjects:BaseInfrastructure:AerodromeInfrastructure:Aerodrome@locationIndicatorICAO)?
  • What if a concept implicitly contains a data type/format? (see CR49, this might come to a mapping for “METAR in IWXXM3” as a concept - is there an additional data type trace necessary?)
  • What if a data type trace is needed but there is no matching element in the AIRM? Or if there is a concept that contains implicitly a format that does not match with the service’s payload item?


If no suitable AIRM concept is found therein the AIRM Logical Model, the Conceptual Model may be used for the "data concept" trace. 

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



Info

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

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

.

  1. "data concept" trace
  2. "data type" trace

Clarifying traces should be in the same model as the trace being qualified.

"clarifying" trace



Reading order of traces

General reading order is:

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

or

  1. "data concept" trace
  2. "data type" trace (1)
  3. "clarifyingnarrowing" 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.
  • "Clarifying" traces cannot exist in their own right.
Note

Which structure (in terms of “logic”) has the order of multiple traces? Possible options (maybe also combinations):

  • from most necessary to least necessary  ("which trace is at least necessary for understanding the concept?")
  • from logical to technical ("what does the data contain - in which format does it come?")
  • from technical to logical ("which format does the data have - what does it contain?")
  • e.g. map METAR in IWXXM/TAC format.
    • Format/syntax is not important to the mapping. The concepts are important. (this is the second bullet in this list.)

How many traces are sufficient/enough?

  • would it be helpful to give advice on how many traces are "ok"? Maybe something like "up to 5 traces" or so?
    • add sufficient traces but no need to add more traces than enough to make sure the semantics are understood.
    • indeed, if too many traces, there may be a problem somewhere in fully understanding the meaning of a concept.
  • if there are too much traces needed maybe think about a change request? to information definition and/or AIRM.
  • Multiple traces: Conceptual vs. Logical Model - which to prefer? - see above
  • e.g. ICING in GRIB - gridded data, coded data,...
    • granularity - map the atoms.

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 explicit

in SESAR documents


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.skos:narrowMatch:
used to state a hierarchical mapping link between two concepts.
Info

The skos names are preferred. Skos has rich support in semantic technologies. However, SESAR documents use slightly different names based on the old AIRM Rulebook.

Both options are therefore valid.

Note

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

Note

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

Annotating traces

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

Representing traces in XSD

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

"clarifying" trace


<clarifyingTrace>

<trace keyword="clarifyingTrace>

Full example

If we apply all of this:

Info
TO DO:

see if "degree" has a skos name instead.

check for a compressed notation - JSON examples. Unwrap the "mapping" level at least.

note attribute should become a <comment> <note> element. Agreed.

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