...
Different types of traces
| Note |
|---|
| Can we survive with just using these names that are inspired by the words in the spec? |
| 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.
| Trace name | Source | Target |
|---|---|---|
| "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: |
...
| Note |
|---|
| Can we survive with just using these names that are inspired by the words in the spec? |
Source and target of traces
...
| 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. |
Reading order of traces
General consensus seems to be:
...
reading order is:
- "information concept" trace
- "additional" traces
or
- "data concept" trace
- "data type" trace
- "additional" traces
All traces have an AND relationship.
Annotating 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
...
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 | |
|---|---|---|
| Equivalent | ExactCopy: Definition of concepts in the information definition and the AIRM are exact copy of each other. SyntacticallyEqual: Definitions are only different due to syntax corrections (grammar, spelling) but are otherwise equivalent. 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. | |
| Wider | Specialised: The definition in the information definition is a special case of the definition found in the AIRM. |
| Note |
|---|
We only need additional traces if the main trace is "specialised" |
| Note |
|---|
Traces cannot be annotated as "generalised" as this breaks the requirement. |
| Info | ||
|---|---|---|
| ||
| 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: |
...
|
...
|
...
|
...
|
...
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: |
...
|
...
|
Annotating traces
It is possible to add a further annotations 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
...
| Trace name | Element name | Attribute |
|---|---|---|
| "information concept" trace | <informationConceptTrace> | <trace keyword="informationConceptTrace> |
| <dataConceptTrace> <dataTypeTrace> | <trace keyword="dataConceptTrace> <trace keyword="dataTypeTrace> |
| "additional" trace | <additionalTrace> | <trace keyword="additionalTrace> |
Full example
If we apply all of this:
| Code Block | ||
|---|---|---|
| ||
<xs:annotation> <xs:documentation> <semanticCorrespondence> <mapping> <informationConceptTrace degree="specialised">-AIRM unique identifier-</informationConceptTrace> <additionalTrace>-AIRM unique identifier-</additionalTrace> </mapping> </semanticCorrespondence> </xs:documentation></xs:annotation> |
Example of tracing exercise
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.
...
How should the different traces be represented in the XSD examples we use?
At the moment we have a list of <trace> elements. This will obviously need to be updated to reflect the agreed practice. I see two obvious options:
Are there other options and which is preferred?