AIXM-400 (intermediate version) Forward-backward data mapping strategy

Description

This document describes data mapping solutions applied in the change proposals. It contains proposed rules for converting the AIXM data either “forward” (from the older version into the new version) or “backward” (from the new version into the older version).

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-328

A new AIXM version can come with new features, properties or allowable values. In the same time, existing features, properties or allowable values may be deleted. Each change proposal is required to propose data mapping/conversion rules for all the elements affected. 

In principle, similar mapping situations should be treated in similar ways. Therefore, the objective of this change proposal is to identify the generic mapping cases that could occur between two consecutive AIXM versions and to propose generic data conversion rules. This should also facilitate the writing of the other change proposals, which could refer to the identifier of each generic mapping case. 

The following high-level principles are applied:

• No backwards mapping for complex new concepts

A new version might come with several new features and properties, that model a new concept, such as GNSS systems. In this situation, no backward mapping is really possible, since the current model does not have any class that would correspond to the new concept. The only solution for systems using a previous AIXM version and that are interested in the new data is to define and use an extension.

• Conversion rules are only recommendations

All forward and backward mapping / conversion rules are formulated as proposals only. The final decision to actually convert the data will depend on the actual user needs. For example, if a new attribute is introduced in a newer version, some users of the previous version might be willing to get the data as a simple text annotation, because they might have a specific need for that information, even if it implies manual processing by an operator. However, other users might not be interested at all in the new value and might just discard it.

• Annotations are not structured

When annotations are used in order to save some information from the newer version (such as a new property), they remain free text annotations. Annotations are not suitable for automatic processing and therefore it is not appropriate to use structured data inside an annotation, in order to mimic a new property and its values. Instead, if a system using an older AIXM version is really interested to get structured data for the new information that comes with the newer version, an extension shall be defined and used.

• Use OTHER:NEW_VALUE… for new codelist values

When new allowable values are introduced in a codelist in a newer AIXM version, they can always be mapped backwards using the codelist extension mechanism, which consists into prefixing the new value with “OTHER:”. This codelist extension mechanism was intentionally made available in AIXM version 5 for this purpose. The only limitation that needs to be kept in mind is that the maximum length of the coded value is 58 characters, so that it fits in the schema pattern for “OTHER:..”

• Some conversion rules should not be applicable to PERMDELTA TimeSlices

Conversion rules that result in the creation of a new annotation.Note should not be applied when working with PERMDELTA. Otherwise, each time a PERMDELTA is converted, a new annotation.Note may be created and saved in the BASELINE data, as there is no possibility to identify which existing annotation.Note might have been generated with a similar past mapping and which could be replaced. Therefore, such annotations risk to accumulate and duplicate each other after several conversions.

• Moving properties from a feature into another feature requires TimeSlices alignment

Some change proposals might move one or more, simple or complex properties from one feature into another feature. There are two extreme situations:

- a feature that becomes an object in the new model, which practically means that all the properties of one feature are transferred to another feature and the current feature does no longer exist;

- an object becomes a feature, which practically means that the object properties are transferred to a new feature. This is in fact the reverse mapping case of the previous bullet point.

In all such cases, the “recipient” feature timeline might need to be split with additional TimeSlices, in order to accommodate the possibly different timeline the properties concerned. The following diagram shows an example of a fictitious situation that falls in this category:

In this case, a property is moved from feature B into feature A. Within feature B, the property has no value during the validTime of the TimeSlice B/TS1, then it has two different values V1 and V2 during the validTime of the TimeSlices B/TS2 and B/TS3 respectively. The validity periods of the feature B TimeSlices is different from the validity periods of the feature A TimeSlices. When mapping the values of the property moved into feature A, the diagram shows that the TimeSlice structure of feature A needs to be changed, in order to correctly reflect the values of the additional property. For example, the TimeSlice A/TS2 needs to be split into two different TimeSlices, as the moved property will get a value V1 starting sometime in the middle of the validTime of the A/TS2 TimeSlice.

The process described above might be very difficult to apply to the complete set of TimeSlices of an existing feature. The recipient system might decide to limit this kind of mapping to the current and future BASELINE only.

Change Proposal details

This section identifies typical mapping cases that could occur between AIXM 5.1.1 and AIXM 5.2 and provides forward/backward mapping rules for each such case. In order to allow referencing these mapping cases from the change proposal concerned, each case is identified with the acronym “MAPC” (MAPping Case) followed by a two digit number. The same identifier is used in both the forwards and backwards mapping cases.