Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (0 modified, 1 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -11,7 +11,7 @@ 11 11 |(% style="width:188px" %)1.0|(% style="width:205px" %)October 2021|(% style="width:441px" %)Public release for SDMX 3.0 12 12 ))) 13 13 14 -= {{id name="_Toc93831"/}}1Introduction =14 += 1 Introduction = 15 15 16 16 The business vision for SDMX envisages the promotion of a “data sharing” model to facilitate low-cost, high-quality statistical data and metadata exchange. Data sharing reduces the reporting burden of organisations by allowing them to publish data once and let their counterparties “pull” data and related metadata as required. The scenario is based on: 17 17 ... ... @@ -33,12 +33,10 @@ 33 33 34 34 These architectural standards address the ‘how’, rather than the ‘what’, and are aimed at enabling existing SDMX standards to achieve their mission. The architectural standards address registry services, which initially comprise: 35 35 36 -• structural metadata repository 36 +* structural metadata repository 37 +* data and metadata registration 38 +* query 37 37 38 -• data and metadata registration 39 - 40 -• query 41 - 42 42 The registry services outlined in this specification are designed to help the SDMX community manage the proliferation of SDMX assets and to support data sharing for reporting and dissemination. 43 43 44 44 = {{id name="_Toc93832"/}}2 Scope and Normative Status = ... ... @@ -81,7 +81,8 @@ 81 81 82 82 [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_28806f51.jpg||height="539" width="443"]] 83 83 84 -====== Figure 1: Schematic of the Basic Structural Artefacts in the SDMX-IM ====== 82 +(% class="wikigeneratedid" id="HFigure1:SchematicoftheBasicStructuralArtefactsintheSDMX-IM" %) 83 +**Figure 1: Schematic of the Basic Structural Artefacts in the SDMX-IM** 85 85 86 86 Note that in Figure 1 (but also most of the relevant subsequent figures) terms that include both data and metadata have been used. For example: 87 87 ... ... @@ -108,7 +108,7 @@ 108 108 109 109 Notifying interested parties of newly published or re-published data, reference metadata or changes in structural metadata involves: 110 110 111 - •registry support of a subscription-based notification service which sends an email or notifies an HTTP address announcing all published data that meets the criteria contained in the subscription request.110 +* registry support of a subscription-based notification service which sends an email or notifies an HTTP address announcing all published data that meets the criteria contained in the subscription request. 112 112 113 113 == {{id name="_Toc93838"/}}3.5 Discovery == 114 114 ... ... @@ -167,9 +167,8 @@ 167 167 168 168 The registry interfaces are invoked in one of two ways: 169 169 170 -* 171 -*1. The interface is the name of the root node of the SDMX-ML document 172 -*1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document. 169 +1. The interface is the name of the root node of the SDMX-ML document 170 +1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document. 173 173 174 174 In addition to these interfaces the registry must support a mechanism for submitting and querying for structural metadata. This is detailed in sections 5.2.2 and 5.2.3. 175 175 ... ... @@ -245,23 +245,22 @@ 245 245 * that the components (Dimensions, Attributes, Measures, Metadata Attributes, etc.) are consistent with the Data Structure Definition or Metadata Structure Definition; 246 246 * that the valid representations of the concepts to which these components correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition. The Registration has an action attribute which takes one of the following values: 247 247 248 -|**Action Attribute Value**|**Behaviour** 249 -|Append|Add this registration to the registry 250 -|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request 251 -|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 246 +(% style="width:755.294px" %) 247 +|(% style="width:187px" %)**Action Attribute Value**|(% style="width:566px" %)**Behaviour** 248 +|(% style="width:187px" %)Append|(% style="width:566px" %)Add this registration to the registry 249 +|(% style="width:187px" %)Replace|(% style="width:566px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request 250 +|(% style="width:187px" %)Delete|(% style="width:566px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 252 252 253 253 The Registration has three Boolean attributes which may be present to determine how an SDMX compliant dataset or metadataset indexing application must index the datasets or metadatasets upon registration. The indexing application behaviour is as follows: 254 254 255 -|**Boolean Attribute**|**Behaviour if Value is “true”** 256 -|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadataset registration) 257 -|indexDataSet|((( 258 -A compliant indexing application must index the range of actual 259 - 260 -(present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value. 261 - 254 +(% style="width:759.294px" %) 255 +|(% style="width:191px" %)**Boolean Attribute**|(% style="width:565px" %)**Behaviour if Value is “true”** 256 +|(% style="width:191px" %)indexTimeSeries|(% style="width:565px" %)A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadataset registration) 257 +|(% style="width:191px" %)indexDataSet|(% style="width:565px" %)((( 258 +A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value. 262 262 Note that for data this requires much less storage than full key indexing, but this method cannot guarantee that a specific combination of Dimension values (the Key) is actually present in the Dataset 263 263 ))) 264 -|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset. The validity period of the Metadatasets may also be indexed. 261 +|(% style="width:191px" %)indexReportingPeriod|(% style="width:565px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset. The validity period of the Metadatasets may also be indexed. 265 265 266 266 === {{id name="_Toc93850"/}}5.2.5 Data and Reference Metadata Discovery === 267 267 ... ... @@ -295,8 +295,9 @@ 295 295 296 296 Given the above, the behaviour described in the following table concerns either draft Artefacts using semantic versioning or any Artefacts using the old versioning scheme. Nevertheless, in the case of semantic versioning the registry must respect the versioning rules when performing the actions below. For example, it is not possible to replace a non-draft Artefact that follows semantic versioning, unless a newer version is introduced according to the semantic versioning rules. Furthermore, even when draft Artefacts are submitted, the registry has to verify semantic versioning is respected against the previous non-draft versions. It is worth noting that the rules for semantic versioning and replacing or maintaining semantically versioned Artefacts applies to externally shared Artefacts. This means that any system may internally perform any change within a version of an Artefact, until the latter is shared outside of that system or becomes public. Then (as also explained in the SDMX Standards Section 6 “Technical Notes”) the Artefacts must adhere to the Semantic Versioning rules. 297 297 298 -|**Interface**|**Behaviour** 299 -|All|((( 295 +(% style="width:757.294px" %) 296 +|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour** 297 +|(% style="width:188px" %)All|(% style="width:542px" %)((( 300 300 1. If the action is set to “replace” (or a maintainable Artefact is PUT or POSTed) then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted. 301 301 1. Cross referenced structures MUST exist in either the submitted document (in Structures or Structure Location) or in the registry to which the request is submitted. 302 302 1. If the action is set to “delete” (or a maintainable Artefact is DELETEd) then the Registry MUST verify that the object can be deleted. In order to qualify for deletion, the object must: ... ... @@ -303,14 +303,14 @@ 303 303 304 304 a) Be a draft version. 305 305 ))) 306 -|**Interface**|**Behaviour** 307 -| |((( 308 -b) Not be explicitly ^^[[(%class="wikiinternallinkwikiinternallink"%)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^referenced from any other object in the Registry.304 +|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour** 305 +|(% style="width:188px" %) |(% style="width:542px" %)((( 306 +b) Not be explicitly{{footnote}}With semantic versioning, it is allowed to reference a range of artefacts, e.g., a DSD referencing a Codelist with version 1.2.3+ means all patch versions greater than 1.2.3. This means that deleting 1.2.4-draft does not break integrity of the aforementioned DSD.{{/footnote}} referenced from any other object in the Registry. 309 309 310 310 4) The semantic versioning rules in the SDMX documentation MUST be obeyed. 311 311 ))) 312 -|Structure submission|Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact. 313 -|SubmitRegistrationRequest|If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query. 310 +|(% style="width:188px" %)Structure submission|(% style="width:542px" %)Structures are submitted at the level of the Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact. 311 +|(% style="width:188px" %)SubmitRegistrationRequest|(% style="width:542px" %)If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query. 314 314 315 315 = {{id name="_Toc93853"/}}6 Identification of SDMX Objects = 316 316 ... ... @@ -340,27 +340,28 @@ 340 340 : 341 341 342 342 ((( 343 -|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes** 344 -|(% rowspan="4" %)//Annotable//|AnnotationTitle|C|string| 345 -|AnnotationType|C|string| 346 -|AnnotationURN|C|string| 347 -|AnnotationText in the form of InternationalString|C| |This can have languagespecific variants 348 -|(% rowspan="4" %)//Identifiable//|All content as for //Annotable// plus| | | 349 -|id|M|string| 350 -|uri|C|string| 351 -|urn|C|string|Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 352 -|(% rowspan="3" %)//Nameable//|All content as for //Identifiable// plus| | | 353 -|Name in the form of InternationalString|M|string|This can have language specific variants. 354 -|Description in the form of InternationalString|C|string|This can have language specific variants. 355 -|(% rowspan="4" %)//Versionable//|All content as for //Identifiable// plus| | | 356 -|version|M|string|This is the version number according to SDMX versioning rules. 357 -|validFrom|C|Date/time| 358 -|validTo|C|Date/time| 359 -|//Maintainable//|All content as for //Versionable// plus| | | 360 -| |isExternalReference|C|boolean|Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURL, each of which must return a valid SDMX-ML file. 361 -| |serviceURL|C|string|The url of the service that can be queried for this resource. 362 -| |structureURL|C|string|The url of the resource. 363 -| |(Maintenance) organisationId|M|string|The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider. 341 +(% style="width:1052.29px" %) 342 +|**Object Type**|(% style="width:241px" %)**Data Attributes**|(% style="width:156px" %)**Status**|**Data type**|(% style="width:457px" %)**Notes** 343 +|(% rowspan="4" %)//Annotable//|(% style="width:241px" %)AnnotationTitle|(% style="width:156px" %)C|string|(% style="width:457px" %) 344 +|(% style="width:241px" %)AnnotationType|(% style="width:156px" %)C|string|(% style="width:457px" %) 345 +|(% style="width:241px" %)AnnotationURN|(% style="width:156px" %)C|string|(% style="width:457px" %) 346 +|(% style="width:241px" %)AnnotationText in the form of InternationalString|(% style="width:156px" %)C| |(% style="width:457px" %)This can have languagespecific variants 347 +|(% rowspan="4" %)//Identifiable//|(% style="width:241px" %)All content as for //Annotable// plus|(% style="width:156px" %) | |(% style="width:457px" %) 348 +|(% style="width:241px" %)id|(% style="width:156px" %)M|string|(% style="width:457px" %) 349 +|(% style="width:241px" %)uri|(% style="width:156px" %)C|string|(% style="width:457px" %) 350 +|(% style="width:241px" %)urn|(% style="width:156px" %)C|string|(% style="width:457px" %)Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 351 +|(% rowspan="3" %)//Nameable//|(% style="width:241px" %)All content as for //Identifiable// plus|(% style="width:156px" %) | |(% style="width:457px" %) 352 +|(% style="width:241px" %)Name in the form of InternationalString|(% style="width:156px" %)M|string|(% style="width:457px" %)This can have language specific variants. 353 +|(% style="width:241px" %)Description in the form of InternationalString|(% style="width:156px" %)C|string|(% style="width:457px" %)This can have language specific variants. 354 +|(% rowspan="4" %)//Versionable//|(% style="width:241px" %)All content as for //Identifiable// plus|(% style="width:156px" %) | |(% style="width:457px" %) 355 +|(% style="width:241px" %)version|(% style="width:156px" %)M|string|(% style="width:457px" %)This is the version number according to SDMX versioning rules. 356 +|(% style="width:241px" %)validFrom|(% style="width:156px" %)C|Date/time|(% style="width:457px" %) 357 +|(% style="width:241px" %)validTo|(% style="width:156px" %)C|Date/time|(% style="width:457px" %) 358 +|//Maintainable//|(% style="width:241px" %)All content as for //Versionable// plus|(% style="width:156px" %) | |(% style="width:457px" %) 359 +| |(% style="width:241px" %)isExternalReference|(% style="width:156px" %)C|boolean|(% style="width:457px" %)Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURL, each of which must return a valid SDMX-ML file. 360 +| |(% style="width:241px" %)serviceURL|(% style="width:156px" %)C|string|(% style="width:457px" %)The url of the service that can be queried for this resource. 361 +| |(% style="width:241px" %)structureURL|(% style="width:156px" %)C|string|(% style="width:457px" %)The url of the resource. 362 +| |(% style="width:241px" %)(Maintenance) organisationId|(% style="width:156px" %)M|string|(% style="width:457px" %)The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider. 364 364 ))) 365 365 366 366 **Table 1: Common Attributes of Object Types** ... ... @@ -409,32 +409,8 @@ 409 409 410 410 An example of this is shown in the XML snippet below: 411 411 412 - **<str:Codelists>**411 +[[image:1747307906944-697.png]] 413 413 414 -**<str:Codelist id="CL_FREQ" agencyID="SDMX" version="1.0.0">** 415 - 416 -**<com:Name xml:lang="en">Standard frequency Codelist</com:Name>** 417 - 418 -**</str:Codelist>** 419 - 420 -**<str:Codelist id="CL_FREQ" agencyID="AA" version="1.0.0">** 421 - 422 -**<com:Name xml:lang="en">Codelist maintained by agency AA</com:Name>** 423 - 424 -**</str:Codelist>** 425 - 426 -**<str:Codelist id="CL_FREQ" agencyID="AA.CC" version="1.0.0">** 427 - 428 -**<com:Name xml:lang="en">Codelist maintained by the AA unit CC</com:Name>** 429 - 430 -**</str:Codelist>** 431 - 432 -**<str:Codelist id="CL_FREQ" agencyID="BB.CC" version="1.0.0">** 433 - 434 -**<com:Name xml:lang="en">Codelist maintained by the BB unit CC</com:Name>** 435 - 436 -**</str:Codelist>** 437 - 438 438 **Figure 8: Example Showing Use of Agency Identifiers** 439 439 440 440 Each of these maintenance agencies has an identical Code list with the Id CL_BOP. However, each is uniquely identified by means of the hierarchic agency structure. ... ... @@ -441,13 +441,13 @@ 441 441 442 442 Following the same principles, the Metadata Provider is the maintenance organisation for a special subset of Maintainable Artefacts, i.e., the Metadatasets; the latter are the containers of reference metadata combined with a target that those metadata refer to. 443 443 444 -=== =={{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) =====419 +=== {{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) === 445 445 446 - **6.2.2.1 Introduction**421 +==== 6.2.2.1 Introduction ==== 447 447 448 448 To provide interoperability between SDMX Registry/Repositories in a distributed network environment, it is important to have a scheme for uniquely identifying (and thus accessing) all first-class (Identifiable) SDMX-IM objects. Most of these unique identifiers are composite (containing maintenance agency, or parent object identifiers), and there is a need to be able to construct a unique reference as a single string. This is achieved by having a globally unique identifier called a universal resource name (URN) which is generated from the actual identification components in the SDMX-RR APIs. In other words, the URN for any Identifiable Artefact is constructed from its component identifiers (agency, id, version etc.). 449 449 450 - **6.2.2.2 URN Structure //__Case Rules for URN__//**// //425 +==== 6.2.2.2 URN Structure //__Case Rules for URN__ // ==== 451 451 452 452 For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows: 453 453 ... ... @@ -459,7 +459,7 @@ 459 459 460 460 The Maintenance agency identifier is separated from the maintainable artefact identifier by a colon ‘:’. All other identifiers in the SDMX URN syntax are separated by a period ‘.’. The version information is encapsulated in parentheses ‘()’ and adheres to the SDMX versioning rules, as explained in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning. 461 461 462 - **6.2.2.3 Explanation of the generic structure**437 +==== 6.2.2.3 Explanation of the generic structure ==== 463 463 464 464 In the explanation below the actual object that is the target of the URN is called the **actual object**. 465 465 ... ... @@ -534,85 +534,86 @@ 534 534 535 535 The SDMX-RR MUST be able to resolve the unique identifier of an SDMX artefact and to produce an SDMX-ML rendering of that artefact if it is located in the Registry. 536 536 537 -=== =={{id name="_Toc93859"/}}6.2.3 Table of SDMX-IM Packages and Classes =====512 +=== {{id name="_Toc93859"/}}6.2.3 Table of SDMX-IM Packages and Classes === 538 538 539 539 The table below lists all of the packages in the SDMX-IM together with the concrete classes that are in these packages and whose objects have a URN. 540 540 541 -|**Package**|**URN class name (model class name where this is different)** 542 -|base|Agency 543 -| |AgencyScheme 544 -| |DataConsumer 545 -| |DataConsumerScheme 546 -| |DataProvider 547 -| |DataProviderScheme 548 -| |MetadataProvider 549 -| |MetadataProviderScheme 550 -| |OrganisationUnit 551 -| |OrganisationUnitScheme 552 -|datastructure|AttributeDescriptor 553 -| |DataAttribute 554 -| |Dataflow 555 -| |DataStructure (DataStructureDefinition) 556 -| |Dimension 557 -| |DimensionDescriptor 558 -| |GroupDimensionDescriptor 559 -| |Measure 560 -| |MeasureDescriptor 561 -| |TimeDimension 562 -| | 563 -|metadatastructure|MetadataAttribute 564 -| |MetadataAttributeDescriptor 565 -| |MetadataStructure MetadataStructureDefinition) 566 -| |Metadataflow 567 -| |MetadataSet 568 -| | 569 -|process|Process 570 -| |ProcessStep 571 -| |Transition 572 -| | 573 -|registry|DataConstraint 574 -| |MetadataConstraint 575 -| |MetadataProvisionAgreement 576 -| |ProvisionAgreement 577 -| |Subscription 578 -| | 579 -|structuremapping|CategorySchemeMap 580 -| |ConceptSchemeMap 581 -| |OrganisationSchemeMap 582 -| |ReportingTaxonomyMap 583 -| |RepresentationMap 584 -| |StructureMap 585 -| | 586 -|codelist|Code 587 -| |Codelist 588 -| |HierarchicalCode 589 -| |Hierarchy 590 -| |HierarchyAssociation 591 -| |Level 592 -| |ValueList 593 -| | 594 -|categoryscheme|Categorisation 595 -| |Category 596 -| |CategoryScheme 597 -| |ReportingCategory 598 -| |ReportingTaxonomy 599 -|conceptscheme|Concept 600 -| |ConceptScheme 601 -| | 602 -|transformation|CustomType 603 -| |CustomTypeScheme 604 -| |NamePersonalisation 605 -| |NamePersonalisationScheme 606 -| |Ruleset 607 -| |RulesetScheme 608 -| |Transformation 609 -| |TransformationScheme 610 -| |UserDefinedOperator 611 -| |UserDefinedOperatorScheme 612 -| |VtlCodelistMapping 613 -| |VtlConceptMapping 614 -| |VtlDataflowMapping 615 -| |VtlMappingScheme 516 +(% style="width:651.294px" %) 517 +|(% style="width:134px" %)**Package**|(% style="width:502px" %)**URN class name (model class name where this is different)** 518 +|(% style="width:134px" %)base|(% style="width:502px" %)Agency 519 +|(% style="width:134px" %) |(% style="width:502px" %)AgencyScheme 520 +|(% style="width:134px" %) |(% style="width:502px" %)DataConsumer 521 +|(% style="width:134px" %) |(% style="width:502px" %)DataConsumerScheme 522 +|(% style="width:134px" %) |(% style="width:502px" %)DataProvider 523 +|(% style="width:134px" %) |(% style="width:502px" %)DataProviderScheme 524 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProvider 525 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProviderScheme 526 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationUnit 527 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationUnitScheme 528 +|(% style="width:134px" %)datastructure|(% style="width:502px" %)AttributeDescriptor 529 +|(% style="width:134px" %) |(% style="width:502px" %)DataAttribute 530 +|(% style="width:134px" %) |(% style="width:502px" %)Dataflow 531 +|(% style="width:134px" %) |(% style="width:502px" %)DataStructure (DataStructureDefinition) 532 +|(% style="width:134px" %) |(% style="width:502px" %)Dimension 533 +|(% style="width:134px" %) |(% style="width:502px" %)DimensionDescriptor 534 +|(% style="width:134px" %) |(% style="width:502px" %)GroupDimensionDescriptor 535 +|(% style="width:134px" %) |(% style="width:502px" %)Measure 536 +|(% style="width:134px" %) |(% style="width:502px" %)MeasureDescriptor 537 +|(% style="width:134px" %) |(% style="width:502px" %)TimeDimension 538 +|(% style="width:134px" %) |(% style="width:502px" %) 539 +|(% style="width:134px" %)metadatastructure|(% style="width:502px" %)MetadataAttribute 540 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataAttributeDescriptor 541 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataStructure MetadataStructureDefinition) 542 +|(% style="width:134px" %) |(% style="width:502px" %)Metadataflow 543 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataSet 544 +|(% style="width:134px" %) |(% style="width:502px" %) 545 +|(% style="width:134px" %)process|(% style="width:502px" %)Process 546 +|(% style="width:134px" %) |(% style="width:502px" %)ProcessStep 547 +|(% style="width:134px" %) |(% style="width:502px" %)Transition 548 +|(% style="width:134px" %) |(% style="width:502px" %) 549 +|(% style="width:134px" %)registry|(% style="width:502px" %)DataConstraint 550 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataConstraint 551 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProvisionAgreement 552 +|(% style="width:134px" %) |(% style="width:502px" %)ProvisionAgreement 553 +|(% style="width:134px" %) |(% style="width:502px" %)Subscription 554 +|(% style="width:134px" %) |(% style="width:502px" %) 555 +|(% style="width:134px" %)structuremapping|(% style="width:502px" %)CategorySchemeMap 556 +|(% style="width:134px" %) |(% style="width:502px" %)ConceptSchemeMap 557 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationSchemeMap 558 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingTaxonomyMap 559 +|(% style="width:134px" %) |(% style="width:502px" %)RepresentationMap 560 +|(% style="width:134px" %) |(% style="width:502px" %)StructureMap 561 +|(% style="width:134px" %) |(% style="width:502px" %) 562 +|(% style="width:134px" %)codelist|(% style="width:502px" %)Code 563 +|(% style="width:134px" %) |(% style="width:502px" %)Codelist 564 +|(% style="width:134px" %) |(% style="width:502px" %)HierarchicalCode 565 +|(% style="width:134px" %) |(% style="width:502px" %)Hierarchy 566 +|(% style="width:134px" %) |(% style="width:502px" %)HierarchyAssociation 567 +|(% style="width:134px" %) |(% style="width:502px" %)Level 568 +|(% style="width:134px" %) |(% style="width:502px" %)ValueList 569 +|(% style="width:134px" %) |(% style="width:502px" %) 570 +|(% style="width:134px" %)categoryscheme|(% style="width:502px" %)Categorisation 571 +|(% style="width:134px" %) |(% style="width:502px" %)Category 572 +|(% style="width:134px" %) |(% style="width:502px" %)CategoryScheme 573 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingCategory 574 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingTaxonomy 575 +|(% style="width:134px" %)conceptscheme|(% style="width:502px" %)Concept 576 +|(% style="width:134px" %) |(% style="width:502px" %)ConceptScheme 577 +|(% style="width:134px" %) |(% style="width:502px" %) 578 +|(% style="width:134px" %)transformation|(% style="width:502px" %)CustomType 579 +|(% style="width:134px" %) |(% style="width:502px" %)CustomTypeScheme 580 +|(% style="width:134px" %) |(% style="width:502px" %)NamePersonalisation 581 +|(% style="width:134px" %) |(% style="width:502px" %)NamePersonalisationScheme 582 +|(% style="width:134px" %) |(% style="width:502px" %)Ruleset 583 +|(% style="width:134px" %) |(% style="width:502px" %)RulesetScheme 584 +|(% style="width:134px" %) |(% style="width:502px" %)Transformation 585 +|(% style="width:134px" %) |(% style="width:502px" %)TransformationScheme 586 +|(% style="width:134px" %) |(% style="width:502px" %)UserDefinedOperator 587 +|(% style="width:134px" %) |(% style="width:502px" %)UserDefinedOperatorScheme 588 +|(% style="width:134px" %) |(% style="width:502px" %)VtlCodelistMapping 589 +|(% style="width:134px" %) |(% style="width:502px" %)VtlConceptMapping 590 +|(% style="width:134px" %) |(% style="width:502px" %)VtlDataflowMapping 591 +|(% style="width:134px" %) |(% style="width:502px" %)VtlMappingScheme 616 616 617 617 **Table 2: SDMX-IM Packages and Contained Classes** 618 618 ... ... @@ -625,7 +625,7 @@ 625 625 urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 626 626 627 627 |**Classname**|**Ending URN pattern**|**Example** 628 -|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA 604 +|Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA 629 629 |//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**) 630 630 |//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0) 631 631 |Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category … ... ... @@ -842,7 +842,7 @@ 842 842 843 843 • All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme, Agency Scheme, Data Provider Scheme, Metadata Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme, Transformation Scheme, Name Personalisation Scheme, Custom Type Scheme, Vtl Mapping Scheme, Ruleset Scheme, User Defined Operator Scheme) 844 844 845 -• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^ 821 +• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^ 846 846 847 847 • All types of Structure (Data Structure Definition, Metadata Structure Definition) 848 848 ... ... @@ -1187,3 +1187,5 @@ 1187 1187 IMF.SubAgency1 1188 1188 1189 1189 [[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList. 1166 + 1167 +{{putFootnotes/}}
- 1747307906944-697.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +37.9 KB - Content