Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 6.2
edited by Helena
on 2025/05/16 12:28
Change comment: There is no comment for this version
To version 6.5
edited by Helena
on 2025/05/16 12:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -26,10 +26,8 @@
26 26  
27 27  The alias of an SDMX artefact can be its URN (Universal Resource Name), an abbreviation of its URN or another user-defined name.
28 28  
29 -In any case, the aliases used in the VTL Transformations have to be mapped to the
29 +In any case, the aliases used in the VTL Transformations have to be mapped to the SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL Transformations, Rulesets{{footnote}}See also the section "VTL-DL Rulesets" in the VTL Reference Manual.{{/footnote}} or User Defined Operators{{footnote}}The VTLMappings are used also for User Defined Operators (UDO). Although UDOs are envisaged to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at their invocation, it is also possible that an UDO invokes directly some specific SDMX artefacts. These SDMX artefacts have to be mapped to the corresponding aliases used in the definition of the UDO through the VtlMappingScheme and VtlMapping classes as well.{{/footnote}} to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping.
30 30  
31 -SDMX artefacts through the VtlMappingScheme and VtlMapping classes (see the section of the SDMX IM relevant to the VTL). A VtlMapping allows specifying the aliases to be used in the VTL Transformations, Rulesets{{footnote}}See also the section "VTL-DL Rulesets" in the VTL Reference Manual.{{/footnote}} or User Defined Operators{{footnote}}The VTLMappings are used also for User Defined Operators (UDO). Although UDOs are envisaged to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at their invocation, it is also possible that an UDO invokes directly some specific SDMX artefacts. These SDMX artefacts have to be mapped to the corresponding aliases used in the definition of the UDO through the VtlMappingScheme and VtlMapping classes as well.{{/footnote}} to reference SDMX artefacts. A VtlMappingScheme is a container for zero or more VtlMapping.
32 -
33 33  The correspondence between an alias and a SDMX artefact must be one-to-one, meaning that a generic alias identifies one and just one SDMX artefact while a SDMX artefact is identified by one and just one alias. In other words, within a VtlMappingScheme an artefact can have just one alias and different artefacts cannot have the same alias.
34 34  
35 35  The references through the URN and the abbreviated URN are described in the following paragraphs.
... ... @@ -200,7 +200,7 @@
200 200  
201 201  === 12.3.3 Mapping from SDMX to VTL data structures ===
202 202  
203 -**12.3.3.1 Basic Mapping**
201 +==== 12.3.3.1 Basic Mapping ====
204 204  
205 205  The main mapping method from SDMX to VTL is called **Basic **mapping. This is considered as the default mapping method and is applied unless a different method is specified through the VtlMappingScheme and VtlDataflowMapping classes. When transforming **from SDMX to VTL**, this method consists in leaving the components unchanged and maintaining their names and roles, according to the following table:
206 206  
... ... @@ -230,18 +230,11 @@
230 230  The SDMX structures that contain a MeasureDimension are mapped as described below (this mapping is equivalent to a pivoting operation):
231 231  
232 232  * A SDMX simple dimension becomes a VTL (simple) identifier and a SDMX TimeDimension becomes a VTL (time) identifier;
233 -* Each possible Code Cj of the SDMX MeasureDimension is mapped to a VTL Measure, having the same name as the SDMX Code (i.e. Cj); the VTL Measure Cj is a new VTL component even if the SDMX data structure has not such a
234 -
235 -Component;
236 -
231 +* Each possible Code Cj of the SDMX MeasureDimension is mapped to a VTL Measure, having the same name as the SDMX Code (i.e. Cj); the VTL Measure Cj is a new VTL component even if the SDMX data structure has not such a Component;
237 237  * The SDMX MeasureDimension is not mapped to VTL (it disappears in the VTL Data Structure);
238 238  * The SDMX Measure is not mapped to VTL as well (it disappears in the VTL Data Structure);
239 239  * An SDMX DataAttribute is mapped in different ways according to its AttributeRelationship:
240 -** If, according to the SDMX AttributeRelationship, the values of the DataAttribute do not depend on the values of the MeasureDimension, the SDMX DataAttribute becomes a VTL Attribute having the same name. This happens if the
241 -
242 -AttributeRelationship is not specified (i.e. the DataAttribute does not depend on any DimensionComponent and therefore is at data set level), or if it refers to a set (or a group) of dimensions which does not include the MeasureDimension;
243 -
244 -*
235 +** If, according to the SDMX AttributeRelationship, the values of the DataAttribute do not depend on the values of the MeasureDimension, the SDMX DataAttribute becomes a VTL Attribute having the same name. This happens if the AttributeRelationship is not specified (i.e. the DataAttribute does not depend on any DimensionComponent and therefore is at data set level), or if it refers to a set (or a group) of dimensions which does not include the MeasureDimension;
245 245  ** Otherwise, if, according to the SDMX AttributeRelationship, the values of the DataAttribute depend on the MeasureDimension, the SDMX DataAttribute is mapped to one VTL Attribute for each possible Code of the SDMX MeasureDimension. By default, the names of the VTL Attributes are obtained by concatenating the name of the SDMX DataAttribute and the names of the correspondent Code of the MeasureDimension separated by underscore. For example, if the SDMX DataAttribute is named DA and the possible Codes of the SDMX MeasureDimension are named C1, C2, …, Cn, then the corresponding VTL Attributes will be named DA_C1, DA_C2, …, DA_Cn (if different names are desired, they can be achieved afterwards by renaming the Attributes through VTL operators).
246 246  ** Like in the Basic mapping, the resulting VTL Attributes are considered as dependent on all the VTL identifiers (i.e. "at data point / observation level"), because VTL does not have the SDMX notion of Attribute Relationship.
247 247  
... ... @@ -264,10 +264,7 @@
264 264  At observation / data point level, calling Cj (j=1, … n) the j^^th^^ Code of the MeasureDimension:
265 265  
266 266  * The set of SDMX observations having the same values for all the Dimensions except than the MeasureDimension become one multi-measure VTL Data Point, having one Measure for each Code Cj of the SDMX MeasureDimension;
267 -* The values of the SDMX simple Dimensions, TimeDimension and DataAttributes not depending on the MeasureDimension (these components by definition have always the same values for all the observations of the set above) become the values of the corresponding VTL (simple)
268 -
269 -Identifiers, (time) Identifier and Attributes.
270 -
258 +* The values of the SDMX simple Dimensions, TimeDimension and DataAttributes not depending on the MeasureDimension (these components by definition have always the same values for all the observations of the set above) become the values of the corresponding VTL (simple) Identifiers, (time) Identifier and Attributes.
271 271  * The value of the Measure of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Measure Cj
272 272  * For the SDMX DataAttributes depending on the MeasureDimension, the value of the DataAttribute DA of the SDMX observation belonging to the set above and having MeasureDimension=Cj becomes the value of the VTL Attribute DA_Cj
273 273  
... ... @@ -360,7 +360,7 @@
360 360  The mapping table is the following:
361 361  
362 362  (% style="width:689.294px" %)
363 -|(% style="width:344px" %)VTL|(% style="width:341px" %)SDMX
351 +|(% style="width:344px" %)**VTL**|(% style="width:341px" %)**SDMX**
364 364  |(% style="width:344px" %)(Simple) Identifier|(% style="width:341px" %)Dimension
365 365  |(% style="width:344px" %)(Time) Identifier|(% style="width:341px" %)TimeDimension
366 366  |(% style="width:344px" %)Some Measures|(% style="width:341px" %)Measure
... ... @@ -420,22 +420,16 @@
420 420  
421 421  SDMX Dataflow having INDICATOR=//INDICATORvalue //and COUNTRY=// COUNTRYvalue//. For example, the VTL dataset ‘DF1(1.0.0)/POPULATION.USA’ would contain all the observations of DF1(1.0.0) having INDICATOR = POPULATION and COUNTRY = USA.
422 422  
423 -In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets{{footnote}}If these DimensionComponents would not be dropped, the various VTL Data Sets resulting from this kind of mapping would have non-matching values for the Identifiers corresponding to the mapping Dimensions (e.g. POPULATION and COUNTRY). As a consequence, taking into account that the typical binary VTL operations at dataset level (+, -, *, / and so on) are executed on the observations having matching values for the identifiers, it would not be possible to compose the resulting VTL datasets one another (e.g. it would not be possible to calculate the population ratio between USA and CANADA).{{/footnote}}. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e.
411 +In order to obtain the data structure of these VTL Data Sets from the SDMX one, it is assumed that the SDMX DimensionComponents on which the mapping is based are dropped, i.e. not maintained in the VTL data structure; this is possible because their values are fixed for each one of the invoked VTL Data Sets{{footnote}}If these DimensionComponents would not be dropped, the various VTL Data Sets resulting from this kind of mapping would have non-matching values for the Identifiers corresponding to the mapping Dimensions (e.g. POPULATION and COUNTRY). As a consequence, taking into account that the typical binary VTL operations at dataset level (+, -, *, / and so on) are executed on the observations having matching values for the identifiers, it would not be possible to compose the resulting VTL datasets one another (e.g. it would not be possible to calculate the population ratio between USA and CANADA).{{/footnote}}. After that, the mapping method from SDMX to VTL specified for the Dataflow DF1(1.0.0) is applied (i.e. basic, pivot …).
424 424  
425 -basic, pivot …).
413 +In the example above, for all the datasets of the kind ‘DF1(1.0.0)///INDICATORvalue//.//COUNTRYvalue//’, the dimensions INDICATOR and COUNTRY would be dropped so that the data structure of all the resulting VTL Data Sets would have the identifier TIME_PERIOD only.
426 426  
427 -In the example above, for all the datasets of the kind
428 -
429 -‘DF1(1.0.0)///INDICATORvalue//.//COUNTRYvalue//’, the dimensions INDICATOR and COUNTRY would be dropped so that the data structure of all the resulting VTL Data Sets would have the identifier TIME_PERIOD only.
430 -
431 431  It should be noted that the desired VTL Data Sets (i.e. of the kind ‘DF1(1.0.0)/// INDICATORvalue//.//COUNTRYvalue//’) can be obtained also by applying the VTL operator “**sub**” (subspace) to the Dataflow DF1(1.0.0), like in the following VTL expression:
432 432  
433 433  ‘DF1(1.0.0)/POPULATION.USA’ :=
434 -
435 435  DF1(1.0.0) [ sub INDICATOR=“POPULATION”, COUNTRY=“USA” ];
436 436  
437 437  ‘DF1(1.0.0)/POPULATION.CANADA’ :=
438 -
439 439  DF1(1.0.0) [ sub INDICATOR=“POPULATION”, COUNTRY=“CANADA” ];
440 440  
441 441  … … …
... ... @@ -451,7 +451,6 @@
451 451  This is equivalent to the application of the VTL “sub” operator only to the identifier //INDICATOR//:
452 452  
453 453  ‘DF1(1.0.0)/POPULATION.’ :=
454 -
455 455  DF1(1.0.0) [ sub INDICATOR=“POPULATION” ];
456 456  
457 457  Therefore the VTL Data Set ‘DF1(1.0.0)/POPULATION.’ would have the identifiers COUNTRY and TIME_PERIOD.
... ... @@ -482,11 +482,8 @@
482 482  ‘DF2(1.0.0)/GDPPERCAPITA.USA’ <- expression11; ‘DF2(1.0.0)/GDPPERCAPITA.CANADA’ <- expression12;
483 483  
484 484  … … …
485 -
486 486  ‘DF2(1.0.0)/POPGROWTH.USA’ <- expression21;
487 -
488 488  ‘DF2(1.0.0)/POPGROWTH.CANADA’ <- expression22;
489 -
490 490  … … …
491 491  
492 492  As said, it is assumed that these VTL derived Data Sets have the TIME_PERIOD as the only identifier. In the mapping from VTL to SMDX, the Dimensions INDICATOR and COUNTRY are added to the VTL data structure on order to obtain the SDMX one, with the following values respectively: