Changes for page SDMX 2.1 Standards. Section 6. Technical Notes
Last modified by Artur K. on 2026/05/29 14:28
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (0 modified, 3 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -701,8 +701,6 @@ 701 701 702 702 This mechanism is an “early binding” one – everything with a versioned identity is a known quantity, and will not change. It is worth pointing out that in some cases relationships are essentially one-way references: an illustrative case is that of Categories. While a Category may be referenced by many dataflows and metadata flows, the addition of more references from flow objects does not version the Category. This is because the flows are not properties of the Categories – they merely make references to it. If the name of a Category changed, or its subCategories changed, then versioning would be necessary. 703 703 704 -^^5^^ 2010-Q3 (with a reporting year start day of ~-~-07-01) starts on 2011-01-01. This is day 6 of week 27, therefore the first week matched is week 28. 705 - 706 706 Versioning operates at the level of versionable and maintainable objects in the SDMX information model. If any of the children of objects at these levels change, then the objects themselves are versioned. 707 707 708 708 One area which is much impacted by this versioning scheme is the ability to reference external objects. With the many dependencies within the various structural objects in SDMX, it is useful to have a scheme for external referencing. This is done at the level of maintainable objects (DSDs, code lists, concept schemes, etc.) In an SDMX-ML Structure Message, whenever an “isExternalReference” attribute is set to true, then the application must resolve the address provided in the associated “uri” attribute and use the SDMX-ML Structure Message stored at that location for the full definition of the object in question. Alternately, if a registry “urn” attribute has been provided, the registry can be used to supply the full details of the object. ... ... @@ -725,13 +725,13 @@ 725 725 726 726 [[image:1747836776649-282.jpeg]] 727 727 728 - 1.**1: Schematic of the Metadata Structure Definition**726 +**Figure 1: Schematic of the Metadata Structure Definition** 729 729 730 730 The MSD comprises the specification of the object types to which metadata can be reported in a Metadata Set (Metadata Target(s)), and the Report Structure(s) comprising the Metadata Attributes that identify the Concept for which metadata may be reported in the Metadata Set. Importantly, one Report Structure references the Metadata Target for which it is relevant. One Report Structure can reference many Metadata Target i.e. the same Report Structure can be used for different target objects. 731 731 732 732 [[image:1747836776655-364.jpeg]] 733 733 734 - 1.**2: Example MSD showing Metadata Targets**732 +**Figure 2: Example MSD showing Metadata Targets** 735 735 736 736 Note that the SDMX-ML schemas have explicit XML elements for each identifiable object type because identifying, for instance, a Maintainable Object has different properties from an Identifiable Object which must also include the agencyId, version, and id of the Maintainable Object in which it resides. 737 737 ... ... @@ -741,8 +741,10 @@ 741 741 742 742 [[image:1747836776658-510.jpeg]] 743 743 744 -**Figure 3: Example MSD showing specification of three Metadata Attributes This example shows the following hierarchy of Metadata Attributes:742 +**Figure 3: Example MSD showing specification of three Metadata Attributes** 745 745 744 +This example shows the following hierarchy of Metadata Attributes: 745 + 746 746 Source – this is presentational and no metadata is expected to be reported at this level 747 747 748 748 * Source Type ... ... @@ -756,10 +756,7 @@ 756 756 757 757 **Figure 4: Example Metadata Set **This example shows: 758 758 759 -1. The reference to the MSD, Metadata Report, and Metadata Target 760 - 761 -(MetadataTargetValue) 762 - 759 +1. The reference to the MSD, Metadata Report, and Metadata Target (MetadataTargetValue) 763 763 1. The reported metadata attributes (AttributeValueSet) 764 764 765 765 = 6 Maintenance Agencies = ... ... @@ -816,8 +816,9 @@ 816 816 817 817 The Information Model for this is shown below: 818 818 816 +[[image:1747855024745-946.png]] 819 819 820 - 818 +**Figure 8: Information Model Extract for Concept Role** 821 821 822 822 It is possible to specify zero or more concept roles for a Dimension, Measure Dimension and Data Attribute (but not the ReportingYearStartDay). The Time Dimension, Primary Measure, and the Attribute ReportingYearStartDay have explicitly defined roles and cannot be further specified with additional concept roles. 823 823 ... ... @@ -837,13 +837,14 @@ 837 837 838 838 The Cross-Domain Concept Scheme maintained by SDMX contains concept role concepts (FREQ chosen as an example). 839 839 840 -[[image:17478 36776691-440.jpeg]]838 +[[image:1747855054559-410.png]] 841 841 840 + 842 842 Whether this is a role or not depends upon the application understanding that FREQ in the Cross-Domain Concept Scheme is a role of Frequency. 843 843 844 844 Using a Concept Scheme that is not the Cross-Domain Concept Scheme where it is required to assign a role using the Cross-Domain Concept Scheme. Again FREQ is chosen as the example. 845 845 846 -[[image:17478 36776693-898.jpeg]]845 +[[image:1747855075263-887.png]] 847 847 848 848 849 849 This explicitly states that this Dimension is playing a role identified by the FREQ concept in the Cross-Domain Concept Scheme. Again the application needs to understand what FREQ in the Cross-Domain Concept Scheme implies in terms of a role.
- 1747855024745-946.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +55.0 KB - Content
- 1747855054559-410.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +55.0 KB - Content
- 1747855075263-887.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +55.0 KB - Content