Changes for page 4 Specific Item Schemes

Last modified by Helena on 2025/09/10 11:19

From version 5.1
edited by Helena
on 2025/06/08 01:08
Change comment: There is no comment for this version
To version 3.1
edited by Helena
on 2025/06/07 00:56
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,9 +1,5 @@
1 -{{box title="**Contents**"}}
2 -{{toc/}}
3 -{{/box}}
1 +=== 4.1 Introduction ===
4 4  
5 -== 4.1 Introduction ==
6 -
7 7  The structures that are an arrangement of objects into hierarchies or lists based on characteristics, and which are maintained as a group inherit from //ItemScheme//. These concrete classes are:
8 8  
9 9  Codelist
... ... @@ -32,21 +32,21 @@
32 32  
33 33  Note that the VTL related schemes (the last 6 of the above list) are detailed in a dedicated section below (section 15).
34 34  
35 -== 4.2 Inheritance View ==
31 +=== 4.2 Inheritance View ===
36 36  
37 37  The inheritance and relationship views are shown together in each of the diagrams in the specific sections below.
38 38  
39 -== 4.3 Codelist ==
35 +=== 4.3 Codelist ===
40 40  
41 -=== 4.3.1 Class Diagram ===
37 +==== 4.3.1 Class Diagram ====
42 42  
43 43  [[image:1749246291075-895.jpeg]]
44 44  
45 45  **Figure 16: Class diagram of the Codelist**
46 46  
47 -=== 4.3.2 Explanation of the Diagram ===
43 +==== 4.3.2 Explanation of the Diagram ====
48 48  
49 -==== 4.3.2.1 Narrative ====
45 +===== 4.3.2.1 Narrative =====
50 50  
51 51  The Codelist inherits from the //ItemScheme// and therefore has the following attributes: id uri urn version validFrom validTo isExternalReference serviceURL structureURL isPartial
52 52  
... ... @@ -60,7 +60,7 @@
60 60  
61 61  A partial Codelist (where isPartial is set to 'true') is identical to a Codelist and contains the Code and associated names and descriptions, just as in a normal Codelist. However, its content is a subset of the full Codelist. The way this works is described in section 3.5.3.1 on //ItemScheme//.
62 62  
63 -==== 4.3.2.2 Definitions ====
59 +===== 4.3.2.2 Definitions =====
64 64  
65 65  |**Class**|**Feature**|**Description**
66 66  |Codelist|(((
... ... @@ -82,13 +82,13 @@
82 82  
83 83  **Figure 17: Class diagram for Codelist Extension**
84 84  
85 -==== 4.3.3.1 Narrative ====
81 +===== 4.3.3.1 Narrative =====
86 86  
87 -A Codelist may extend other Codelists via the CodelistExtension class. The latter, via the sequence, indicates the order of precedence of the extended Codelists for conflict resolution of Codes. Besides that, the prefix property is used to ensure uniqueness of inherited Codes in the extending[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^~[1~]^^>>path:#_ftn1]](%%) Codelist in case conflicting Codes must be included in the latter. Each CodelistExtension association may include one InclusiveCodeSelection or one ExclusiveCodeSelection; those allow including or excluding a specific selection of Codes from the extended Codelists.
83 +A Codelist may extend other Codelists via the CodelistExtension class. The latter, via the sequence, indicates the order of precedence of the extended Codelists for conflict resolution of Codes. Besides that, the prefix property is used to ensure uniqueness of inherited Codes in the extending[[^^~[1~]^^>>path:#_ftn1]] Codelist in case conflicting Codes must be included in the latter. Each CodelistExtension association may include one InclusiveCodeSelection or one ExclusiveCodeSelection; those allow including or excluding a specific selection of Codes from the extended Codelists.
88 88  
89 89  The code selection classes may have MemberValues in order to specify the subset of the Codes that should be included or excluded from the extended Codelist. A MemberValue may have a value that corresponds to a Code, including its children Codes (via the cascadeValues property), or even include instances of the wildcard character ‘%’ in order to point to a set of Codes with common parts in their identifiers.
90 90  
91 -==== 4.3.3.2 Definitions ====
87 +**4.3.3.2 Definitions**
92 92  
93 93  |**Class**|**Feature**|**Description**
94 94  |CodelistExtension| |The association between Codelists that may extend other Codelists.
... ... @@ -108,7 +108,7 @@
108 108  | |cascadeValues|A property to indicate if the child Codes of the selected Code shall be included in the selection. It is also possible to include children and exclude the Code by using the 'excluderoot' value.
109 109  | |value|The value of the Code to include in the selection. It may include the ‘%’ character as a wildcard.
110 110  
111 -=== 4.3.4 Class Diagram – Geospatial Codelist ===
107 +==== 4.3.4 Class Diagram – Geospatial Codelist ====
112 112  
113 113  The geospatial support is implemented via an extension of the normal Codelist. This is illustrated in the following diagrams.
114 114  
... ... @@ -120,7 +120,7 @@
120 120  
121 121  **Figure 19: Class diagram for Geospatial Codelist**
122 122  
123 -==== 4.3.4.1 Narrative ====
119 +===== 4.3.4.1 Narrative =====
124 124  
125 125  A //GeoCodelist// is a specialisation of Codelist that includes geospatial information, by comprising a set of special Codes, i.e., //GeoRefCode//s. A //GeoCodelist// may be implemented by any of the two following classes, via the geoType property:
126 126  
... ... @@ -132,7 +132,7 @@
132 132  
133 133  The latter, i.e., GeoGridCodelist, comprises a set of GridCodes, which are related to the gridDefinition specified in the GeoGridCodelist.
134 134  
135 -==== 4.3.4.2 Definitions ====
131 +===== 4.3.4.2 Definitions =====
136 136  
137 137  |**Class**|**Feature**|**Description**
138 138  |//GeoCodelist//|(((
... ... @@ -160,17 +160,17 @@
160 160  |GeoGridCode| |A Code that represents a Geo Grid Cell belonging in a specific grid definition.
161 161  | |geoCell|The value used to assign the Code to one cell in the grid.
162 162  
163 -== 4.4 ValueList ==
159 +=== 4.4 ValueList ===
164 164  
165 -=== 4.4.1 Class Diagram ===
161 +==== 4.4.1 Class Diagram ====
166 166  
167 167  [[image:1749246291179-291.jpeg]]
168 168  
169 169  **Figure 20: Class diagram of the ValueList**
170 170  
171 -=== 4.4.2 Explanation of the Diagram ===
167 +==== 4.4.2 Explanation of the Diagram ====
172 172  
173 -==== 4.4.2.1 Narrative ====
169 +===== 4.4.2.1 Narrative =====
174 174  
175 175  A ValueList inherits from //EnumeratedList// (and hence the //MaintenableArtefact//) and thus has the following attributes:
176 176  
... ... @@ -182,7 +182,7 @@
182 182  
183 183  The ValueList can have one or more ValueItems.
184 184  
185 -==== 4.4.2.2 Definitions ====
181 +===== 4.4.2.2 Definitions =====
186 186  
187 187  |**Class**|**Feature**|**Description**
188 188  |ValueList|(((
... ... @@ -196,15 +196,15 @@
196 196  //EnumeratedItem//
197 197  )))|A language independent set of letters, numbers or symbols that represent a concept whose meaning is described in a natural language.
198 198  
199 -== 4.5 Concept Scheme and Concepts ==
195 +=== 4.5 Concept Scheme and Concepts ===
200 200  
201 -=== 4.5.1 Class Diagram - Inheritance ===
197 +==== 4.5.1 Class Diagram - Inheritance ====
202 202  
203 203  [[image:1749246291184-799.jpeg]]
204 204  
205 205  **Figure 21 Class diagram of the Concept Scheme**
206 206  
207 -=== 4.5.2 Explanation of the Diagram ===
203 +==== 4.5.2 Explanation of the Diagram ====
208 208  
209 209  The ConceptScheme inherits from the //ItemScheme //and therefore has the following attributes: id uri urn version validFrom validTo isExternalReference registryURL structureURL repositoryURL isPartial Concept inherits from Item and has the following attributes:
210 210  
... ... @@ -216,15 +216,15 @@
216 216  
217 217  A partial ConceptScheme (where isPartial is set to “true”) is identical to a ConceptScheme and contains the Concept and associated names and descriptions, just as in a normal ConceptScheme. However, its content is a subset of the full ConceptScheme. The way this works is described in section 3.5.3.1 on ItemScheme.
218 218  
219 -=== 4.5.3 Class Diagram Relationship ===
215 +==== 4.5.3     Class Diagram Relationship ====
220 220  
221 221  [[image:1749246291189-654.jpeg]]
222 222  
223 223  **Figure 22: Relationship class diagram of the Concept Scheme**
224 224  
225 -=== 4.5.4 Explanation of the diagram ===
221 +==== 4.5.4 Explanation of the diagram ====
226 226  
227 -==== 4.5.4.1 Narrative ====
223 +===== 4.5.4.1 Narrative =====
228 228  
229 229  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.
230 230  
... ... @@ -234,7 +234,7 @@
234 234  
235 235  The Concept may be related to a concept described in terms of the ISO/IEC 11179 standard. The ISOConceptReference identifies this concept and concept scheme in which it is contained.
236 236  
237 -==== 4.5.4.2 Definitions ====
233 +===== 4.5.4.2 Definitions =====
238 238  
239 239  |**Class**|**Feature**|**Description**
240 240  |(((
... ... @@ -259,21 +259,21 @@
259 259  | |conceptSchemeID|The identifier of the concept scheme.
260 260  | |conceptID|The identifier of the concept.
261 261  
262 -== 4.6 Category Scheme ==
258 +=== 4.6 Category Scheme ===
263 263  
264 -=== 4.6.1 Context ===
260 +==== 4.6.1 Context ====
265 265  
266 266  This package defines the structure that supports the definition of and relationships between categories in a category scheme. It is similar to the package for concept scheme. An example of a category scheme is one which categorises data – sometimes known as a subject matter domain scheme or a data category scheme. Importantly, as will be seen later, the individual nodes in the scheme (the “categories”) can be associated to any set of IdentiableArtefacts in a Categorisation.
267 267  
268 -=== 4.6.2 Class diagram Inheritance ===
264 +==== 4.6.2 Class diagram Inheritance ====
269 269  
270 270  [[image:1749246291193-743.jpeg]]
271 271  
272 272  **Figure 23 Inheritance Class diagram of the Category Scheme**
273 273  
274 -=== 4.6.3 Explanation of the Diagram ===
270 +===== 4.6.3    Explanation of the Diagram =====
275 275  
276 -==== 4.6.3.1 Narrative ====
272 +====== 4.6.3.1 Narrative ======
277 277  
278 278  The categories are modelled as a hierarchical //ItemScheme//. The CategoryScheme inherits from the //ItemScheme// and has the following attributes:
279 279  
... ... @@ -289,7 +289,7 @@
289 289  
290 290  A partial CategoryScheme (where isPartial is set to “true”) is identical to a CategoryScheme and contains the Category and associated names and descriptions, just as in a normal CategoryScheme. However, its content is a subset of the full CategoryScheme. The way this works is described in section 3.5.3.1 on ItemScheme.
291 291  
292 -=== 4.6.4 Class diagram Relationship ===
288 +===== 4.6.4     Class diagram Relationship =====
293 293  
294 294  [[image:1749246291197-631.jpeg]]
295 295  
... ... @@ -297,7 +297,7 @@
297 297  
298 298  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 effect on the versioning of either the CategoryScheme or the IdentifiableArtefact.
299 299  
300 -==== 4.6.4.1 Definitions ====
296 +====== 4.6.4.1 Definitions ======
301 301  
302 302  |**Class**|**Feature**|**Description**
303 303  |CategoryScheme|(((
... ... @@ -320,17 +320,17 @@
320 320  | |+categorisedArtefact|Associates the Identifable Artefact.
321 321  | |+categorisedBy|Associates the Category.
322 322  
323 -== 4.7 Organisation Scheme ==
319 +=== 4.7 Organisation Scheme ===
324 324  
325 -=== 4.7.1 Class Diagram ===
321 +==== Class Diagram ====
326 326  
327 327  [[image:1749246291201-410.jpeg]]
328 328  
329 329  **Figure 25 The Organisation Scheme class diagram**
330 330  
331 -=== 4.7.2 Explanation of the Diagram ===
327 +===== 4.7.2    Explanation of the Diagram =====
332 332  
333 -==== 4.7.2.1 Narrative ====
329 +====== 4.7.2.1 Narrative ======
334 334  
335 335  The //OrganisationScheme// is abstract. It contains //Organisation// which is also abstract. The //Organisation// can have child //Organisation//.
336 336  
... ... @@ -346,7 +346,7 @@
346 346  
347 347  A partial //OrganisationScheme// (where isPartial is set to “true”) is identical to an //OrganisationScheme// and contains the //Organisation// and associated names and descriptions, just as in a normal //OrganisationScheme//. However, its content is a subset of the full //OrganisationScheme//. The way this works is described in section 3.5.3.1 on //ItemScheme//.
348 348  
349 -==== 4.7.2.2 Definitions ====
345 +====== 4.7.2.2 Definitions ======
350 350  
351 351  |**Class**|**Feature**|**Description**
352 352  |//OrganisationScheme//|(((
... ... @@ -436,17 +436,19 @@
436 436  )))|A designation in the organisational structure.
437 437  | |/hierarchy|Association to child Organisation Units
438 438  
439 -== 4.8 Reporting Taxonomy ==
440 440  
441 -=== 4.8.1 Class Diagram ===
442 442  
437 +=== 4.8 Reporting Taxonomy ===
438 +
439 +==== 4.8.1 Class Diagram ====
440 +
443 443  [[image:1749246291205-630.jpeg]]
444 444  
445 445  **Figure 26: Class diagram of the Reporting Taxonomy**
446 446  
447 -=== 4.8.2 Explanation of the Diagram ===
445 +===== 4.8.2 Explanation of the Diagram =====
448 448  
449 -==== 4.8.2.1 Narrative ====
447 +====== 4.8.2.1 Narrative ======
450 450  
451 451  In some data reporting environments, and in particular those in primary reporting, a report may comprise a variety of heterogeneous data, each described by a different //Structure//. Equally, a specific disseminated or published report may also comprise a variety of heterogeneous data. The definition of the set of linked sub reports is supported by the ReportingTaxonomy.
452 452  
... ... @@ -466,7 +466,7 @@
466 466  
467 467  A partial ReportingTaxonomy (where isPartial is set to “true”) is identical to a ReportingTaxonomy and contains the ReportingCategory and associated names and descriptions, just as in a normal ReportingTaxonomy. However, its content is a sub set of the full ReportingTaxonomy The way this works is described in section 3.5.3.1 on //ItemScheme//.
468 468  
469 -==== 4.8.2.2 Definitions ====
467 +====== 4.8.2.2 Definitions ======
470 470  
471 471  |**Class**|**Feature**|**Description**
472 472  |ReportingTaxonomy|(((