Changes for page Guidelines on coding time transformations in SDMX

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -28,12 +28,11 @@
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		-1. SDMX Concepts for Time Transformations
	31	+= 2. 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		-1.
36		-11. Time Transformation Type
	35	+== 2.1 Time Transformation Type ==
37	37
38	38	Definition: This concept provides coded information about time-related transformation types of time series.
39	39
...	...	@@ -62,8 +62,7 @@
62	62	|**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.
63	63	|**_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.
64	64
65		-1.
66		-11. Time Transformation Periods
	64	+== 2.2 Time Transformation Periods ==
67	67
68	68	Definition: This concept provides information about the number of periods used for a time-related transformation of the time series.
69	69
...	...	@@ -83,8 +83,7 @@
83	83	|**2**|Two|
84	84	|**etc.**|etc.|
85	85
86		-1.
87		-11. Relation of transformation coding to transformation rules
	84	+== 2.3 Relation of transformation coding to transformation rules ==
88	88
89	89	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:
90	90
...	...	@@ -103,8 +103,6 @@
103	103	(VTL)
104	104	)))
105	105
106		-
107		-
108	108	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.
109	109
110	110	**Example:**
...	...	@@ -148,8 +148,7 @@
148	148
149	149	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.
150	150
151		-1.
152		-11. Recommendation
	146	+== 2.4 Recommendation ==
153	153
154	154	Where possible, it is recommended to use the above solution with the two concepts TIMETRANS_TYPE and TIMETRANS_PER to express time transformations because:
155	155
...	...	@@ -157,9 +157,10 @@
157	157	* it is possible to add extra concepts if required without introducing ambiguity;
158	158	* the coded transformations can be linked directly with transformation formulas.
159	159
160		-1. Compound coding for time transformations
161		-11. Known Limitations
	154	+= 3. Compound coding for time transformations =
162	162
	156	+== 3.1 Known Limitations ==
	157	+
163	163	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).
164	164
165	165	A "transformation frequency" might be added to keep the normalised approach also for those cases.
...	...	@@ -172,8 +172,6 @@
172	172
173	173	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]].
174	174
175		-
176		-
177	177	Example for composite CL_TIMETRANS:
178	178
179	179	|**Recommended code value**|**Recommended
...	...	@@ -228,7 +228,7 @@
228	228
229	229	The use of codes like G3Y introduces redundancy in the code list. G3Y equals G36 for monthly data, G12 for quarterly data and G3 for annual data. Thus introducing such extensions should be well justified by solid use cases and DSD guidelines should explain which of the two possibilities (GxY or Gx) are preferred and why. Machine-to-machine queries, formulas, validation rules or coding templates may require mappings between those possibilities, taking into account both the frequency of a series and the transformation code.
230	230
231		-1. Annex: coded examples
	224	+= Annex: coded examples =
232	232
233	233	The table below shows coding example using all 3 options lined out above.
234	234