Skip to Content

Changes for page 4 Specific Item Schemes

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

Summary

Details

Page properties
Content
... ... @@ -20,8 +20,6 @@
20 20  
21 21  === {{id name="_Toc370990"/}}4.3.1 Class Diagram ===
22 22  
23 -[[image:1747732337979-971.png]]
24 -
25 25  **Figure 15 Class diagram of the Codelist**
26 26  
27 27  === {{id name="_Toc370991"/}}4.3.2 Explanation of the Diagram ===
... ... @@ -74,8 +74,6 @@
74 74  
75 75  === {{id name="_Toc370993"/}}4.4.1 Class Diagram - Inheritance ===
76 76  
77 -[[image:1747732287949-594.png]]
78 -
79 79  **Figure 16 Class diagram of the Concept Scheme**
80 80  
81 81  === {{id name="_Toc370994"/}}4.4.2 Explanation of the Diagram ===
... ... @@ -111,7 +111,6 @@
111 111  
112 112  === {{id name="_Toc370995"/}}4.4.3 Class Diagram - Relationship ===
113 113  
114 -[[image:1747732242162-856.png]]
115 115  
116 116  **Figure 17: Relationship class diagram of the Concept Scheme**
117 117  
... ... @@ -119,10 +119,14 @@
119 119  
120 120  ==== 4.4.4.1 Narrative ====
121 121  
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.
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
123 123  
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.
119 +MetadataStructureDefinition.
125 125  
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 +
126 126  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.
127 127  
128 128  The Representation is documented in more detail in the section on the SDMX Base.
... ... @@ -161,11 +161,8 @@
161 161  
162 162  === {{id name="_Toc370999"/}}4.5.2 Class diagram - Inheritance ===
163 163  
164 -====== [[image:1747732448450-721.png]] ======
163 +====== Figure 18 Inheritance Class diagram of the Category Scheme ======
165 165  
166 -(% class="wikigeneratedid" id="HFigure18InheritanceClassdiagramoftheCategoryScheme" %)
167 -**Figure 18 Inheritance Class diagram of the Category Scheme**
168 -
169 169  === {{id name="_Toc371000"/}}4.5.3 Explanation of the Diagram ===
170 170  
171 171  ==== 4.5.3.1 Narrative ====
... ... @@ -198,12 +198,12 @@
198 198  
199 199  === {{id name="_Toc371001"/}}4.5.4 Class diagram - Relationship ===
200 200  
201 -[[image:1747732486733-495.png]]
202 -
203 203  **Figure 19: Relationship Class diagram of the Category Scheme**
204 204  
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.
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
206 206  
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 +
207 207  ==== 4.5.4.1 Definitions ====
208 208  
209 209  (((
... ... @@ -317,7 +317,6 @@
317 317  
318 318  === {{id name="_Toc371006"/}}4.7.1 Class Diagram ===
319 319  
320 -[[image:1747732548003-370.png]]
321 321  
322 322  **Figure 21: Class diagram of the Reporting Taxonomy**
323 323  
1747732242162-856.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -21.8 KB
Content
1747732287949-594.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -42.4 KB
Content
1747732337979-971.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -39.3 KB
Content
1747732448450-721.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -34.0 KB
Content
1747732486733-495.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -18.6 KB
Content
1747732548003-370.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -48.9 KB
Content