Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (0 modified, 0 added, 7 removed)
Details
- Page properties
-
- Content
-
... ... @@ -683,50 +683,75 @@ 683 683 684 684 > urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 685 685 686 -(% style="width:1091.29px" %) 687 -|(% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN** 688 -|(% style="width:250px" %)Agency|(% style="width:444px" %)The URN for an Agency is shown later in this table. 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.|(% style="width:396px" %)((( 686 +|**SDMX Class**|**Key attribute(s)**|**Example of URN** 687 +|Agency|The URN for an Agency is shown later in this table. 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.|((( 689 689 IMF 689 + 690 + 690 690 Sub agency in the IMF AGENCIES 692 + 693 + 691 691 IMF.SubAgency1 692 692 ))) 693 -|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 694 -|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId: 695 -conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 696 -|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0) 697 -|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q 698 -|(% style="width:250px" %)((( 699 -*Hierarchical Codelist 700 -)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)((( 701 -UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %)) 696 +|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 697 +|Concept|((( 698 +conceptSchemeAgencyId: 699 + 700 +conceptSchemeId(version).conceptId 701 +)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 702 +|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0) 703 +|Code|codeListAgencyId:codelistId(version).codeId|((( 704 +SDMX:CL_FREQ(1.0).Q 705 + 706 + 702 702 ))) 703 -|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)((( 708 + 709 + 710 + 711 +|((( 712 +*Hierarchical 713 + 714 +Codelist 715 +)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|((( 716 +UNESCO:CL_EXP_SOURCE(1.0) 717 + 718 + 719 +))) 720 +|Hierarchy|((( 704 704 hierachicalcodeListAgencyId: 722 + 705 705 hierarchicalcodelistId(version).Hierarchy 706 -)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). 707 -H-C-GOV 708 -|(% style="width:250px" %)Level|(% style="width:444px" %)((( 724 +)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV 725 +|Level|((( 709 709 hierachicalcodeListAgencyId: 727 + 710 710 hierarchicalcodelistId(version).Hierarchy.Level 711 -)))|( % style="width:396px" %)(((729 +)))|((( 712 712 ESTAT:HCL_REGION(1.0).H_1.COUNTRY 713 713 714 714 715 715 ))) 716 -| (% style="width:250px" %)HierarchicalCode|(% style="width:444px" %)hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1717 -| (% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0)718 -|( % style="width:250px" %)(((734 +|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1 735 +|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0) 736 +|((( 719 719 Dimension 738 + 720 720 Descriptor 740 + 721 721 Measure 742 + 722 722 Descriptor 744 + 723 723 Attribute 746 + 724 724 Descriptor 725 -)))|( % style="width:444px" %)(((748 +)))|((( 726 726 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 750 + 727 727 componentListId 752 + 728 728 where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition) 729 -)))|( % style="width:396px" %)(((754 +)))|((( 730 730 TFFS:EXT_DEBT(1.0).DimensionDescriptor 731 731 732 732 TFFS:EXT_DEBT(1.0).MeasureDescriptor ... ... @@ -733,132 +733,181 @@ 733 733 734 734 TFFS:EXT_DEBT(1.0).AttributeDescriptor 735 735 ))) 736 -|( % style="width:250px" %)(((761 +|((( 737 737 GroupDimension 763 + 738 738 Descriptor 739 -)))|( % style="width:444px" %)(((765 +)))|((( 740 740 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 767 + 741 741 groupDimensionDescriptorId 742 -)))| (% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING743 -| (% style="width:250px" %)Dimension|(% style="width:444px" %)(((769 +)))|TFFS:EXT_DEBT(1.0).SIBLING 770 +|Dimension|((( 744 744 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 772 + 745 745 dimensionId 746 -)))| (% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ747 -| (% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((774 +)))|TFFS:EXT_DEBT(1.0).FREQ 775 +|TimeDimension|((( 748 748 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 777 + 749 749 timeDimensionId 750 -)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD 751 -|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). 752 -measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW 753 -|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS 754 -|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)((( 779 +)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD 780 +|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW 781 + 782 + 783 + 784 +| |measureDimensionId| 785 +|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS 786 +|PrimaryMeasure|((( 755 755 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 788 + 756 756 primaryMeasureId 757 -)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE 758 -|(% style="width:250px" %)((( 759 -*Category Scheme 760 -)))|(% style="width:444px" %)categorySchemeAgencyId: 761 -categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0) 762 -|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId: 763 -categorySchemeId(version). 764 -categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)((( 790 +)))|TFFS:EXT_DEBT(1.0).OBS_VALUE 791 +|((( 792 +*Category 793 + 794 +Scheme 795 +)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0) 796 +|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|((( 765 765 IMF:SDDS(1.0): 798 + 766 766 level_1_category.level_2_category … 767 767 ))) 768 -|(% style="width:250px" %)((( 769 -*Reporting Taxonomy 770 -)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0) 771 -|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)((( 801 +|((( 802 +*Reporting 803 + 804 +Taxonomy 805 +)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0) 806 +|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|((( 772 772 IMF:REP_1(1.0): 808 + 773 773 level_1_repcategory.level_2_repcategory … 774 774 ))) 775 -|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0) 776 -|(% style="width:250px" %)((( 777 -*Organisation Unit Scheme 778 -)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0) 779 -|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F 780 -|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0) 811 +|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0) 812 +|((( 813 +*Organisation 781 781 782 -|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA 783 -|(% style="width:262px" %)((( 784 -*DataProvider Scheme 785 -)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0) 786 -|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 787 -|(% style="width:262px" %)((( 788 -*DataConsumer Scheme 789 -)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0) 790 -|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 791 -|(% style="width:262px" %)((( 792 -*Metadata Structure 793 -)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0) 794 -|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)((( 815 +Unit Scheme 816 +)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0) 817 +|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F 818 +|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0) 819 + 820 + 821 + 822 +|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA 823 +|((( 824 +*DataProvider 825 + 826 +Scheme 827 +)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0) 828 +|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 829 +|((( 830 +*DataConsumer 831 + 832 +Scheme 833 +)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0) 834 +|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 835 +|((( 836 +*Metadata 837 + 838 +Structure 839 +)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0) 840 +|MetadataTarget|((( 795 795 MSDAgencyId: 842 + 796 796 MSDId(version).metadataTargetId 797 -)))| (% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY798 -|( % style="width:262px" %)(((844 +)))|IMF:SDDS_MSD(1.0).AGENCY 845 +|((( 799 799 Dimension 847 + 800 800 DescriptorValues 849 + 801 801 Target 802 -)))|( % style="width:369px" %)(((851 +)))|((( 803 803 MSDAgencyId: MSDId(version). 853 + 804 804 metadataTargetId.keyDescriptorValueTargetId 805 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY 806 -|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)((( 807 -MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId 808 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 809 -|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)((( 855 +)))|IMF:SDDS_MSD(1.0).AGENCY.KEY 856 +|Identifiable ObjectTarget|((( 810 810 MSDAgencyId: 811 -MSDId(version).metadataTargetId.dataSetTargetId 812 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101 813 -|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)((( 814 -MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId 815 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER 816 816 817 -|(% style="width:251px" %)((( 859 +MSDId(version).metadataTargetId.identifiable 860 + 861 +ObjectTargetId 862 +)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 863 +|DataSetTarget|((( 864 +MSDAgencyId: 865 + 866 +MSDId(version).metadataTargetId.dataSet 867 + 868 +TargetId 869 +)))|IMF:SDDS_MSD(1.0).AGENCY.D1101 870 +|PeportPeriod Target|((( 871 +MSDAgencyId: 872 + 873 +MSDId(version).metadataTargetId.reportPeriod 874 + 875 +TargetId 876 +)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER 877 + 878 + 879 + 880 +|((( 818 818 ReportStructure 819 819 820 820 821 -)))|(% style="width:442px" %)((( 822 -MSDAgencyId: MSDId(version).reportStructureId 823 -)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT 824 -|(% style="width:251px" %)((( 884 +)))|((( 885 +MSDAgencyId: 886 + 887 +MSDId(version).reportStructureId 888 +)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT 889 +|((( 825 825 Metadata 826 826 827 827 Attribute 828 -)))|(% style="width:442px" %)((( 829 -MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID 830 -)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 831 -|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0) 832 -|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)((( 893 +)))|((( 894 +MSDAgencyId: 895 + 896 +MSDId(version).reportStructureId.metadataattri buteID 897 +)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 898 +|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0) 899 +|*Provision Agreement|((( 833 833 provisionAgreementAgencyId:provisionAgreem entId(version) 834 -)))|(% style="width:1178px" %)((( 901 + 902 + 903 +)))|((( 835 835 TFFS:CRED_EXT_DEBT_AB(1.0) 905 + 906 + 907 + 836 836 ))) 837 -|( % style="width:251px" %)(((909 +|((( 838 838 *Content 839 839 840 840 Constraint 841 -)))| (% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)842 -|( % style="width:251px" %)(((913 +)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0) 914 +|((( 843 843 *Attachment 844 844 845 845 Constraint 846 -)))|( % style="width:442px" %)(((918 +)))|((( 847 847 constraintAgencyId: 848 848 849 849 attachmentConstraintId(version) 850 -)))| (% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)851 -| (% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0)852 -| (% style="width:251px" %)*StructureSet|(%style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0)853 -| (% style="width:251px" %)StructureMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2854 -| (% style="width:251px" %)Component Map|(% style="width:442px" %)(((922 +)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0) 923 +|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0) 924 +|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0) 925 +|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2 926 +|Component Map|((( 855 855 structureSetAgencyId: structureSetId(version). 856 856 857 857 structureMapId. componentMapId 858 -)))| (% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY859 -| (% style="width:251px" %)CodelistMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY860 -| (% style="width:251px" %)CodeMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER930 +)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY 931 +|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY 932 +|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER 861 861 934 + 935 + 862 862 | |((( 863 863 codeListMapId. 864 864 ... ... @@ -966,6 +966,7 @@ 966 966 967 967 7**Table 3: Table of identification components for SDMX Identifiable Artefacts** 968 968 1043 + 969 969 = 7 Implementation Notes = 970 970 971 971 == 7.1 Structural Definition Metadata == ... ... @@ -986,72 +986,109 @@ 986 986 987 987 The following table lists the Maintainable Artefacts. 988 988 989 -(% style="width:640.294px" %) 990 -|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content** 991 -|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %) 992 -|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code 993 -|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept 994 -|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category 995 -|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit 996 -|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency 997 -|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider 998 -|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer 999 -|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category 1000 -|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation 1001 -|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type 1002 -|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation 1003 -|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping 1004 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping 1005 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping 1006 -|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset 1007 -|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator 1008 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator 1009 -|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)((( 1064 +|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**| 1065 +|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) | 1066 +|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code| 1067 +|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept| 1068 +|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category| 1069 +|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit| 1070 +|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency| 1071 +|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider| 1072 +|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer| 1073 +|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category| 1074 +|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation| 1075 +|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type| 1076 +| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content** 1077 +| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) 1078 +| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation 1079 +| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping 1080 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping 1081 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping 1082 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)((( 1083 +Vtl Concept Scheme 1084 + 1085 +Mapping 1086 +))) 1087 +| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset 1088 +| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator 1089 +| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %) 1090 +| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)((( 1010 1010 Dimension Descriptor 1092 + 1011 1011 Group Dimension 1094 + 1012 1012 Descriptor 1096 + 1013 1013 Dimension 1098 + 1014 1014 Measure Dimension 1100 + 1015 1015 Time Dimension 1102 + 1016 1016 Attribute Descriptor 1104 + 1017 1017 Data Attribute 1106 + 1018 1018 Measure Descriptor 1108 + 1019 1019 Primary Measure 1020 1020 ))) 1021 -|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)((( 1022 -Metadata Target, Dimension Descriptor 1111 +| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)((( 1112 +Metadata Target, 1113 + 1114 +Dimension Descriptor 1115 + 1023 1023 Values Target Identifiable 1117 + 1024 1024 Object Target 1119 + 1025 1025 Report Period Target 1121 + 1026 1026 Data SetTarget 1123 + 1027 1027 Report Structure 1125 + 1028 1028 Metadata Attribute 1029 1029 ))) 1030 -|(% style="width:171px" %)Structure Usage|(%style="width:232px" %)Dataflow Definition|(%style="width:206px" %)1031 -|(% style="width:171px" %) |(%style="width:232px" %)Metadataflow Definition|(%style="width:206px" %)1032 -|(% style="width:171px" %)None|(%style="width:232px" %)Process|(%style="width:206px" %)Process Step1033 -|(% style="width:171px" %)None|(%style="width:232px" %)Structure Set|(%style="width:206px" %)(((1128 +| |(% colspan="2" %)Structure Usage|(% colspan="2" %)Dataflow Definition|(% colspan="2" %) 1129 +| |(% colspan="2" %) |(% colspan="2" %)Metadataflow Definition|(% colspan="2" %) 1130 +| |(% colspan="2" %)None|(% colspan="2" %)Process|(% colspan="2" %)Process Step 1131 +| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)((( 1034 1034 Component Map 1133 + 1035 1035 Concept Scheme Map 1135 + 1036 1036 Codelist Map 1137 + 1037 1037 Category Scheme Map 1139 + 1038 1038 Reporting Taxonomy Map 1141 + 1039 1039 Organisation Scheme Map 1143 + 1040 1040 Concept Map 1145 + 1041 1041 Code Map 1147 + 1042 1042 Category Map 1149 + 1043 1043 Organisation Map 1151 + 1044 1044 Reporting Category Map 1153 + 1045 1045 Hybrid Codelist Map 1155 + 1046 1046 Hybrid Code Map 1047 1047 ))) 1048 -|(% style="width:171px" %)None|(%style="width:232px" %)Provision Agreement|(%style="width:206px" %)1049 -|(% style="width:171px" %)None|(%style="width:232px" %)Hierarchical Codelist|(%style="width:206px" %)(((1158 +| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %) 1159 +| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)((( 1050 1050 Hierarchy 1161 + 1051 1051 Hierarchical Code 1052 1052 ))) 1164 +| | | | | | | 1053 1053 1054 -**able 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1166 +**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1055 1055 1056 1056 === 7.1.2 Item Scheme, Structure === 1057 1057 ... ... @@ -1058,7 +1058,10 @@ 1058 1058 The artefacts included in the structural definitions are: 1059 1059 1060 1060 * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme) 1061 -* All types of Structure (Data Structure Definition, Metadata Structure Definition) 1173 +* All types of Structure (Data Structure Definition, Metadata Structure 1174 + 1175 +Definition) 1176 + 1062 1062 * All types of Structure Usage (Dataflow Definition, Metadataflow Definition) 1063 1063 1064 1064 === 7.1.3 Structure Usage === ... ... @@ -1077,8 +1077,6 @@ 1077 1077 1078 1078 ==== 7.1.3.3 Structure Usage Model ==== 1079 1079 1080 -[[image:1747829078194-749.png]] 1081 - 1082 1082 **Figure 10: SDMX-IM of links from Structure Usage to Category** 1083 1083 1084 1084 In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry: ... ... @@ -1105,10 +1105,10 @@ 1105 1105 1106 1106 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. 1107 1107 1108 -[[image:1747829109466-595.png]] 1109 1109 1110 1110 **Figure 11: SDMX-IM of the Data Provider** 1111 1111 1224 + 1112 1112 Note that the Data Provider does not inherit the hierarchy association. The diagram below shows a logical schematic of the data model classes required to maintain provision agreements 1113 1113 1114 1114 [[image:1747824123019-181.jpeg]] ... ... @@ -1117,10 +1117,8 @@ 1117 1117 1118 1118 The diagram below is a logical representation of the data required in order to maintain Provision Agreements. 1119 1119 1120 -[[image:1747829139951-378.png]] 1121 1121 1122 -(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %) 1123 -**Figure 13: Logical class diagram of the information contained in the Provision Agreement** 1234 +==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ==== 1124 1124 1125 1125 A Provision Agreement is structural metadata. Each Provision Agreement must reference a Data Provider and a Dataflow or Metadataflow Definition. The Data Provider and the Dataflow/Metadataflow Definition must exist already in order to set up a Provision Agreement. 1126 1126 ... ... @@ -1148,12 +1148,13 @@ 1148 1148 1149 1149 === 7.3.3 Data and Metadata Constraints: Model === 1150 1150 1151 -[[image:1747829204737-370.png]] 1152 1152 1153 -**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts** 1154 1154 1155 - The class diagramaboveshows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement,DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasourceare all concrete sub-classes of ConstrainableArtefactandcan thereforehave Constraints specified. Note that the actual Constraint as submitted is associatedtothe reference classes which inherit from ConstrainableRef:theseare usedto refer to the classes to whichthe Constraintapplies.1264 +==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ==== 1156 1156 1266 +The class diagram above shows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement, DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasource are all concrete sub-classes of ConstrainableArtefact and can therefore have Constraints specified. Note that the actual Constraint as submitted is associated to the reference classes which inherit from ConstrainableRef: these are used to refer to the classes to which the Constraint applies. 1267 + 1268 + 1157 1157 The content of the Constraint can be found in the SDMX Information Model document. 1158 1158 1159 1159 == 7.4 Data and Metadata Registration == ... ... @@ -1188,14 +1188,11 @@ 1188 1188 1189 1189 The Registration has an action attribute which takes one of the following values: 1190 1190 1191 -(% style="width:970.294px" %) 1192 -|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour** 1193 -|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry 1194 -|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1195 -|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1303 +|**Action Attribute Value**|**Behaviour** 1304 +|Append|Add this Registration to the registry 1305 +|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1306 +|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1196 1196 1197 -[[image:1747829290890-122.png]] 1198 - 1199 1199 **Figure 17: Logical Class Diagram of Registration of Data and Metadata** 1200 1200 1201 1201 The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query ... ... @@ -1210,19 +1210,25 @@ 1210 1210 1211 1211 Information in the data or metadata set is extracted and placed in one or more Content Constraints (see the Constraints 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 Provision Agreement as shown in the table below. 1212 1212 1213 -|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity** 1214 -|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint. 1215 -|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)((( 1216 -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. 1322 +|**Indexing Required**|**Registration Process Activity** 1323 +|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint. 1324 +|indexDataSet|((( 1325 +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 1326 + 1327 +Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 1217 1217 ))) 1218 -| (% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((1329 +|indexReportingPeriod|((( 1219 1219 This applies only to a registered dataset. 1331 + 1220 1220 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 1221 1221 ))) 1222 -| (% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((1334 +|indexAttributes|((( 1223 1223 **Data Set** 1336 + 1224 1224 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 1338 + 1225 1225 **Metadata Set** 1340 + 1226 1226 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. 1227 1227 ))) 1228 1228 ... ... @@ -1232,13 +1232,14 @@ 1232 1232 1233 1233 === 7.4.3 Registration Response === 1234 1234 1235 -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 Submit Registration class has a status field which is either set to “Success”, “Warning” or “Failure”.1350 +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 Submit Registration class has a status field which is either set to 1236 1236 1352 +“Success”, “Warning” or “Failure”. 1353 + 1237 1237 If the registration has succeeded, a Registration will be returned - this holds the Registry-allocated Id of the newly registered Datasource plus a Datasource holding the URL to access the dataset, metadataset, or query service. 1238 1238 1239 1239 The Registration Response returns set of registration status (one for each registration submitted) in terms of a Status Message (this is common to all Registry Responses) that indicates success or failure. In the event of registration failure, a set of Message Text are returned, giving the error messages that occurred during registration. It is entirely possible when registering a batch of datasets, that the response will contain some successful and some failed statuses. The logical model for the Registration Response is shown below: 1240 1240 1241 -[[image:1747829477882-750.png]] 1242 1242 1243 1243 **Figure 18: Logical class diagram showing the registration response** 1244 1244 ... ... @@ -1248,12 +1248,15 @@ 1248 1248 1249 1249 A user can submit a subscription in the registry that defines which events are of interest, and either an email and/or an HTTP address to which a notification of qualifying events will be delivered. The subscription will be identified in the registry by a URN which is returned to the user when the subscription is created. If the user wants to delete the subscription at a later point, the subscription URN is used as identification. Subscriptions have a validity period expressed as a date range (startDate, endDate) and the registry may delete any expired subscriptions, and will notify the subscriber on expiry. 1250 1250 1251 -When a registry/repository artefact is modified, any subscriptions which are observing the object are activated, and either an email or HTTP POST is instigated to report details of the changes to the user specified in the subscription. This is called a “notification”.1367 +When a registry/repository artefact is modified, any subscriptions which are observing the object are activated, and either an email or HTTP POST is instigated to report details of the changes to the user specified in the subscription. This is called a 1252 1252 1253 - === 7.5.1SubscriptionLogical Class Diagram ===1369 +“notification”. 1254 1254 1255 - [[image:1747829554603-150.png]]1371 + 7.5.1Subscription Logical Class Diagram 1256 1256 1373 + 1374 +[[image:1747824123028-257.png]] 1375 + 1257 1257 **Figure 19: Logical Class Diagram of the Subscription** 1258 1258 1259 1259 === 7.5.2 Subscription Information === ... ... @@ -1260,25 +1260,30 @@ 1260 1260 1261 1261 Regardless of the type of registry/repository events being observed, a subscription always contains: 1262 1262 1263 -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. 1264 -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. 1265 -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. 1266 -1. A selector which specifies which type of events are of interest. The set of event types is: 1382 +~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. 1267 1267 1268 -|(% style="width:327px" %)**Event Type**|(% style="width:1545px" %)**Comment** 1269 -|(% style="width:327px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1545px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1270 -|(% style="width:327px" %)DATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1271 -|(% style="width:327px" %)METADATA_REGISTRATION_EVENTS|(% style="width:1545px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1272 -|(% style="width:327px" %)ALL_EVENTS|(% style="width:1545px" %)All events of the specified EventType 1384 +2. 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. 1273 1273 1386 +3. 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. 1387 + 1388 +4. A selector which specifies which type of events are of interest. The set of event types is: 1389 + 1390 +|**Event Type**|**Comment** 1391 +|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1392 +|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1393 +|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1394 +|ALL_EVENTS|All events of the specified EventType 1395 + 1274 1274 === 7.5.3 Wildcard Facility === 1275 1275 1276 1276 Subscription notification supports wildcarded identifier components URNs, which are identiiers which have some or all of their component parts replaced by the wildcard character `%`. Identifier components comprise: 1277 1277 1278 -* agencyID 1279 -* id 1280 -* version 1400 + agencyID 1281 1281 1402 + id 1403 + 1404 + version 1405 + 1282 1282 Examples of wildcarded identifier components for an identified object type of Codelist are shown below. 1283 1283 1284 1284 AgencyID = %
- 1747829078194-749.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -40.4 KB - Content
- 1747829109466-595.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -30.4 KB - Content
- 1747829139951-378.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -21.1 KB - Content
- 1747829204737-370.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -55.8 KB - Content
- 1747829290890-122.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -41.4 KB - Content
- 1747829477882-750.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -24.6 KB - Content
- 1747829554603-150.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -99.1 KB - Content