Working towards the next version of the SWIM Supporting Material
|Table of Contents|
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?
Much of the background has been captured in the comments section below.
The discussion has been split into parts to make easier to follow.
The traces are to be read by humans/machines
The traces are to be created by humans/machines
Different types of traces
|Requirement||Trace required||Trace name||Definition|
|SWIM-INFO-016 Mapping of information concepts||requires one concept trace||"information concept" trace||trace 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
|SWIM-INFO-018 Additional traces to clarify the mapping||allows any number of additional clarifying traces||"additional" trace||trace 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.
|"information concept" trace||Likely sources: information exchange requirements|
Best place to start: Conceptual Model.
If not found there, use Contextual Model or Logical Model
|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" trace||source depends on the trace being clarified|
Should be in the same model as the trace being qualified.
The Interoperability Architecture provides good advice. Basically, trace to the adjacent box by default.
Reading order of traces
General reading order is:
- "information concept" trace
- "additional" traces
- "data concept" trace
- "data type" trace
- "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"
|Definition being traced to is...||Annotations that can make this more explicit||or in skos|
|Wider||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.
We only need additional traces if the main trace is "specialised"
Traces cannot be annotated as "generalised" as this breaks the requirement.
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:
A data or information construct is considered to be in semantic correspondence with the AIRM if one of the following conditions holds:
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
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.
Different artefacts have used different trace "qualifiers".
- "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.
- "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).
- "Context Traces" that add qualifiers (i.e. implement SWIM-INFO-018). These are optional, and their order should not have semantic significance.
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:
- AIRM Semantic Trace
- AIRM Definition Trace. This seems to be in line with what Stefan mentioned above.
- AIRM Context Trace. This appears to add the qualifiers as mentioned by Stefan above.
Looking at the ISRM (Information Service Reference Model) it has:
- 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;
- 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;
- 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.
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.