Last modified by Helena on 2025/09/10 11:19

From version 9.4
edited by Helena
on 2025/05/23 13:07
Change comment: There is no comment for this version
To version 2.7
edited by Helena
on 2025/05/21 14:27
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -SDMX 2.1 Standards. Section 5. Registry Specification – Logical Interfaces
1 +SDMX 2.1 Standards. Section. 5. Registry Specification – Logical Interfaces
Content
... ... @@ -4,11 +4,10 @@
4 4  
5 5  **Revision History**
6 6  
7 -(% style="width:833.294px" %)
8 -|(% style="width:122px" %)**Revision**|(% style="width:126px" %)**Date**|(% style="width:581px" %)**Contents**
9 -|(% style="width:122px" %) |(% style="width:126px" %)April 2011|(% style="width:581px" %)Initial release
10 -|(% style="width:122px" %)1.0|(% style="width:126px" %)July 2011|(% style="width:581px" %)Rectification of problems of the specifications dated April 2011
11 -|(% style="width:122px" %)2.0|(% style="width:126px" %)July 2020|(% style="width:581px" %)Addition of VTL (Validation and Transformation Language) package, maintainable artefacts, nameable artefacts to 5.2.3, 6.2.2, 6.2.3, 6.2.4, 7.1.1
7 +|**Revision**|**Date**|**Contents**
8 +| |April 2011|Initial release
9 +|1.0|July 2011|Rectification of problems of the specifications dated April 2011
10 +|2.0|July 2020|Addition of VTL (Validation and Transformation Language) package, maintainable artefacts, nameable artefacts to 5.2.3, 6.2.2, 6.2.3, 6.2.4, 7.1.1
12 12  
13 13  **Corrigendum**
14 14  
... ... @@ -289,22 +289,27 @@
289 289  * that a queryable data source exists - this would necessitate the registration service querying the service to determine its existence
290 290  * that a simple data source exists (i.e. a file accessible at a URL)
291 291  * that the correct Data Structure Definition or Metadata Structure Definition is used by the registered data that the components (Dimensions, Attributes, Measures, Identifier Components etc.) are consistent with the Data Structure Definition or Metadata Structure Definition
292 -* that the valid representations of the concepts to which these components correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition
291 +* that the valid representations of the concepts to which these components 382 correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition
293 293  
294 -The Registration has an action attribute which takes one of the following values:
293 +3The Registration has an action attribute which takes one of the following values:
295 295  
296 -|(% style="width:219px" %)**Action Attribute Value**|(% style="width:1652px" %)**Behaviour**
297 -|(% style="width:219px" %)Append|(% style="width:1652px" %)Add this registration to the registry
298 -|(% style="width:219px" %)Replace|(% style="width:1652px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
299 -|(% style="width:219px" %)Delete|(% style="width:1652px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
295 +|(% style="width:249px" %)(((
296 +**Action Attribute Value**
297 +)))|(% style="width:1622px" %)**Behaviour**
298 +|(% style="width:249px" %)Append|(% style="width:1622px" %)Add this registration to the registry
299 +|(% style="width:249px" %)Replace|(% style="width:1622px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
300 +|(% style="width:249px" %)Delete|(% style="width:1622px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
300 300  
301 301  The Registration has three Boolean attributes which may be present to determine how an SDMX compliant Dataset or Metadata Set indexing application must index the Datasets or Metadata Set upon registration. The indexing application behaviour is as follows:
302 302  
303 -|(% style="width:228px" %)**Boolean Attribute**|(% style="width:1644px" %)**Behaviour if Value is “true”**
304 -|(% style="width:228px" %)indexTimeSeries|(% style="width:1644px" %)A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration)
305 -|(% style="width:228px" %)indexDataSet|(% style="width:1644px" %)A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value.
304 +|**Boolean Attribute**|**Behaviour if Value is “true”**
305 +|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadata Set registration)
306 +|indexDataSet|(((
307 +A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset (for a Dataset registration) or the range of actual (present) values for each Metadata Attribute which takes an enumerated value.
308 +
306 306  Note that for data this requires much less storage than full key indexing, but this method cannot guarantee that a specific combination of Dimension values (the Key) is actually present in the Dataset
307 -|(% style="width:228px" %)indexReportingPeriod|(% style="width:1644px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
310 +)))
311 +|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset or Metadata Set
308 308  
309 309  === 5.2.5 Data and Reference Metadata Discovery ===
310 310  
... ... @@ -326,7 +326,7 @@
326 326  Subscription management involves a user submitting a subscription request which contains:
327 327  
328 328  * 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).
329 -* a list of URIs or end-points to which an XML notification message can be sent. Supported end-point types will be email (mailto : ) and HTTP POST (a normal http:~/~/ address)
333 +* a list of URIs or end-points to which an XML notification message can be sent. Supported end-point types will be email (mailto~:) and HTTP POST (a normal http:~/~/ address)
330 330  * request for a list of submitted subscriptions
331 331  * deletion of a subscription
332 332  
... ... @@ -336,8 +336,8 @@
336 336  
337 337  The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages.
338 338  
339 -|(% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour**
340 -|(% style="width:227px" %)All|(% style="width:1644px" %)(((
343 +|(% style="width:244px" %)**Interface**|**Behaviour**
344 +|(% style="width:244px" %)All|(((
341 341  1) If the action is set to “replace” then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted, unless the final attribute is set to “true” in which case the only changes that are allowed are to the following constructs:
342 342  
343 343  * Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list.
... ... @@ -351,6 +351,7 @@
351 351  * isExternalReference
352 352  
353 353  2) Cross referenced structures MUST exist in either the submitted document (in Structures or Structure Location) or in the registry to which the request is submitted.
358 +
354 354  3) If the action is set to “delete” then the Registry MUST verify that the object can deleted. In order to qualify for deletion the object must:
355 355  
356 356  а) Not have the final attribute set to “true”
... ... @@ -357,11 +357,12 @@
357 357  b) Not be referenced from any other object in the Registry.
358 358  
359 359  4) The version rules in the SDMX Schema documentation MUST be obeyed.
365 +
360 360  5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed.
361 361  )))
362 -|(% style="width:227px" %)SubmitStructureRequest|(% style="width:1644px" %)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.
363 -|(% style="width:227px" %)SubmitProvisioningRequest|(% style="width:1644px" %)No additional behaviour.
364 -|(% style="width:227px" %)Submit Registration Request|(% style="width:1644px" %)(((
368 +|(% style="width:244px" %)SubmitStructureRequest|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.
369 +|(% style="width:244px" %)SubmitProvisioningRequest|No additional behaviour.
370 +|(% style="width:244px" %)Submit Registration Request|(((
365 365  If the datasource is a file (simple datasource) then the file MAY be retrieved and indexed according to the Boolean attributes set in the Registration.
366 366  For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query.
367 367  )))
... ... @@ -427,8 +427,6 @@
427 427  
428 428  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.
429 429  
430 -[[image:1747994320263-112.png]]
431 -
432 432  **Figure 6: Agency Scheme Model**
433 433  
434 434  The Agency in SDMX is extremely important. The Agency Id system used in SDMX is an n-level structure. The top level of this structure is maintained by SDMX. Any Agency in this top level can declare sub agencies and any sub agency can also declare sub agencies. The Agency Scheme has a fixed id and version and is never declared explicitly in the SDMX object identification mechanism.
... ... @@ -450,7 +450,7 @@
450 450  
451 451  [[image:1747824123012-527.jpeg]]
452 452  
453 -**Figure 7: Example of Hierarchic Structure of Agencies**
457 +==== Figure 7: Example of Hierarchic Structure of Agencies ====
454 454  
455 455  The following organizations maintain an Agency Scheme.
456 456  
... ... @@ -465,8 +465,9 @@
465 465  
466 466  An example of this is shown in the XML snippet below.
467 467  
468 -[[image:1747832400104-286.png]]
472 +[[image:1747824123013-196.jpeg||height="309" width="446"]]
469 469  
474 +(% class="wikigeneratedid" id="HFigure8:ExampleShowingUseofAgencyIdentifiers" %)
470 470  **Figure 8: Example Showing Use of Agency Identifiers**
471 471  
472 472  Each of these maintenance agencies has an identical Code list with the Id CL_BOP. However, each is uniquely identified by means of the hierarchic agency structure.
... ... @@ -479,14 +479,13 @@
479 479  
480 480  ==== 6.2.2.2 URN Structure ====
481 481  
482 -(% class="wikigeneratedid" id="HCaseRulesforURN" %)
483 -//Case Rules for URN//
487 +===== //Case Rules for URN// =====
484 484  
485 485  For the URN, all parts of the string are case sensitive. The Id of any object must be UPPER CASE. Therefore, CRED_ext_Debt is invalid and it should be CRED_EXT_DEBT.
486 486  
487 487  The generic structure of the URN is as follows:
488 488  
489 ->SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
493 +SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id
490 490  
491 491  ~* this can repeat and may not be present (see explanation below)
492 492  
... ... @@ -498,7 +498,7 @@
498 498  
499 499  In the explanation below the actual object that is the target of the URN is called the **//actual object//**.
500 500  
501 -**SDMXPrefix:** urn:sdmx:org.
505 +**SDMXPrefix:** urn:sdmx:org.                                     
502 502  
503 503  **SDMX-IM package name:** sdmx.infomodel.package=
504 504  
... ... @@ -581,92 +581,91 @@
581 581  
582 582  The table below lists all of the packages in the SDMX-IM together with the concrete classes that are in these packages and whose objects have a URN.
583 583  
584 -(% style="width:644.294px" %)
585 -|(% style="width:127px" %)**Package**|(% style="width:494px" %)(((
588 +|(% style="width:127px" %)**Package**|(% style="width:1745px" %)(((
586 586  **URN Classname (model classname where this is different)**
587 587  )))
588 -|(% style="width:127px" %)base|(% style="width:494px" %)Agency
589 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationUnitScheme
590 -|(% style="width:127px" %) |(% style="width:494px" %)AgencyScheme
591 -|(% style="width:127px" %) |(% style="width:494px" %)DataProviderScheme
592 -|(% style="width:127px" %) |(% style="width:494px" %)DataConsumerScheme
593 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationUnit
594 -|(% style="width:127px" %) |(% style="width:494px" %)DataProvider
595 -|(% style="width:127px" %) |(% style="width:494px" %)DataConsumer
596 -|(% style="width:127px" %)datastructure|(% style="width:494px" %)DataStructure (DataStructureDefinition)
597 -|(% style="width:127px" %) |(% style="width:494px" %)AttributeDescriptor
598 -|(% style="width:127px" %) |(% style="width:494px" %)DataAttribute
599 -|(% style="width:127px" %) |(% style="width:494px" %)GroupDimensionDescriptor
600 -|(% style="width:127px" %) |(% style="width:494px" %)DimensionDescriptor
601 -|(% style="width:127px" %) |(% style="width:494px" %)Dimension
602 -|(% style="width:127px" %) |(% style="width:494px" %)MeasureDimension
603 -|(% style="width:127px" %) |(% style="width:494px" %)TimeDimension
604 -|(% style="width:127px" %) |(% style="width:494px" %)MeasureDescriptor
605 -|(% style="width:127px" %) |(% style="width:494px" %)PrimaryMeasure
606 -|(% style="width:127px" %) |(% style="width:494px" %)Dataflow (DataflowDefinition)
607 -|(% style="width:127px" %)metadatastructure|(% style="width:494px" %)MetadataTarget
608 -|(% style="width:127px" %) |(% style="width:494px" %)DimensionDescriptorValueTarget
609 -|(% style="width:127px" %) |(% style="width:494px" %)IdentifiableObjectTarget
610 -|(% style="width:127px" %) |(% style="width:494px" %)ReportPeriodTarget
611 -|(% style="width:127px" %) |(% style="width:494px" %)DataSetTarget
612 -|(% style="width:127px" %) |(% style="width:494px" %)ReportStructure
613 -|(% style="width:127px" %) |(% style="width:494px" %)MetadataAttribute
614 -|(% style="width:127px" %) |(% style="width:494px" %)(((
591 +|(% style="width:127px" %)base|(% style="width:45px" %)Agency
592 +|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme
593 +|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme
594 +|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme
595 +|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme
596 +|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit
597 +|(% style="width:127px" %) |(% style="width:45px" %)DataProvider
598 +|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer
599 +|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition)
600 +|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor
601 +|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute
602 +|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor
603 +|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor
604 +|(% style="width:127px" %) |(% style="width:45px" %)Dimension
605 +|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension
606 +|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension
607 +|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor
608 +|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure
609 +|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition)
610 +|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget
611 +|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget
612 +|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget
613 +|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget
614 +|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget
615 +|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure
616 +|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute
617 +|(% style="width:127px" %) |(% style="width:45px" %)(((
615 615  MetadataStructure
616 616  
617 617  (MetadataStructureDefinition)
618 618  )))
619 -|(% style="width:127px" %) |(% style="width:494px" %)Metadataflow (MetadataflowDefinition)
620 -|(% style="width:127px" %)process|(% style="width:494px" %)Process
621 -|(% style="width:127px" %) |(% style="width:494px" %)ProcessStep
622 -|(% style="width:127px" %) |(% style="width:494px" %)Transition
623 -|(% style="width:127px" %)registry|(% style="width:494px" %)ProvisionAgreement
624 -|(% style="width:127px" %) |(% style="width:494px" %)AttachmentConstraint
625 -|(% style="width:127px" %) |(% style="width:494px" %)ContentConstraint
626 -|(% style="width:127px" %) |(% style="width:494px" %)Subscription
627 -|(% style="width:127px" %)mapping|(% style="width:494px" %)StructureMap
628 -|(% style="width:127px" %) |(% style="width:494px" %)StructureSet
629 -|(% style="width:127px" %) |(% style="width:494px" %)ComponentMap
630 -|(% style="width:127px" %) |(% style="width:494px" %)ConceptSchemeMap
631 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationSchemeMap
632 -|(% style="width:127px" %) |(% style="width:494px" %)CodelistMap
633 -|(% style="width:127px" %) |(% style="width:494px" %)CategorySchemeMap
634 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingTaxonomyMap
635 -|(% style="width:127px" %) |(% style="width:494px" %)ConceptMap
636 -|(% style="width:127px" %) |(% style="width:494px" %)OrganisationMap
637 -|(% style="width:127px" %) |(% style="width:494px" %)CodeMap
638 -|(% style="width:127px" %) |(% style="width:494px" %)HybridCodelistMap
639 -|(% style="width:127px" %) |(% style="width:494px" %)CategoryMap
640 -|(% style="width:127px" %) |(% style="width:494px" %)HybridCodeMap
641 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingCategoryMap
642 -|(% style="width:127px" %)codelist|(% style="width:494px" %)Codelist
643 -|(% style="width:127px" %) |(% style="width:494px" %)HierarchicalCodelist
644 -|(% style="width:127px" %) |(% style="width:494px" %)Hierarchy
645 -|(% style="width:127px" %) |(% style="width:494px" %)Hierarchy
646 -|(% style="width:127px" %) |(% style="width:494px" %)Code
647 -|(% style="width:127px" %) |(% style="width:494px" %)HierarchicalCode
648 -|(% style="width:127px" %) |(% style="width:494px" %)Level
649 -|(% style="width:127px" %)categoryscheme|(% style="width:494px" %)CategoryScheme
650 -|(% style="width:127px" %) |(% style="width:494px" %)Category
651 -|(% style="width:127px" %) |(% style="width:494px" %)Categorisation
652 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingTaxonomy
653 -|(% style="width:127px" %) |(% style="width:494px" %)ReportingCategory
654 -|(% style="width:127px" %)conceptscheme|(% style="width:494px" %)ConceptScheme
655 -|(% style="width:127px" %) |(% style="width:494px" %)Concept
656 -|(% style="width:127px" %)transformation|(% style="width:494px" %)TransformationScheme
657 -|(% style="width:127px" %) |(% style="width:494px" %)Transformation
658 -|(% style="width:127px" %) |(% style="width:494px" %)CustomTypeScheme
659 -|(% style="width:127px" %) |(% style="width:494px" %)CustomType
660 -|(% style="width:127px" %) |(% style="width:494px" %)NamePersonalisationScheme
661 -|(% style="width:127px" %) |(% style="width:494px" %)NamePersonalisation
662 -|(% style="width:127px" %) |(% style="width:494px" %)VtlCodelistMapping
663 -|(% style="width:127px" %) |(% style="width:494px" %)VtlConceptMapping
664 -|(% style="width:127px" %) |(% style="width:494px" %)VtlDataflowMapping
665 -|(% style="width:127px" %) |(% style="width:494px" %)VtlConceptSchemeMapping
666 -|(% style="width:127px" %) |(% style="width:494px" %)RulesetScheme
667 -|(% style="width:127px" %) |(% style="width:494px" %)Ruleset
668 -|(% style="width:127px" %) |(% style="width:494px" %)UserDefinedOperatorScheme
669 -|(% style="width:127px" %) |(% style="width:494px" %)UserDefinedOperator
622 +|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition)
623 +|(% style="width:127px" %)process|(% style="width:45px" %)Process
624 +|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep
625 +|(% style="width:127px" %) |(% style="width:45px" %)Transition
626 +|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement
627 +|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint
628 +|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint
629 +|(% style="width:127px" %) |(% style="width:45px" %)Subscription
630 +|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap
631 +|(% style="width:127px" %) |(% style="width:45px" %)StructureSet
632 +|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap
633 +|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap
634 +|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap
635 +|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap
636 +|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap
637 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap
638 +|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap
639 +|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap
640 +|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap
641 +|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap
642 +|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap
643 +|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap
644 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap
645 +|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist
646 +|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist
647 +|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
648 +|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy
649 +|(% style="width:127px" %) |(% style="width:1745px" %)Code
650 +|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode
651 +|(% style="width:127px" %) |(% style="width:1745px" %)Level
652 +|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme
653 +|(% style="width:127px" %) |(% style="width:1745px" %)Category
654 +|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation
655 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy
656 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory
657 +|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme
658 +|(% style="width:127px" %) |(% style="width:1745px" %)Concept
659 +|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme
660 +|(% style="width:127px" %) |(% style="width:1745px" %)Transformation
661 +|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme
662 +|(% style="width:127px" %) |(% style="width:1745px" %)CustomType
663 +|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme
664 +|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation
665 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping
666 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping
667 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping
668 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping
669 +|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme
670 +|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset
671 +|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme
672 +|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator
670 670  
671 671  **Table 2: SDMX-IM Packages and Contained Classes**
672 672  
... ... @@ -680,49 +680,75 @@
680 680  
681 681  > urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
682 682  
683 -(% style="width:1277.29px" %)
684 -|(% style="width:269px" %)**SDMX Class**|(% style="width:453px" %)**Key attribute(s)**|(% style="width:550px" %)**Example of URN**
685 -|(% style="width:269px" %)Agency|(% style="width:453px" %)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:550px" %)(((
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.|(((
686 686  IMF
689 +
690 +
687 687  Sub agency in the IMF AGENCIES
692 +
693 +
688 688  IMF.SubAgency1
689 689  )))
690 -|(% style="width:269px" %)*ConceptScheme|(% style="width:453px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:550px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0)
691 -|(% style="width:269px" %)Concept|(% style="width:453px" %)conceptSchemeAgencyId:
692 -conceptSchemeId(version).conceptId|(% style="width:550px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ
693 -|(% style="width:269px" %)*Codelist|(% style="width:453px" %)codeListAgencyId:codeListId(version)|(% style="width:550px" %)SDMX:CL_FREQ(1.0)
694 -|(% style="width:269px" %)Code|(% style="width:453px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:550px" %)SDMX:CL_FREQ(1.0).Q
695 -|(% style="width:269px" %)(((
696 -*Hierarchical Codelist
697 -)))|(% style="width:453px" %)hierachicalCodelistAgencyId:
698 -hierarchicalCodelistId(version)|(% style="width:550px" %)(((
699 -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 +
700 700  )))
701 -|(% style="width:269px" %)Hierarchy|(% style="width:453px" %)(((
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|(((
702 702  hierachicalcodeListAgencyId:
722 +
703 703  hierarchicalcodelistId(version).Hierarchy
704 -)))|(% style="width:550px" %)UNESCO:CL_EXP_SOURCE(1.0).
705 -H-C-GOV
706 -|(% style="width:269px" %)Level|(% style="width:453px" %)(((
724 +)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV
725 +|Level|(((
707 707  hierachicalcodeListAgencyId:
727 +
708 708  hierarchicalcodelistId(version).Hierarchy.Level
709 -)))|(% style="width:550px" %)(((
729 +)))|(((
710 710  ESTAT:HCL_REGION(1.0).H_1.COUNTRY
731 +
732 +
711 711  )))
712 -|(% style="width:269px" %)HierarchicalCode|(% style="width:453px" %)hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|(% style="width:550px" %)UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1
713 -|(% style="width:269px" %)*DataStructure|(% style="width:453px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:550px" %)TFFS:EXT_DEBT(1.0)
714 -|(% style="width:269px" %)(((
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 +|(((
715 715  Dimension
738 +
716 716  Descriptor
740 +
717 717  Measure
742 +
718 718  Descriptor
744 +
719 719  Attribute
746 +
720 720  Descriptor
721 -)))|(% style="width:453px" %)(((
748 +)))|(((
722 722  dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
750 +
723 723  componentListId
752 +
724 724  where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
725 -)))|(% style="width:550px" %)(((
754 +)))|(((
726 726  TFFS:EXT_DEBT(1.0).DimensionDescriptor
727 727  
728 728  TFFS:EXT_DEBT(1.0).MeasureDescriptor
... ... @@ -729,209 +729,289 @@
729 729  
730 730  TFFS:EXT_DEBT(1.0).AttributeDescriptor
731 731  )))
732 -|(% style="width:269px" %)(((
761 +|(((
733 733  GroupDimension
763 +
734 734  Descriptor
735 -)))|(% style="width:453px" %)(((
765 +)))|(((
736 736  dataStructureDefinitionAgencyId: dataStructureDefinitionId(version).
767 +
737 737  groupDimensionDescriptorId
738 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).SIBLING
739 -|(% style="width:269px" %)Dimension|(% style="width:453px" %)(((
769 +)))|TFFS:EXT_DEBT(1.0).SIBLING
770 +|Dimension|(((
740 740  dataStructureDefinitionAgencyId: dataStructureDefinition (version).
772 +
741 741  dimensionId
742 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).FREQ
743 -|(% style="width:269px" %)TimeDimension|(% style="width:453px" %)(((
774 +)))|TFFS:EXT_DEBT(1.0).FREQ
775 +|TimeDimension|(((
744 744  dataStructureDefinitionAgencyId: dataStructureDefinition (version).
777 +
745 745  timeDimensionId
746 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD
747 -|(% style="width:269px" %)Measure Dimension|(% style="width:453px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version).
748 -measureDimensionId|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW
749 -|(% style="width:269px" %)DataAttrribute|(% style="width:453px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS
750 -|(% style="width:269px" %)PrimaryMeasure|(% style="width:453px" %)(((
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|(((
751 751  dataStructureDefinitionAgencyId: dataStructureDefinition (version).
788 +
752 752  primaryMeasureId
753 -)))|(% style="width:550px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE
754 -|(% style="width:269px" %)(((
755 -*Category Scheme
756 -)))|(% style="width:453px" %)categorySchemeAgencyId:
757 -categorySchemeId(version)|(% style="width:550px" %)IMF:SDDS(1.0)
758 -|(% style="width:269px" %)Category|(% style="width:453px" %)categorySchemeAgencyId:
759 -categorySchemeId(version).
760 -categoryId.categoryId categoryId.categoryId etc.|(% style="width:550px" %)(((
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.|(((
761 761  IMF:SDDS(1.0):
798 +
762 762  level_1_category.level_2_category …
763 763  )))
764 -|(% style="width:269px" %)(((
765 -*Reporting Taxonomy
766 -)))|(% style="width:453px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:550px" %) IMF:REP_1(1.0)
767 -|(% style="width:269px" %)ReportingCategory|(% style="width:453px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:550px" %)(((
801 +|(((
802 +*Reporting
803 +
804 +Taxonomy
805 +)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0)
806 +|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(((
768 768  IMF:REP_1(1.0):
808 +
769 769  level_1_repcategory.level_2_repcategory …
770 770  )))
771 -|(% style="width:269px" %)*Categorisation|(% style="width:453px" %)categorisationAgencyId: categorisationId(version)|(% style="width:550px" %)IMF:cat001(1.0)
772 -|(% style="width:269px" %)(((
773 -*Organisation Unit Scheme
774 -)))|(% style="width:453px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:550px" %)ECB:ORGANISATIONS(1.0)
775 -|(% style="width:269px" %)Organisation Unit|(% style="width:453px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:550px" %)ECB:ORGANISATIONS(1.0).1F
776 -|(% style="width:269px" %)*AgencyScheme|(% style="width:453px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:550px" %)ECB:AGENCIES(1.0)
811 +|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0)
812 +|(((
813 +*Organisation
777 777  
778 -(% style="width:1274.29px" %)
779 -|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:535px" %)ECB:AGENCY(1.0).AA
780 -|(% style="width:262px" %)(((
781 -*DataProvider Scheme
782 -)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:535px" %)SDMX:DATA_PROVIDERS(1.0)
783 -|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:535px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1
784 -|(% style="width:262px" %)(((
785 -*DataConsumer Scheme
786 -)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:535px" %)SDMX:DATA_CONSUMERS(1.0)
787 -|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:535px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1
788 -|(% style="width:262px" %)(((
789 -*Metadata Structure
790 -)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:535px" %)IMF:SDDS_MSD(1.0)
791 -|(% 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|(((
792 792  MSDAgencyId:
842 +
793 793  MSDId(version).metadataTargetId
794 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY
795 -|(% style="width:262px" %)(((
844 +)))|IMF:SDDS_MSD(1.0).AGENCY
845 +|(((
796 796  Dimension
847 +
797 797  DescriptorValues
849 +
798 798  Target
799 -)))|(% style="width:369px" %)(((
851 +)))|(((
800 800  MSDAgencyId: MSDId(version).
853 +
801 801  metadataTargetId.keyDescriptorValueTargetId
802 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY
803 -|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)(((
804 -MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId
805 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT
806 -|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)(((
855 +)))|IMF:SDDS_MSD(1.0).AGENCY.KEY
856 +|Identifiable ObjectTarget|(((
807 807  MSDAgencyId:
808 -MSDId(version).metadataTargetId.dataSetTargetId
809 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101
810 -|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)(((
811 -MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId
812 -)))|(% style="width:535px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER
813 813  
814 -(% style="width:1277.29px" %)
815 -|(% style="width:270px" %)(((
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 +|(((
816 816  ReportStructure
817 -)))|(% style="width:454px" %)(((
818 -MSDAgencyId: MSDId(version).reportStructureId
819 -)))|(% style="width:549px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT
820 -|(% style="width:270px" %)(((
821 -Metadata Attribute
822 -)))|(% style="width:454px" %)(((
823 -MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID
824 -)))|(% style="width:549px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION
825 -|(% style="width:270px" %)*Dataflow|(% style="width:454px" %)dataflowAgencyId: dataflowId(version)|(% style="width:549px" %)TFFS:CRED_EXT_DEBT(1.0)
826 -|(% style="width:270px" %)*Provision Agreement|(% style="width:454px" %)(((
882 +
883 +
884 +)))|(((
885 +MSDAgencyId:
886 +
887 +MSDId(version).reportStructureId
888 +)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT
889 +|(((
890 +Metadata
891 +
892 +Attribute
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|(((
827 827  provisionAgreementAgencyId:provisionAgreem entId(version)
828 -)))|(% style="width:549px" %)(((
901 +
902 +
903 +)))|(((
829 829  TFFS:CRED_EXT_DEBT_AB(1.0)
905 +
906 +
907 +
830 830  )))
831 -|(% style="width:270px" %)(((
832 -*Content Constraint
833 -)))|(% style="width:454px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:549px" %)TFFS:CREDITOR_DATA_CONTENT(1.0)
834 -|(% style="width:270px" %)(((
835 -*Attachment Constraint
836 -)))|(% style="width:454px" %)(((
909 +|(((
910 +*Content
911 +
912 +Constraint
913 +)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0)
914 +|(((
915 +*Attachment
916 +
917 +Constraint
918 +)))|(((
837 837  constraintAgencyId:
838 838  
839 839  attachmentConstraintId(version)
840 -)))|(% style="width:549px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)
841 -|(% style="width:270px" %)*Metadataflow|(% style="width:454px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:549px" %)IMF:SDDS_FLOW(1.0)
842 -|(% style="width:270px" %)*StructureSet|(% style="width:454px" %)structureSetAgencyId: structureSetId(version)|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0)
843 -|(% style="width:270px" %)StructureMap|(% style="width:454px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2
844 -|(% style="width:270px" %)Component Map|(% style="width:454px" %)(((
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|(((
845 845  structureSetAgencyId: structureSetId(version).
846 846  
847 847  structureMapId. componentMapId
848 -)))|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY
849 -|(% style="width:270px" %)CodelistMap|(% style="width:454px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY
850 -|(% style="width:270px" %)CodeMap|(% style="width:454px" %)structureSetAgencyId: structureSetId(version).
930 +)))|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
933 +
934 +
935 +
936 +| |(((
851 851  codeListMapId.
852 -codeMapId|(% style="width:549px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER
853 853  
854 -(% style="width:1279.29px" %)
855 -|(% style="width:271px" %)(((
856 -CategorySchemeMap
857 -)))|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). categorySchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT
858 -|(% style="width:271px" %)CategoryMap|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_MAP
859 -|(% style="width:271px" %)Organisation SchemeMap|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). organisationSchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP
860 -|(% style="width:271px" %)Organisation Map|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). organisationSchemeMapId. organisationMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP.IMF_1C0
861 -|(% style="width:271px" %)(((
939 +codeMapId
940 +)))|
941 +|(((
942 +Category
943 +
944 +SchemeMap
945 +)))|structureSetAgencyId: structureSetId(version). categorySchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT
946 +|CategoryMap|structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_M AP
947 +|Organisation SchemeMap|structureSetAgencyId: structureSetId(version). organisationSchemeMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP
948 +|Organisation Map|structureSetAgencyId: structureSetId(version). organisationSchemeMapId. organisationMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP.IMF_1C0
949 +|(((
862 862  Concept
863 863  
864 864  SchemeMap
865 -)))|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). conceptSchemeMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_OECD
866 -|(% style="width:271px" %)ConceptMap|(% style="width:453px" %)(((
953 +)))|structureSetAgencyId: structureSetId(version). conceptSchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD
954 +|ConceptMap|(((
867 867  structureSetAgencyId: structureSetId(version). conceptSchemeMapId.
956 +
868 868  conceptMapId
869 -)))|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY
870 -|(% style="width:271px" %)(((
871 -ReportingTaxonomyMap
872 -)))|(% style="width:453px" %)structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).TAXMAP
873 -|(% style="width:271px" %)(((
874 -ReportingCategoryMap
875 -)))|(% style="width:453px" %)(((
958 +
959 +
960 +)))|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY
961 +|(((
962 +Reporting
963 +
964 +TaxonomyMap
965 +)))|structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|SDMX:BOP_STRUCTURES(1.0).TAXMAP
966 +|(((
967 +Reporting
968 +
969 +CategoryMap
970 +)))|(((
876 876  structureSetAgencyId: structureSetId(version).
972 +
877 877  reportngCategoryId
878 -)))|(% style="width:551px" %)SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT
974 +)))|SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT
879 879  
880 -(% style="width:1282.29px" %)
881 -|(% style="width:272px" %)(((
882 -HybridCodelistMap
883 -)))|(% style="width:450px" %)structureSetAgencyId: structureSetId(version).
884 -hybridCodelistMapId.|(% style="width:557px" %)SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP
885 -|(% style="width:272px" %)HybridCodeMap|(% style="width:450px" %)structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|(% style="width:557px" %)SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1
886 -|(% style="width:272px" %)*Process|(% style="width:450px" %)processAgencyId: processId{version]|(% style="width:557px" %)BIS:PROCESS1(1.0)
887 -|(% style="width:272px" %)ProcessStep|(% style="width:450px" %)(((
976 +
977 +
978 +|(((
979 +HybridCodelist
980 +
981 +Map
982 +)))|structureSetAgencyId: structureSetId(version). hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP
983 +|HybridCodeMap|structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1
984 +|*Process|processAgencyId: processId{version]|BIS:PROCESS1(1.0)
985 +|ProcessStep|(((
888 888  processAgencyId: processId(version).
987 +
889 889  processStepId
890 -)))|(% style="width:557px" %)BIS:PROCESS1(1.0).STEP1
891 -|(% style="width:272px" %)Transition|(% style="width:450px" %)(((
989 +)))|BIS:PROCESS1(1.0).STEP1
990 +|Transition|(((
892 892  processAgencyId: processId(version).
992 +
893 893  processStepId transitionId
894 -)))|(% style="width:557px" %)BIS:PROCESS1(1.0).STEP1.TRANSITION1
895 -|(% style="width:272px" %)Subscription|(% style="width:450px" %)The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure, The name of the URN is registryURN There is no pre-determined format.|(% style="width:557px" %)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 registryURN that is returned from the registry in the subscription response message.
896 -|(% style="width:272px" %)(((
897 -*Transformation Scheme
898 -)))|(% style="width:450px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:557px" %)ECB: TRANSFORMATION_SCHEME(1.0)
899 -|(% style="width:272px" %)Transformation|(% style="width:450px" %)(((
994 +)))|BIS:PROCESS1(1.0).STEP1.TRANSITION1
995 +|Subscription|The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure, The name of the URN is registryURN There is no pre-determined format.|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 registryURN that is returned from the registry in the subscription response message.
996 +|(((
997 +*Transformation
998 +
999 +Scheme
1000 +)))|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0)
1001 +|Transformation|(((
900 900  transformationSchemeAgencyId transformationSchemeId(version)
1003 +
901 901  transformationId
902 -)))|(% style="width:557px" %)ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1
903 -|(% style="width:272px" %)CustomType Scheme|(% style="width:450px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:557px" %)ECB:CUSTOM_TYPE_SCHEME(1.0)
1005 +)))|ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1
1006 +|CustomType Scheme|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0)
904 904  
905 -(% style="width:1281.29px" %)
906 -|(% style="width:275px" %)CustomType|(% style="width:450px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:552px" %)ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1
907 -|(% style="width:275px" %)(((
1008 +
1009 +
1010 +|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1
1011 +|(((
908 908  Name
1013 +
909 909  Personalisation
1015 +
910 910  Scheme
911 -)))|(% style="width:450px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:552px" %)ECB:PSN_SCHEME(1.0)
912 -|(% style="width:275px" %)(((
1017 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0)
1018 +|(((
913 913  Name
1020 +
914 914  Personalisation
915 -)))|(% style="width:450px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)
916 -namePersonalisationId|(% style="width:552px" %)ECB:PSN_SCHEME(1.0).PSN1234
917 -|(% style="width:275px" %)VtlMapping Scheme|(% style="width:450px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:552px" %)ECB:CLIST_MP(2.0)
918 -|(% style="width:275px" %)VtlCodelist Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:552px" %)ECB:CLIST_MP(2.0).ABZ
919 -|(% style="width:275px" %)VtlConcept Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:552px" %)ECB:CLIST_MP(1.0).XYA
920 -|(% style="width:275px" %)VtlDataflow Mapping|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:552px" %)ECB:CLIST_MP(1.0).MOQ
921 -|(% style="width:275px" %)(((
1022 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234
1023 +|VtlMapping Scheme|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0)
1024 +|VtlCodelist Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0).ABZ
1025 +|VtlConcept Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0).XYA
1026 +|VtlDataflow Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0).MOQ
1027 +|(((
922 922  VtlConcept
923 923  
924 924  SchemeMapping
925 -)))|(% style="width:450px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptSchemeId|(% style="width:552px" %)ECB:CLIST_MP(1.0).Z11
926 -|(% style="width:275px" %)RulesetScheme|(% style="width:450px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:552px" %)ECB:RULESET_23(1.0)
927 -|(% style="width:275px" %)Ruleset|(% style="width:450px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:552px" %)ECB:RULESET_23(1.0).SET111
928 -|(% style="width:275px" %)(((
929 -UserDefinedOperatorScheme
930 -)))|(% style="width:450px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:552px" %)ECB:OS_CALC(1.2)
931 -|(% style="width:275px" %)UserDefined Operator|(% style="width:450px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:552px" %)ECB:OS_CALC(1.2).OS267
1031 +)))|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptSchemeId|ECB:CLIST_MP(1.0).Z11
1032 +|RulesetScheme|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0)
1033 +|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0).SET111
1034 +|(((
1035 +UserDefined
932 932  
933 -**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1037 +OperatorScheme
1038 +)))|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2)
1039 +|UserDefined Operator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2).OS267
934 934  
1041 +7**Table 3: Table of identification components for SDMX Identifiable Artefacts**
1042 +
1043 +
935 935  = 7 Implementation Notes =
936 936  
937 937  == 7.1 Structural Definition Metadata ==
... ... @@ -952,72 +952,109 @@
952 952  
953 953  The following table lists the Maintainable Artefacts.
954 954  
955 -(% style="width:640.294px" %)
956 -|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content**
957 -|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %)
958 -|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code
959 -|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept
960 -|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category
961 -|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit
962 -|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency
963 -|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider
964 -|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer
965 -|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category
966 -|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation
967 -|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type
968 -|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation
969 -|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping
970 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping
971 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping
972 -|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset
973 -|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator
974 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator
975 -|(% 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" %)(((
976 976  Dimension Descriptor
1092 +
977 977  Group Dimension
1094 +
978 978  Descriptor
1096 +
979 979  Dimension
1098 +
980 980  Measure Dimension
1100 +
981 981  Time Dimension
1102 +
982 982  Attribute Descriptor
1104 +
983 983  Data Attribute
1106 +
984 984  Measure Descriptor
1108 +
985 985  Primary Measure
986 986  )))
987 -|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)(((
988 -Metadata Target, Dimension Descriptor
1111 +| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)(((
1112 +Metadata Target,
1113 +
1114 +Dimension Descriptor
1115 +
989 989  Values Target Identifiable
1117 +
990 990  Object Target
1119 +
991 991  Report Period Target
1121 +
992 992  Data SetTarget
1123 +
993 993  Report Structure
1125 +
994 994  Metadata Attribute
995 995  )))
996 -|(% style="width:171px" %)Structure Usage|(% style="width:232px" %)Dataflow Definition|(% style="width:206px" %)
997 -|(% style="width:171px" %) |(% style="width:232px" %)Metadataflow Definition|(% style="width:206px" %)
998 -|(% style="width:171px" %)None|(% style="width:232px" %)Process|(% style="width:206px" %)Process Step
999 -|(% 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" %)(((
1000 1000  Component Map
1133 +
1001 1001  Concept Scheme Map
1135 +
1002 1002  Codelist Map
1137 +
1003 1003  Category Scheme Map
1139 +
1004 1004  Reporting Taxonomy Map
1141 +
1005 1005  Organisation Scheme Map
1143 +
1006 1006  Concept Map
1145 +
1007 1007  Code Map
1147 +
1008 1008  Category Map
1149 +
1009 1009  Organisation Map
1151 +
1010 1010  Reporting Category Map
1153 +
1011 1011  Hybrid Codelist Map
1155 +
1012 1012  Hybrid Code Map
1013 1013  )))
1014 -|(% style="width:171px" %)None|(% style="width:232px" %)Provision Agreement|(% style="width:206px" %)
1015 -|(% 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" %)(((
1016 1016  Hierarchy
1161 +
1017 1017  Hierarchical Code
1018 1018  )))
1164 +| | | | | | |
1019 1019  
1020 -**able 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1166 +**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
1021 1021  
1022 1022  === 7.1.2 Item Scheme, Structure ===
1023 1023  
... ... @@ -1024,7 +1024,10 @@
1024 1024  The artefacts included in the structural definitions are:
1025 1025  
1026 1026  * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme)
1027 -* All types of Structure (Data Structure Definition, Metadata Structure Definition)
1173 +* All types of Structure (Data Structure Definition, Metadata Structure
1174 +
1175 +Definition)
1176 +
1028 1028  * All types of Structure Usage (Dataflow Definition, Metadataflow Definition)
1029 1029  
1030 1030  === 7.1.3 Structure Usage ===
... ... @@ -1043,8 +1043,6 @@
1043 1043  
1044 1044  ==== 7.1.3.3 Structure Usage Model ====
1045 1045  
1046 -[[image:1747829078194-749.png]]
1047 -
1048 1048  **Figure 10: SDMX-IM of links from Structure Usage to Category**
1049 1049  
1050 1050  In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry:
... ... @@ -1071,10 +1071,10 @@
1071 1071  
1072 1072  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.
1073 1073  
1074 -[[image:1747829109466-595.png]]
1075 1075  
1076 1076  **Figure 11: SDMX-IM of the Data Provider**
1077 1077  
1224 +
1078 1078  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
1079 1079  
1080 1080  [[image:1747824123019-181.jpeg]]
... ... @@ -1083,10 +1083,8 @@
1083 1083  
1084 1084  The diagram below is a logical representation of the data required in order to maintain Provision Agreements.
1085 1085  
1086 -[[image:1747829139951-378.png]]
1087 1087  
1088 -(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %)
1089 -**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 ====
1090 1090  
1091 1091  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.
1092 1092  
... ... @@ -1114,12 +1114,13 @@
1114 1114  
1115 1115  === 7.3.3 Data and Metadata Constraints: Model ===
1116 1116  
1117 -[[image:1747829204737-370.png]]
1118 1118  
1119 -**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts**
1120 1120  
1121 -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.
1264 +==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ====
1122 1122  
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 +
1123 1123  The content of the Constraint can be found in the SDMX Information Model document.
1124 1124  
1125 1125  == 7.4 Data and Metadata Registration ==
... ... @@ -1140,7 +1140,7 @@
1140 1140  
1141 1141  [[image:1747824123025-411.jpeg]]
1142 1142  
1143 -**Figure 16: Schematic of the Objects Concerned with Registration**
1289 + **Figure 16: Schematic of the Objects Concerned with Registration**
1144 1144  
1145 1145  ==== 7.4.2.2 Registration Request Model ====
1146 1146  
... ... @@ -1154,14 +1154,11 @@
1154 1154  
1155 1155  The Registration has an action attribute which takes one of the following values:
1156 1156  
1157 -(% style="width:970.294px" %)
1158 -|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour**
1159 -|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry
1160 -|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request
1161 -|(% 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
1162 1162  
1163 -[[image:1747829290890-122.png]]
1164 -
1165 1165  **Figure 17: Logical Class Diagram of Registration of Data and Metadata**
1166 1166  
1167 1167  The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query
... ... @@ -1176,19 +1176,25 @@
1176 1176  
1177 1177  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.
1178 1178  
1179 -|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity**
1180 -|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint.
1181 -|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)(((
1182 -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.
1183 1183  )))
1184 -|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((
1329 +|indexReportingPeriod|(((
1185 1185  This applies only to a registered dataset.
1331 +
1186 1186  Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint.
1187 1187  )))
1188 -|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((
1334 +|indexAttributes|(((
1189 1189  **Data Set**
1336 +
1190 1190  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 +
1191 1191  **Metadata Set**
1340 +
1192 1192  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.
1193 1193  )))
1194 1194  
... ... @@ -1198,13 +1198,14 @@
1198 1198  
1199 1199  === 7.4.3 Registration Response ===
1200 1200  
1201 -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
1202 1202  
1352 +“Success”, “Warning” or “Failure”.
1353 +
1203 1203  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.
1204 1204  
1205 1205  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:
1206 1206  
1207 -[[image:1747829477882-750.png]]
1208 1208  
1209 1209  **Figure 18: Logical class diagram showing the registration response**
1210 1210  
... ... @@ -1214,12 +1214,15 @@
1214 1214  
1215 1215  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.
1216 1216  
1217 -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
1218 1218  
1219 -=== 7.5.1Subscription Logical Class Diagram ===
1369 +notification”.
1220 1220  
1221 -[[image:1747829554603-150.png]]
1371 + 7.5.1Subscription Logical Class Diagram
1222 1222  
1373 +
1374 +[[image:1747824123028-257.png]]
1375 +
1223 1223  **Figure 19: Logical Class Diagram of the Subscription**
1224 1224  
1225 1225  === 7.5.2 Subscription Information ===
... ... @@ -1226,58 +1226,73 @@
1226 1226  
1227 1227  Regardless of the type of registry/repository events being observed, a subscription always contains:
1228 1228  
1229 -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.
1230 -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.
1231 -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.
1232 -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.
1233 1233  
1234 -|(% style="width:319px" %)**Event Type**|(% style="width:1553px" %)**Comment**
1235 -|(% style="width:319px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1553px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository.
1236 -|(% style="width:319px" %)DATA_REGISTRATION_EVENTS|(% style="width:1553px" %)Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database.
1237 -|(% style="width:319px" %)METADATA_REGISTRATION_EVENTS|(% style="width:1553px" %)Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database.
1238 -|(% style="width:319px" %)ALL_EVENTS|(% style="width:1553px" %)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.
1239 1239  
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 +
1240 1240  === 7.5.3 Wildcard Facility ===
1241 1241  
1242 1242  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:
1243 1243  
1244 -* agencyID
1245 -* id
1246 -* version
1400 + agencyID
1247 1247  
1402 + id
1403 +
1404 + version
1405 +
1248 1248  Examples of wildcarded identifier components for an identified object type of Codelist are shown below.
1249 1249  
1250 -//AgencyID = %
1408 +AgencyID = %
1409 +
1251 1251  Id = %
1252 -Version = %//
1253 1253  
1412 +Version = %
1413 +
1254 1254  This subscribes to all Codelists of all versions for all agencies.
1255 1255  
1256 -//AgencyID = AGENCY1
1416 +AgencyID = AGENCY1
1417 +
1257 1257  Id = CODELIST1
1258 -Version = %//
1259 1259  
1420 +Version = %
1421 +
1260 1260  This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1261 1261  
1262 -//AGENCY1
1424 +AGENCY1
1425 +
1263 1263  AgencyID = AGENCY1
1427 +
1264 1264  Id = %
1265 -Version = %//
1266 1266  
1430 +Version = %
1431 +
1267 1267  This subscribes to all versions of all Codelist objects maintained by the agency
1268 1268  
1269 -//AGENCY1
1434 +AGENCY1
1435 +
1270 1270  AgencyID = %
1437 +
1271 1271  Id = CODELIST1
1272 -Version = %//
1273 1273  
1440 +Version = %
1441 +
1274 1274  This subscribes to all versions of Codelist CODELIST1 maintained by the agency
1275 1275  
1276 -//AGENCY1//
1444 +AGENCY1
1277 1277  
1278 1278  Note that if the subscription is to the latest version then this can be achieved by the * character
1279 1279  
1280 -//i.e. Version = *//
1448 +i.e. Version = *
1281 1281  
1282 1282  Note that a subscription using the URN mechanism cannot use wildcard characters.
1283 1283  
... ... @@ -1289,15 +1289,16 @@
1289 1289  
1290 1290  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:
1291 1291  
1292 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
1293 -|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification.
1294 -|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification.
1295 -|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1296 -|(% style="width:405px" %)DataStructureDefinition & MetadataStructureDefinition|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1297 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment**
1298 -|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification.
1299 -|(% style="width:405px" %)Category|(% style="width:1467px" %)Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1300 1300  
1461 +|**Selector**|**Comment**
1462 +|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification.
1463 +|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification.
1464 +|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification.
1465 +|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will
1466 +|**Selector**|**Comment**
1467 +| |activate the notification.
1468 +|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category.
1469 +
1301 1301  The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration.
1302 1302  
1303 1303  == 7.6 Notification ==
... ... @@ -1304,10 +1304,8 @@
1304 1304  
1305 1305  === 7.6.1 Logical Class Diagram ===
1306 1306  
1307 -[[image:1747829675568-610.png]]
1308 1308  
1309 -(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %)
1310 -**Figure 20: Logical Class Diagram of the Notification**
1477 +==== Figure 20: Logical Class Diagram of the Notification ====
1311 1311  
1312 1312  A notification is an XML document that is sent to a user via email or http POST whenever a subscription is activated. It is an asynchronous one-way message.
1313 1313  
... ... @@ -1327,3 +1327,5 @@
1327 1327  === 7.6.3 Registration Event Component ===
1328 1328  
1329 1329  The notification will contain the Registration.
1497 +
1498 +
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
1747829675568-610.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -31.1 KB
Content
1747832400104-286.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -172.3 KB
Content
1747994320263-112.png
Author
... ... @@ -1,1 +1,0 @@
1 -xwiki:XWiki.helena
Size
... ... @@ -1,1 +1,0 @@
1 -13.9 KB
Content