Versions Compared

Version Old Version 13 New Version 14
Changes made by

WILSON Scott

WILSON Scott

Saved on

Key

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

Insert excerpt
SITCOM Task Status
SITCOM 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?

Background

Much of the background has been captured in the comments section below.

Discussion

The discussion has been split into parts to make easier to follow.

Assumptions

The traces are to be read by humans/machines

The traces are to be created by humans/machines

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?
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

Source and target of traces

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

  1. "data concept" trace
  2. "data type" trace
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" tracesource depends on the trace being clarified

Should be in the same model as the trace being qualified.

Info

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

Reading order of traces

General reading order is:

  1. "information concept" trace
  2. "additional" traces

or

  1. "data concept" trace
  2. "data type" trace
  3. "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 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.
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
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.


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?


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>

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>

Full example

If we apply all of this:

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-</informationConceptTrace>
        <trace type="additionalTrace">-AIRM unique identifier-</additionalTrace>
      </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.