Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

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

SWIM-INFO-016 Mapping of information concepts requires one concept trace

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

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
Can we survive with just using these names that are inspired by the words in the spec?

Source and target of traces

The start point depends on the requirement being fulfilled

Reading order of traces

General consensus seems to be:

  1. "concept" trace
  2. "data type" trace
  3. "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 alignment (eg exact, broader, etc aka SKOS-like).

We only need additional traces if the main trace is "specialised"


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.

Representing traces in XSD

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:

  • rename. e.g. have <contextTrace> elements
  • add an attribute e.g. <trace keyword="contextTrace>

Are there other options and which is preferred?

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.




  • No labels