Skip to Content
Last modified by Artur K. on 2026/05/29 14:28
From version 1.4
edited by Helena K.
on 2026/01/27 13:34
Change comment: There is no comment for this version
To version 1.1
edited by Helena K.
on 2026/01/27 13:31
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -28,11 +28,12 @@
28 28  
29 29  Further recommended code values for expressing general statistical concepts such as "not applicable", etc., can be found in section “Generic codes” of the "Guidelines for the creation and management of SDMX Cross-Domain Code Lists" (to be found under “Guidelines” on the official SDMX website[[~[2~]>>path:#_ftn2]]).
30 30  
31 -= 2. SDMX Concepts for Time Transformations =
31 +1. SDMX Concepts for Time Transformations
32 32  
33 33  SDMX defines two cross domain concepts for the purpose of coding time transformations: Time transformation type (ID TIMETRANS_TYPE) and time transformation periods (ID TIMETRANS_PER). The concept TIMETRANS_TYPE is coded with a cross domain code list. The concept TIMETRANS_PER is coded with a coded list of integers.
34 34  
35 -== 2.1 Time Transformation Type ==
35 +1.
36 +11. Time Transformation Type
36 36  
37 37  Definition: This concept provides coded information about time-related transformation types of time series.
38 38  
... ... @@ -61,7 +61,8 @@
61 61  |**S**|Shifted|The time series was moved back or forth in time. This may for instance be used when non-calendar year series are aligned to the calendar year using certain estimation formulas.
62 62  |**_O**|Other transformation|This code is taken from the guidelines on generic codes, specifying "Other". In that context it should be used if more complex transformations are applied. An explanation of the transformation or a transformation script should be given in a comment field.
63 63  
64 -== 2.2 Time Transformation Periods ==
65 +1.
66 +11. Time Transformation Periods
65 65  
66 66  Definition: This concept provides information about the number of periods used for a time-related transformation of the time series.
67 67  
... ... @@ -81,7 +81,8 @@
81 81  |**2**|Two|
82 82  |**etc.**|etc.|
83 83  
84 -== 2.3 Relation of transformation coding to transformation rules ==
86 +1.
87 +11. Relation of transformation coding to transformation rules
85 85  
86 86  Transformation can also be expressed with transformation rules using a syntax such as the Validation and Transformation Language (VTL). Following the transformation graph model behind VTL, the transformation coding suggested in this guideline can be seen complementary with using transformation rules in VTL. The idea is that a coded non-transformed time series is transformed using a VTL rule and the result is then coded again with transformation codes for further data exchange. This principle is shown in the graph below:
87 87  
... ... @@ -100,6 +100,8 @@
100 100  (VTL)
101 101  )))
102 102  
106 +
107 +
103 103  Using the two concepts as suggested above for coding the type of transformation applied and the number of periods covered will additionally ensure that the parameters used for the formula are directly used in the coding of the resulting series. Thus no complex mapping is needed. The transformation applied is linked to the transformation type concept and the number of periods used for the calculation is linked to the transformation periods concept.
104 104  
105 105  **Example:**
... ... @@ -143,7 +143,8 @@
143 143  
144 144  This is especially useful when only transformed series should be exchanged and level series or transformations are not subject to exchange. An example could be GDP growth rates, where for early estimates often level series are still under embargo, whereas growth rates are publishable.
145 145  
146 -== 2.4 Recommendation ==
151 +1.
152 +11. Recommendation
147 147  
148 148  Where possible, it is recommended to use the above solution with the two concepts TIMETRANS_TYPE and TIMETRANS_PER to express time transformations because:
149 149  
... ... @@ -151,10 +151,9 @@
151 151  * it is possible to add extra concepts if required without introducing ambiguity;
152 152  * the coded transformations can be linked directly with transformation formulas.
153 153  
154 -= 3. Compound coding for time transformations =
160 +1. Compound coding for time transformations
161 +11. Known Limitations
155 155  
156 -== 3.1 Known Limitations ==
157 -
158 158  The normalised approach as presented above does not support the definition of mixed-frequency time transformations – like monthly series of annual growth rates – since there is only a single frequency dimension available. This also means that when annual growth rates are expressed in a quarterly dataset, the time transformation period would need to be modified (i.e. when frequency changes from A to Q, the number of periods need to be quadrupled).
159 159  
160 160  A "transformation frequency" might be added to keep the normalised approach also for those cases.
... ... @@ -167,6 +167,8 @@
167 167  
168 168  The number of periods in the code follows the frequency of the series unless stated otherwise. Example: code G3Y refers to a three-year growth rate, irrespective of the series frequency. For complex transformations, the codes that would be used for the respective transformations can be concatenated and separated by an underscore[[~[4~]>>path:#_ftn4]].
169 169  
175 +
176 +
170 170  Example for composite CL_TIMETRANS:
171 171  
172 172  |**Recommended code value**|**Recommended
© Semantic R&D Group, 2026