Working towards the next version of the SWIM Supporting Material
SWIM-INFO-018 Additional traces to clarify the mapping allows any number of additional "clarifying" traces
If we define these
- "concept" trace / "definition" trace: point to the comprehensive or even normative definition (when available) or to the best matching wider AIRM concept
- "information concept" trace
- "data concept" trace
- "data type" trace:
- "additional" traces: traces that add qualifiers. helping achieving a more accurate semantic definition by giving more context to the main mapping
Source and target of traces
"concept" trace / "definition" trace:
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.
Reading order of traces
General consensus seems to be:
- "concept" trace
- "data type" trace
- "additional" traces
Add a comment of the mapping (or trace?). This comes in handy for example when tracing legacy interfaces that have data type constraints leading to loss of Information.
Level of semantic correspondence
See Rule 60 below for resuselevel of alignment (eg exact, broader, etc aka SKOS-like).
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.
Representing traces in XSD
Example of tracing
Example of tracing
If not prefer to name the traces like "semanticTrace" etc. it may be helpful for the user to give advice like "If you have your payload at hand and want to map it to the AIRM first look into the LM" (bottom-up approach) or "If you are in the process of creating your payload take a look into the AIRM CM to check for possible concepts to cover with your payload" (top-down approach). Perhaps this approach is more intuitive for (especially new) users because they can start with their own working status. Just a random guess from my point of view.
However it should be consistent with the information given at the AIRM homepage. Links to the according pages will also help.