Changes for page 1 Introduction
Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -23,8 +23,8 @@ 23 23 24 24 In some diagrams for some classes the attribute compartment is suppressed even though there may be some attributes. This is deliberate and is done to aid clarity of the diagram. The method used is: 25 25 26 -* The attributes will always be present on the class diagram where the class is defined and its attributes and associations are defined. // //27 -* On other diagrams, such as inheritance diagrams, the attributes may be suppressed from the class for clarity. // //26 +* The attributes will always be present on the class diagram where the class is defined and its attributes and associations are defined. 27 +* On other diagrams, such as inheritance diagrams, the attributes may be suppressed from the class for clarity. 28 28 29 29 [[image:SDMX 3-0-0 SECTION 2 FINAL-1.0 (1)_en_bbb8fac9.png||height="54" width="158"]] 30 30 ... ... @@ -43,12 +43,12 @@ 43 43 44 44 The content in the “Feature” column comprises or explains one of the following structural features of the class: 45 45 46 -* Whether it is an abstract class. Abstract classes are shown in //italic Courier// font. // //46 +* Whether it is an abstract class. Abstract classes are shown in //italic Courier// font. 47 47 * The superclass this class inherits from, if any.// // 48 48 * The sub classes of this class, if any. 49 49 * Attribute – the attributeName is shown in Courier font. 50 50 * Association – the associationName is shown in Courier font. If the association is derived from the association between super classes, then the format is /associationName. 51 -* Role – the +roleName is shown in Courier font. // //51 +* Role – the +roleName is shown in Courier font. 52 52 53 53 The Description column provides a short definition or explanation of the Class or Feature. UML class names may be used in the description and if so, they are presented in normal font with spaces between words. For example, the class ConceptScheme will be written as Concept Scheme. 54 54 ... ... @@ -60,20 +60,16 @@ 60 60 61 61 In addition to this, in order to aid understanding each package can be considered to be in one of three conceptual layers: 62 62 63 -the SDMX Base layer comprises fundamental building blocks which are used by the Structural Definitions layer and the Reporting and Dissemination layer 63 +* the SDMX Base layer comprises fundamental building blocks which are used by the Structural Definitions layer and the Reporting and Dissemination layer 64 +* the Structural Definitions layer comprises the definition of the structural artefacts needed to support data and metadata reporting and dissemination 65 +* the Reporting and Dissemination layer comprises the definition of the data and metadata containers used for reporting and dissemination 66 +* In reality the layers have no implicit or explicit structural function as any package can make use of any construct in another package. 64 64 65 -the Structural Definitions layer comprises the definition of the structural artefacts needed to support data and metadata reporting and dissemination 66 - 67 -the Reporting and Dissemination layer comprises the definition of the data and metadata containers used for reporting and dissemination 68 - 69 -In reality the layers have no implicit or explicit structural function as any package can make use of any construct in another package. 70 - 71 71 === 1.3.2 Version 1.0 === 72 72 73 73 In version 1.0 the metamodel supported the requirements for: 74 74 75 75 Data Structure Definition including (domain) category scheme, (metadata) concept scheme, and code list 76 - 77 77 Data and related metadata reporting and dissemination 78 78 79 79 The SDMX-IM comprises a number of packages. These packages act as convenient compartments for the various sub models in the SDMX-IM. The diagram below shows the sub models of the SDMX-IM that were included in the version 1.0 specification. ... ... @@ -87,19 +87,12 @@ 87 87 The version 2.0/2.1 model extends the functionality of version 1.0. principally in the area of metadata, but also in various ways to define structures to support data analysis by systems with knowledge of cube type structures such as OLAP{{footnote}}OLAP: On line analytical processing{{/footnote}} systems. The following major constructs have been added at version 2.0/2.1 88 88 89 89 Metadata structure definition 90 - 91 91 Metadata set 92 - 93 93 Hierarchical Codelist 94 - 95 95 Data and Metadata Provisioning 96 - 97 97 Process 98 - 99 99 Mapping 100 - 101 101 Constraints 102 - 103 103 Constructs supporting the Registry 104 104 105 105 Furthermore, the term Data Structure Definition replaces the term Key Family: as both of these terms are used in various communities, they are synonymous. The term Data Structure Definition is used in the model and this document.