Last modified by Artur on 2025/09/30 13:28
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -231,7 +231,7 @@ 231 231 ))) 232 232 |indexReportingPeriod|(% style="width:712px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset. 233 233 234 -=== =={{id name="_Toc90799"/}}5.2.5 Data Discovery =====234 +=== 5.2.5 Data Discovery === 235 235 236 236 The Data Discovery Service implements the following Registry Interfaces: 237 237 ... ... @@ -238,7 +238,7 @@ 238 238 * QueryRegistrationRequest 239 239 * QueryRegistrationResponse 240 240 241 -=== =={{id name="_Toc90800"/}}5.2.6 Subscription and Notification =====241 +=== 5.2.6 Subscription and Notification === 242 242 243 243 The Subscription and Notification Service implements the following Registry Interfaces: 244 244 ... ... @@ -257,34 +257,32 @@ 257 257 258 258 Notification requires that the structural metadata repository and the provisioning metadata repository monitor any event which is of interest to a user (the object of a subscription request query), and to issue an SDMX notification document to the endpoints specified in the relevant subscriptions. 259 259 260 -=== =={{id name="_Toc90801"/}}5.2.7 Registry Behaviour =====260 +=== 5.2.7 Registry Behaviour === 261 261 262 262 The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages. It should be noted, though, that as of SDMX 3.0, an extended versioning scheme newly including semantic versioning is foreseen for all Maintainable Artefacts. Moreover, while the old versioning scheme is allowed, given there is no more a "final" flag, there is no way guaranteeing the consistency across version of a Maintainable, unless semantic versioning is used. 263 263 264 264 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. 265 265 266 -|**Interface**|**Behaviour** 267 -|All|((( 266 +(% style="width:982.835px" %) 267 +|(% style="width:217px" %)**Interface**|(% style="width:763px" %)**Behaviour** 268 +|(% style="width:217px" %)All|(% style="width:763px" %)((( 268 268 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. 269 269 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. 270 270 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: 271 271 272 -1. Be a draft version. 273 +a) Be a draft version. 274 +b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry. 273 273 274 -b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry. 275 - 276 276 4) The semantic versioning rules in the SDMX documentation MUST be obeyed. 277 277 ))) 278 -|Structure submission|((( 279 -Structures are submitted at the level of the 280 - 281 -Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact. 278 +|(% style="width:217px" %)Structure submission|(% style="width:763px" %)((( 279 +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. 282 282 ))) 283 -|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. 281 +|(% style="width:217px" %)SubmitRegistrationRequest|(% style="width:763px" %)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. 284 284 285 -= {{id name="_Toc90802"/}}6 Identification of SDMX Objects =283 += 6 Identification of SDMX Objects = 286 286 287 -== ={{id name="_Toc90803"/}}6.1 Identification, Versioning, and Maintenance ===285 +== 6.1 Identification, Versioning, and Maintenance == 288 288 289 289 All major classes of the SDMX Information model inherit from one of: 290 290 ... ... @@ -293,7 +293,7 @@ 293 293 * //**VersionableArtefact**// – this has all of the above features plus a version number, according to the SDMX versioning rules in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning”, and a validity period. 294 294 * //**MaintainableArtefact**// – this has all of the above features, plus registry and structure URIs, and an association to the maintenance organisation of the object. 295 295 296 -=== =={{id name="_Toc90804"/}}6.1.1 Identification, Naming, Versioning, and Maintenance Model =====294 +=== 6.1.1 Identification, Naming, Versioning, and Maintenance Model === 297 297 298 298 [[image:SDMX 3.1 Section 5_en_4a9b2cfc.jpg||height="688" width="587"]] 299 299 ... ... @@ -302,13 +302,11 @@ 302 302 The table below shows the identification and related data attributes to be stored in a registry for objects that are one of: 303 303 304 304 * //Annotable// 303 +* //Identifiable// 304 +* //Nameable// 305 +* //Versionable// 306 +* //Maintainable// 305 305 306 -//Identifiable// • //Nameable// 307 - 308 -• //Versionable// 309 - 310 -• //Maintainable// 311 - 312 312 | |(% colspan="2" %)**Object Type**|(% colspan="2" %)**Data Attributes**|(% colspan="2" %)**Status**|(% colspan="2" %)**Data type**|(% colspan="2" %)**Notes** 313 313 | |(% colspan="2" rowspan="4" %)//Annotable//|(% colspan="2" %)AnnotationTitle|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %) 314 314 | |(% colspan="2" %)AnnotationType|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %) ... ... @@ -353,9 +353,9 @@ 353 353 354 354 **Table 1: Common Attributes of Object Types** 355 355 356 -== ={{id name="_Toc90805"/}}6.2 Unique identification of SDMX objects ===352 +== 6.2 Unique identification of SDMX objects == 357 357 358 -=== =={{id name="_Toc90806"/}}6.2.1 Agencies and Metadata Providers =====354 +=== 6.2.1 Agencies and Metadata Providers === 359 359 360 360 The Maintenance Agency in SDMX is maintained in an Agency Scheme which itself is a sub class of Organisation Scheme – this is shown in the class diagram below. 361 361 ... ... @@ -388,14 +388,11 @@ 388 388 389 389 The following organizations maintain an Agency Scheme. 390 390 391 -• SDMX – contains Agencies AA, BB 387 +* SDMX – contains Agencies AA, BB 388 +* AA – contains Agencies CC, DD 389 +* BB – contains Agencies CC, DD 390 +* DD – Contains Agency EE 392 392 393 -• AA – contains Agencies CC, DD 394 - 395 -• BB – contains Agencies CC, DD 396 - 397 -• DD – Contains Agency EE 398 - 399 399 Each agency is identified by its full hierarchy excluding SDMX. 400 400 401 401 e.g., the id of EE as an agencyID is AA.DD.EE ... ... @@ -408,13 +408,13 @@ 408 408 409 409 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. 410 410 411 -=== =={{id name="_Toc90807"/}}6.2.2 Universal Resource Name (URN) =====404 +=== 6.2.2 Universal Resource Name (URN) === 412 412 413 - **6.2.2.1 Introduction**406 +==== 6.2.2.1 Introduction ==== 414 414 415 415 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.). 416 416 417 - **6.2.2.2 URN Structure //__Case Rules for URN__//**// //410 +==== 6.2.2.2 URN Structure //__Case Rules for URN__// ==== 418 418 419 419 For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows: 420 420 ... ... @@ -426,7 +426,7 @@ 426 426 427 427 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. 428 428 429 - **6.2.2.3 Explanation of the generic structure**422 +==== 6.2.2.3 Explanation of the generic structure ==== 430 430 431 431 In the explanation below the actual object that is the target of the URN is called the **actual object**. 432 432 ... ... @@ -505,103 +505,103 @@ 505 505 506 506 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. 507 507 508 -=== =={{id name="_Toc90808"/}}6.2.3 Table of SDMX-IM Packages and Classes =====501 +=== 6.2.3 Table of SDMX-IM Packages and Classes === 509 509 510 510 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. 511 511 512 -|**Package**|**URN class name (model class name where this is different)** 513 -|base|Agency 514 -| |AgencyScheme 515 -| |DataConsumer 516 -| |DataConsumerScheme 517 -| |DataProvider 518 -| |DataProviderScheme 519 -| |MetadataProvider 520 -| |MetadataProviderScheme 521 -| |OrganisationUnit 522 -| |OrganisationUnitScheme 523 -| | 524 -|datastructure|AttributeDescriptor 525 -| |DataAttribute 526 -| |Dataflow 527 -| |DataStructure (DataStructureDefinition) 528 -| |Dimension 529 -| |DimensionDescriptor 530 -| |GroupDimensionDescriptor 531 -| |Measure 532 -| |MeasureDescriptor 533 -| |TimeDimension 534 -| | 535 -|metadatastructure|MetadataAttribute 536 -| |MetadataAttributeDescriptor 537 -| |((( 505 +(% style="width:750.835px" %) 506 +|(% style="width:222px" %)**Package**|(% style="width:526px" %)**URN class name (model class name where this is different)** 507 +|(% style="width:222px" %)base|(% style="width:526px" %)Agency 508 +|(% style="width:222px" %) |(% style="width:526px" %)AgencyScheme 509 +|(% style="width:222px" %) |(% style="width:526px" %)DataConsumer 510 +|(% style="width:222px" %) |(% style="width:526px" %)DataConsumerScheme 511 +|(% style="width:222px" %) |(% style="width:526px" %)DataProvider 512 +|(% style="width:222px" %) |(% style="width:526px" %)DataProviderScheme 513 +|(% style="width:222px" %) |(% style="width:526px" %)MetadataProvider 514 +|(% style="width:222px" %) |(% style="width:526px" %)MetadataProviderScheme 515 +|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnit 516 +|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnitScheme 517 +|(% style="width:222px" %) |(% style="width:526px" %) 518 +|(% style="width:222px" %)datastructure|(% style="width:526px" %)AttributeDescriptor 519 +|(% style="width:222px" %) |(% style="width:526px" %)DataAttribute 520 +|(% style="width:222px" %) |(% style="width:526px" %)Dataflow 521 +|(% style="width:222px" %) |(% style="width:526px" %)DataStructure (DataStructureDefinition) 522 +|(% style="width:222px" %) |(% style="width:526px" %)Dimension 523 +|(% style="width:222px" %) |(% style="width:526px" %)DimensionDescriptor 524 +|(% style="width:222px" %) |(% style="width:526px" %)GroupDimensionDescriptor 525 +|(% style="width:222px" %) |(% style="width:526px" %)Measure 526 +|(% style="width:222px" %) |(% style="width:526px" %)MeasureDescriptor 527 +|(% style="width:222px" %) |(% style="width:526px" %)TimeDimension 528 +|(% style="width:222px" %) |(% style="width:526px" %) 529 +|(% style="width:222px" %)metadatastructure|(% style="width:526px" %)MetadataAttribute 530 +|(% style="width:222px" %) |(% style="width:526px" %)MetadataAttributeDescriptor 531 +|(% style="width:222px" %) |(% style="width:526px" %)((( 538 538 MetadataStructure 539 539 540 540 (MetadataStructureDefinition) 541 541 ))) 542 542 543 -: 544 - 545 545 ((( 546 -|**Package**|**URN class name (model class name where this is different)** 547 -| |Metadataflow 548 -| |MetadataSet 549 -| | 550 -|process|Process 551 -| |ProcessStep 552 -| |Transition 553 -| | 554 -|registry|DataConstraint 555 -| |MetadataConstraint 556 -| |MetadataProvisionAgreement 557 -| |ProvisionAgreement 558 -| |Subscription 559 -| | 560 -|structuremapping|CategorySchemeMap 561 -| |ConceptSchemeMap 562 -| |OrganisationSchemeMap 563 -| |ReportingTaxonomyMap 564 -| |RepresentationMap 565 -| |StructureMap 566 -| | 567 -|codelist|Code 568 -| |Codelist 569 -| |HierarchicalCode 570 -| |Hierarchy 571 -| |HierarchyAssociation 572 -| |Level 573 -| |ValueList 574 -| | 575 -|categoryscheme|Categorisation 576 -| |Category 577 -| |CategoryScheme 578 -| |ReportingCategory 579 -| |ReportingTaxonomy 580 -|**Package**|**URN class name (model class name where this is different)** 581 -| | 582 -|conceptscheme|Concept 583 -| |ConceptScheme 584 -| | 585 -|transformation|CustomType 586 -| |CustomTypeScheme 587 -| |NamePersonalisation 588 -| |NamePersonalisationScheme 589 -| |Ruleset 590 -| |RulesetScheme 591 -| |Transformation 592 -| |TransformationScheme 593 -| |UserDefinedOperator 594 -| |UserDefinedOperatorScheme 595 -| |VtlCodelistMapping 596 -| |VtlConceptMapping 597 -| |VtlDataflowMapping 598 -| |VtlMappingScheme 599 -| | 538 +(% style="width:751.835px" %) 539 +|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)** 540 +|(% style="width:221px" %) |(% style="width:528px" %)Metadataflow 541 +|(% style="width:221px" %) |(% style="width:528px" %)MetadataSet 542 +|(% style="width:221px" %) |(% style="width:528px" %) 543 +|(% style="width:221px" %)process|(% style="width:528px" %)Process 544 +|(% style="width:221px" %) |(% style="width:528px" %)ProcessStep 545 +|(% style="width:221px" %) |(% style="width:528px" %)Transition 546 +|(% style="width:221px" %) |(% style="width:528px" %) 547 +|(% style="width:221px" %)registry|(% style="width:528px" %)DataConstraint 548 +|(% style="width:221px" %) |(% style="width:528px" %)MetadataConstraint 549 +|(% style="width:221px" %) |(% style="width:528px" %)MetadataProvisionAgreement 550 +|(% style="width:221px" %) |(% style="width:528px" %)ProvisionAgreement 551 +|(% style="width:221px" %) |(% style="width:528px" %)Subscription 552 +|(% style="width:221px" %) |(% style="width:528px" %) 553 +|(% style="width:221px" %)structuremapping|(% style="width:528px" %)CategorySchemeMap 554 +|(% style="width:221px" %) |(% style="width:528px" %)ConceptSchemeMap 555 +|(% style="width:221px" %) |(% style="width:528px" %)OrganisationSchemeMap 556 +|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomyMap 557 +|(% style="width:221px" %) |(% style="width:528px" %)RepresentationMap 558 +|(% style="width:221px" %) |(% style="width:528px" %)StructureMap 559 +|(% style="width:221px" %) |(% style="width:528px" %) 560 +|(% style="width:221px" %)codelist|(% style="width:528px" %)Code 561 +|(% style="width:221px" %) |(% style="width:528px" %)Codelist 562 +|(% style="width:221px" %) |(% style="width:528px" %)HierarchicalCode 563 +|(% style="width:221px" %) |(% style="width:528px" %)Hierarchy 564 +|(% style="width:221px" %) |(% style="width:528px" %)HierarchyAssociation 565 +|(% style="width:221px" %) |(% style="width:528px" %)Level 566 +|(% style="width:221px" %) |(% style="width:528px" %)ValueList 567 +|(% style="width:221px" %) |(% style="width:528px" %) 568 +|(% style="width:221px" %)categoryscheme|(% style="width:528px" %)Categorisation 569 +|(% style="width:221px" %) |(% style="width:528px" %)Category 570 +|(% style="width:221px" %) |(% style="width:528px" %)CategoryScheme 571 +|(% style="width:221px" %) |(% style="width:528px" %)ReportingCategory 572 +|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomy 573 +|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)** 574 +|(% style="width:221px" %) |(% style="width:528px" %) 575 +|(% style="width:221px" %)conceptscheme|(% style="width:528px" %)Concept 576 +|(% style="width:221px" %) |(% style="width:528px" %)ConceptScheme 577 +|(% style="width:221px" %) |(% style="width:528px" %) 578 +|(% style="width:221px" %)transformation|(% style="width:528px" %)CustomType 579 +|(% style="width:221px" %) |(% style="width:528px" %)CustomTypeScheme 580 +|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisation 581 +|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisationScheme 582 +|(% style="width:221px" %) |(% style="width:528px" %)Ruleset 583 +|(% style="width:221px" %) |(% style="width:528px" %)RulesetScheme 584 +|(% style="width:221px" %) |(% style="width:528px" %)Transformation 585 +|(% style="width:221px" %) |(% style="width:528px" %)TransformationScheme 586 +|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperator 587 +|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperatorScheme 588 +|(% style="width:221px" %) |(% style="width:528px" %)VtlCodelistMapping 589 +|(% style="width:221px" %) |(% style="width:528px" %)VtlConceptMapping 590 +|(% style="width:221px" %) |(% style="width:528px" %)VtlDataflowMapping 591 +|(% style="width:221px" %) |(% style="width:528px" %)VtlMappingScheme 592 +|(% style="width:221px" %) |(% style="width:528px" %) 600 600 ))) 601 601 602 602 **Table 2: SDMX-IM Packages and Contained Classes** 603 603 604 -=== =={{id name="_Toc90809"/}}6.2.4 URN Identification components of SDMX objects =====597 +=== 6.2.4 URN Identification components of SDMX objects === 605 605 606 606 The table below describes the identification components for all SDMX object types that have identification. Note the actual attributes are all ‘id’ but have been prefixed by their class name or multiple class names to show navigation, e.g., ‘conceptSchemeAgencyId’ is really the ‘Id’ attribute of the Agency class that is associated to the ConceptScheme. 607 607 ... ... @@ -609,67 +609,56 @@ 609 609 610 610 urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 611 611 612 -|**Classname**|**Ending URN pattern**|**Example** 613 -|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA 614 -|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**) 615 -|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0) 616 -|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category … 617 -|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0) 605 +(% style="width:1272.83px" %) 606 +|(% style="width:290px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:332px" %)**Example** 607 +|(% style="width:290px" %)Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**).AA 608 +|(% style="width:290px" %)//AgencyScheme//|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**) 609 +|(% style="width:290px" %)//Categorisation//|(% style="width:649px" %)categorisationAgencyId:categorisationId(version)|(% style="width:332px" %)IMF:cat001(1.0.0) 610 +|(% style="width:290px" %)Category|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:332px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category … 611 +|(% style="width:290px" %)//CategoryScheme//|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:332px" %)IMF:SDDS(1.0.0) 618 618 619 -|**Classname**|**Ending URN pattern**|**Example** 620 -|//CategorySchemeMap//|((( 621 -catSchemeMapAgencyId:catSchemeMapId(version 613 +|(% style="width:292px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:742px" %)**Example** 614 +|(% style="width:292px" %)//CategorySchemeMap//|(% style="width:647px" %)((( 615 +catSchemeMapAgencyId:catSchemeMapId(version) 616 +)))|(% style="width:742px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0) 617 +|(% style="width:292px" %)Code|(% style="width:647px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0).Q 618 +|(% style="width:292px" %)//Codelist//|(% style="width:647px" %)codeListAgencyId:codeListId(version)|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0) 619 +|(% style="width:292px" %)ComponentMap|(% style="width:647px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:742px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY 620 +|(% style="width:292px" %)Concept|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ 621 +|(% style="width:292px" %)//ConceptScheme//|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0) 622 +|(% style="width:292px" %)//ConceptSchemeMap//|(% style="width:647px" %)((( 623 +conceptSchemeMapAgencyId:conceptSchemeMap Id(version) 624 +)))|(% style="width:742px" %)SDMX:CONCEPT_MAP(1.0.0) 625 +|(% style="width:292px" %)CustomType|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:742px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1 626 +|(% style="width:292px" %)//CustomTypeScheme//|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:742px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0) 627 +|(% style="width:292px" %)DataAttrribute|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS 628 +|(% style="width:292px" %)//DataConstraint//|(% style="width:647px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:742px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0) 622 622 623 -) 624 -)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0) 625 -|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q 626 -|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0) 627 -|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY 628 -|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ 629 -|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0) 630 -|//ConceptSchemeMap//|((( 631 -conceptSchemeMapAgencyId:conceptSchemeMap 632 - 633 -Id(version) 634 -)))|SDMX:CONCEPT_MAP(1.0.0) 635 -|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1 636 -|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0) 637 -|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS 638 -|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0) 639 - 640 -|**Classname**|**Ending URN pattern**|**Example** 641 -|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1 642 -|//DataConsumerScheme//|((( 643 -dataConsumerSchemeAgencyId:**DATA_CONSUME** 644 - 645 -**RS**(**1.0**) 646 -)))|SDMX:**DATA_CONSUMERS**(**1.0**) 647 -|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0) 648 -|DataProvider|((( 649 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**( 650 - 651 -**1.0**).dataProviderId 652 -)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1 653 -|//DataProviderScheme//|((( 654 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**( 655 - 656 -**1.0**) 657 -)))|SDMX:**DATA_PROVIDERS**(**1.0**) 658 -|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0) 659 -|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ 660 -|((( 630 +|(% style="width:294px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:742px" %)**Example** 631 +|(% style="width:294px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1 632 +|(% style="width:294px" %)//DataConsumerScheme//|(% style="width:645px" %)((( 633 +dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**) 634 +)))|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**) 635 +|(% style="width:294px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:742px" %)TFFS:CRED_EXT_DEBT(1.0.0) 636 +|(% style="width:294px" %)DataProvider|(% style="width:645px" %)((( 637 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId 638 +)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1 639 +|(% style="width:294px" %)//DataProviderScheme//|(% style="width:645px" %)((( 640 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**) 641 +)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**) 642 +|(% style="width:294px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0) 643 +|(% style="width:294px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).FREQ 644 +|(% style="width:294px" %)((( 661 661 DimensionDescriptor 662 662 663 663 MeasureDescriptor 664 664 665 665 AttributeDescriptor 666 -)))|((( 650 +)))|(% style="width:645px" %)((( 667 667 dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId 668 668 669 -where the componentListId is the name of the class (there is only one occurrence of each in the 670 - 671 -Data Structure Definition) 672 -)))|((( 653 +where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition) 654 +)))|(% style="width:742px" %)((( 673 673 TFFS:EXT_DEBT(1.0.0).DimensionDescriptor 674 674 675 675 TFFS:EXT_DEBT(1.0.0).MeasureDescriptor ... ... @@ -676,83 +676,81 @@ 676 676 677 677 TFFS:EXT_DEBT(1.0.0).AttributeDescriptor 678 678 ))) 679 -|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING 680 -|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1 661 +|(% style="width:294px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).SIBLING 662 +|(% style="width:294px" %)HierarchicalCode|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:742px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1 681 681 682 -|**Classname**|**Ending URN pattern**|**Example** 683 -|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0) 684 -|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0) 685 -|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1 686 -|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE 687 -|MetadataAttribute|((( 664 +|**Classname**|(% style="width:644px" %)**Ending URN pattern**|(% style="width:743px" %)**Example** 665 +|//Hierarchy//|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0) 666 +|//HierarchyAssociation//|(% style="width:644px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:743px" %)UNESCO:CL_EXP_SOURCE(1.0.0) 667 +|Level|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0).LVL1 668 +|Measure|(% style="width:644px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:743px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE 669 +|MetadataAttribute|(% style="width:644px" %)((( 688 688 msdAgencyId:msdId(version).metadataAttributeId. 689 689 690 690 metadataAttributeId 691 -)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD 692 -|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor 693 -|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0) 694 -|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0) 695 -|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1 696 -|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**) 697 -|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0) 698 -|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0) 699 -|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0) 673 +)))|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD 674 +|MetadataAttributeDescriptor|(% style="width:644px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor 675 +|//MetadataConstraint//|(% style="width:644px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:743px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0) 676 +|//Metadataflow//|(% style="width:644px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:743px" %)IMF:SDDS_MDF(1.0.0) 677 +|MetadataProvider|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1 678 +|//MetadataProviderScheme//|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**) 679 +|//MetadataProvisionAgreement//|(% style="width:644px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:743px" %)IMF:SDDS_MDF_AB(1.0.0) 680 +|//MetadataSet//|(% style="width:644px" %)metadataProviderId:metadataSetId(version)|(% style="width:743px" %)MD_PROVIDER:METADATASET(1.0.0) 681 +|//MetadataStructure//|(% style="width:644px" %)msdAgencyId:msdId(version)|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0) 700 700 701 -|**Classname**|**Ending URN pattern**|**Example** 702 -|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234 703 -|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0) 704 -|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0) 705 -|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F 706 -|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0) 707 -|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0) 708 -|ProcessStep|((( 683 +|(% style="width:296px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:739px" %)**Example** 684 +|(% style="width:296px" %)NamePersonalisation|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0).PSN1234 685 +|(% style="width:296px" %)//NamePersonalisationScheme//|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0) 686 +|(% style="width:296px" %)//OrganisationSchemeMap//|(% style="width:646px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:739px" %)SDMX:AGENCIES_PROVIDERS(1.0.0) 687 +|(% style="width:296px" %)OrganisationUnit|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0).1F 688 +|(% style="width:296px" %)//OrganisationUnitScheme//|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0) 689 +|(% style="width:296px" %)//Process//|(% style="width:646px" %)processAgencyId:processId{version)|(% style="width:739px" %)BIS:PROCESS1(1.0.0) 690 +|(% style="width:296px" %)ProcessStep|(% style="width:646px" %)((( 709 709 processAgencyId:processId(version).processStepId. 710 710 711 711 processStepId 712 -)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1 713 -|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0) 714 -|ReportingCategory|((( 694 +)))|(% style="width:739px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1 695 +|(% style="width:296px" %)//ProvisionAgreement//|(% style="width:646px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:739px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0) 696 +|(% style="width:296px" %)ReportingCategory|(% style="width:646px" %)((( 715 715 reportingTaxonomyAgencyId: 716 716 717 717 reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId 718 -)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT 719 -|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0) 720 -|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0) 700 +)))|(% style="width:739px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT 701 +|(% style="width:296px" %)//ReportingTaxonomy//|(% style="width:646px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:739px" %)IMF:REP_1(1.0.0) 702 +|(% style="width:296px" %)//ReportingTaxonomyMap//|(% style="width:646px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:739px" %)SDMX:RT_MAP(1.0.0) 721 721 722 -|**Classname**|**Ending URN pattern**|**Example** 723 -|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0) 724 -|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111 725 -|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0) 726 -|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0) 727 -|Subscription|((( 704 +|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example** 705 +|(% style="width:297px" %)//RepresentationMap//|(% style="width:647px" %)repMapAgencyId:repMapId(version)|(% style="width:737px" %)SDMX:REF_AREA_MAPPING(1.0.0) 706 +|(% style="width:297px" %)Ruleset|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:737px" %)ECB:RULESET_23(1.0.0).SET111 707 +|(% style="width:297px" %)//RulesetScheme//|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:737px" %)ECB:RULESET_23(1.0.0) 708 +|(% style="width:297px" %)//StructureMap//|(% style="width:647px" %)structureMapAgencyId:structureMap(version)|(% style="width:737px" %)SDMX:BOP_STRUCTURES(1.0.0) 709 +|(% style="width:297px" %)Subscription|(% style="width:647px" %)((( 728 728 The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure. 729 - 730 730 The name of the URN is registryURN There is no pre-determined format. 731 -)))|This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registry URN that is returned from the registry in the subscription response message. 732 -|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD 733 -|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1 734 -|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0) 735 -|**Classname**|**Ending URN pattern**|**Example** 736 -|Transition|((( 712 +)))|(% style="width:737px" %)This cannot be generated by a common mechanism as subscriptions, although maintainable in the sense that they can be submitted and deleted, are not mandated to be created by a maintenance agency and have no versioning mechanism. It is therefore the responsibility of the target registry to generate a unique Id for the Subscription, and for the application creating the subscription to store the registry URN that is returned from the registry in the subscription response message. 713 +|(% style="width:297px" %)TimeDimension|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:737px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD 714 +|(% style="width:297px" %)Transformation|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:737px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1 715 +|(% style="width:297px" %)//TransformationScheme//|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:737px" %)ECB: TRANSFORMATION_SCHEME(1.0.0) 716 +|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example** 717 +|(% style="width:297px" %)Transition|(% style="width:647px" %)((( 737 737 processAgencyId:processId(version).processStepId. 738 - 739 739 transitionId 740 -)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1 741 -|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267 742 -|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0) 743 -|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0) 744 -|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ 745 -|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA 746 -|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ 747 -|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0) 720 +)))|(% style="width:737px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1 721 +|(% style="width:297px" %)UserDefinedOperator|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:737px" %)ECB:OS_CALC(1.2.0).OS267 722 +|(% style="width:297px" %)//UserDefinedOperatorScheme//|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:737px" %)ECB:OS_CALC(1.2.0) 723 +|(% style="width:297px" %)//ValueList//|(% style="width:647px" %)valuelistAgencyId:valuelistId(version)|(% style="width:737px" %)SDMX:VLIST(1.0.0) 724 +|(% style="width:297px" %)VtlCodelistMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:737px" %)ECB:CLIST_MP(2.0.0).ABZ 725 +|(% style="width:297px" %)VtlConceptMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).XYA 726 +|(% style="width:297px" %)VtlDataflowMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).MOQ 727 +|(% style="width:297px" %)//VtlMappingScheme//|(% style="width:647px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:737px" %)ECB:CLIST_MP(2.0.0) 748 748 749 749 5**Table 3: Table of identification components for SDMX Identifiable Artefacts** 750 750 751 -= {{id name="_Toc90810"/}}7 Implementation Notes =731 += 7 Implementation Notes = 752 752 753 -== ={{id name="_Toc90811"/}}7.1 Structural Definition Metadata ===733 +== 7.1 Structural Definition Metadata == 754 754 755 -=== =={{id name="_Toc90812"/}}7.1.1 Introduction =====735 +=== 7.1.1 Introduction === 756 756 757 757 The SDMX Registry must have the ability to support agencies in their role of defining and disseminating structural metadata artefacts. These artefacts include data structure definitions, code lists, concepts etc. and are fully defined in the SDMX-IM. An authenticated agency may submit valid structural metadata definitions which must be stored in the registry. Note that the term “structural metadata” refers as a general term to all structural components (Data Structure Definitions, Metadata Structure Definitions, Code Lists, Concept Schemes, etc.) 758 758 ... ... @@ -768,46 +768,40 @@ 768 768 769 769 The following table lists the Maintainable Artefacts. 770 770 771 -|(% colspan="2" %)**Maintainable Artefacts**|**Content** 772 -|**Abstract Class**|**Concrete Class**| 773 -|Item Scheme|Codelist|Code 774 -| |Concept Scheme|Concept 775 -| |Category Scheme|Category 776 -| |Organisation Unit Scheme|Organisation Unit 777 -| |Agency Scheme|Agency 778 -| |Data Provider Scheme|Data Provider 779 -| |Metadata Provider Scheme|Metadata Provider 780 -| |Data Consumer Scheme|Data Consumer 781 -| |Reporting Taxonomy|Reporting Category 782 -| |Transformation Scheme|Transformation 783 -| |Custom Type Scheme|Custom Type 784 -| |Name Personalisation Scheme|Name Personalisation 785 -| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping 786 -| |Ruleset Scheme|Ruleset 787 -| |User Defined Operator Scheme|User Defined Operator 788 -|Enumerated List|ValueList|Value Item 789 -|Structure|Data Structure Definition|((( 751 +(% style="width:825.835px" %) 752 +|(% colspan="2" style="width:455px" %)**Maintainable Artefacts**|(% style="width:367px" %)**Content** 753 +|(% style="width:160px" %)**Abstract Class**|(% style="width:295px" %)**Concrete Class**|(% style="width:367px" %) 754 +|(% style="width:160px" %)Item Scheme|(% style="width:295px" %)Codelist|(% style="width:367px" %)Code 755 +|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme|(% style="width:367px" %)Concept 756 +|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme|(% style="width:367px" %)Category 757 +|(% style="width:160px" %) |(% style="width:295px" %)Organisation Unit Scheme|(% style="width:367px" %)Organisation Unit 758 +|(% style="width:160px" %) |(% style="width:295px" %)Agency Scheme|(% style="width:367px" %)Agency 759 +|(% style="width:160px" %) |(% style="width:295px" %)Data Provider Scheme|(% style="width:367px" %)Data Provider 760 +|(% style="width:160px" %) |(% style="width:295px" %)Metadata Provider Scheme|(% style="width:367px" %)Metadata Provider 761 +|(% style="width:160px" %) |(% style="width:295px" %)Data Consumer Scheme|(% style="width:367px" %)Data Consumer 762 +|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy|(% style="width:367px" %)Reporting Category 763 +|(% style="width:160px" %) |(% style="width:295px" %)Transformation Scheme|(% style="width:367px" %)Transformation 764 +|(% style="width:160px" %) |(% style="width:295px" %)Custom Type Scheme|(% style="width:367px" %)Custom Type 765 +|(% style="width:160px" %) |(% style="width:295px" %)Name Personalisation Scheme|(% style="width:367px" %)Name Personalisation 766 +|(% style="width:160px" %) |(% style="width:295px" %)Vtl Mapping Scheme|(% style="width:367px" %)Vtl Codelist Mapping Vtl Concept Mapping 767 +|(% style="width:160px" %) |(% style="width:295px" %)Ruleset Scheme|(% style="width:367px" %)Ruleset 768 +|(% style="width:160px" %) |(% style="width:295px" %)User Defined Operator Scheme|(% style="width:367px" %)User Defined Operator 769 +|(% style="width:160px" %)Enumerated List|(% style="width:295px" %)ValueList|(% style="width:367px" %)Value Item 770 +|(% style="width:160px" %)Structure|(% style="width:295px" %)Data Structure Definition|(% style="width:367px" %)((( 790 790 Dimension Descriptor 791 - 792 792 Group Dimension Descriptor 793 - 794 794 Dimension 795 - 796 796 Time Dimension 797 - 798 798 Attribute Descriptor 799 - 800 800 Data Attribute 801 - 802 802 Measure Descriptor 803 - 804 804 Measure 805 805 ))) 806 -| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute 807 -|Structure Usage|Dataflow| 808 -| |Metadataflow| 809 -|None|Process|Process Step 810 -|None|Structure Map|((( 780 +|(% style="width:160px" %) |(% style="width:295px" %)Metadata Structure Definition|(% style="width:367px" %)Metadata Attribute Descriptor Metadata Attribute 781 +|(% style="width:160px" %)Structure Usage|(% style="width:295px" %)Dataflow|(% style="width:367px" %) 782 +|(% style="width:160px" %) |(% style="width:295px" %)Metadataflow|(% style="width:367px" %) 783 +|(% style="width:160px" %)None|(% style="width:295px" %)Process|(% style="width:367px" %)Process Step 784 +|(% style="width:160px" %)None|(% style="width:295px" %)Structure Map|(% style="width:367px" %)((( 811 811 Component Map 812 812 813 813 Epoch Map ... ... @@ -814,44 +814,44 @@ 814 814 815 815 Date Pattern Map 816 816 ))) 817 -|None|Representation Map|Representation Mapping 818 -|Item Scheme Map|Organisation Scheme Map|Item Map 819 -| |Concept Scheme Map|Item Map 820 -| |Category Scheme Map|Item Map 821 -| |Reporting Taxonomy Map|Item Map 822 -|None|Provision Agreement| 823 -|None|Metadata Provision Agreement| 824 -|None|Hierarchy|Hierarchical Code 825 -|None|Hierarchy Association| 826 -|None|Categorisation| 827 -|Constraint|Data Constraint|DataKeySet 828 -| | |CubeRegion 829 -|Constraint|Metadata Constraint|MetadataTargetRegion 791 +|(% style="width:160px" %)None|(% style="width:295px" %)Representation Map|(% style="width:367px" %)Representation Mapping 792 +|(% style="width:160px" %)Item Scheme Map|(% style="width:295px" %)Organisation Scheme Map|(% style="width:367px" %)Item Map 793 +|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme Map|(% style="width:367px" %)Item Map 794 +|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme Map|(% style="width:367px" %)Item Map 795 +|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy Map|(% style="width:367px" %)Item Map 796 +|(% style="width:160px" %)None|(% style="width:295px" %)Provision Agreement|(% style="width:367px" %) 797 +|(% style="width:160px" %)None|(% style="width:295px" %)Metadata Provision Agreement|(% style="width:367px" %) 798 +|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy|(% style="width:367px" %)Hierarchical Code 799 +|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy Association|(% style="width:367px" %) 800 +|(% style="width:160px" %)None|(% style="width:295px" %)Categorisation|(% style="width:367px" %) 801 +|(% style="width:160px" %)Constraint|(% style="width:295px" %)Data Constraint|(% style="width:367px" %)DataKeySet 802 +|(% style="width:160px" %) |(% style="width:295px" %) |(% style="width:367px" %)CubeRegion 803 +|(% style="width:160px" %)Constraint|(% style="width:295px" %)Metadata Constraint|(% style="width:367px" %)MetadataTargetRegion 830 830 831 831 **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 832 832 833 -=== =={{id name="_Toc90813"/}}7.1.2 Item Scheme, Structure =====807 +=== 7.1.2 Item Scheme, Structure === 834 834 835 835 The artefacts included in the structural definitions are: 836 836 837 837 * 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) 838 -* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^ 812 +* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^ 839 839 * All types of Structure (Data Structure Definition, Metadata Structure Definition) 840 840 * All types of Structure Usage (Dataflow, Metadataflow) 841 841 842 -=== =={{id name="_Toc90814"/}}7.1.3 Structure Usage =====816 +=== 7.1.3 Structure Usage === 843 843 844 - **7.1.3.1 Structure Usage: Basic Concepts**818 +==== 7.1.3.1 Structure Usage: Basic Concepts ==== 845 845 846 846 The Structure Usage defines, in its concrete classes of Dataflow and Metadataflow, which flows of data and metadata use which specific Structure, and importantly for the support of data and metadata discovery, the Structure Usage can be linked to one or more Category in one or more Category Scheme using the Categorisation mechanism. This gives the ability for an application to discover data and metadata by “drilling down” the Category Schemes. 847 847 848 - **7.1.3.2 Structure Usage Schematic**822 +==== 7.1.3.2 Structure Usage Schematic ==== 849 849 850 850 [[image:SDMX 3.1 Section 5_en_9b750e13.jpg||height="246" width="438"]] 851 851 852 852 **Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions** 853 853 854 - **7.1.3.3 Structure Usage Model**828 +==== 7.1.3.3 Structure Usage Model ==== 855 855 856 856 [[image:SDMX 3.1 Section 5_en_1c94cbe.jpg||height="548" width="578"]] 857 857 ... ... @@ -869,9 +869,9 @@ 869 869 1*. Categorisation to Dataflow and Category 870 870 1*. Categorisation to Metadataflow and Category 871 871 872 -== ={{id name="_Toc90815"/}}7.2 Data and Metadata Provisioning ===846 +== 7.2 Data and Metadata Provisioning == 873 873 874 -=== =={{id name="_Toc90816"/}}7.2.1 Provisioning Agreement: Basic concepts =====848 +=== 7.2.1 Provisioning Agreement: Basic concepts === 875 875 876 876 Data/Metadata provisioning defines a framework in which the provision of different types of statistical data and metadata by various data/metadata providers can be specified and controlled. This framework is the basis on which the existence of data can be made known to the SDMX-enabled community and hence the basis on which data can subsequently be discovered. Such a framework can be used to regulate the data content to facilitate the building of intelligent applications. It can also be used to facilitate the processing implied by service level agreements, or other provisioning agreements in those scenarios that are based on legal directives. Additionally, quality and timeliness metadata can be supported by this framework which makes it practical to implement information supply chain monitoring. 877 877 ... ... @@ -879,7 +879,7 @@ 879 879 880 880 Although the Provision Agreement directly supports the data-sharing “pull” model, it is also useful in “push” exchanges (bilateral and gateway scenarios), or in a dissemination environment. It should be noted, too, that in any exchange scenario, the registry functions as a repository of structural metadata. 881 881 882 -=== =={{id name="_Toc90817"/}}7.2.2 Provisioning Agreement Model – pull use case =====856 +=== 7.2.2 Provisioning Agreement Model – pull use case === 883 883 884 884 An organisation which publishes statistical data or reference metadata and wishes to make it available to an SDMX enabled community is called a Data Provider. In terms of the SDMX Information Model, the Data Provider is maintained in a Data Provider Scheme. 885 885