Skip to Content

Changes for page 4 Specific Item Schemes

Last modified by Artur on 2025/09/10 11:19
From version 3.6
edited by Helena
on 2025/05/20 12:09
Change comment: There is no comment for this version
To version 4.3
edited by Helena
on 2025/05/22 00:40
Change comment: There is no comment for this version

Summary

Details

Page properties
Parent
... ... @@ -1,0 +1,1 @@
1 +Methodology.SDMX 2\.1 Standards\. Section 2\. Information model\: UML conceptual design.WebHome
Content
... ... @@ -20,6 +20,8 @@
20 20  
21 21  === {{id name="_Toc370990"/}}4.3.1 Class Diagram ===
22 22  
23 +[[image:1747732337979-971.png]]
24 +
23 23  **Figure 15 Class diagram of the Codelist**
24 24  
25 25  === {{id name="_Toc370991"/}}4.3.2 Explanation of the Diagram ===
... ... @@ -72,6 +72,8 @@
72 72  
73 73  === {{id name="_Toc370993"/}}4.4.1 Class Diagram - Inheritance ===
74 74  
77 +[[image:1747732287949-594.png]]
78 +
75 75  **Figure 16 Class diagram of the Concept Scheme**
76 76  
77 77  === {{id name="_Toc370994"/}}4.4.2 Explanation of the Diagram ===
... ... @@ -107,6 +107,7 @@
107 107  
108 108  === {{id name="_Toc370995"/}}4.4.3 Class Diagram - Relationship ===
109 109  
114 +[[image:1747732242162-856.png]]
110 110  
111 111  **Figure 17: Relationship class diagram of the Concept Scheme**
112 112  
... ... @@ -114,14 +114,10 @@
114 114  
115 115  ==== 4.4.4.1 Narrative ====
116 116  
117 -The ConceptScheme can have one or more Concepts. A Concept can have zero or more child Concepts, thus supporting a hierarchy of Concepts. Note that a child Concept can have only one parent Concept in this association. The purpose of the hierarchy is to relate concepts that have a semantic relationship: for example a Reporting_Country and Vis_a_Vis_Country may both have Country as a parent concept, or a CONTACT may have a PRIMARY_CONTACT as a child concept. It is not the purpose of such schemes to define reporting structures: these reporting structures are defined in the
122 +The ConceptScheme can have one or more Concepts. A Concept can have zero or more child Concepts, thus supporting a hierarchy of Concepts. Note that a child Concept can have only one parent Concept in this association. The purpose of the hierarchy is to relate concepts that have a semantic relationship: for example a Reporting_Country and Vis_a_Vis_Country may both have Country as a parent concept, or a CONTACT may have a PRIMARY_CONTACT as a child concept. It is not the purpose of such schemes to define reporting structures: these reporting structures are defined in the MetadataStructureDefinition.
118 118  
119 -MetadataStructureDefinition.
124 +The Concept can be associated with a coreRepresentation. The coreRepresentation isthe specification of the format and value domain of the Concept when used on a structure like a DataStructureDefinition or a MetadataStructureDefinition, unless the specification of the Representation is overridden in the relevant structure definition. In a hierarchical ConceptScheme the Representation is inherited from the parent Concept unless overridden at the level of the child Concept.
120 120  
121 -The Concept can be associated with a coreRepresentation. The coreRepresentation isthe specification of the format and value domain of the Concept when used on a structure like a DataStructureDefinition or a
122 -
123 -MetadataStructureDefinition, unless the specification of the Representation is overridden in the relevant structure definition. In a hierarchical ConceptScheme the Representation is inherited from the parent Concept unless overridden at the level of the child Concept.
124 -
125 125  Note that the ConceptScheme is used as the Representation of the MeasureDimension in a DataStructureDefinition (see 5.3.2). Each Concept in this ConceptScheme is a specific measure, each of which can be given a coreRepresentation. Thus the valid format of the observation for each measure when reported in a data set for the MeasureDimension is specified in the Concept. This allows a different format for each measure. This is covered in more detail in 5.3.
126 126  
127 127  The Representation is documented in more detail in the section on the SDMX Base.
... ... @@ -160,8 +160,11 @@
160 160  
161 161  === {{id name="_Toc370999"/}}4.5.2 Class diagram - Inheritance ===
162 162  
163 -====== Figure 18 Inheritance Class diagram of the Category Scheme ======
164 +====== [[image:1747732448450-721.png]] ======
164 164  
166 +(% class="wikigeneratedid" id="HFigure18InheritanceClassdiagramoftheCategoryScheme" %)
167 +**Figure 18 Inheritance Class diagram of the Category Scheme**
168 +
165 165  === {{id name="_Toc371000"/}}4.5.3 Explanation of the Diagram ===
166 166  
167 167  ==== 4.5.3.1 Narrative ====
... ... @@ -194,12 +194,12 @@
194 194  
195 195  === {{id name="_Toc371001"/}}4.5.4 Class diagram - Relationship ===
196 196  
201 +[[image:1747732486733-495.png]]
202 +
197 197  **Figure 19: Relationship Class diagram of the Category Scheme**
198 198  
199 -The CategoryScheme can have one or more Categorys. The Category is Identifiable and has identity information. A Category can have zero or more child Categorys, thus supporting a hierarchy of Categorys. Any IdentifiableArtefact can be +categorisedBy a Category. This is achieved by means of a Categorisation. Each
205 +The CategoryScheme can have one or more Categorys. The Category is Identifiable and has identity information. A Category can have zero or more child Categorys, thus supporting a hierarchy of Categorys. Any IdentifiableArtefact can be +categorisedBy a Category. This is achieved by means of a Categorisation. Each Categorisation can associate one IdentifiableArtefact with one Category. Multiple Categorisations can be used to build a set of IdentifiableArtefacts that are +categorisedBy the same Category. Note that there is no navigation (i.e. no embedded reference) to the Categorisation from the Category. From an implementation perspective this is necessary as Categorisation has no affect on the versioning of either the Category or the IdentifiableArtefact.
200 200  
201 -Categorisation can associate one IdentifiableArtefact with one Category. Multiple Categorisations can be used to build a set of IdentifiableArtefacts that are +categorisedBy the same Category. Note that there is no navigation (i.e. no embedded reference) to the Categorisation from the Category. From an implementation perspective this is necessary as Categorisation has no affect on the versioning of either the Category or the IdentifiableArtefact.
202 -
203 203  ==== 4.5.4.1 Definitions ====
204 204  
205 205  (((
... ... @@ -313,6 +313,7 @@
313 313  
314 314  === {{id name="_Toc371006"/}}4.7.1 Class Diagram ===
315 315  
320 +[[image:1747732548003-370.png]]
316 316  
317 317  **Figure 21: Class diagram of the Reporting Taxonomy**
318 318  
... ... @@ -327,7 +327,6 @@
327 327  Section 1
328 328  
329 329  ~1. linked to DatafowDefinition_1
330 -
331 331  2 linked to DatafowDefinition_2
332 332  
333 333  Section 2
1747732242162-856.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +21.8 KB
Content
1747732287949-594.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +42.4 KB
Content
1747732337979-971.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +39.3 KB
Content
1747732448450-721.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +34.0 KB
Content
1747732486733-495.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +18.6 KB
Content
1747732548003-370.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +48.9 KB
Content