Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -422,8 +422,10 @@ 422 422 423 423 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.). 424 424 425 -==== 6.2.2.2 URN Structure //__Case Rules for URN__ //====425 +==== 6.2.2.2 URN Structure ==== 426 426 427 +===== **//__Case Rules for URN__//** ===== 428 + 427 427 For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows: 428 428 429 429 SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobjectid(maintainedobject-version).*containerobject-id.object-id ... ... @@ -444,10 +444,32 @@ 444 444 445 445 The packages are: 446 446 447 -base codelist conceptscheme datastructure categoryscheme registry metadatastructure process structuremapping transformation449 +base 448 448 449 - **maintainable-object-id** is the identifierof the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object. **maintainable-object-version** isthe version, according to the SDMX versioning rules, of the maintainable object and is enclosed in parentheses ‘()’, which are always present. **container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Codelist) and has no intermediary container object, whereas a MetadataAttribute has an intermediary container object (MetadataAttributeDescriptor) and may have an intermediary container object, which is its parent MetadataAttribute. For this reason, the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a URN, the id of the AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor is not included when the actual object is a DataAttribute or a Dimension/ TimeDimension, or a Measure.451 +codelist 450 450 453 +conceptscheme 454 + 455 +datastructure 456 + 457 +categoryscheme 458 + 459 +registry 460 + 461 +metadatastructure 462 + 463 +process 464 + 465 +structuremapping 466 + 467 +transformation 468 + 469 +**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. 470 + 471 +**maintainable-object-version** is the version, according to the SDMX versioning rules, of the maintainable object and is enclosed in parentheses ‘()’, which are always present. 472 + 473 +**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Codelist) and has no intermediary container object, whereas a MetadataAttribute has an intermediary container object (MetadataAttributeDescriptor) and may have an intermediary container object, which is its parent MetadataAttribute. For this reason, the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a URN, the id of the AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor is not included when the actual object is a DataAttribute or a Dimension/ TimeDimension, or a Measure. 474 + 451 451 Note that although a Code can have a parent Code and a Concept can have a parent Concept these are maintained in a flat structure and therefore do not have a containerobject-id. 452 452 453 453 For example, the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId. ... ... @@ -454,7 +454,7 @@ 454 454 455 455 object-id is the identifier of the actual object unless the actual object is a //Maintainable// object. If present it is always the last id and is not followed by any other character. 456 456 457 -//__**Generic Examples of the URN Structure**__// 481 +===== //__**Generic Examples of the URN Structure**__// ===== 458 458 459 459 __Actual object is a maintainable__ 460 460 ... ... @@ -480,7 +480,7 @@ 480 480 481 481 SDMXPrefix.SDMX-IM-package-name.classname=agencyid:maintained-objectid(version).contained-object-id.contained-object-id contained-objectid.object-id 482 482 483 -//__**Concrete Examples of the URN Structure**__// 507 +===== //__**Concrete Examples of the URN Structure**__// ===== 484 484 485 485 The Data Structure Definition CRED_EXT_DEBT of legacy version 2.1 maintained by the toplevel Agency TFFS would have the URN: 486 486 ... ... @@ -600,136 +600,118 @@ 600 600 601 601 urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 602 602 603 -|**Classname**|**Ending URN pattern**|**Example** 604 -|Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA 605 -|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**) 606 -|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0) 607 -|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category … 608 -|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0) 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) 609 609 610 -|**Classname**|**Ending URN pattern**|**Example** 611 -|//CategorySchemeMap//|((( 612 -catSchemeMapAgencyId:catSchemeMapId(version 613 - 614 -) 615 -)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0) 616 -|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q 617 -|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0) 618 -|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY 619 -|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ 620 -|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0) 621 -|//ConceptSchemeMap//|((( 635 +|(% style="width:250px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:1049px" %)**Example** 636 +|(% style="width:250px" %)//CategorySchemeMap//|(% style="width:639px" %)((( 637 +catSchemeMapAgencyId:catSchemeMapId(version) 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" %)((( 622 622 conceptSchemeMapAgencyId:conceptSchemeMap 623 - 624 624 Id(version) 625 -)))|SDMX:CONCEPT_MAP(1.0.0) 626 -|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1 627 -|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0) 628 -|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS 629 -|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0) 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) 630 630 631 -|**Classname**|**Ending URN pattern**|**Example** 632 -|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1 633 -|//DataConsumerScheme//|((( 634 -dataConsumerSchemeAgencyId:**DATA_CONSUME** 635 - 636 -**RS**(**1.0**) 637 -)))|SDMX:**DATA_CONSUMERS**(**1.0**) 638 -|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0) 639 -|DataProvider|((( 640 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**( 641 - 642 -**1.0**).dataProviderId 643 -)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1 644 -|//DataProviderScheme//|((( 645 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**( 646 - 647 -**1.0**) 648 -)))|SDMX:**DATA_PROVIDERS**(**1.0**) 649 -|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0) 650 -|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ 651 -|((( 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" %)((( 656 +dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**) 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" %)((( 660 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId 661 +)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1 662 +|(% style="width:248px" %)//DataProviderScheme//|(% style="width:643px" %)((( 663 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**) 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" %)((( 652 652 DimensionDescriptor 653 - 654 654 MeasureDescriptor 655 - 656 656 AttributeDescriptor 657 -)))|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)|((( 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" %)((( 658 658 TFFS:EXT_DEBT(1.0.0).DimensionDescriptor 659 - 660 660 TFFS:EXT_DEBT(1.0.0).MeasureDescriptor 661 - 662 662 TFFS:EXT_DEBT(1.0.0).AttributeDescriptor 663 663 ))) 664 -|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING 665 -|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1 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 666 666 667 -|**Classname**|**Ending URN pattern**|**Example** 668 -|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0) 669 -|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0) 670 -|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1 671 -|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE 672 -|MetadataAttribute|((( 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" %)((( 673 673 msdAgencyId:msdId(version).metadataAttributeId. 674 - 675 675 metadataAttributeId 676 -)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD 677 -|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor 678 -|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0) 679 -|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0) 680 -|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1 681 -|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**) 682 -|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0) 683 -|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0) 684 -|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0) 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) 685 685 686 -|**Classname**|**Ending URN pattern**|**Example** 687 -|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234 688 -|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0) 689 -|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0) 690 -|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F691 -|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0) 692 -|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0) 693 -|ProcessStep|((( 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" %)((( 694 694 processAgencyId:processId(version).processStepId. 695 - 696 696 processStepId 697 -)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1 698 -|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0) 699 -|ReportingCategory|((( 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" %)((( 700 700 reportingTaxonomyAgencyId: 701 - 702 702 reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId 703 -)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT 704 -|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0) 705 -|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0) 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) 706 706 707 -|**Classname**|**Ending URN pattern**|**Example** 708 -|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0) 709 -|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111 710 -|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0) 711 -|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0) 712 -|Subscription|((( 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" %)((( 713 713 The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure. 714 - 715 715 The name of the URN is registryURN There is no pre-determined format. 716 -)))|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. 717 -|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD 718 -|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1 719 -|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0) 720 -|**Classname**|**Ending URN pattern**|**Example** 721 -|Transition|((( 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" %)((( 722 722 processAgencyId:processId(version).processStepId. 723 - 724 724 transitionId 725 -)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1 726 -|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267 727 -|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0) 728 -|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0) 729 -|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ 730 -|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA 731 -|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ 732 -|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|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) 733 733 734 734 **Table 3: Table of identification components for SDMX Identifiable Artefacts** 735 735 ... ... @@ -753,62 +753,54 @@ 753 753 754 754 The following table lists the Maintainable Artefacts. 755 755 756 -|(% colspan="2" %)**Maintainable Artefacts**|**Content** 757 -|**Abstract Class**|**Concrete Class**| 758 -|Item Scheme|Codelist|Code 759 -| |Concept Scheme|Concept 760 -| |Category Scheme|Category 761 -| |Organisation Unit Scheme|Organisation Unit 762 -| |Agency Scheme|Agency 763 -| |Data Provider Scheme|Data Provider 764 -| |Metadata Provider Scheme|Metadata Provider 765 -| |Data Consumer Scheme|Data Consumer 766 -| |Reporting Taxonomy|Reporting Category 767 -| |Transformation Scheme|Transformation 768 -| |Custom Type Scheme|Custom Type 769 -| |Name Personalisation Scheme|Name Personalisation 770 -| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping 771 -| |Ruleset Scheme|Ruleset 772 -| |User Defined Operator Scheme|User Defined Operator 773 -|Enumerated List|ValueList|Value Item 774 -|Structure|Data Structure Definition|((( 762 +(% style="width:881.294px" %) 763 +|(% colspan="2" style="width:522px" %)**Maintainable Artefacts**|(% style="width:490px" %)**Content** 764 +|(% style="width:198px" %)**Abstract Class**|(% style="width:324px" %)**Concrete Class**|(% style="width:490px" %) 765 +|(% style="width:198px" %)Item Scheme|(% style="width:324px" %)Codelist|(% style="width:490px" %)Code 766 +|(% style="width:198px" %) |(% style="width:324px" %)Concept Scheme|(% style="width:490px" %)Concept 767 +|(% style="width:198px" %) |(% style="width:324px" %)Category Scheme|(% style="width:490px" %)Category 768 +|(% style="width:198px" %) |(% style="width:324px" %)Organisation Unit Scheme|(% style="width:490px" %)Organisation Unit 769 +|(% style="width:198px" %) |(% style="width:324px" %)Agency Scheme|(% style="width:490px" %)Agency 770 +|(% style="width:198px" %) |(% style="width:324px" %)Data Provider Scheme|(% style="width:490px" %)Data Provider 771 +|(% style="width:198px" %) |(% style="width:324px" %)Metadata Provider Scheme|(% style="width:490px" %)Metadata Provider 772 +|(% style="width:198px" %) |(% style="width:324px" %)Data Consumer Scheme|(% style="width:490px" %)Data Consumer 773 +|(% style="width:198px" %) |(% style="width:324px" %)Reporting Taxonomy|(% style="width:490px" %)Reporting Category 774 +|(% style="width:198px" %) |(% style="width:324px" %)Transformation Scheme|(% style="width:490px" %)Transformation 775 +|(% style="width:198px" %) |(% style="width:324px" %)Custom Type Scheme|(% style="width:490px" %)Custom Type 776 +|(% style="width:198px" %) |(% style="width:324px" %)Name Personalisation Scheme|(% style="width:490px" %)Name Personalisation 777 +|(% style="width:198px" %) |(% style="width:324px" %)Vtl Mapping Scheme|(% style="width:490px" %)Vtl Codelist Mapping Vtl Concept Mapping 778 +|(% style="width:198px" %) |(% style="width:324px" %)Ruleset Scheme|(% style="width:490px" %)Ruleset 779 +|(% style="width:198px" %) |(% style="width:324px" %)User Defined Operator Scheme|(% style="width:490px" %)User Defined Operator 780 +|(% style="width:198px" %)Enumerated List|(% style="width:324px" %)ValueList|(% style="width:490px" %)Value Item 781 +|(% style="width:198px" %)Structure|(% style="width:324px" %)Data Structure Definition|(% style="width:490px" %)((( 775 775 Dimension Descriptor 776 - 777 777 Group Dimension Descriptor 778 - 779 779 Dimension 780 - 781 781 Time Dimension 782 - 783 783 Attribute Descriptor 784 - 785 785 Data Attribute 786 - 787 787 Measure Descriptor 788 - 789 789 Measure 790 790 ))) 791 -| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute 792 -|Structure Usage|Dataflow| 793 -| |Metadataflow| 794 -|None|Process|Process Step 795 -|None|Structure Map|((( 791 +|(% style="width:198px" %) |(% style="width:324px" %)Metadata Structure Definition|(% style="width:490px" %)Metadata Attribute Descriptor Metadata Attribute 792 +|(% style="width:198px" %)Structure Usage|(% style="width:324px" %)Dataflow|(% style="width:490px" %) 793 +|(% style="width:198px" %) |(% style="width:324px" %)Metadataflow|(% style="width:490px" %) 794 +|(% style="width:198px" %)None|(% style="width:324px" %)Process|(% style="width:490px" %)Process Step 795 +|(% style="width:198px" %)None|(% style="width:324px" %)Structure Map|(% style="width:490px" %)((( 796 796 Component Map 797 - 798 798 Epoch Map 799 - 800 800 Date Pattern Map 801 801 ))) 802 -|None|Representation Map|Representation Mapping 803 -|Item Scheme Map|Organisation Scheme Map|Item Map 804 -| |Concept Scheme Map|Item Map 805 -| |Category Scheme Map|Item Map 806 -| |Reporting Taxonomy Map|Item Map 807 -|None|Provision Agreement| 808 -|None|Metadata Provision Agreement| 809 -|None|Hierarchy|Hierarchical Code 810 -|None|Hierarchy Association| 811 -|None|Categorisation| 800 +|(% style="width:198px" %)None|(% style="width:324px" %)Representation Map|(% style="width:490px" %)Representation Mapping 801 +|(% style="width:198px" %)Item Scheme Map|(% style="width:324px" %)Organisation Scheme Map|(% style="width:490px" %)Item Map 802 +|(% style="width:198px" %) |(% style="width:324px" %)Concept Scheme Map|(% style="width:490px" %)Item Map 803 +|(% style="width:198px" %) |(% style="width:324px" %)Category Scheme Map|(% style="width:490px" %)Item Map 804 +|(% style="width:198px" %) |(% style="width:324px" %)Reporting Taxonomy Map|(% style="width:490px" %)Item Map 805 +|(% style="width:198px" %)None|(% style="width:324px" %)Provision Agreement|(% style="width:490px" %) 806 +|(% style="width:198px" %)None|(% style="width:324px" %)Metadata Provision Agreement|(% style="width:490px" %) 807 +|(% style="width:198px" %)None|(% style="width:324px" %)Hierarchy|(% style="width:490px" %)Hierarchical Code 808 +|(% style="width:198px" %)None|(% style="width:324px" %)Hierarchy Association|(% style="width:490px" %) 809 +|(% style="width:198px" %)None|(% style="width:324px" %)Categorisation|(% style="width:490px" %) 812 812 813 813 **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 814 814 ... ... @@ -816,14 +816,11 @@ 816 816 817 817 The artefacts included in the structural definitions are: 818 818 819 -• 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) 817 +* 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) 818 +* All types of Enumerated List (ValueList){{footnote}}Note that Codelist is also an EnumeratedList.{{/footnote}} 819 +* All types of Structure (Data Structure Definition, Metadata Structure Definition) 820 +* All types of Structure Usage (Dataflow, Metadataflow) 820 820 821 -• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^ 822 - 823 -• All types of Structure (Data Structure Definition, Metadata Structure Definition) 824 - 825 -• All types of Structure Usage (Dataflow, Metadataflow) 826 - 827 827 ===== {{id name="_Toc93865"/}}7.1.3 Structure Usage ===== 828 828 829 829 **7.1.3.1 Structure Usage: Basic Concepts** ... ... @@ -852,9 +852,9 @@ 852 852 * Categorisation to Dataflow and Category 853 853 * Categorisation to Metadataflow and Category 854 854 855 -== ={{id name="_Toc93866"/}}7.2 Data and Metadata Provisioning ===850 +== {{id name="_Toc93866"/}}7.2 Data and Metadata Provisioning == 856 856 857 -=== =={{id name="_Toc93867"/}}7.2.1 Provisioning Agreement: Basic concepts =====852 +=== {{id name="_Toc93867"/}}7.2.1 Provisioning Agreement: Basic concepts === 858 858 859 859 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. 860 860 ... ... @@ -862,7 +862,7 @@ 862 862 863 863 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. 864 864 865 -=== =={{id name="_Toc93868"/}}7.2.2 Provisioning Agreement Model – pull use case =====860 +=== {{id name="_Toc93868"/}}7.2.2 Provisioning Agreement Model – pull use case === 866 866 867 867 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. 868 868 ... ... @@ -884,9 +884,9 @@ 884 884 885 885 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. 886 886 887 -== ={{id name="_Toc93869"/}}7.3 Data and Metadata Constraints ===882 +== {{id name="_Toc93869"/}}7.3 Data and Metadata Constraints == 888 888 889 -=== =={{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 === 890 890 891 891 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. 892 892 ... ... @@ -950,17 +950,14 @@ 950 950 951 951 The Registration has an action attribute which takes one of the following values: 952 952 953 -: 954 - 955 955 ((( 956 -|**Action Attribute Value**|**Behaviour** 957 -|Append|Add this Registration to the registry 958 -|Replace|((( 959 -Replace the existing Registration with identified by the id in the 960 - 961 -Registration of the SubmitRegistrationRequest 949 +(% style="width:761.294px" %) 950 +|(% style="width:196px" %)**Action Attribute Value**|(% style="width:561px" %)**Behaviour** 951 +|(% style="width:196px" %)Append|(% style="width:561px" %)Add this Registration to the registry 952 +|(% style="width:196px" %)Replace|(% style="width:561px" %)((( 953 +Replace the existing Registration with identified by the id in the Registration of the SubmitRegistrationRequest 962 962 ))) 963 -|Delete|Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest 955 +|(% style="width:196px" %)Delete|(% style="width:561px" %)Delete the existing Registration identified by the id in the Registration of the SubmitRegistrationRequest 964 964 ))) 965 965 966 966 [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_bc1dcdec.jpg||height="575" width="579"]] ... ... @@ -977,27 +977,20 @@ 977 977 978 978 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. 979 979 980 -: 981 - 982 982 ((( 983 -|**Indexing Required**|**Registration Process Activity** 984 -|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint. 985 -|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. 986 -|indexReportingPeriod|((( 973 +(% style="width:678.294px" %) 974 +|**Indexing Required**|(% style="width:504px" %)**Registration Process Activity** 975 +|indexTimeSeries|(% style="width:504px" %)Extract all the series keys and create a KeySet(s) Constraint. 976 +|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. 977 +|indexReportingPeriod|(% style="width:504px" %)((( 987 987 This applies only to a registered __dataset__. 988 - 989 989 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 990 990 ))) 991 -|**Indexing Required**|**Registration Process Activity** 992 -|indexAttributes|((( 981 +|**Indexing Required**|(% style="width:504px" %)**Registration Process Activity** 982 +|indexAttributes|(% style="width:504px" %)((( 993 993 **Data Set** 994 - 995 -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 996 - 997 -SDMXIM, and the associated Selection Value 998 - 984 +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 999 999 **Metadata Set** 1000 - 1001 1001 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. 1002 1002 ))) 1003 1003 ))) ... ... @@ -1006,7 +1006,7 @@ 1006 1006 1007 1007 The Registration must reference the ProvisionAgreement or MetadataProvisionAgreement to which it relates. 1008 1008 1009 -=== =={{id name="_Toc93876"/}}7.4.3 Registration Response =====994 +=== {{id name="_Toc93876"/}}7.4.3 Registration Response === 1010 1010 1011 1011 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”. 1012 1012 ... ... @@ -1036,20 +1036,18 @@ 1036 1036 1037 1037 Regardless of the type of registry/repository events being observed, a subscription always contains: 1038 1038 1039 -1. Aset 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.1024 +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. 1040 1040 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. 1041 1041 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. 1042 1042 1. A selector which specifies which type of events are of interest. The set of event types is: 1043 1043 1044 -: 1045 -:: 1046 - 1047 1047 ((( 1048 -|**Event Type**|**Comment** 1049 -|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1050 -|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1051 -|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1052 -|ALL_EVENTS|All events of the specified EventType 1030 +(% style="width:856.294px" %) 1031 +|(% style="width:320px" %)**Event Type**|(% style="width:532px" %)**Comment** 1032 +|(% style="width:320px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:532px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1033 +|(% 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. 1034 +|(% 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. 1035 +|(% style="width:320px" %)ALL_EVENTS|(% style="width:532px" %)All events of the specified EventType 1053 1053 ))) 1054 1054 1055 1055 === {{id name="_Toc93880"/}}7.5.3 Wildcard Facility === ... ... @@ -1116,15 +1116,14 @@ 1116 1116 1117 1117 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: 1118 1118 1119 -: 1120 - 1121 1121 ((( 1122 -|**Selector**|**Comment** 1123 -|DataProvider & MetadataProvider|Any datasets or metadata sets registered by the specified data or metadata provider will activate the notification. 1124 -|ProvisionAgreement & MetadataProvisionAgreement|Any datasets or metadata sets registered for the agreement will activate the notification. 1125 -|Dataflow & Metadataflow|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1126 -|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 1127 -|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1103 +(% style="width:1126.29px" %) 1104 +|(% style="width:382px" %)**Selector**|(% style="width:740px" %)**Comment** 1105 +|(% 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. 1106 +|(% style="width:382px" %)ProvisionAgreement & MetadataProvisionAgreement|(% style="width:740px" %)Any datasets or metadata sets registered for the agreement will activate the notification. 1107 +|(% style="width:382px" %)Dataflow & Metadataflow|(% style="width:740px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1108 +|(% 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 1109 +|(% 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. 1128 1128 ))) 1129 1129 1130 1130 The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration. ... ... @@ -1156,12 +1156,6 @@ 1156 1156 1157 1157 The notification will contain the Registration. 1158 1158 1159 - [[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.1141 +---- 1160 1160 1161 -[[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: 1162 - 1163 -IMF.SubAgency1 1164 - 1165 -[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList. 1166 - 1167 1167 {{putFootnotes/}}