Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Attachments (0 modified, 9 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -4,10 +4,11 @@ 4 4 5 5 **Revision History** 6 6 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 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 11 11 12 12 **Corrigendum** 13 13 ... ... @@ -288,27 +288,22 @@ 288 288 * that a queryable data source exists - this would necessitate the registration service querying the service to determine its existence 289 289 * that a simple data source exists (i.e. a file accessible at a URL) 290 290 * 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 291 -* that the valid representations of the concepts to which these components382correspond conform to the definition in the Data Structure Definition or Metadata Structure Definition292 +* 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 292 292 293 - 3The Registration has an action attribute which takes one of the following values:294 +The Registration has an action attribute which takes one of the following values: 294 294 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 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 301 301 302 302 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: 303 303 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 - 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. 309 309 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 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 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 312 312 313 313 === 5.2.5 Data and Reference Metadata Discovery === 314 314 ... ... @@ -330,7 +330,7 @@ 330 330 Subscription management involves a user submitting a subscription request which contains: 331 331 332 332 * 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). 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)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) 334 334 * request for a list of submitted subscriptions 335 335 * deletion of a subscription 336 336 ... ... @@ -340,8 +340,8 @@ 340 340 341 341 The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages. 342 342 343 -|(% style="width: 143px" %)**Interface**|(% style="width:1729px" %)**Behaviour**344 -|(% style="width: 143px" %)All|(% style="width:1729px" %)(((339 +|(% style="width:227px" %)**Interface**|(% style="width:1644px" %)**Behaviour** 340 +|(% style="width:227px" %)All|(% style="width:1644px" %)((( 345 345 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: 346 346 347 347 * Name – this applies to the Maintainable object and its contained elements, such a Code in a Code list. ... ... @@ -355,7 +355,6 @@ 355 355 * isExternalReference 356 356 357 357 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 - 359 359 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: 360 360 361 361 а) Not have the final attribute set to “true” ... ... @@ -362,19 +362,15 @@ 362 362 b) Not be referenced from any other object in the Registry. 363 363 364 364 4) The version rules in the SDMX Schema documentation MUST be obeyed. 365 - 366 366 5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed. 367 367 ))) 368 -|(% style="width: 143px" %)SubmitStructureRequest|(% style="width:1729px" %)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: 143px" %)SubmitProvisioningRequest|(% style="width:1729px" %)No additional behaviour.370 -|(% style="width: 143px" %)Submit Registration Request|(% style="width:1729px" %)(((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" %)((( 371 371 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. 372 - 373 373 For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query. 374 374 ))) 375 375 376 - 377 - 378 378 = 6 Identification of SDMX Objects = 379 379 380 380 == 6.1 Identification, Versioning, and Maintenance == ... ... @@ -381,7 +381,6 @@ 381 381 382 382 All major classes of the SDMX Information model inherit from one of: 383 383 384 - 385 385 * **IdentifiableArtefact** - this gives an object the ability to be uniquely identified (see following section on identification), to have a user-defined URI, and to have multi-lingual annotations. 386 386 * **NamableArtefact **- this has all of the features of IdentifiableArtefact plus the ability to have a multi-lingual name and description, 387 387 * **VersionableArtefact **– this has all of the above features plus a version number and a validity period. ... ... @@ -389,6 +389,8 @@ 389 389 390 390 === 6.1.1 Identification, Naming, Versioning, and Maintenance Model === 391 391 382 +[[image:1747824504225-229.png]] 383 + 392 392 **Figure 5: Class diagram of fundamental artefacts in the SDMX-IM** 393 393 394 394 The table below shows the identification and related data attributes to be stored in a registry for objects that are one of: ... ... @@ -399,38 +399,34 @@ 399 399 * Versionable 400 400 * Maintainable 401 401 402 -|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes** 403 -|Annotable|AnnotationTitle|C|string| 404 -| |AnnotationType|C|string| 405 -| |AnnotationURN|C|string| 406 -| |((( 407 -AnnotationText in the form of 394 +(% style="width:935.294px" %) 395 +|**Object Type**|(% style="width:244px" %)**Data Attributes**|(% style="width:99px" %)**Status**|**Data type**|(% style="width:389px" %)**Notes** 396 +|Annotable|(% style="width:244px" %)AnnotationTitle|(% style="width:99px" %)C|string|(% style="width:389px" %) 397 +| |(% style="width:244px" %)AnnotationType|(% style="width:99px" %)C|string|(% style="width:389px" %) 398 +| |(% style="width:244px" %)AnnotationURN|(% style="width:99px" %)C|string|(% style="width:389px" %) 399 +| |(% style="width:244px" %)((( 400 +AnnotationText in the form of International String 401 +)))|(% style="width:99px" %)C| |(% style="width:389px" %)This can have languagespecific variants. 402 +|Identifiable|(% style="width:244px" %)all content as for Annotable plus|(% style="width:99px" %) | |(% style="width:389px" %) 403 +| |(% style="width:244px" %)id|(% style="width:99px" %)M|string|(% style="width:389px" %) 404 +| |(% style="width:244px" %)uri|(% style="width:99px" %)C|string|(% style="width:389px" %) 405 +| |(% style="width:244px" %)urn|(% style="width:99px" %)C|string|(% style="width:389px" %)Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 406 +|Nameable|(% style="width:244px" %)all content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %) 407 +| |(% style="width:244px" %)Name in the form of International String|(% style="width:99px" %)M|string|(% style="width:389px" %)This can have languagespecific variants. 408 +| |(% style="width:244px" %)((( 409 +Description in the form of International String 410 +)))|(% style="width:99px" %)C|string|(% style="width:389px" %)This can have languagespecific variants. 411 +|Versionable|(% style="width:244px" %)All content as for Identifiable plus|(% style="width:99px" %) | |(% style="width:389px" %) 412 +| |(% style="width:244px" %)version|(% style="width:99px" %)C|string|(% style="width:389px" %)This is the version number. If not present the default is 1.0 413 +| |(% style="width:244px" %)validFrom|(% style="width:99px" %)C|Date/time|(% style="width:389px" %) 414 +| |(% style="width:244px" %)validTo|(% style="width:99px" %)C|Date/time|(% style="width:389px" %) 415 +|Maintainable|(% style="width:244px" %)All content as for Versionable plus|(% style="width:99px" %) | |(% style="width:389px" %) 416 +| |(% style="width:244px" %)final|(% style="width:99px" %) |boolean|(% style="width:389px" %)Value of “true” indicates that this is a final specification and it cannot be changed except as a new version. Note that providing a “final’ object is not referenced from another object then it may be deleted. 417 +| |(% style="width:244px" %)isExternalReference|(% style="width:99px" %)C|boolean|(% style="width:389px" %)Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURI, each of which must return a valid SDMX-ML file. 418 +| |(% style="width:244px" %)serviceURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the service that can be queried for this resource 419 +| |(% style="width:244px" %)structureURL|(% style="width:99px" %)C|string|(% style="width:389px" %)The url of the resource. 420 +| |(% style="width:244px" %)(Maintenance) agencyId|(% style="width:99px" %)M|string|(% style="width:389px" %)The object must be linked to a maintenance agency. 408 408 409 -International String 410 -)))|C| |This can have languagespecific variants. 411 -| | | | | 412 -|Identifiable|all content as for Annotable plus| | | 413 -| |id|M|string| 414 -| |uri|C|string| 415 -| |urn|C|string|Although the urn is computable and therefore may not be submitted or stored physically, the Registry must return the urn for each object, and must be able to service a query on an object referenced solely by its urn. 416 -|Nameable|all content as for Identifiable plus| | | 417 -| |Name in the form of International String|M|string|This can have languagespecific variants. 418 -| |((( 419 -Description in the form of International 420 - 421 -String 422 -)))|C|string|This can have languagespecific variants. 423 -|Versionable|All content as for Identifiable plus| | | 424 -| |version|C|string|This is the version number. If not present the default is 1.0 425 -| |validFrom|C|Date/time| 426 -| |validTo|C|Date/time| 427 -|Maintainable|All content as for Versionable plus| | | 428 -| |final| |boolean|Value of “true” indicates that this is a final specification and it cannot be changed except as a new version. Note that providing a “final’ object is not referenced from another object then it may be deleted. 429 -| |isExternalReference|C|boolean|Value of “true” indicates that the actual resource is held outside of this registry. The actual reference is given in the registry URI or the structureURI, each of which must return a valid SDMX-ML file. 430 -| |serviceURL|C|string|The url of the service that can be queried for this resource 431 -| |structureURL|C|string|The url of the resource. 432 -| |(Maintenance) agencyId|M|string|The object must be linked to a maintenance agency. 433 - 434 434 **Table 1: Common Attributes of Object Types** 435 435 436 436 == 6.2 Unique identification of SDMX objects == ... ... @@ -460,7 +460,8 @@ 460 460 461 461 [[image:1747824123012-527.jpeg]] 462 462 463 -==== Figure 7: Example of Hierarchic Structure of Agencies ==== 451 +* 452 +** Figure 7: Example of Hierarchic Structure of Agencies 464 464 465 465 The following organizations maintain an Agency Scheme. 466 466 ... ... @@ -475,11 +475,10 @@ 475 475 476 476 An example of this is shown in the XML snippet below. 477 477 467 +[[image:1747824123013-196.jpeg||height="309" width="446"]] 478 478 479 - [[image:1747824123013-196.jpeg]]469 +**Figure 8: Example Showing Use of Agency Identifiers** 480 480 481 -==== Figure 8: Example Showing Use of Agency Identifiers ==== 482 - 483 483 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. 484 484 485 485 === 6.2.2 Universal Resource Name (URN) === ... ... @@ -496,7 +496,7 @@ 496 496 497 497 The generic structure of the URN is as follows: 498 498 499 -SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id 487 +>SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id 500 500 501 501 ~* this can repeat and may not be present (see explanation below) 502 502 ... ... @@ -508,7 +508,7 @@ 508 508 509 509 In the explanation below the actual object that is the target of the URN is called the **//actual object//**. 510 510 511 -**SDMXPrefix:** urn:sdmx:org. 499 +**SDMXPrefix:** urn:sdmx:org. 512 512 513 513 **SDMX-IM package name:** sdmx.infomodel.package= 514 514 ... ... @@ -518,10 +518,8 @@ 518 518 519 519 **(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present. 520 520 521 -**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a 509 +**container-object-id** is the identifier of an intermediary object that contains the actual object which the URN is identifying. It is not mandatory as many actual objects do not have an intermediary container object. For instance, a Code is in a maintained object (Code List) and has no intermediary container object, whereas a Metadata Attribute has an intermediary container object (Report Structure) and may have an intermediary container object which is its parent Metadata Attribute. For this reason the container object id may repeat, with each repetition identifying the object at the next-lower level in its hierarchy. Note that if there is only a single containing object in the model then it is NOT included in the URN structure. This applies to Attribute Descriptor, Dimension Descriptor, and Measure Descriptor where there can be only one such object and this object has a fixed id. Therefore, whilst each of these has a URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure. 522 522 523 -URN, the id of the Attribute Descriptor, Dimension Descriptor, and Measure Descriptor is not included when the actual object is a Data Attribute or a Dimension/Measure Dimension/ Time Dimension, or a Measure. 524 - 525 525 Note that although a Code can have a parent Code and a Concept can have a parent Concept these are maintained in a flat structure and therefore do not have a container-object-id. 526 526 527 527 For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId. ... ... @@ -528,58 +528,57 @@ 528 528 529 529 **object-id** is the identifier of the actual object unless the actual object is a maintainable object. If present it is always the last id and is not followed by any other character. 530 530 531 -===== //Generic Examples of the URN Structure// ===== 517 +===== __**//Generic Examples of the URN Structure//**__ ===== 532 532 519 +__Actual object is a maintainable__ 533 533 534 - Actualobject isable521 +> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version) 535 535 536 - SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version)523 +__Actual object is contained in a maintained object with no intermediate containing object__ 537 537 538 - Actualobjectiscontained inamaintainedwith no intermediate containingobject525 +> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id 539 539 540 - SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version).object-id527 +__Actual object is contained in a maintained object with an intermediate containing object__ 541 541 542 - Actualobjectiscontainedinaintained object withanintermediate containingobject529 +> SDMXPrefix.SDMX-IM package name.classname=agency 543 543 544 -SDMXPrefix.SDMX-IM package name.classname=agency 545 - 546 546 id:maintained-object-id(version).contained-object-id.object-id 547 547 548 -Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical 533 +__Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__ 549 549 550 550 In this case the object id may not be unique in itself but only within the context of the hierarchy. In the general syntax of the URN all intermediary objects in the structure (with the exception, of course, of the maintained object) are shown as a contained object. An example here would be a Category in a Category Scheme. The Category is hierarchical and all intermediate Categories are shown as a contained object. The example below shows the generic structure for Category Scheme/Category/Category 551 551 552 -SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id 537 +> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id 553 553 554 -Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical 539 +__Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__ 555 555 556 556 In this case the generic syntax is the same as for the example above as the parent object is regarded as a containing object, even if it is of the same type. An example here is a Metadata Attribute where the contained objects are Report Structure (first contained object id) and Metadata Attribute (subsequent contained object Ids). The example below shows the generic structure for MSD/Report Structure/Metadata Attribute/Metadata Attribute 557 557 558 -SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id 543 +> SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id 559 559 560 -===== //Concrete Examples of the URN Structure// ===== 545 +===== __**//Concrete Examples of the URN Structure//**__ ===== 561 561 562 562 The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN: 563 563 564 -urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0) 549 +> urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0) 565 565 566 566 The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be: 567 567 568 -urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR 553 +> urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR 569 569 570 570 The URN for a category (id of 1) which has parent category (id of 2) maintained by SDMX in the category scheme SUBJECT_MATTER_DOMAINS version 1.0 would be: 571 571 572 -urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2 557 +> urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2 573 573 574 574 The URN for a Metadata Attribute maintained by SDMX in the MSD CONTACT_METADATA version 1.0 in the Report Structure CONTACT_REPORT where the hierarchy of the Metadata Attribute is 575 575 576 576 CONTACT_DETAILS/CONTACT_NAME would be: 577 577 578 -urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME 563 +> urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME 579 579 580 580 The TFFS defines ABC as a sub Agency of TFFS then the URN of a Dataflow maintained by ABC and identified as EXTERNAL_DEBT version 1.0 would be: 581 581 582 -urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX 567 +> urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX 583 583 584 584 TERNAL_DEBT(1.0) 585 585 ... ... @@ -594,112 +594,94 @@ 594 594 595 595 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. 596 596 597 -|**Package**|((( 598 -**URN Classname (model classname** 599 - 600 -**where this is different)** 582 +|(% style="width:127px" %)**Package**|(% style="width:1745px" %)((( 583 +**URN Classname (model classname where this is different)** 601 601 ))) 602 -|base|Agency 603 -| |OrganisationUnitScheme 604 -| |AgencyScheme 605 -| |DataProviderScheme 606 -| |DataConsumerScheme 607 -| |OrganisationUnit 608 -| |DataProvider 609 -| |DataConsumer 610 -| | 611 -|datastructure|DataStructure (DataStructureDefinition) 612 -| |AttributeDescriptor 613 -| |DataAttribute 614 -| |GroupDimensionDescriptor 615 -| |DimensionDescriptor 616 -| |Dimension 617 -| |MeasureDimension 618 -| |TimeDimension 619 -| |MeasureDescriptor 620 -| |PrimaryMeasure 621 -| |Dataflow (DataflowDefinition) 622 -| | 623 -|metadatastructure|MetadataTarget 624 -| |DimensionDescriptorValueTarget 625 -| |IdentifiableObjectTarget 626 -| |ReportPeriodTarget 627 -| |DataSetTarget 628 -| |ReportStructure 629 -| |MetadataAttribute 630 -| |((( 585 +|(% style="width:127px" %)base|(% style="width:45px" %)Agency 586 +|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme 587 +|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme 588 +|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme 589 +|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme 590 +|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit 591 +|(% style="width:127px" %) |(% style="width:45px" %)DataProvider 592 +|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer 593 +|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition) 594 +|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor 595 +|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute 596 +|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor 597 +|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor 598 +|(% style="width:127px" %) |(% style="width:45px" %)Dimension 599 +|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension 600 +|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension 601 +|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor 602 +|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure 603 +|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition) 604 +|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget 605 +|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget 606 +|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget 607 +|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget 608 +|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget 609 +|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure 610 +|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute 611 +|(% style="width:127px" %) |(% style="width:45px" %)((( 631 631 MetadataStructure 632 632 633 633 (MetadataStructureDefinition) 634 634 ))) 635 -| |Metadataflow (MetadataflowDefinition) 636 -| | 637 -|process|Process 638 -| |ProcessStep 639 -| |Transition 640 -| | 641 -|registry|ProvisionAgreement 642 -| |AttachmentConstraint 643 -| |ContentConstraint 644 -| |Subscription 645 -| | 646 -|mapping|StructureMap 647 -| |StructureSet 648 -| |ComponentMap 649 -|**Package**|((( 650 -**URN Classname (model classname** 616 +|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition) 617 +|(% style="width:127px" %)process|(% style="width:45px" %)Process 618 +|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep 619 +|(% style="width:127px" %) |(% style="width:45px" %)Transition 620 +|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement 621 +|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint 622 +|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint 623 +|(% style="width:127px" %) |(% style="width:45px" %)Subscription 624 +|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap 625 +|(% style="width:127px" %) |(% style="width:45px" %)StructureSet 626 +|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap 627 +|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap 628 +|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap 629 +|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap 630 +|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap 631 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap 632 +|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap 633 +|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap 634 +|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap 635 +|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap 636 +|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap 637 +|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap 638 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap 639 +|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist 640 +|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist 641 +|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy 642 +|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy 643 +|(% style="width:127px" %) |(% style="width:1745px" %)Code 644 +|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode 645 +|(% style="width:127px" %) |(% style="width:1745px" %)Level 646 +|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme 647 +|(% style="width:127px" %) |(% style="width:1745px" %)Category 648 +|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation 649 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy 650 +|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory 651 +|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme 652 +|(% style="width:127px" %) |(% style="width:1745px" %)Concept 653 +|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme 654 +|(% style="width:127px" %) |(% style="width:1745px" %)Transformation 655 +|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme 656 +|(% style="width:127px" %) |(% style="width:1745px" %)CustomType 657 +|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme 658 +|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation 659 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping 660 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping 661 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping 662 +|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping 663 +|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme 664 +|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset 665 +|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme 666 +|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator 651 651 652 -**where this is different)** 653 -))) 654 -| |ConceptSchemeMap 655 -| |OrganisationSchemeMap 656 -| |CodelistMap 657 -| |CategorySchemeMap 658 -| |ReportingTaxonomyMap 659 -| |ConceptMap 660 -| |OrganisationMap 661 -| |CodeMap 662 -| |HybridCodelistMap 663 -| |CategoryMap 664 -| |HybridCodeMap 665 -| |ReportingCategoryMap 666 -| | 667 -|codelist|Codelist 668 -| |HierarchicalCodelist 669 -| |Hierarchy 670 -| |Hierarchy 671 -| |Code 672 -| |HierarchicalCode 673 -| |Level 674 -| | 675 -|categoryscheme|CategoryScheme 676 -| |Category 677 -| |Categorisation 678 -| |ReportingTaxonomy 679 -| |ReportingCategory 680 -| | 681 -|conceptscheme|ConceptScheme 682 -| |Concept 683 -| | 684 -|transformation|TransformationScheme 685 -| |Transformation 686 -| |CustomTypeScheme 687 -| |CustomType 688 -| |NamePersonalisationScheme 689 -| |NamePersonalisation 690 -| |VtlCodelistMapping 691 -| |VtlConceptMapping 692 -| |VtlDataflowMapping 693 -| |VtlConceptSchemeMapping 694 -| |RulesetScheme 695 -| |Ruleset 696 -| |UserDefinedOperatorScheme 697 -| |UserDefinedOperator 698 -| | 699 - 700 700 **Table 2: SDMX-IM Packages and Contained Classes** 701 701 702 - 703 703 === 6.2.4 URN Identification components of SDMX objects === 704 704 705 705 The table below describes the identification components for all SDMX object types that have identification. Note the actual attributes are all Id, but have been prefixed by their class name or multiple class names to show navigation, e.g. conceptSchemeAgencyId is really the Id attribute of the Agency class that is associated to the ConceptScheme. ... ... @@ -708,78 +708,50 @@ 708 708 709 709 Note that for brevity the URN examples omit the prefix. All URNs have the prefix 710 710 711 -urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 678 +> urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 712 712 713 - 714 -|**SDMX Class**|**Key attribute(s)**|**Example of URN** 715 -|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.|((( 680 +(% style="width:1091.29px" %) 681 +|(% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN** 682 +|(% 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" %)((( 716 716 IMF 717 - 718 - 719 719 Sub agency in the IMF AGENCIES 720 - 721 - 722 722 IMF.SubAgency1 723 723 ))) 724 -|*ConceptScheme|conceptSchemeAgencyId:conceptSchemeId(ve rsion)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 725 -|Concept|((( 726 -conceptSchemeAgencyId: 727 - 728 -conceptSchemeId(version).conceptId 729 -)))|SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 730 -|*Codelist|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0) 731 -|Code|codeListAgencyId:codelistId(version).codeId|((( 732 -SDMX:CL_FREQ(1.0).Q 733 - 734 - 687 +|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 688 +|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId: 689 +conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 690 +|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0) 691 +|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q 692 +|(% style="width:250px" %)((( 693 +*Hierarchical Codelist 694 +)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)((( 695 +UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %)) 735 735 ))) 736 - 737 - 738 - 739 -|((( 740 -*Hierarchical 741 - 742 -Codelist 743 -)))|hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|((( 744 -UNESCO:CL_EXP_SOURCE(1.0) 745 - 746 - 747 -))) 748 -|Hierarchy|((( 697 +|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)((( 749 749 hierachicalcodeListAgencyId: 750 - 751 751 hierarchicalcodelistId(version).Hierarchy 752 -)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV 753 -|Level|((( 700 +)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). 701 +H-C-GOV 702 +|(% style="width:250px" %)Level|(% style="width:444px" %)((( 754 754 hierachicalcodeListAgencyId: 755 - 756 756 hierarchicalcodelistId(version).Hierarchy.Level 757 -)))|((( 705 +)))|(% style="width:396px" %)((( 758 758 ESTAT:HCL_REGION(1.0).H_1.COUNTRY 759 - 760 - 761 761 ))) 762 -|HierarchicalCode|hierachicalCodeListAgencyId: hierarchicalcodelistId(version).hierarchy.hierarc hicalCode|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV.GOV_CODE1 763 -|*DataStructure|dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|TFFS:EXT_DEBT(1.0) 764 -|((( 708 +|(% 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_CODE1 709 +|(% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0) 710 +|(% style="width:250px" %)((( 765 765 Dimension 766 - 767 767 Descriptor 768 - 769 769 Measure 770 - 771 771 Descriptor 772 - 773 773 Attribute 774 - 775 775 Descriptor 776 -)))|((( 717 +)))|(% style="width:444px" %)((( 777 777 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 778 - 779 779 componentListId 780 - 781 781 where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition) 782 -)))|((( 721 +)))|(% style="width:396px" %)((( 783 783 TFFS:EXT_DEBT(1.0).DimensionDescriptor 784 784 785 785 TFFS:EXT_DEBT(1.0).MeasureDescriptor ... ... @@ -786,181 +786,124 @@ 786 786 787 787 TFFS:EXT_DEBT(1.0).AttributeDescriptor 788 788 ))) 789 -|((( 728 +|(% style="width:250px" %)((( 790 790 GroupDimension 791 - 792 792 Descriptor 793 -)))|((( 731 +)))|(% style="width:444px" %)((( 794 794 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 795 - 796 796 groupDimensionDescriptorId 797 -)))|TFFS:EXT_DEBT(1.0).SIBLING 798 -|Dimension|((( 734 +)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING 735 +|(% style="width:250px" %)Dimension|(% style="width:444px" %)((( 799 799 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 800 - 801 801 dimensionId 802 -)))|TFFS:EXT_DEBT(1.0).FREQ 803 -|TimeDimension|((( 738 +)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ 739 +|(% style="width:250px" %)TimeDimension|(% style="width:444px" %)((( 804 804 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 805 - 806 806 timeDimensionId 807 -)))|TFFS:EXT_DEBT(1.0).TIME_PERIOD 808 -|Measure Dimension|dataStructureDefinitionAgencyId: dataStructureDefinition (version).|TFFS:EXT_DEBT(1.0).STOCK_FLOW 809 - 810 - 811 - 812 -| |measureDimensionId| 813 -|DataAttrribute|dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|TFFS:EXT_DEBT(1.0).OBS_STATUS 814 -|PrimaryMeasure|((( 742 +)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD 743 +|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). 744 +measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW 745 +|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS 746 +|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)((( 815 815 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 816 - 817 817 primaryMeasureId 818 -)))|TFFS:EXT_DEBT(1.0).OBS_VALUE 819 -|((( 820 -*Category 821 - 822 -Scheme 823 -)))|categorySchemeAgencyId: categorySchemeId(version)|IMF:SDDS(1.0) 824 -|Category|categorySchemeAgencyId: categorySchemeId(version). categoryId.categoryId categoryId.categoryId etc.|((( 749 +)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE 750 +|(% style="width:250px" %)((( 751 +*Category Scheme 752 +)))|(% style="width:444px" %)categorySchemeAgencyId: 753 +categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0) 754 +|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId: 755 +categorySchemeId(version). 756 +categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)((( 825 825 IMF:SDDS(1.0): 826 - 827 827 level_1_category.level_2_category … 828 828 ))) 829 -|((( 830 -*Reporting 831 - 832 -Taxonomy 833 -)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0) 834 -|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|((( 760 +|(% style="width:250px" %)((( 761 +*Reporting Taxonomy 762 +)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0) 763 +|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)((( 835 835 IMF:REP_1(1.0): 836 - 837 837 level_1_repcategory.level_2_repcategory … 838 838 ))) 839 -|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0) 840 -|((( 841 -*Organisation 767 +|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0) 768 +|(% style="width:250px" %)((( 769 +*Organisation Unit Scheme 770 +)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0) 771 +|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F 772 +|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0) 842 842 843 -Unit Scheme 844 -)))|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|ECB:ORGANISATIONS(1.0) 845 -|Organisation Unit|organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|ECB:ORGANISATIONS(1.0).1F 846 -|*AgencyScheme|agencySchemeAgencyId: agencySchemeId(version)|ECB:AGENCIES(1.0) 847 - 848 - 849 - 850 -|Agency|agencySchemeAgencyId: agencySchemeId(version). agencyId|ECB:AGENCY(1.0).AA 851 -|((( 852 -*DataProvider 853 - 854 -Scheme 855 -)))|dataProviderSchemeAgencyId: dataProviderSchemeId(version)|SDMX:DATA_PROVIDERS(1.0) 856 -|DataProvider|dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 857 -|((( 858 -*DataConsumer 859 - 860 -Scheme 861 -)))|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|SDMX:DATA_CONSUMERS(1.0) 862 -|Data Consumer|dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 863 -|((( 864 -*Metadata 865 - 866 -Structure 867 -)))|MSDAgencyId:MSDId(version)|IMF:SDDS_MSD(1.0) 868 -|MetadataTarget|((( 774 +|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA 775 +|(% style="width:262px" %)((( 776 +*DataProvider Scheme 777 +)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0) 778 +|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 779 +|(% style="width:262px" %)((( 780 +*DataConsumer Scheme 781 +)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0) 782 +|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 783 +|(% style="width:262px" %)((( 784 +*Metadata Structure 785 +)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0) 786 +|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)((( 869 869 MSDAgencyId: 870 - 871 871 MSDId(version).metadataTargetId 872 -)))|IMF:SDDS_MSD(1.0).AGENCY 873 -|((( 789 +)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY 790 +|(% style="width:262px" %)((( 874 874 Dimension 875 - 876 876 DescriptorValues 877 - 878 878 Target 879 -)))|((( 794 +)))|(% style="width:369px" %)((( 880 880 MSDAgencyId: MSDId(version). 881 - 882 882 metadataTargetId.keyDescriptorValueTargetId 883 -)))|IMF:SDDS_MSD(1.0).AGENCY.KEY 884 -|Identifiable ObjectTarget|((( 797 +)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY 798 +|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)((( 799 +MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId 800 +)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 801 +|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)((( 885 885 MSDAgencyId: 803 +MSDId(version).metadataTargetId.dataSetTargetId 804 +)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101 805 +|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)((( 806 +MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId 807 +)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER 886 886 887 -MSDId(version).metadataTargetId.identifiable 888 - 889 -ObjectTargetId 890 -)))|IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 891 -|DataSetTarget|((( 892 -MSDAgencyId: 893 - 894 -MSDId(version).metadataTargetId.dataSet 895 - 896 -TargetId 897 -)))|IMF:SDDS_MSD(1.0).AGENCY.D1101 898 -|PeportPeriod Target|((( 899 -MSDAgencyId: 900 - 901 -MSDId(version).metadataTargetId.reportPeriod 902 - 903 -TargetId 904 -)))|IMF:SDDS_MSD(1.0).AGENCY.REP_PER 905 - 906 - 907 - 908 -|((( 809 +|(% style="width:251px" %)((( 909 909 ReportStructure 910 - 911 - 912 -)))|((( 913 -MSDAgencyId: 914 - 915 -MSDId(version).reportStructureId 916 -)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT 917 -|((( 918 -Metadata 919 - 920 -Attribute 921 -)))|((( 922 -MSDAgencyId: 923 - 924 -MSDId(version).reportStructureId.metadataattri buteID 925 -)))|IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 926 -|*Dataflow|dataflowAgencyId: dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0) 927 -|*Provision Agreement|((( 811 +)))|(% style="width:442px" %)((( 812 +MSDAgencyId: MSDId(version).reportStructureId 813 +)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT 814 +|(% style="width:251px" %)((( 815 +Metadata Attribute 816 +)))|(% style="width:442px" %)((( 817 +MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID 818 +)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 819 +|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0) 820 +|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)((( 928 928 provisionAgreementAgencyId:provisionAgreem entId(version) 929 - 930 - 931 -)))|((( 822 +)))|(% style="width:1178px" %)((( 932 932 TFFS:CRED_EXT_DEBT_AB(1.0) 933 - 934 - 935 - 936 936 ))) 937 -|((( 938 -*Content 939 - 940 -Constraint 941 -)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0) 942 -|((( 943 -*Attachment 944 - 945 -Constraint 946 -)))|((( 825 +|(% style="width:251px" %)((( 826 +*Content Constraint 827 +)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0) 828 +|(% style="width:251px" %)((( 829 +*Attachment Constraint 830 +)))|(% style="width:442px" %)((( 947 947 constraintAgencyId: 948 948 949 949 attachmentConstraintId(version) 950 -)))|TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0) 951 -|*Metadataflow|metadataflowAgencyId: metadataflowId(version)|IMF:SDDS_FLOW(1.0) 952 -|*StructureSet|structureSetAgencyId: structureSetId(version)|SDMX:BOP_STRUCTURES(1.0) 953 -|StructureMap|structureSetAgencyId: structureSetId(version). structureMapId|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2 954 -|Component Map|((( 834 +)))|(% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0) 835 +|(% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0) 836 +|(% style="width:251px" %)*StructureSet|(% style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0) 837 +|(% style="width:251px" %)StructureMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2 838 +|(% style="width:251px" %)Component Map|(% style="width:442px" %)((( 955 955 structureSetAgencyId: structureSetId(version). 956 956 957 957 structureMapId. componentMapId 958 -)))|SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY 959 -|CodelistMap|structureSetAgencyId: structureSetId(version). codelistMapId|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY 960 -|CodeMap|structureSetAgencyId: structureSetId(version).|SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER 842 +)))|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY 843 +|(% style="width:251px" %)CodelistMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY 844 +|(% style="width:251px" %)CodeMap|(% style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER 961 961 962 - 963 - 964 964 | |((( 965 965 codeListMapId. 966 966 ... ... @@ -967,9 +967,7 @@ 967 967 codeMapId 968 968 )))| 969 969 |((( 970 -Category 971 - 972 -SchemeMap 852 +CategorySchemeMap 973 973 )))|structureSetAgencyId: structureSetId(version). categorySchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT 974 974 |CategoryMap|structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_M AP 975 975 |Organisation SchemeMap|structureSetAgencyId: structureSetId(version). organisationSchemeMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP ... ... @@ -983,71 +983,53 @@ 983 983 structureSetAgencyId: structureSetId(version). conceptSchemeMapId. 984 984 985 985 conceptMapId 986 - 987 987 988 988 )))|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY 989 989 |((( 990 -Reporting 991 - 992 -TaxonomyMap 869 +ReportingTaxonomyMap 993 993 )))|structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|SDMX:BOP_STRUCTURES(1.0).TAXMAP 994 994 |((( 995 -Reporting 996 - 997 -CategoryMap 872 +ReportingCategoryMap 998 998 )))|((( 999 999 structureSetAgencyId: structureSetId(version). 1000 - 1001 1001 reportngCategoryId 1002 1002 )))|SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT 1003 1003 1004 - 1005 - 1006 1006 |((( 1007 -HybridCodelist 1008 - 1009 -Map 1010 -)))|structureSetAgencyId: structureSetId(version). hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 879 +HybridCodelistMap 880 +)))|structureSetAgencyId: structureSetId(version). 881 +hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 1011 1011 |HybridCodeMap|structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1 1012 1012 |*Process|processAgencyId: processId{version]|BIS:PROCESS1(1.0) 1013 1013 |ProcessStep|((( 1014 1014 processAgencyId: processId(version). 1015 - 1016 1016 processStepId 1017 1017 )))|BIS:PROCESS1(1.0).STEP1 1018 1018 |Transition|((( 1019 1019 processAgencyId: processId(version). 1020 - 1021 1021 processStepId transitionId 1022 1022 )))|BIS:PROCESS1(1.0).STEP1.TRANSITION1 1023 1023 |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. 1024 1024 |((( 1025 -*Transformation 1026 - 1027 -Scheme 894 +*Transformation Scheme 1028 1028 )))|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0) 1029 1029 |Transformation|((( 1030 1030 transformationSchemeAgencyId transformationSchemeId(version) 1031 - 1032 1032 transformationId 1033 1033 )))|ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1 1034 1034 |CustomType Scheme|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0) 1035 1035 1036 - 1037 - 1038 1038 |CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1 1039 1039 |((( 1040 1040 Name 1041 - 1042 1042 Personalisation 1043 - 1044 1044 Scheme 1045 1045 )))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0) 1046 1046 |((( 1047 1047 Name 1048 - 1049 1049 Personalisation 1050 -)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234 911 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) 912 +namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234 1051 1051 |VtlMapping Scheme|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0) 1052 1052 |VtlCodelist Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0).ABZ 1053 1053 |VtlConcept Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0).XYA ... ... @@ -1060,15 +1060,12 @@ 1060 1060 |RulesetScheme|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0) 1061 1061 |Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0).SET111 1062 1062 |((( 1063 -UserDefined 1064 - 1065 -OperatorScheme 925 +UserDefinedOperatorScheme 1066 1066 )))|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2) 1067 1067 |UserDefined Operator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2).OS267 1068 1068 1069 - 7**Table 3: Table of identification components for SDMX Identifiable Artefacts**929 +**Table 3: Table of identification components for SDMX Identifiable Artefacts** 1070 1070 1071 - 1072 1072 = 7 Implementation Notes = 1073 1073 1074 1074 == 7.1 Structural Definition Metadata == ... ... @@ -1089,109 +1089,72 @@ 1089 1089 1090 1090 The following table lists the Maintainable Artefacts. 1091 1091 1092 -|(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content**| 1093 -|(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) | 1094 -|(% colspan="2" %)Item Scheme|(% colspan="2" %)Codelist|(% colspan="2" %)Code| 1095 -|(% colspan="2" %) |(% colspan="2" %)Concept Scheme|(% colspan="2" %)Concept| 1096 -|(% colspan="2" %) |(% colspan="2" %)Category Scheme|(% colspan="2" %)Category| 1097 -|(% colspan="2" %) |(% colspan="2" %)Organisation Unit Scheme|(% colspan="2" %)Organisation Unit| 1098 -|(% colspan="2" %) |(% colspan="2" %)Agency Scheme|(% colspan="2" %)Agency| 1099 -|(% colspan="2" %) |(% colspan="2" %)Data Provider Scheme|(% colspan="2" %)Data Provider| 1100 -|(% colspan="2" %) |(% colspan="2" %)Data Consumer Scheme|(% colspan="2" %)Data Consumer| 1101 -|(% colspan="2" %) |(% colspan="2" %)Reporting Taxonomy|(% colspan="2" %)Reporting Category| 1102 -|(% colspan="2" %) |(% colspan="2" %)Transformation Scheme|(% colspan="2" %)Transformation| 1103 -|(% colspan="2" %) |(% colspan="2" %)Custom Type Scheme|(% colspan="2" %)Custom Type| 1104 -| |(% colspan="4" %)**Maintainable Artefacts**|(% colspan="2" %)**Content** 1105 -| |(% colspan="2" %)**Abstract Class**|(% colspan="2" %)**Concrete Class**|(% colspan="2" %) 1106 -| |(% colspan="2" %) |(% colspan="2" %)Name Personalisation Scheme|(% colspan="2" %)Name Personalisation 1107 -| |(% colspan="2" %) |(% colspan="2" %)Vtl Mapping Scheme|(% colspan="2" %)Vtl Codelist Mapping 1108 -| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Concept Mapping 1109 -| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)Vtl Dataflow Mapping 1110 -| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %)((( 1111 -Vtl Concept Scheme 1112 - 1113 -Mapping 1114 -))) 1115 -| |(% colspan="2" %) |(% colspan="2" %)Ruleset Scheme|(% colspan="2" %)Ruleset 1116 -| |(% colspan="2" %) |(% colspan="2" %)User Defined Operator Scheme|(% colspan="2" %)User Defined Operator 1117 -| |(% colspan="2" %) |(% colspan="2" %) |(% colspan="2" %) 1118 -| |(% colspan="2" %)Structure|(% colspan="2" %)Data Structure Definition|(% colspan="2" %)((( 951 +(% style="width:640.294px" %) 952 +|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content** 953 +|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %) 954 +|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code 955 +|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept 956 +|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category 957 +|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit 958 +|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency 959 +|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider 960 +|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer 961 +|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category 962 +|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation 963 +|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type 964 +|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation 965 +|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping 966 +|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping 967 +|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping 968 +|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset 969 +|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator 970 +|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator 971 +|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)((( 1119 1119 Dimension Descriptor 1120 - 1121 1121 Group Dimension 1122 - 1123 1123 Descriptor 1124 - 1125 1125 Dimension 1126 - 1127 1127 Measure Dimension 1128 - 1129 1129 Time Dimension 1130 - 1131 1131 Attribute Descriptor 1132 - 1133 1133 Data Attribute 1134 - 1135 1135 Measure Descriptor 1136 - 1137 1137 Primary Measure 1138 1138 ))) 1139 -| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)((( 1140 -Metadata Target, 1141 - 1142 -Dimension Descriptor 1143 - 983 +|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)((( 984 +Metadata Target, Dimension Descriptor 1144 1144 Values Target Identifiable 1145 - 1146 1146 Object Target 1147 - 1148 1148 Report Period Target 1149 - 1150 1150 Data SetTarget 1151 - 1152 1152 Report Structure 1153 - 1154 1154 Metadata Attribute 1155 1155 ))) 1156 -| |(%colspan="2" %)Structure Usage|(%colspan="2" %)Dataflow Definition|(%colspan="2" %)1157 -| |(%colspan="2" %) |(%colspan="2" %)Metadataflow Definition|(%colspan="2" %)1158 -| |(%colspan="2" %)None|(%colspan="2" %)Process|(%colspan="2" %)Process Step1159 -| |(%colspan="2" %)None|(%colspan="2" %)Structure Set|(%colspan="2" %)(((992 +|(% style="width:171px" %)Structure Usage|(% style="width:232px" %)Dataflow Definition|(% style="width:206px" %) 993 +|(% style="width:171px" %) |(% style="width:232px" %)Metadataflow Definition|(% style="width:206px" %) 994 +|(% style="width:171px" %)None|(% style="width:232px" %)Process|(% style="width:206px" %)Process Step 995 +|(% style="width:171px" %)None|(% style="width:232px" %)Structure Set|(% style="width:206px" %)((( 1160 1160 Component Map 1161 - 1162 1162 Concept Scheme Map 1163 - 1164 1164 Codelist Map 1165 - 1166 1166 Category Scheme Map 1167 - 1168 1168 Reporting Taxonomy Map 1169 - 1170 1170 Organisation Scheme Map 1171 - 1172 1172 Concept Map 1173 - 1174 1174 Code Map 1175 - 1176 1176 Category Map 1177 - 1178 1178 Organisation Map 1179 - 1180 1180 Reporting Category Map 1181 - 1182 1182 Hybrid Codelist Map 1183 - 1184 1184 Hybrid Code Map 1185 1185 ))) 1186 -| |(%colspan="2" %)None|(%colspan="2" %)Provision Agreement|(%colspan="2" %)1187 -| |(%colspan="2" %)None|(%colspan="2" %)Hierarchical Codelist|(%colspan="2" %)(((1010 +|(% style="width:171px" %)None|(% style="width:232px" %)Provision Agreement|(% style="width:206px" %) 1011 +|(% style="width:171px" %)None|(% style="width:232px" %)Hierarchical Codelist|(% style="width:206px" %)((( 1188 1188 Hierarchy 1189 - 1190 1190 Hierarchical Code 1191 1191 ))) 1192 -| | | | | | | 1193 1193 1194 -** Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**1016 +**able 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1195 1195 1196 1196 === 7.1.2 Item Scheme, Structure === 1197 1197 ... ... @@ -1198,10 +1198,7 @@ 1198 1198 The artefacts included in the structural definitions are: 1199 1199 1200 1200 * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme) 1201 -* All types of Structure (Data Structure Definition, Metadata Structure 1202 - 1203 -Definition) 1204 - 1023 +* All types of Structure (Data Structure Definition, Metadata Structure Definition) 1205 1205 * All types of Structure Usage (Dataflow Definition, Metadataflow Definition) 1206 1206 1207 1207 === 7.1.3 Structure Usage === ... ... @@ -1220,6 +1220,8 @@ 1220 1220 1221 1221 ==== 7.1.3.3 Structure Usage Model ==== 1222 1222 1042 +[[image:1747829078194-749.png]] 1043 + 1223 1223 **Figure 10: SDMX-IM of links from Structure Usage to Category** 1224 1224 1225 1225 In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry: ... ... @@ -1246,10 +1246,10 @@ 1246 1246 1247 1247 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. 1248 1248 1070 +[[image:1747829109466-595.png]] 1249 1249 1250 1250 **Figure 11: SDMX-IM of the Data Provider** 1251 1251 1252 - 1253 1253 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 1254 1254 1255 1255 [[image:1747824123019-181.jpeg]] ... ... @@ -1258,8 +1258,10 @@ 1258 1258 1259 1259 The diagram below is a logical representation of the data required in order to maintain Provision Agreements. 1260 1260 1082 +[[image:1747829139951-378.png]] 1261 1261 1262 -==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ==== 1084 +(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %) 1085 +**Figure 13: Logical class diagram of the information contained in the Provision Agreement** 1263 1263 1264 1264 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. 1265 1265 ... ... @@ -1287,13 +1287,12 @@ 1287 1287 1288 1288 === 7.3.3 Data and Metadata Constraints: Model === 1289 1289 1113 +[[image:1747829204737-370.png]] 1290 1290 1115 +**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts** 1291 1291 1292 - ==== Figure15: Logicalclass diagram showing inheritancebetween and reference to constrainable artifacts====1117 +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. 1293 1293 1294 -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. 1295 - 1296 - 1297 1297 The content of the Constraint can be found in the SDMX Information Model document. 1298 1298 1299 1299 == 7.4 Data and Metadata Registration == ... ... @@ -1314,7 +1314,7 @@ 1314 1314 1315 1315 [[image:1747824123025-411.jpeg]] 1316 1316 1317 - 1139 +**Figure 16: Schematic of the Objects Concerned with Registration** 1318 1318 1319 1319 ==== 7.4.2.2 Registration Request Model ==== 1320 1320 ... ... @@ -1328,11 +1328,14 @@ 1328 1328 1329 1329 The Registration has an action attribute which takes one of the following values: 1330 1330 1331 -|**Action Attribute Value**|**Behaviour** 1332 -|Append|Add this Registration to the registry 1333 -|Replace|Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1334 -|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1153 +(% style="width:970.294px" %) 1154 +|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour** 1155 +|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry 1156 +|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1157 +|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 1335 1335 1159 +[[image:1747829290890-122.png]] 1160 + 1336 1336 **Figure 17: Logical Class Diagram of Registration of Data and Metadata** 1337 1337 1338 1338 The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query ... ... @@ -1347,25 +1347,19 @@ 1347 1347 1348 1348 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. 1349 1349 1350 -|**Indexing Required**|**Registration Process Activity** 1351 -|indexTimeSeries|Extract all the series keys and create a KeySet(s) Constraint. 1352 -|indexDataSet|((( 1353 -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 1354 - 1355 -Regions containing Member Selections of Dimension Components of the Constraints model in the SDMX-IM, and the associated Selection Value. 1175 +|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity** 1176 +|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint. 1177 +|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)((( 1178 +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. 1356 1356 ))) 1357 -|indexReportingPeriod|((( 1180 +|(% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)((( 1358 1358 This applies only to a registered dataset. 1359 - 1360 1360 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 1361 1361 ))) 1362 -|indexAttributes|((( 1184 +|(% style="width:185px" %)indexAttributes|(% style="width:1686px" %)((( 1363 1363 **Data Set** 1364 - 1365 1365 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 1366 - 1367 1367 **Metadata Set** 1368 - 1369 1369 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. 1370 1370 ))) 1371 1371 ... ... @@ -1375,14 +1375,13 @@ 1375 1375 1376 1376 === 7.4.3 Registration Response === 1377 1377 1378 -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 1197 +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”. 1379 1379 1380 -“Success”, “Warning” or “Failure”. 1381 - 1382 1382 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. 1383 1383 1384 1384 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: 1385 1385 1203 +[[image:1747829477882-750.png]] 1386 1386 1387 1387 **Figure 18: Logical class diagram showing the registration response** 1388 1388 ... ... @@ -1392,15 +1392,12 @@ 1392 1392 1393 1393 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. 1394 1394 1395 -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 1213 +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”. 1396 1396 1397 - “notification”.1215 +=== 7.5.1Subscription Logical Class Diagram === 1398 1398 1399 - .5.1SubscriptionLogical Class Diagram1217 +[[image:1747829554603-150.png]] 1400 1400 1401 - 1402 -[[image:1747824123028-257.png]] 1403 - 1404 1404 **Figure 19: Logical Class Diagram of the Subscription** 1405 1405 1406 1406 === 7.5.2 Subscription Information === ... ... @@ -1407,73 +1407,58 @@ 1407 1407 1408 1408 Regardless of the type of registry/repository events being observed, a subscription always contains: 1409 1409 1410 -~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. 1225 +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. 1226 +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. 1227 +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. 1228 +1. A selector which specifies which type of events are of interest. The set of event types is: 1411 1411 1412 -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. 1230 +|(% style="width:319px" %)**Event Type**|(% style="width:1553px" %)**Comment** 1231 +|(% style="width:319px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1553px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1232 +|(% 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. 1233 +|(% 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. 1234 +|(% style="width:319px" %)ALL_EVENTS|(% style="width:1553px" %)All events of the specified EventType 1413 1413 1414 -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. 1415 - 1416 -4. A selector which specifies which type of events are of interest. The set of event types is: 1417 - 1418 -|**Event Type**|**Comment** 1419 -|STRUCTURAL_REPOSITORY_EVENTS|Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1420 -|DATA_REGISTRATION_EVENTS|Whenever a published dataset is registered. This can be either a SDMXML data file or an SDMX conformant database. 1421 -|METADATA_REGISTRATION_EVENTS|Whenever a published metadataset is registered. This can be either a SDMXML reference metadata file or an SDMX conformant database. 1422 -|ALL_EVENTS|All events of the specified EventType 1423 - 1424 1424 === 7.5.3 Wildcard Facility === 1425 1425 1426 1426 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: 1427 1427 1428 - agencyID 1240 +* agencyID 1241 +* id 1242 +* version 1429 1429 1430 - id 1431 - 1432 - version 1433 - 1434 1434 Examples of wildcarded identifier components for an identified object type of Codelist are shown below. 1435 1435 1436 -AgencyID = % 1437 - 1246 +//AgencyID = % 1438 1438 Id = % 1248 +Version = %// 1439 1439 1440 -Version = % 1441 - 1442 1442 This subscribes to all Codelists of all versions for all agencies. 1443 1443 1444 -AgencyID = AGENCY1 1445 - 1252 +//AgencyID = AGENCY1 1446 1446 Id = CODELIST1 1254 +Version = %// 1447 1447 1448 -Version = % 1449 - 1450 1450 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1451 1451 1452 -AGENCY1 1453 - 1258 +//AGENCY1 1454 1454 AgencyID = AGENCY1 1455 - 1456 1456 Id = % 1261 +Version = %// 1457 1457 1458 -Version = % 1459 - 1460 1460 This subscribes to all versions of all Codelist objects maintained by the agency 1461 1461 1462 -AGENCY1 1463 - 1265 +//AGENCY1 1464 1464 AgencyID = % 1465 - 1466 1466 Id = CODELIST1 1268 +Version = %// 1467 1467 1468 -Version = % 1469 - 1470 1470 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1471 1471 1472 -AGENCY1 1272 +//AGENCY1// 1473 1473 1474 1474 Note that if the subscription is to the latest version then this can be achieved by the * character 1475 1475 1476 -i.e. Version = * 1276 +//i.e. Version = *// 1477 1477 1478 1478 Note that a subscription using the URN mechanism cannot use wildcard characters. 1479 1479 ... ... @@ -1485,16 +1485,15 @@ 1485 1485 1486 1486 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: 1487 1487 1288 +|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1289 +|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification. 1290 +|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification. 1291 +|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1292 +|(% 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 1293 +|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1294 +|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification. 1295 +|(% 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. 1488 1488 1489 -|**Selector**|**Comment** 1490 -|DataProvider|Any datasets or metadata sets registered by the specified data provider will activate the notification. 1491 -|ProvisionAgreement|Any datasets or metadata sets registered for the provision agreement will activate the notification. 1492 -|Dataflow (&Metadataflow)|Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1493 -|DataStructureDefinition & MetadataStructureDefinition|Any datasets or metadata sets registered for those dataflows (or metadataflows) that are based on the specified Data Structure Definition will 1494 -|**Selector**|**Comment** 1495 -| |activate the notification. 1496 -|Category|Any datasets or metadata sets registered for those dataflows, metadataflows, provision agreements that are categorised by the category. 1497 - 1498 1498 The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration. 1499 1499 1500 1500 == 7.6 Notification == ... ... @@ -1501,8 +1501,10 @@ 1501 1501 1502 1502 === 7.6.1 Logical Class Diagram === 1503 1503 1303 +[[image:1747829675568-610.png]] 1504 1504 1505 -==== Figure 20: Logical Class Diagram of the Notification ==== 1305 +(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %) 1306 +**Figure 20: Logical Class Diagram of the Notification** 1506 1506 1507 1507 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. 1508 1508 ... ... @@ -1522,5 +1522,3 @@ 1522 1522 === 7.6.3 Registration Event Component === 1523 1523 1524 1524 The notification will contain the Registration. 1525 - 1526 -
- 1747824504225-229.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +52.8 KB - Content
- 1747829078194-749.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +40.4 KB - Content
- 1747829109466-595.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +30.4 KB - Content
- 1747829139951-378.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +21.1 KB - Content
- 1747829204737-370.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +55.8 KB - Content
- 1747829290890-122.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +41.4 KB - Content
- 1747829477882-750.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +24.6 KB - Content
- 1747829554603-150.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +99.1 KB - Content
- 1747829675568-610.png
-
- Author
-
... ... @@ -1,0 +1,1 @@ 1 +xwiki:XWiki.helena - Size
-
... ... @@ -1,0 +1,1 @@ 1 +31.1 KB - Content