Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Objects (0 modified, 0 added, 1 removed)
Details
- Page properties
-
- Content
-
... ... @@ -183,11 +183,11 @@ 183 183 184 184 === {{id name="_Toc93847"/}}5.2.2 Structure Submission Service === 185 185 186 -The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model).186 +The registry must support a mechanism for submitting structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__[[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. In order for the architecture to be scalable, the finest-grained piece of structural metadata that can be processed by the SDMX-RR is a MaintainableArtefact, with the exception of Item Schemes, where changes at an Item level is also possible (see next section on the SDMX Information Model). 187 187 188 188 === {{id name="_Toc93848"/}}5.2.3 Structure Query Service === 189 189 190 -The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: [[__https:~~/~~/github.com/sdmx-twg/sdmx-rest__>>https://https:github.comsdmx-twgsdmx-rest]]). The registry response to this query mechanism is the SDMX Structure message, which has as its root node:190 +The registry must support a mechanism for querying for structural metadata. This mechanism can be the SDMX REST interface for structural metadata (this is defined in the corresponding GitHub project, dedicated to the SDMX REST API: __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest]][[->>url:https://github.com/sdmx-twg/sdmx-rest]][[rest>>url:https://github.com/sdmx-twg/sdmx-rest]]__ [[)>>url:https://github.com/sdmx-twg/sdmx-rest]]. The registry response to this query mechanism is the SDMX Structure message, which has as its root node: 191 191 192 192 * Structure 193 193 ... ... @@ -280,7 +280,7 @@ 280 280 Subscription management involves a user submitting a subscription request which contains: 281 281 282 282 * a query or constraint expression in terms of a filter which defines the events for which the user is interested (e.g., new data for a specific dataflow, or for a domain category, or changes to a Data Structure Definition). 283 -* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~: ) and HTTP POST (a normal http:~/~/ address);283 +* a list of URIs or endpoints to which an XML notification message can be sent. Supported endpoint types will be email (mailto~:) and HTTP POST (a normal http:~/~/ address); 284 284 * request for a list of submitted subscriptions; 285 285 * deletion of a subscription; 286 286 ... ... @@ -301,8 +301,10 @@ 301 301 302 302 a) Be a draft version. 303 303 ))) 304 +|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour** 304 304 |(% style="width:188px" %) |(% style="width:542px" %)((( 305 305 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. 307 + 306 306 4) The semantic versioning rules in the SDMX documentation MUST be obeyed. 307 307 ))) 308 308 |(% 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. ... ... @@ -327,12 +327,14 @@ 327 327 328 328 The table below shows the identification and related data attributes to be stored in a registry for objects that are one of: 329 329 330 -* //nnotable// 332 +* //Annotable// 331 331 * //Identifiable// 332 332 * //Nameable// 333 333 * //Versionable// 334 334 * //Maintainable// 335 335 338 +: 339 + 336 336 ((( 337 337 (% style="width:1052.29px" %) 338 338 |**Object Type**|(% style="width:241px" %)**Data Attributes**|(% style="width:156px" %)**Status**|**Data type**|(% style="width:457px" %)**Notes** ... ... @@ -360,9 +360,9 @@ 360 360 361 361 **Table 1: Common Attributes of Object Types** 362 362 363 -== {{id name="_Toc93856"/}}6.2 Unique identification of SDMX objects == 367 +=== {{id name="_Toc93856"/}}6.2 Unique identification of SDMX objects === 364 364 365 -=== {{id name="_Toc93857"/}}6.2.1 Agencies and Metadata Providers === 369 +===== {{id name="_Toc93857"/}}6.2.1 Agencies and Metadata Providers ===== 366 366 367 367 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. 368 368 ... ... @@ -443,14 +443,23 @@ 443 443 The packages are: 444 444 445 445 base 450 + 446 446 codelist 452 + 447 447 conceptscheme 454 + 448 448 datastructure 456 + 449 449 categoryscheme 458 + 450 450 registry 460 + 451 451 metadatastructure 462 + 452 452 process 464 + 453 453 structuremapping 466 + 454 454 transformation 455 455 456 456 **maintainable-object-id** is the identifier of the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object. ... ... @@ -495,23 +495,23 @@ 495 495 496 496 The Data Structure Definition CRED_EXT_DEBT of legacy version 2.1 maintained by the toplevel Agency TFFS would have the URN: 497 497 498 - urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1)511 +urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(2.1) 499 499 500 500 The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 of semantic version 1.0.0 would be: 501 501 502 - urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR515 +urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0.0).AR 503 503 504 504 The URN for a category (id of 1) which has parent category (id of 2) maintained by SDMX in the category scheme SUBJECT_MATTER_DOMAINS of the semantic extended version 1.0.0draft would be: 505 505 506 - urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2519 +urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJECT_MATT ER_DOMAINS(1.0.0-draft).1.2 507 507 508 508 The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA of semantic version 1.0.0 where the hierarchy of the Metadata Attribute is CONTACT_DETAILS/CONTACT_NAME would be: 509 509 510 - urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME523 +urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribute=SDMX: CONTACT_METADATA(1.0.0).CONTACT_DETAILS.CONTACT_NAME 511 511 512 512 The TFFS defines ABC as a sub-Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT of semantic version 1.0.0 would be: 513 513 514 - urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0)527 +urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EXTERNAL_ DEBT(1.0.0) 515 515 516 516 The SDMX-RR MUST support this globally unique identification scheme. The SDMX-RR MUST be able to create the URN from the individual identification attributes submitted and to transform the URN to these identification attributes. The identification attributes are: 517 517 ... ... @@ -611,108 +611,118 @@ 611 611 612 612 urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 613 613 614 -(% style="width:1419.29px" %) 615 -|(% style="width:227px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:543px" %)**Example** 616 -|(% style="width:227px" %)Agency{{footnote}}The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical. For example, a sub-agency of IMF is referred like this: IMF.SubAgency1{{/footnote}}|(% style="width:645px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:543px" %)ECB:**AGENCIES**(**1.0**).AA 617 -|(% style="width:227px" %)//AgencyScheme//|(% style="width:645px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:543px" %)ECB:**AGENCIES**(**1.0**) 618 -|(% style="width:227px" %)//Categorisation//|(% style="width:645px" %)categorisationAgencyId:categorisationId(version)|(% style="width:543px" %)IMF:cat001(1.0.0) 619 -|(% style="width:227px" %)Category|(% style="width:645px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:543px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category … 620 -|(% style="width:227px" %)//CategoryScheme//|(% style="width:645px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:543px" %)IMF:SDDS(1.0.0) 621 -|(% style="width:227px" %)//CategorySchemeMap//|(% style="width:645px" %)((( 627 +(% style="width:1311.29px" %) 628 +|(% style="width:252px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:418px" %)**Example** 629 +|(% style="width:252px" %)Agency{{footnote}}The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical. For example, a sub-agency of IMF is referred like this: IMF.SubAgency1{{/footnote}}|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**).AA 630 +|(% style="width:252px" %)//AgencyScheme//|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**) 631 +|(% style="width:252px" %)//Categorisation//|(% style="width:639px" %)categorisationAgencyId:categorisationId(version)|(% style="width:418px" %)IMF:cat001(1.0.0) 632 +|(% style="width:252px" %)Category|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:418px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category … 633 +|(% style="width:252px" %)//CategoryScheme//|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:418px" %)IMF:SDDS(1.0.0) 634 + 635 +|(% style="width:250px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:1049px" %)**Example** 636 +|(% style="width:250px" %)//CategorySchemeMap//|(% style="width:639px" %)((( 622 622 catSchemeMapAgencyId:catSchemeMapId(version) 623 -)))|(% style="width: 543px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)624 -|(% style="width:2 27px" %)Code|(% style="width:645px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:543px" %)SDMX:CL_FREQ(1.0.0).Q625 -|(% style="width:2 27px" %)//Codelist//|(% style="width:645px" %)codeListAgencyId:codeListId(version)|(% style="width:543px" %)SDMX:CL_FREQ(1.0.0)626 -|(% style="width:2 27px" %)ComponentMap|(% style="width:645px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:543px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY627 -|(% style="width:2 27px" %)Concept|(% style="width:645px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:543px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ628 -|(% style="width:2 27px" %)//ConceptScheme//|(% style="width:645px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:543px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)629 -|(% style="width:2 27px" %)//ConceptSchemeMap//|(% style="width:645px" %)(((638 +)))|(% style="width:1049px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0) 639 +|(% style="width:250px" %)Code|(% style="width:639px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0).Q 640 +|(% style="width:250px" %)//Codelist//|(% style="width:639px" %)codeListAgencyId:codeListId(version)|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0) 641 +|(% style="width:250px" %)ComponentMap|(% style="width:639px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:1049px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY 642 +|(% style="width:250px" %)Concept|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ 643 +|(% style="width:250px" %)//ConceptScheme//|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0) 644 +|(% style="width:250px" %)//ConceptSchemeMap//|(% style="width:639px" %)((( 630 630 conceptSchemeMapAgencyId:conceptSchemeMap 631 631 Id(version) 632 -)))|(% style="width:543px" %)SDMX:CONCEPT_MAP(1.0.0) 633 -|(% style="width:227px" %)CustomType|(% style="width:645px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:543px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1 634 -|(% style="width:227px" %)//CustomTypeScheme//|(% style="width:645px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:543px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0) 635 -|(% style="width:227px" %)DataAttrribute|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:543px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS 636 -|(% style="width:227px" %)//DataConstraint//|(% style="width:645px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:543px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0) 637 -|(% style="width:229px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:543px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1 638 -|(% style="width:229px" %)//DataConsumerScheme//|(% style="width:645px" %)((( 647 +)))|(% style="width:1049px" %)SDMX:CONCEPT_MAP(1.0.0) 648 +|(% style="width:250px" %)CustomType|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:1049px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1 649 +|(% style="width:250px" %)//CustomTypeScheme//|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:1049px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0) 650 +|(% style="width:250px" %)DataAttrribute|(% style="width:639px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:1049px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS 651 +|(% style="width:250px" %)//DataConstraint//|(% style="width:639px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:1049px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0) 652 + 653 +|(% style="width:248px" %)**Classname**|(% style="width:643px" %)**Ending URN pattern**|(% style="width:1047px" %)**Example** 654 +|(% style="width:248px" %)DataConsumer|(% style="width:643px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1 655 +|(% style="width:248px" %)//DataConsumerScheme//|(% style="width:643px" %)((( 639 639 dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**) 640 -)))|(% style="width: 543px" %)SDMX:**DATA_CONSUMERS**(**1.0**)641 -|(% style="width:2 29px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:543px" %)TFFS:CRED_EXT_DEBT(1.0.0)642 -|(% style="width:2 29px" %)DataProvider|(% style="width:645px" %)(((657 +)))|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**) 658 +|(% style="width:248px" %)//Dataflow//|(% style="width:643px" %)dataflowAgencyId:dataflowId(version)|(% style="width:1047px" %)TFFS:CRED_EXT_DEBT(1.0.0) 659 +|(% style="width:248px" %)DataProvider|(% style="width:643px" %)((( 643 643 dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId 644 -)))|(% style="width: 543px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1645 -|(% style="width:2 29px" %)//DataProviderScheme//|(% style="width:645px" %)(((661 +)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1 662 +|(% style="width:248px" %)//DataProviderScheme//|(% style="width:643px" %)((( 646 646 dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**) 647 -)))|(% style="width: 543px" %)SDMX:**DATA_PROVIDERS**(**1.0**)648 -|(% style="width:2 29px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:543px" %)TFFS:EXT_DEBT(1.0.0)649 -|(% style="width:2 29px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:543px" %)TFFS:EXT_DEBT(1.0.0).FREQ650 -|(% style="width:2 29px" %)(((664 +)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**) 665 +|(% style="width:248px" %)//DataStructure//|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0) 666 +|(% style="width:248px" %)Dimension|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).FREQ 667 +|(% style="width:248px" %)((( 651 651 DimensionDescriptor 652 652 MeasureDescriptor 653 653 AttributeDescriptor 654 -)))|(% style="width:64 5px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(% style="width:543px" %)(((671 +)))|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(% style="width:1047px" %)((( 655 655 TFFS:EXT_DEBT(1.0.0).DimensionDescriptor 656 656 TFFS:EXT_DEBT(1.0.0).MeasureDescriptor 657 657 TFFS:EXT_DEBT(1.0.0).AttributeDescriptor 658 658 ))) 659 -|(% style="width:229px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:543px" %)TFFS:EXT_DEBT(1.0.0).SIBLING 660 -|(% style="width:229px" %)HierarchicalCode|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:543px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1 661 -|(% style="width:206px" %)//Hierarchy//|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:543px" %)UNESCO:H-C-GOV(1.0.0) 662 -|(% style="width:206px" %)//HierarchyAssociation//|(% style="width:645px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:543px" %)UNESCO:CL_EXP_SOURCE(1.0.0) 663 -|(% style="width:206px" %)Level|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:543px" %)UNESCO:H-C-GOV(1.0.0).LVL1 664 -|(% style="width:206px" %)Measure|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:543px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE 665 -|(% style="width:206px" %)MetadataAttribute|(% style="width:645px" %)((( 676 +|(% style="width:248px" %)GroupDimensionDescriptor|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).SIBLING 677 +|(% style="width:248px" %)HierarchicalCode|(% style="width:643px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:1047px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1 678 + 679 +|(% style="width:248px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:1044px" %)**Example** 680 +|(% style="width:248px" %)//Hierarchy//|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0) 681 +|(% style="width:248px" %)//HierarchyAssociation//|(% style="width:646px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:1044px" %)UNESCO:CL_EXP_SOURCE(1.0.0) 682 +|(% style="width:248px" %)Level|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0).LVL1 683 +|(% style="width:248px" %)Measure|(% style="width:646px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:1044px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE 684 +|(% style="width:248px" %)MetadataAttribute|(% style="width:646px" %)((( 666 666 msdAgencyId:msdId(version).metadataAttributeId. 667 667 metadataAttributeId 668 -)))|(% style="width:543px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD 669 -|(% style="width:206px" %)MetadataAttributeDescriptor|(% style="width:645px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:543px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor 670 -|(% style="width:206px" %)//MetadataConstraint//|(% style="width:645px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:543px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0) 671 -|(% style="width:206px" %)//Metadataflow//|(% style="width:645px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:543px" %)IMF:SDDS_MDF(1.0.0) 672 -|(% style="width:206px" %)MetadataProvider|(% style="width:645px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:543px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1 673 -|(% style="width:206px" %)//MetadataProviderScheme//|(% style="width:645px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:543px" %)SDMX:**METADATA_PROVIDERS**(**1.0**) 674 -|(% style="width:206px" %)//MetadataProvisionAgreement//|(% style="width:645px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:543px" %)IMF:SDDS_MDF_AB(1.0.0) 675 -|(% style="width:206px" %)//MetadataSet//|(% style="width:645px" %)metadataProviderId:metadataSetId(version)|(% style="width:543px" %)MD_PROVIDER:METADATASET(1.0.0) 676 -|(% style="width:206px" %)//MetadataStructure//|(% style="width:645px" %)msdAgencyId:msdId(version)|(% style="width:543px" %)IMF:SDDS_MSD(1.0.0) 677 -|(% style="width:227px" %)NamePersonalisation|(% style="width:527px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:545px" %)ECB:PSN_SCHEME(1.0.0).PSN1234 678 -|(% style="width:227px" %)//NamePersonalisationScheme//|(% style="width:527px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:545px" %)ECB:PSN_SCHEME(1.0.0) 679 -|(% style="width:227px" %)//OrganisationSchemeMap//|(% style="width:527px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:545px" %)SDMX:AGENCIES_PROVIDERS(1.0.0) 680 -|(% style="width:227px" %)OrganisationUnit|(% style="width:527px" %)organisationUnitSchemeAgencyId:organisationUnitSchemeId(version).organisationUnitId|(% style="width:545px" %)ECB:ORGANISATIONS(1.0.0).1F 681 -|(% style="width:227px" %)//OrganisationUnitScheme//|(% style="width:527px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:545px" %)ECB:ORGANISATIONS(1.0.0) 682 -|(% style="width:227px" %)//Process//|(% style="width:527px" %)processAgencyId:processId{version)|(% style="width:545px" %)BIS:PROCESS1(1.0.0) 683 -|(% style="width:227px" %)ProcessStep|(% style="width:527px" %)((( 687 +)))|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD 688 +|(% style="width:248px" %)MetadataAttributeDescriptor|(% style="width:646px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor 689 +|(% style="width:248px" %)//MetadataConstraint//|(% style="width:646px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:1044px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0) 690 +|(% style="width:248px" %)//Metadataflow//|(% style="width:646px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:1044px" %)IMF:SDDS_MDF(1.0.0) 691 +|(% style="width:248px" %)MetadataProvider|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1 692 +|(% style="width:248px" %)//MetadataProviderScheme//|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**) 693 +|(% style="width:248px" %)//MetadataProvisionAgreement//|(% style="width:646px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:1044px" %)IMF:SDDS_MDF_AB(1.0.0) 694 +|(% style="width:248px" %)//MetadataSet//|(% style="width:646px" %)metadataProviderId:metadataSetId(version)|(% style="width:1044px" %)MD_PROVIDER:METADATASET(1.0.0) 695 +|(% style="width:248px" %)//MetadataStructure//|(% style="width:646px" %)msdAgencyId:msdId(version)|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0) 696 + 697 +|(% style="width:248px" %)**Classname**|(% style="width:629px" %)**Ending URN pattern**|(% style="width:1061px" %)**Example** 698 +|(% style="width:248px" %)NamePersonalisation|(% style="width:629px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:1061px" %)ECB:PSN_SCHEME(1.0.0).PSN1234 699 +|(% style="width:248px" %)//NamePersonalisationScheme//|(% style="width:629px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:1061px" %)ECB:PSN_SCHEME(1.0.0) 700 +|(% style="width:248px" %)//OrganisationSchemeMap//|(% style="width:629px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:1061px" %)SDMX:AGENCIES_PROVIDERS(1.0.0) 701 +|(% style="width:248px" %)OrganisationUnit|(% style="width:629px" %)organisationUnitSchemeAgencyId:organisationUnitSchemeId(version).organisationUnitId|(% style="width:1061px" %)ECB:ORGANISATIONS(1.0.0).1F 702 +|(% style="width:248px" %)//OrganisationUnitScheme//|(% style="width:629px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:1061px" %)ECB:ORGANISATIONS(1.0.0) 703 +|(% style="width:248px" %)//Process//|(% style="width:629px" %)processAgencyId:processId{version)|(% style="width:1061px" %)BIS:PROCESS1(1.0.0) 704 +|(% style="width:248px" %)ProcessStep|(% style="width:629px" %)((( 684 684 processAgencyId:processId(version).processStepId. 685 685 processStepId 686 -)))|(% style="width: 545px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1687 -|(% style="width:2 27px" %)//ProvisionAgreement//|(% style="width:527px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:545px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)688 -|(% style="width:2 27px" %)ReportingCategory|(% style="width:527px" %)(((707 +)))|(% style="width:1061px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1 708 +|(% style="width:248px" %)//ProvisionAgreement//|(% style="width:629px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:1061px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0) 709 +|(% style="width:248px" %)ReportingCategory|(% style="width:629px" %)((( 689 689 reportingTaxonomyAgencyId: 690 690 reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId 691 -)))|(% style="width:545px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT 692 -|(% style="width:227px" %)//ReportingTaxonomy//|(% style="width:527px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:545px" %)IMF:REP_1(1.0.0) 693 -|(% style="width:227px" %)//ReportingTaxonomyMap//|(% style="width:527px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:545px" %)SDMX:RT_MAP(1.0.0) 694 -|(% style="width:229px" %)//RepresentationMap//|(% style="width:645px" %)repMapAgencyId:repMapId(version)|(% style="width:215px" %)SDMX:REF_AREA_MAPPING(1.0.0) 695 -|(% style="width:229px" %)Ruleset|(% style="width:645px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:215px" %)ECB:RULESET_23(1.0.0).SET111 696 -|(% style="width:229px" %)//RulesetScheme//|(% style="width:645px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:215px" %)ECB:RULESET_23(1.0.0) 697 -|(% style="width:229px" %)//StructureMap//|(% style="width:645px" %)structureMapAgencyId:structureMap(version)|(% style="width:215px" %)SDMX:BOP_STRUCTURES(1.0.0) 698 -|(% style="width:229px" %)Subscription|(% style="width:645px" %)((( 712 +)))|(% style="width:1061px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT 713 +|(% style="width:248px" %)//ReportingTaxonomy//|(% style="width:629px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:1061px" %)IMF:REP_1(1.0.0) 714 +|(% style="width:248px" %)//ReportingTaxonomyMap//|(% style="width:629px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:1061px" %)SDMX:RT_MAP(1.0.0) 715 + 716 +|(% style="width:247px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:1042px" %)**Example** 717 +|(% style="width:247px" %)//RepresentationMap//|(% style="width:649px" %)repMapAgencyId:repMapId(version)|(% style="width:1042px" %)SDMX:REF_AREA_MAPPING(1.0.0) 718 +|(% style="width:247px" %)Ruleset|(% style="width:649px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:1042px" %)ECB:RULESET_23(1.0.0).SET111 719 +|(% style="width:247px" %)//RulesetScheme//|(% style="width:649px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:1042px" %)ECB:RULESET_23(1.0.0) 720 +|(% style="width:247px" %)//StructureMap//|(% style="width:649px" %)structureMapAgencyId:structureMap(version)|(% style="width:1042px" %)SDMX:BOP_STRUCTURES(1.0.0) 721 +|(% style="width:247px" %)Subscription|(% style="width:649px" %)((( 699 699 The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure. 700 700 The name of the URN is registryURN There is no pre-determined format. 701 -)))|(% style="width:10 15px" %)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.702 -|(% style="width:2 29px" %)TimeDimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:1015px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD703 -|(% style="width:2 29px" %)Transformation|(% style="width:645px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:1015px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1704 -|(% style="width:2 29px" %)//TransformationScheme//|(% style="width:645px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:1015px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)705 -|(% style="width:2 29px" %)Transition|(% style="width:645px" %)(((724 +)))|(% style="width:1042px" %)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. 725 +|(% style="width:247px" %)TimeDimension|(% style="width:649px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:1042px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD 726 +|(% style="width:247px" %)Transformation|(% style="width:649px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:1042px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1 727 +|(% style="width:247px" %)//TransformationScheme//|(% style="width:649px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:1042px" %)ECB: TRANSFORMATION_SCHEME(1.0.0) 728 +|(% style="width:247px" %)Transition|(% style="width:649px" %)((( 706 706 processAgencyId:processId(version).processStepId. 707 707 transitionId 708 -)))|(% style="width:10 15px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1709 -|(% style="width:2 29px" %)UserDefinedOperator|(% style="width:645px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:1015px" %)ECB:OS_CALC(1.2.0).OS267710 -|(% style="width:2 29px" %)//UserDefinedOperatorScheme//|(% style="width:645px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:1015px" %)ECB:OS_CALC(1.2.0)711 -|(% style="width:2 29px" %)//ValueList//|(% style="width:645px" %)valuelistAgencyId:valuelistId(version)|(% style="width:1015px" %)SDMX:VLIST(1.0.0)712 -|(% style="width:2 29px" %)VtlCodelistMapping|(% style="width:645px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:1015px" %)ECB:CLIST_MP(2.0.0).ABZ713 -|(% style="width:2 29px" %)VtlConceptMapping|(% style="width:645px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:1015px" %)ECB:CLIST_MP(1.0.0).XYA714 -|(% style="width:2 29px" %)VtlDataflowMapping|(% style="width:645px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:1015px" %)ECB:CLIST_MP(1.0.0).MOQ715 -|(% style="width:2 29px" %)//VtlMappingScheme//|(% style="width:645px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:1015px" %)ECB:CLIST_MP(2.0.0)731 +)))|(% style="width:1042px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1 732 +|(% style="width:247px" %)UserDefinedOperator|(% style="width:649px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:1042px" %)ECB:OS_CALC(1.2.0).OS267 733 +|(% style="width:247px" %)//UserDefinedOperatorScheme//|(% style="width:649px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:1042px" %)ECB:OS_CALC(1.2.0) 734 +|(% style="width:247px" %)//ValueList//|(% style="width:649px" %)valuelistAgencyId:valuelistId(version)|(% style="width:1042px" %)SDMX:VLIST(1.0.0) 735 +|(% style="width:247px" %)VtlCodelistMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:1042px" %)ECB:CLIST_MP(2.0.0).ABZ 736 +|(% style="width:247px" %)VtlConceptMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:1042px" %)ECB:CLIST_MP(1.0.0).XYA 737 +|(% style="width:247px" %)VtlDataflowMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:1042px" %)ECB:CLIST_MP(1.0.0).MOQ 738 +|(% style="width:247px" %)//VtlMappingScheme//|(% style="width:649px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:1042px" %)ECB:CLIST_MP(2.0.0) 716 716 717 717 **Table 3: Table of identification components for SDMX Identifiable Artefacts** 718 718 ... ... @@ -720,7 +720,7 @@ 720 720 721 721 === {{id name="_Toc93862"/}}7.1 Structural Definition Metadata === 722 722 723 -=== {{id name="_Toc93863"/}}7.1.1 Introduction === 746 +===== {{id name="_Toc93863"/}}7.1.1 Introduction ===== 724 724 725 725 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.) 726 726 ... ... @@ -787,7 +787,7 @@ 787 787 788 788 **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 789 789 790 -=== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure === 813 +===== {{id name="_Toc93864"/}}7.1.2 Item Scheme, Structure ===== 791 791 792 792 The artefacts included in the structural definitions are: 793 793 ... ... @@ -796,19 +796,19 @@ 796 796 * All types of Structure (Data Structure Definition, Metadata Structure Definition) 797 797 * All types of Structure Usage (Dataflow, Metadataflow) 798 798 799 -=== {{id name="_Toc93865"/}}7.1.3 Structure Usage === 822 +===== {{id name="_Toc93865"/}}7.1.3 Structure Usage ===== 800 800 801 - ====7.1.3.1 Structure Usage: Basic Concepts====824 +**7.1.3.1 Structure Usage: Basic Concepts** 802 802 803 803 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. 804 804 805 - ====7.1.3.2 Structure Usage Schematic====828 +**7.1.3.2 Structure Usage Schematic** 806 806 807 807 [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_52097ab5.jpg||height="246" width="438"]] 808 808 809 809 **Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions** 810 810 811 - ====7.1.3.3 Structure Usage Model====834 +**7.1.3.3 Structure Usage Model** 812 812 813 813 [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_302cc1a2.jpg||height="548" width="578"]] 814 814 ... ... @@ -856,9 +856,9 @@ 856 856 857 857 A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider or Metadata Provider and a Dataflow or Metadataflow Definition. The Data/Metadata Provider and the Dataflow/Metadataflow must exist already in order to set up a Metadata Provision or Provision Agreement. 858 858 859 -== {{id name="_Toc93869"/}}7.3 Data and Metadata Constraints == 882 +=== {{id name="_Toc93869"/}}7.3 Data and Metadata Constraints === 860 860 861 -=== {{id name="_Toc93870"/}}7.3.1 Data and Metadata Constraints: Basic Concepts === 884 +===== {{id name="_Toc93870"/}}7.3.1 Data and Metadata Constraints: Basic Concepts ===== 862 862 863 863 Constraints are, effectively, lists of the valid or actual content of data and metadata. Constraints can be used to specify a subset of the theoretical content of data set or metadata set which can be derived from the specification of the DSD or MSD. A Constraint can comprise a list of keys or a list of content (usually code values) of a specific component such as a dimension or attribute. 864 864 ... ... @@ -922,14 +922,17 @@ 922 922 923 923 The Registration has an action attribute which takes one of the following values: 924 924 948 +: 949 + 925 925 ((( 926 -(% style="width:761.294px" %) 927 -|(% style="width:196px" %)**Action Attribute Value**|(% style="width:561px" %)**Behaviour** 928 -|(% style="width:196px" %)Append|(% style="width:561px" %)Add this Registration to the registry 929 -|(% style="width:196px" %)Replace|(% style="width:561px" %)((( 930 -Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest 951 +|**Action Attribute Value**|**Behaviour** 952 +|Append|Add this Registration to the registry 953 +|Replace|((( 954 +Replace the existing Registration with identified by the id in the 955 + 956 +Registration of the SubmitRegistrationRequest 931 931 ))) 932 -| (% style="width:196px" %)Delete|(% style="width:561px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest958 +|Delete|Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest 933 933 ))) 934 934 935 935 [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_bc1dcdec.jpg||height="575" width="579"]] ... ... @@ -946,20 +946,27 @@ 946 946 947 947 Information in the data or metadata set is extracted and placed in one or more //Constraint//s (see the //Constraint// model in the SDMX Information Model – Section 2 of the SDMX Standards). The information to be extracted is indicated by the Boolean values set on the ProvisionAgreement or MetadataProvisionAgreement as shown in the table below. 948 948 975 +: 976 + 949 949 ((( 950 -(% style="width:678.294px" %) 951 -|**Indexing Required**|(% style="width:504px" %)**Registration Process Activity** 952 -|indexTimeSeries|(% style="width:504px" %)Extract all the series keys and create a KeySet(s) Constraint. 953 -|indexDataSet|(% style="width:504px" %)Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 954 -|indexReportingPeriod|(% style="width:504px" %)((( 978 +|**Indexing Required**|**Registration Process Activity** 979 +|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint. 980 +|indexDataSet|Extract all the codes and other content of the Key value of the Series Key in a Data Set and create one or more Cube Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 981 +|indexReportingPeriod|((( 955 955 This applies only to a registered __dataset__. 983 + 956 956 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 957 957 ))) 958 -|**Indexing Required**| (% style="width:504px" %)**Registration Process Activity**959 -|indexAttributes|( % style="width:504px" %)(((986 +|**Indexing Required**|**Registration Process Activity** 987 +|indexAttributes|((( 960 960 **Data Set** 961 -Extract the content of the Attribute Values in a Data Set and create one or more Cube Regions containing Member Selections of Data Attribute Components of the Constraints model in the SDMXIM, and the associated Selection Value 989 + 990 +Extract the content of the Attribute Values in a Data Set and create one or more Cube Regions containing Member Selections of Data Attribute Components of the Constraints model in the 991 + 992 +SDMXIM, and the associated Selection Value 993 + 962 962 **Metadata Set** 995 + 963 963 Indicate the presence of a Reported Attribute by creating one or more Cube Regions containing Member Selections of Metadata Attribute Components of the Constraints model in the SDMX-IM. Note that the content is not stored in the Selection Value. 964 964 ))) 965 965 ))) ... ... @@ -968,7 +968,7 @@ 968 968 969 969 The Registration must reference the ProvisionAgreement or MetadataProvisionAgreement to which it relates. 970 970 971 -=== {{id name="_Toc93876"/}}7.4.3 Registration Response === 1004 +===== {{id name="_Toc93876"/}}7.4.3 Registration Response ===== 972 972 973 973 After a registration request has been submitted to the registry, a response is returned to the submitter indicating success or failure. Given that a registration request can hold many Registrations, then there must be a registration status for each Registration. The SubmitRegistration class has a status field, which is either set to “Success”, “Warning” or “Failure”. 974 974 ... ... @@ -998,18 +998,20 @@ 998 998 999 999 Regardless of the type of registry/repository events being observed, a subscription always contains: 1000 1000 1001 -1. set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent. 1034 +1. A set of URIs describing the end-points to which notifications must be sent if the subscription is activated. The URIs can be either mailto~: or http: protocol. In the former case an email notification is sent; in the latter an HTTP POST notification is sent. 1002 1002 1. A user-defined identifier, which is returned in the response to the subscription request. This helps with asynchronous processing and is NOT stored in the Registry. 1003 1003 1. A validity period which defines both when the subscription becomes active and expires. The subscriber may be sent a notification on expiration of the subscription. 1004 1004 1. A selector which specifies which type of events are of interest. The set of event types is: 1005 1005 1039 +: 1040 +:: 1041 + 1006 1006 ((( 1007 -(% style="width:856.294px" %) 1008 -|(% style="width:320px" %)**Event Type**|(% style="width:532px" %)**Comment** 1009 -|(% style="width:320px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:532px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1010 -|(% style="width:320px" %)DATA_REGISTRATION_EVENTS|(% style="width:532px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1011 -|(% style="width:320px" %)METADATA_REGISTRATION_EVENTS|(% style="width:532px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1012 -|(% style="width:320px" %)ALL_EVENTS|(% style="width:532px" %)All events of the specified EventType 1043 +|**Event Type**|**Comment** 1044 +|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1045 +|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1046 +|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1047 +|ALL_EVENTS|All events of the specified EventType 1013 1013 ))) 1014 1014 1015 1015 === {{id name="_Toc93880"/}}7.5.3 Wildcard Facility === ... ... @@ -1023,25 +1023,33 @@ 1023 1023 Examples of wildcarded identifier components for an identified object type of Codelist are shown below: 1024 1024 1025 1025 AgencyID = * 1061 + 1026 1026 Id = * 1063 + 1027 1027 Version = * 1028 1028 1029 1029 This subscribes to all Codelists of all versions for all agencies. 1030 1030 1031 1031 AgencyID = AGENCY1 1069 + 1032 1032 Id = CODELIST1 1071 + 1033 1033 Version = * 1034 1034 1035 1035 This subscribes to all versions of Codelist CODELIST1 maintained by the agency AGENCY1. 1036 1036 1037 1037 AgencyID = AGENCY1 1077 + 1038 1038 Id = * 1079 + 1039 1039 Version = * 1040 1040 1041 1041 This subscribes to all versions of all Codelist objects maintained by the agency AGENCY1. 1042 1042 1043 1043 AgencyID = * 1085 + 1044 1044 Id = CODELIST1 1087 + 1045 1045 Version = * 1046 1046 1047 1047 This subscribes to all versions of Codelist CODELIST1 maintained by any agency. ... ... @@ -1068,14 +1068,15 @@ 1068 1068 1069 1069 Whenever a dataset or metadata-set is registered a registration event is created. A subscription may be observing all data or metadata registrations, or it may focus on specific registrations as shown in the table below: 1070 1070 1114 +: 1115 + 1071 1071 ((( 1072 -(% style="width:1126.29px" %) 1073 -|(% style="width:382px" %)**Selector**|(% style="width:740px" %)**Comment** 1074 -|(% style="width:382px" %)DataProvider & MetadataProvider|(% style="width:740px" %)Any datasets or metadata sets registered by the specified data or metadata provider will activate the notification. 1075 -|(% style="width:382px" %)ProvisionAgreement & MetadataProvisionAgreement|(% style="width:740px" %)Any datasets or metadata sets registered for the agreement will activate the notification. 1076 -|(% style="width:382px" %)Dataflow & Metadataflow|(% style="width:740px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1077 -|(% style="width:382px" %)DataStructureDefinition & MetadataStructureDefinition|(% style="width:740px" %)Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will activate the notification 1078 -|(% style="width:382px" %)Category|(% style="width:740px" %)Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1117 +|**Selector**|**Comment** 1118 +|DataProvider & MetadataProvider|Any datasets or metadata sets registered by the specified data or metadata provider will activate the notification. 1119 +|ProvisionAgreement & MetadataProvisionAgreement|Any datasets or metadata sets registered for the agreement will activate the notification. 1120 +|Dataflow & Metadataflow|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1121 +|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will activate the notification 1122 +|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1079 1079 ))) 1080 1080 1081 1081 The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration. ... ... @@ -1107,6 +1107,12 @@ 1107 1107 1108 1108 The notification will contain the Registration. 1109 1109 1110 - ----1154 +[[1>>path:#sdfootnote1anc||name="sdfootnote1sym"]] 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.4draft does not break integrity of the aforementioned DSD. 1111 1111 1156 +[[2>>path:#sdfootnote2anc||name="sdfootnote2sym"]] The identification of an Agency in the URN structure for the maintainable object is by means of the agencyId. The AgencyScheme is not identified as SDMX has a mechanism for identifying an Agency uniquely by its Id. Note that this Id may be hierarchical. For example, a sub-agency of IMF is referred like this: 1157 + 1158 +IMF.SubAgency1 1159 + 1160 +[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList. 1161 + 1112 1112 {{putFootnotes/}}
- SUZ.Methodology.Code.MethodologyClass[0]
-