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 6 Next »


Page Table of Content


Extract of requirement

Title

Mapping of data concepts to the matching AIRM concepts

Identifier

SWIM-INFO-017

Requirement

The mapping of a data concept shall contain a trace from the data concept in the information definition to the AIRM concept that has an equivalent or wider meaning and a trace to the data type in the AIRM that has an equivalent or wider meaning.

Rationale

This includes a basic trace to establish the semantic correspondence between concepts. Without such a trace the mapping is pointless.


The requirement adds a second trace for data concepts, as the constraint on value space expressed by the data type is also important to the semantics.

Verification

Correctness

Examples/Notes

Example: An example is an information definition contains a data concept called “Target Startup Approval Time” that is a time.


Two traces are needed for this mapping:
  • one trace to the AIRM concept called “StartUp”; and
  • one trace to the AIRM data type called “DateTime”.

Note: In cases where the trace is to an AIRM concept that has a wider meaning, SWIM-INFO-018 also applies. An example of a trace to an AIRM concept with a wider meaning can be found in SWIM-INFO-018.


Note: It may be possible to combine these traces into one single statement depending on the tracing techniques adopted.


Note: This requirement implies that implementations using technology that provides no typing (for example, JSON) will need to specify the applicable value range constraints at design time relative to the AIRM data type to demonstrate semantic correspondence.


Note: SWIM-INFO-019 requires the use of the AIRM’s unique identifiers in traces.

Level of Implementation

Mandatory

Explanations

Needs to be read in conjunction with the rule on compatibility of data types. Make it clear we are still tracing semantics, not logical constraints on data types.

Options: if can't map the datatype

  • raise a CR to change AIRM
  • explain how to achieve the mapping e.g. I use characterString but expect only numerics. Explain why it is compatible.
  • could be that the mapping at concept level is wrong.

Examples

  • simple mapping e.g. characterString and numeric
  • complex mapping such as estimated take-off time
  • geometries as a way to better explore compatibility.

How to read the AIRM to find the data types etc. Maybe an annex to the supporting material. Where should I start e,g, LM or IM.

  • Information concepts are in the IM.
  • Data concepts and their Datatypes are in the LM
  • Basic type semantics are in the Foundation.

Two use cases - place at the root of this semantic correspondence section:

  • technical - near service developers - use LM
  • operational - e.g. for information exchange requirements  - use IM.

Other notes

  • if you have a data type but the AIRM does not you are probably in the wrong AIRM part. Consider looking at the LM.


SEE COMPLIANCE HANDBOOK FOR IDEAS


Verification Support

Correctness: Check that the trace is to the correct target

Examples/Best Practice

Example of SWIM-INFO-017
<gmd:title> guess what </gmd:title>
  • No labels