Changes for page 4 Specific Item Schemes

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

From 2.1 to 3.1 From 3.3 to 3.4

From version 3.1

edited by Helena
on 2025/06/07 00:56

Change comment: There is no comment for this version

To version 3.3

edited by Helena
on 2025/06/08 01:06

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -1,5 +1,9 @@
--=== 4.1 Introduction ===
++{{box title="**Contents**"}}
++{{toc/}}
++{{/box}}
++== 4.1 Introduction ==
++
  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:
  Codelist
@@ -28,11 +28,11 @@
  Note that the VTL related schemes (the last 6 of the above list) are detailed in a dedicated section below (section 15).
--=== 4.2 Inheritance View ===
++== 4.2 Inheritance View ==
  The inheritance and relationship views are shown together in each of the diagrams in the specific sections below.
--=== 4.3 Codelist ===
++== 4.3 Codelist ==
  ==== 4.3.1 Class Diagram ====
@@ -40,9 +40,9 @@
  **Figure 16: Class diagram of the Codelist**
--==== 4.3.2 Explanation of the Diagram ====
++=== 4.3.2 Explanation of the Diagram ===
--===== 4.3.2.1 Narrative =====
++==== 4.3.2.1 Narrative ====
  The Codelist inherits from the //ItemScheme// and therefore has the following attributes: id uri urn version validFrom validTo isExternalReference serviceURL structureURL isPartial
@@ -56,7 +56,7 @@
  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//.
--===== 4.3.2.2 Definitions =====
++==== 4.3.2.2 Definitions ====
  |**Class**|**Feature**|**Description**
  |Codelist|(((
@@ -78,13 +78,13 @@
  **Figure 17: Class diagram for Codelist Extension**
--===== 4.3.3.1 Narrative =====
++==== 4.3.3.1 Narrative ====
--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.
++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" %)^^~[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.
  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.
--**4.3.3.2 Definitions**
++==== 4.3.3.2 Definitions ====
  |**Class**|**Feature**|**Description**
  |CodelistExtension| |The association between Codelists that may extend other Codelists.
@@ -104,7 +104,7 @@
  | |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.
  | |value|The value of the Code to include in the selection. It may include the ‘%’ character as a wildcard.
--==== 4.3.4 Class Diagram – Geospatial Codelist ====
++=== 4.3.4 Class Diagram – Geospatial Codelist ===
  The geospatial support is implemented via an extension of the normal Codelist. This is illustrated in the following diagrams.
@@ -116,7 +116,7 @@
  **Figure 19: Class diagram for Geospatial Codelist**
--===== 4.3.4.1 Narrative =====
++==== 4.3.4.1 Narrative ====
  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:
@@ -128,7 +128,7 @@
  The latter, i.e., GeoGridCodelist, comprises a set of GridCodes, which are related to the gridDefinition specified in the GeoGridCodelist.
--===== 4.3.4.2 Definitions =====
++==== 4.3.4.2 Definitions ====
  |**Class**|**Feature**|**Description**
  |//GeoCodelist//|(((
@@ -156,17 +156,17 @@
  |GeoGridCode| |A Code that represents a Geo Grid Cell belonging in a specific grid definition.
  | |geoCell|The value used to assign the Code to one cell in the grid.
--=== 4.4 ValueList ===
++== 4.4 ValueList ==
--==== 4.4.1 Class Diagram ====
++=== 4.4.1 Class Diagram ===
  [[image:1749246291179-291.jpeg]]
  **Figure 20: Class diagram of the ValueList**
--==== 4.4.2 Explanation of the Diagram ====
++=== 4.4.2 Explanation of the Diagram ===
--===== 4.4.2.1 Narrative =====
++==== 4.4.2.1 Narrative ====
  A ValueList inherits from //EnumeratedList// (and hence the //MaintenableArtefact//) and thus has the following attributes:
@@ -178,7 +178,7 @@
  The ValueList can have one or more ValueItems.
--===== 4.4.2.2 Definitions =====
++==== 4.4.2.2 Definitions ====
  |**Class**|**Feature**|**Description**
  |ValueList|(((
@@ -192,15 +192,15 @@
  //EnumeratedItem//
  )))|A language independent set of letters, numbers or symbols that represent a concept whose meaning is described in a natural language.
--=== 4.5 Concept Scheme and Concepts ===
++== 4.5 Concept Scheme and Concepts ==
--==== 4.5.1 Class Diagram - Inheritance ====
++=== 4.5.1 Class Diagram - Inheritance ===
  [[image:1749246291184-799.jpeg]]
  **Figure 21 Class diagram of the Concept Scheme**
--==== 4.5.2 Explanation of the Diagram ====
++=== 4.5.2 Explanation of the Diagram ===
  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:
@@ -212,15 +212,15 @@
  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.
--==== 4.5.3     Class Diagram Relationship ====
++=== 4.5.3 Class Diagram Relationship ===
  [[image:1749246291189-654.jpeg]]
  **Figure 22: Relationship class diagram of the Concept Scheme**
--==== 4.5.4 Explanation of the diagram ====
++=== 4.5.4 Explanation of the diagram ===
--===== 4.5.4.1 Narrative =====
++==== 4.5.4.1 Narrative ====
  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,7 +230,7 @@
  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.
--===== 4.5.4.2 Definitions =====
++==== 4.5.4.2 Definitions ====
  |**Class**|**Feature**|**Description**
  |(((
@@ -255,21 +255,21 @@
  | |conceptSchemeID|The identifier of the concept scheme.
  | |conceptID|The identifier of the concept.
--=== 4.6 Category Scheme ===
++== 4.6 Category Scheme ==
--==== 4.6.1 Context ====
++=== 4.6.1 Context ===
  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.
--==== 4.6.2 Class diagram Inheritance ====
++=== 4.6.2 Class diagram Inheritance ===
  [[image:1749246291193-743.jpeg]]
  **Figure 23 Inheritance Class diagram of the Category Scheme**
--===== 4.6.3    Explanation of the Diagram =====
++=== 4.6.3 Explanation of the Diagram ===
--====== 4.6.3.1 Narrative ======
++==== 4.6.3.1 Narrative ====
  The categories are modelled as a hierarchical //ItemScheme//. The CategoryScheme inherits from the //ItemScheme// and has the following attributes:
@@ -285,7 +285,7 @@
  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.
--===== 4.6.4     Class diagram Relationship =====
++=== 4.6.4 Class diagram Relationship ===
  [[image:1749246291197-631.jpeg]]
@@ -293,7 +293,7 @@
  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.
--====== 4.6.4.1 Definitions ======
++==== 4.6.4.1 Definitions ====
  |**Class**|**Feature**|**Description**
  |CategoryScheme|(((
@@ -316,7 +316,7 @@
  | |+categorisedArtefact|Associates the Identifable Artefact.
  | |+categorisedBy|Associates the Category.
--=== 4.7 Organisation Scheme ===
++== 4.7 Organisation Scheme ==
  ==== Class Diagram ====