Mapping behaviour using item validity - Revision history

Vmurrell: /* Use Cases */

2025-11-03T16:52:17Z

‎Use Cases

Vmurrell at 13:20, 3 November 2025

2025-11-03T13:20:44Z

Vmurrell at 14:46, 4 September 2023

2023-09-04T14:46:42Z

Glenn: Glenn moved page Mapping behavior using item validity to Mapping behaviour using item validity without leaving a redirect

2020-01-22T13:28:51Z

Glenn moved page Mapping behavior using item validity to Mapping behaviour using item validity without leaving a redirect

Glenn at 13:28, 22 January 2020

2020-01-22T13:28:31Z

Glenn: /* Overview */

2020-01-21T17:40:19Z

‎Overview

Glenn at 17:36, 21 January 2020

2020-01-21T17:36:28Z

Glenn at 17:35, 21 January 2020

2020-01-21T17:35:58Z

Glenn: Glenn moved page Mapping behaviour using item validity to Mapping behavior using item validity without leaving a redirect: Typo

2020-01-21T17:35:47Z

Glenn moved page Mapping behaviour using item validity to Mapping behavior using item validity without leaving a redirect: Typo

Glenn: /* Ambiguous Validity Period Rules */

2020-01-21T17:29:49Z

‎Ambiguous Validity Period Rules

@@ Line 9: / Line 9: @@
 The main use case for setting Validity Periods on Codelist Maps is to forward schedule changes to the behavior of a map with respect to how classifications are transformed. By way of an example, consider a map that translates a country code dimension into a trading bloc dimension. If it is known that a particular country will move to a different trading bloc on a particular date, two separate rules can be created: one describing the country-bloc mapping before the move, the other describing the mapping after.
 This is illustrated in the example below:
-::[[File:Codelist mapping example with validity periods.jpg|frameless|800px]]
+::[[File:Codelist mapping example with validity periods.png|frameless|800px]]
 A DSD with INDICATOR, REF_AREA and FREQ dimensions is transformed into a similar DSD with the addition of a TRADE_BLOC dimension. When defining the mapping rules, most dimensions can be implicitly mapped (an implicit mapping is when the dimension value for each series is simply copied from the source dataset to the target dataset without any transformation). The mapping rules for the TRADE_BLOC dimension however are described using a Codelist Map working from the REF_AREA dimension.
@@ Line 16: / Line 16: @@
 The example below shows how this works in practice:
-::[[File:Codelist mapping with validity periods worked example.jpg|frameless|700px]]
+::[[File:Codelist mapping with validity periods worked example.png|frameless|700px]]
 The Source Series with Key ''A_IND:YYY:A'' is discarded and does not appear in the transformed dataset because no mapping rule is defined for REF_AREA ''YYY'' in the Codelist Map.

@@ Line 1: / Line 1: @@
 __NOTOC__
 [[Category:How_To]]
 == Overview ==

@@ Line 1: / Line 1: @@
 __NOTOC__
 [[Category:Behaviour]]
 == Overview ==
 Fusion Registry's [[Structure mapping|Structure Mapping]] function allows datasets to be transformed from one structure and classification scheme to another. Mapping of classifications is performed using [[Codelist map|Codelist Maps]] which define how Codes in one Codelist map to those in another.

@@ Line 1: / Line 1: @@
 __NOTOC__
-[[Category:Behavior]]
+[[Category:Behaviour]]
 == Overview ==
 Fusion Registry's [[Structure mapping|Structure Mapping]] function allows datasets to be transformed from one structure and classification scheme to another. Mapping of classifications is performed using [[Codelist map|Codelist Maps]] which define how Codes in one Codelist map to those in another.

@@ Line 4: / Line 4: @@
 Fusion Registry's [[Structure mapping|Structure Mapping]] function allows datasets to be transformed from one structure and classification scheme to another. Mapping of classifications is performed using [[Codelist map|Codelist Maps]] which define how Codes in one Codelist map to those in another.
 <br><br>
-When defining ''Codelist Maps'', multiple mapping rules can be specified for each Code with a ''Validity Period'' for each. The Validity Period sets when in '''real time''' the rule will be active.  Mapping rules with Validity Periods are executed if the time at which the mapping is performed falls within the time range specified. Conversely, rules without Validity Periods are always active and are executed irrespective of when the mapping is actually performed.
+When defining ''Codelist Maps'', multiple mapping rules can be specified for each Code with a ''Validity Period'' for each. The Validity Period sets when in '''real time''' the rule is active.  Mapping rules with Validity Periods are executed if the time at which the mapping is performed falls within the time range specified. Conversely, rules without Validity Periods are always active and are executed irrespective of when the mapping is actually performed.
 ==Use Cases==

← Older revision	Revision as of 13:28, 22 January 2020
(No difference)

← Older revision	Revision as of 17:35, 21 January 2020
(No difference)

@@ Line 43: / Line 43: @@
 | AAA || BLOC_2 || 1-Jan-2020 || 31-Dec-2023
 |}
-Note that rule with ambiguous Validitory Periods are always ignored, even if only one rule is valid at the time the transformation is performed as would be the case on 01-Jan-2023 in the above example.
+Note that rules with ambiguous Validitory Periods are always ignored, even if only one rule is valid at the time the transformation is performed as would be the case on 01-Jan-2023 in the above example.
 While the Fusion Registry user interface prevents the interactive creation of rules with ambiguous Validity Periods, it is still possible to load Structure Sets containing them. This is because the Item Validity information, which is not part of the official SDMX standard, is encoded as SDMX Annotations on the Structure Set. A Structure Set with Annotations on a Codelist Map that describe ambiguous Codelist Map validity periods remains valid SDMX.