Last modified by Helena on 2025/09/10 11:19
Summary
-
Page properties (2 modified, 0 added, 0 removed)
-
Attachments (0 modified, 0 added, 11 removed)
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 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,12 +336,13 @@ 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 +|**Interface**|**Behaviour** 344 +|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. 344 344 * Description - this applies to the Maintainable object and its contained elements, such a Code in a Code list. 349 + 345 345 * Annotation - this applies to the Maintainable object and its contained elements, such a Code in a Code list. 346 346 * validTo 347 347 * validFrom ... ... @@ -350,22 +350,26 @@ 350 350 * uri 351 351 * isExternalReference 352 352 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.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:358 +1. 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. 359 +1. 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 - а)Not have the final attribute set to “true”357 - b)Not be referenced from any other object in the Registry.361 +1. Not have the final attribute set to “true” 362 +1. Not be referenced from any other object in the Registry. 358 358 359 -4) The version rules in the SDMX Schema documentation MUST be obeyed. 360 -5) The specific rules for the elements and attributes documented in the SDMX Schema MUST be obeyed. 364 +1. The version rules in the SDMX Schema documentation MUST be obeyed. 365 + 366 +* 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 +|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 +|SubmitProvisioningRequest|No additional behaviour. 370 +|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. 372 + 366 366 For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX-ML data query. 367 367 ))) 368 368 376 + 377 + 369 369 = 6 Identification of SDMX Objects = 370 370 371 371 == 6.1 Identification, Versioning, and Maintenance == ... ... @@ -372,6 +372,7 @@ 372 372 373 373 All major classes of the SDMX Information model inherit from one of: 374 374 384 + 375 375 * **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. 376 376 * **NamableArtefact **- this has all of the features of IdentifiableArtefact plus the ability to have a multi-lingual name and description, 377 377 * **VersionableArtefact **– this has all of the above features plus a version number and a validity period. ... ... @@ -379,8 +379,6 @@ 379 379 380 380 === 6.1.1 Identification, Naming, Versioning, and Maintenance Model === 381 381 382 -[[image:1747824504225-229.png]] 383 - 384 384 **Figure 5: Class diagram of fundamental artefacts in the SDMX-IM** 385 385 386 386 The table below shows the identification and related data attributes to be stored in a registry for objects that are one of: ... ... @@ -391,34 +391,38 @@ 391 391 * Versionable 392 392 * Maintainable 393 393 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. 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 421 421 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 + 422 422 **Table 1: Common Attributes of Object Types** 423 423 424 424 == 6.2 Unique identification of SDMX objects == ... ... @@ -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,8 +450,7 @@ 450 450 451 451 [[image:1747824123012-527.jpeg]] 452 452 453 -* 454 -** Figure 7: Example of Hierarchic Structure of Agencies 463 +==== Figure 7: Example of Hierarchic Structure of Agencies ==== 455 455 456 456 The following organizations maintain an Agency Scheme. 457 457 ... ... @@ -466,10 +466,11 @@ 466 466 467 467 An example of this is shown in the XML snippet below. 468 468 469 -[[image:1747832400104-286.png]] 470 470 471 - **Figure8:ExampleShowingUse of Agency Identifiers**479 +[[image:1747824123013-196.jpeg]] 472 472 481 +==== Figure 8: Example Showing Use of Agency Identifiers ==== 482 + 473 473 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. 474 474 475 475 === 6.2.2 Universal Resource Name (URN) === ... ... @@ -480,14 +480,13 @@ 480 480 481 481 ==== 6.2.2.2 URN Structure ==== 482 482 483 -(% class="wikigeneratedid" id="HCaseRulesforURN" %) 484 -//Case Rules for URN// 493 +===== //Case Rules for URN// ===== 485 485 486 486 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. 487 487 488 488 The generic structure of the URN is as follows: 489 489 490 - >SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id499 +SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobject-id(maintainedobject-version).*containerobject-id.object-id 491 491 492 492 ~* this can repeat and may not be present (see explanation below) 493 493 ... ... @@ -499,7 +499,7 @@ 499 499 500 500 In the explanation below the actual object that is the target of the URN is called the **//actual object//**. 501 501 502 -**SDMXPrefix:** urn:sdmx:org. 511 +**SDMXPrefix:** urn:sdmx:org. 503 503 504 504 **SDMX-IM package name:** sdmx.infomodel.package= 505 505 ... ... @@ -509,8 +509,10 @@ 509 509 510 510 **(maintainable-object-version)** is the version of the maintainable object and is enclosed in round brackets (). It will always be present. 511 511 512 -**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.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 513 513 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 + 514 514 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. 515 515 516 516 For example the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId. ... ... @@ -517,57 +517,58 @@ 517 517 518 518 **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. 519 519 520 -===== __**//Generic Examples of the URN Structure//**__=====531 +===== //Generic Examples of the URN Structure// ===== 521 521 522 -__Actual object is a maintainable__ 523 523 524 - > SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version)534 +Actual object is a maintainable 525 525 526 - __Actualobject iscontained inamaintainedwith no intermediate containing object__536 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version) 527 527 528 - > SDMXPrefix.SDMX-IM packagename.classname=agencyid:maintained-object-id(version).object-id538 +Actual object is contained in a maintained object with no intermediate containing object 529 529 530 - __Actualobject iscontained inamaintainedwith an intermediate containingobject__540 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).object-id 531 531 532 - >SDMXPrefix.SDMX-IMpackage name.classname=agency542 +Actual object is contained in a maintained object with an intermediate containing object 533 533 544 +SDMXPrefix.SDMX-IM package name.classname=agency 545 + 534 534 id:maintained-object-id(version).contained-object-id.object-id 535 535 536 - __Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical__548 +Actual object is contained in a maintained object with no intermediate containing object but the object type itself is hierarchical 537 537 538 538 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 539 539 540 - >SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id552 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id.object-id 541 541 542 - __Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical__554 +Actual object is contained in a maintained object with an intermediate containing object and the object type itself is hierarchical 543 543 544 544 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 545 545 546 - >SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id558 +SDMXPrefix.SDMX-IM package name.classname=agency id:maintained-object-id(version).contained-object-id. contained-object-id contained-object-id.object-id 547 547 548 -===== __**//Concrete Examples of the URN Structure//**__=====560 +===== //Concrete Examples of the URN Structure// ===== 549 549 550 550 The Data Structure Definition CRED_EXT_DEBT version 1.0 maintained by the top level Agency TFFS would have the URN: 551 551 552 - >urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0)564 +urn:sdmx:org.sdmx.infomodel.datastructure.DataStucture=TFFS:CRED_EXT_ DEBT(1.0) 553 553 554 554 The URN for a code for Argentina maintained by ISO in the code list CL_3166A2 version 1.0 would be: 555 555 556 - >urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR568 +urn:sdmx:org.sdmx.infomodel.codelist.Code=ISO:CL_3166A2(1.0).AR 557 557 558 558 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: 559 559 560 - >urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2572 +urn:sdmx:org.sdmx.infomodel.categoryscheme.Category=SDMX:SUBJE CT_MATTER_DOMAINS(1.0).1.2 561 561 562 562 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 563 563 564 564 CONTACT_DETAILS/CONTACT_NAME would be: 565 565 566 - >urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME578 +urn:sdmx:org.sdmx.infomodel.metadatastructure.MetadataAttribut e=SDMX:CONTACT_METADATA(1.0).CONTACT_REPORT.CONTACT_DETAILS.CO NTACT_NAME 567 567 568 568 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: 569 569 570 - >urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX582 +urn:sdmx:org.sdmx.infomodel.datastructure.Dataflow=TFFS.ABC:EX 571 571 572 572 TERNAL_DEBT(1.0) 573 573 ... ... @@ -582,94 +582,112 @@ 582 582 583 583 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. 584 584 585 -|(% style="width:127px" %)**Package**|(% style="width:1745px" %)((( 586 -**URN Classname (model classname where this is different)** 597 +|**Package**|((( 598 +**URN Classname (model classname** 599 + 600 +**where this is different)** 587 587 ))) 588 -|(% style="width:127px" %)base|(% style="width:45px" %)Agency 589 -|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnitScheme 590 -|(% style="width:127px" %) |(% style="width:45px" %)AgencyScheme 591 -|(% style="width:127px" %) |(% style="width:45px" %)DataProviderScheme 592 -|(% style="width:127px" %) |(% style="width:45px" %)DataConsumerScheme 593 -|(% style="width:127px" %) |(% style="width:45px" %)OrganisationUnit 594 -|(% style="width:127px" %) |(% style="width:45px" %)DataProvider 595 -|(% style="width:127px" %) |(% style="width:45px" %)DataConsumer 596 -|(% style="width:127px" %)datastructure|(% style="width:45px" %)DataStructure (DataStructureDefinition) 597 -|(% style="width:127px" %) |(% style="width:45px" %)AttributeDescriptor 598 -|(% style="width:127px" %) |(% style="width:45px" %)DataAttribute 599 -|(% style="width:127px" %) |(% style="width:45px" %)GroupDimensionDescriptor 600 -|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptor 601 -|(% style="width:127px" %) |(% style="width:45px" %)Dimension 602 -|(% style="width:127px" %) |(% style="width:45px" %)MeasureDimension 603 -|(% style="width:127px" %) |(% style="width:45px" %)TimeDimension 604 -|(% style="width:127px" %) |(% style="width:45px" %)MeasureDescriptor 605 -|(% style="width:127px" %) |(% style="width:45px" %)PrimaryMeasure 606 -|(% style="width:127px" %) |(% style="width:45px" %)Dataflow (DataflowDefinition) 607 -|(% style="width:127px" %)metadatastructure|(% style="width:45px" %)MetadataTarget 608 -|(% style="width:127px" %) |(% style="width:45px" %)DimensionDescriptorValueTarget 609 -|(% style="width:127px" %) |(% style="width:45px" %)IdentifiableObjectTarget 610 -|(% style="width:127px" %) |(% style="width:45px" %)ReportPeriodTarget 611 -|(% style="width:127px" %) |(% style="width:45px" %)DataSetTarget 612 -|(% style="width:127px" %) |(% style="width:45px" %)ReportStructure 613 -|(% style="width:127px" %) |(% style="width:45px" %)MetadataAttribute 614 -|(% style="width:127px" %) |(% style="width:45px" %)((( 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 +| |((( 615 615 MetadataStructure 616 616 617 617 (MetadataStructureDefinition) 618 618 ))) 619 -|(% style="width:127px" %) |(% style="width:45px" %)Metadataflow (MetadataflowDefinition) 620 -|(% style="width:127px" %)process|(% style="width:45px" %)Process 621 -|(% style="width:127px" %) |(% style="width:45px" %)ProcessStep 622 -|(% style="width:127px" %) |(% style="width:45px" %)Transition 623 -|(% style="width:127px" %)registry|(% style="width:45px" %)ProvisionAgreement 624 -|(% style="width:127px" %) |(% style="width:45px" %)AttachmentConstraint 625 -|(% style="width:127px" %) |(% style="width:45px" %)ContentConstraint 626 -|(% style="width:127px" %) |(% style="width:45px" %)Subscription 627 -|(% style="width:127px" %)mapping|(% style="width:45px" %)StructureMap 628 -|(% style="width:127px" %) |(% style="width:45px" %)StructureSet 629 -|(% style="width:127px" %) |(% style="width:45px" %)ComponentMap 630 -|(% style="width:127px" %) |(% style="width:1745px" %)ConceptSchemeMap 631 -|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationSchemeMap 632 -|(% style="width:127px" %) |(% style="width:1745px" %)CodelistMap 633 -|(% style="width:127px" %) |(% style="width:1745px" %)CategorySchemeMap 634 -|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomyMap 635 -|(% style="width:127px" %) |(% style="width:1745px" %)ConceptMap 636 -|(% style="width:127px" %) |(% style="width:1745px" %)OrganisationMap 637 -|(% style="width:127px" %) |(% style="width:1745px" %)CodeMap 638 -|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodelistMap 639 -|(% style="width:127px" %) |(% style="width:1745px" %)CategoryMap 640 -|(% style="width:127px" %) |(% style="width:1745px" %)HybridCodeMap 641 -|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategoryMap 642 -|(% style="width:127px" %)codelist|(% style="width:1745px" %)Codelist 643 -|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCodelist 644 -|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy 645 -|(% style="width:127px" %) |(% style="width:1745px" %)Hierarchy 646 -|(% style="width:127px" %) |(% style="width:1745px" %)Code 647 -|(% style="width:127px" %) |(% style="width:1745px" %)HierarchicalCode 648 -|(% style="width:127px" %) |(% style="width:1745px" %)Level 649 -|(% style="width:127px" %)categoryscheme|(% style="width:1745px" %)CategoryScheme 650 -|(% style="width:127px" %) |(% style="width:1745px" %)Category 651 -|(% style="width:127px" %) |(% style="width:1745px" %)Categorisation 652 -|(% style="width:127px" %) |(% style="width:1745px" %)ReportingTaxonomy 653 -|(% style="width:127px" %) |(% style="width:1745px" %)ReportingCategory 654 -|(% style="width:127px" %)conceptscheme|(% style="width:1745px" %)ConceptScheme 655 -|(% style="width:127px" %) |(% style="width:1745px" %)Concept 656 -|(% style="width:127px" %)transformation|(% style="width:1745px" %)TransformationScheme 657 -|(% style="width:127px" %) |(% style="width:1745px" %)Transformation 658 -|(% style="width:127px" %) |(% style="width:1745px" %)CustomTypeScheme 659 -|(% style="width:127px" %) |(% style="width:1745px" %)CustomType 660 -|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisationScheme 661 -|(% style="width:127px" %) |(% style="width:1745px" %)NamePersonalisation 662 -|(% style="width:127px" %) |(% style="width:1745px" %)VtlCodelistMapping 663 -|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptMapping 664 -|(% style="width:127px" %) |(% style="width:1745px" %)VtlDataflowMapping 665 -|(% style="width:127px" %) |(% style="width:1745px" %)VtlConceptSchemeMapping 666 -|(% style="width:127px" %) |(% style="width:1745px" %)RulesetScheme 667 -|(% style="width:127px" %) |(% style="width:1745px" %)Ruleset 668 -|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperatorScheme 669 -|(% style="width:127px" %) |(% style="width:1745px" %)UserDefinedOperator 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** 670 670 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 + 671 671 **Table 2: SDMX-IM Packages and Contained Classes** 672 672 702 + 673 673 === 6.2.4 URN Identification components of SDMX objects === 674 674 675 675 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. ... ... @@ -678,50 +678,78 @@ 678 678 679 679 Note that for brevity the URN examples omit the prefix. All URNs have the prefix 680 680 681 - >urn:sdmx.org.sdmx.infomodel.{package}.{classname}=711 +urn:sdmx.org.sdmx.infomodel.{package}.{classname}= 682 682 683 - (% style="width:1091.29px" %)684 -| (% style="width:250px" %)**SDMX Class**|(% style="width:444px" %)**Key attribute(s)**|(% style="width:396px" %)**Example of URN**685 -| (% 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" %)(((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.|((( 686 686 IMF 717 + 718 + 687 687 Sub agency in the IMF AGENCIES 720 + 721 + 688 688 IMF.SubAgency1 689 689 ))) 690 -|(% style="width:250px" %)*ConceptScheme|(% style="width:444px" %)conceptSchemeAgencyId:conceptSchemeId(ve rsion)|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0) 691 -|(% style="width:250px" %)Concept|(% style="width:444px" %)conceptSchemeAgencyId: 692 -conceptSchemeId(version).conceptId|(% style="width:396px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0).FREQ 693 -|(% style="width:250px" %)*Codelist|(% style="width:444px" %)codeListAgencyId:codeListId(version)|(% style="width:396px" %)SDMX:CL_FREQ(1.0) 694 -|(% style="width:250px" %)Code|(% style="width:444px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:396px" %)SDMX:CL_FREQ(1.0).Q 695 -|(% style="width:250px" %)((( 696 -*Hierarchical Codelist 697 -)))|(% style="width:444px" %)hierachicalCodelistAgencyId: hierarchicalCodelistId(version)|(% style="width:396px" %)((( 698 -UNESCO:CL_EXP_SOURCE(1.0(% style="background-color:transparent" %)) 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 + 699 699 ))) 700 -|(% style="width:250px" %)Hierarchy|(% style="width:444px" %)((( 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|((( 701 701 hierachicalcodeListAgencyId: 750 + 702 702 hierarchicalcodelistId(version).Hierarchy 703 -)))|(% style="width:396px" %)UNESCO:CL_EXP_SOURCE(1.0). 704 -H-C-GOV 705 -|(% style="width:250px" %)Level|(% style="width:444px" %)((( 752 +)))|UNESCO:CL_EXP_SOURCE(1.0). H-C-GOV 753 +|Level|((( 706 706 hierachicalcodeListAgencyId: 755 + 707 707 hierarchicalcodelistId(version).Hierarchy.Level 708 -)))|( % style="width:396px" %)(((757 +)))|((( 709 709 ESTAT:HCL_REGION(1.0).H_1.COUNTRY 759 + 760 + 710 710 ))) 711 -| (% 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_CODE1712 -| (% style="width:250px" %)*DataStructure|(% style="width:444px" %)dataStructureDefintitionAgencyId: dataStructureDefintitionId(version)|(% style="width:396px" %)TFFS:EXT_DEBT(1.0)713 -|( % style="width:250px" %)(((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 +|((( 714 714 Dimension 766 + 715 715 Descriptor 768 + 716 716 Measure 770 + 717 717 Descriptor 772 + 718 718 Attribute 774 + 719 719 Descriptor 720 -)))|( % style="width:444px" %)(((776 +)))|((( 721 721 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 778 + 722 722 componentListId 780 + 723 723 where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition) 724 -)))|( % style="width:396px" %)(((782 +)))|((( 725 725 TFFS:EXT_DEBT(1.0).DimensionDescriptor 726 726 727 727 TFFS:EXT_DEBT(1.0).MeasureDescriptor ... ... @@ -728,124 +728,181 @@ 728 728 729 729 TFFS:EXT_DEBT(1.0).AttributeDescriptor 730 730 ))) 731 -|( % style="width:250px" %)(((789 +|((( 732 732 GroupDimension 791 + 733 733 Descriptor 734 -)))|( % style="width:444px" %)(((793 +)))|((( 735 735 dataStructureDefinitionAgencyId: dataStructureDefinitionId(version). 795 + 736 736 groupDimensionDescriptorId 737 -)))| (% style="width:396px" %)TFFS:EXT_DEBT(1.0).SIBLING738 -| (% style="width:250px" %)Dimension|(% style="width:444px" %)(((797 +)))|TFFS:EXT_DEBT(1.0).SIBLING 798 +|Dimension|((( 739 739 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 800 + 740 740 dimensionId 741 -)))| (% style="width:396px" %)TFFS:EXT_DEBT(1.0).FREQ742 -| (% style="width:250px" %)TimeDimension|(% style="width:444px" %)(((802 +)))|TFFS:EXT_DEBT(1.0).FREQ 803 +|TimeDimension|((( 743 743 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 805 + 744 744 timeDimensionId 745 -)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).TIME_PERIOD 746 -|(% style="width:250px" %)Measure Dimension|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). 747 -measureDimensionId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).STOCK_FLOW 748 -|(% style="width:250px" %)DataAttrribute|(% style="width:444px" %)dataStructureDefinitionAgencyId: dataStructureDefinition (version). dataAttributeId|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_STATUS 749 -|(% style="width:250px" %)PrimaryMeasure|(% style="width:444px" %)((( 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|((( 750 750 dataStructureDefinitionAgencyId: dataStructureDefinition (version). 816 + 751 751 primaryMeasureId 752 -)))|(% style="width:396px" %)TFFS:EXT_DEBT(1.0).OBS_VALUE 753 -|(% style="width:250px" %)((( 754 -*Category Scheme 755 -)))|(% style="width:444px" %)categorySchemeAgencyId: 756 -categorySchemeId(version)|(% style="width:396px" %)IMF:SDDS(1.0) 757 -|(% style="width:250px" %)Category|(% style="width:444px" %)categorySchemeAgencyId: 758 -categorySchemeId(version). 759 -categoryId.categoryId categoryId.categoryId etc.|(% style="width:396px" %)((( 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.|((( 760 760 IMF:SDDS(1.0): 826 + 761 761 level_1_category.level_2_category … 762 762 ))) 763 -|(% style="width:250px" %)((( 764 -*Reporting Taxonomy 765 -)))|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version)|(% style="width:396px" %) IMF:REP_1(1.0) 766 -|(% style="width:250px" %)ReportingCategory|(% style="width:444px" %)reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|(% style="width:396px" %)((( 829 +|((( 830 +*Reporting 831 + 832 +Taxonomy 833 +)))|reportingTaxonomyAgencyId: reportingTaxonomyId(version)| IMF:REP_1(1.0) 834 +|ReportingCategory|reportingTaxonomyAgencyId: reportingTaxonomyId(version) reportingcategoryId.reportingcategoryId|((( 767 767 IMF:REP_1(1.0): 836 + 768 768 level_1_repcategory.level_2_repcategory … 769 769 ))) 770 -|(% style="width:250px" %)*Categorisation|(% style="width:444px" %)categorisationAgencyId: categorisationId(version)|(% style="width:396px" %)IMF:cat001(1.0) 771 -|(% style="width:250px" %)((( 772 -*Organisation Unit Scheme 773 -)))|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version)|(% style="width:396px" %)ECB:ORGANISATIONS(1.0) 774 -|(% style="width:250px" %)Organisation Unit|(% style="width:444px" %)organisationUnitSchemeAgencyId: organisationUnitSchemeId(version). organisationUnitId|(% style="width:396px" %)ECB:ORGANISATIONS(1.0).1F 775 -|(% style="width:250px" %)*AgencyScheme|(% style="width:444px" %)agencySchemeAgencyId: agencySchemeId(version)|(% style="width:396px" %)ECB:AGENCIES(1.0) 839 +|*Categorisation|categorisationAgencyId: categorisationId(version)|IMF:cat001(1.0) 840 +|((( 841 +*Organisation 776 776 777 -|(% style="width:262px" %)Agency|(% style="width:369px" %)agencySchemeAgencyId: agencySchemeId(version). agencyId|(% style="width:1262px" %)ECB:AGENCY(1.0).AA 778 -|(% style="width:262px" %)((( 779 -*DataProvider Scheme 780 -)))|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0) 781 -|(% style="width:262px" %)DataProvider|(% style="width:369px" %)dataProviderSchemeAgencyId: dataProviderSchemeId(version) dataProviderId|(% style="width:1262px" %)SDMX:DATA_PROVIDERS(1.0).PROVIDER_1 782 -|(% style="width:262px" %)((( 783 -*DataConsumer Scheme 784 -)))|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version)|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0) 785 -|(% style="width:262px" %)Data Consumer|(% style="width:369px" %)dataConsumerSchemeAgencyId: dataConsumerSchemeId(version) dataConsumerId|(% style="width:1262px" %)SDMX:DATA_CONSUMERS(1.0).CONSUMER_1 786 -|(% style="width:262px" %)((( 787 -*Metadata Structure 788 -)))|(% style="width:369px" %)MSDAgencyId:MSDId(version)|(% style="width:1262px" %)IMF:SDDS_MSD(1.0) 789 -|(% style="width:262px" %)MetadataTarget|(% style="width:369px" %)((( 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|((( 790 790 MSDAgencyId: 870 + 791 791 MSDId(version).metadataTargetId 792 -)))| (% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY793 -|( % style="width:262px" %)(((872 +)))|IMF:SDDS_MSD(1.0).AGENCY 873 +|((( 794 794 Dimension 875 + 795 795 DescriptorValues 877 + 796 796 Target 797 -)))|( % style="width:369px" %)(((879 +)))|((( 798 798 MSDAgencyId: MSDId(version). 881 + 799 799 metadataTargetId.keyDescriptorValueTargetId 800 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.KEY 801 -|(% style="width:262px" %)Identifiable Object Target|(% style="width:369px" %)((( 802 -MSDAgencyId: MSDId(version).metadataTargetId.identifiableObjectTargetId 803 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.STR-OBJECT 804 -|(% style="width:262px" %)DataSetTarget|(% style="width:369px" %)((( 883 +)))|IMF:SDDS_MSD(1.0).AGENCY.KEY 884 +|Identifiable ObjectTarget|((( 805 805 MSDAgencyId: 806 -MSDId(version).metadataTargetId.dataSetTargetId 807 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.D1101 808 -|(% style="width:262px" %)PeportPeriod Target|(% style="width:369px" %)((( 809 -MSDAgencyId: MSDId(version).metadataTargetId.reportPeriodTargetId 810 -)))|(% style="width:1262px" %)IMF:SDDS_MSD(1.0).AGENCY.REP_PER 811 811 812 -|(% style="width:251px" %)((( 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 +|((( 813 813 ReportStructure 814 -)))|(% style="width:442px" %)((( 815 -MSDAgencyId: MSDId(version).reportStructureId 816 -)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT 817 -|(% style="width:251px" %)((( 818 -Metadata Attribute 819 -)))|(% style="width:442px" %)((( 820 -MSDAgencyId: MSDId(version).reportStructureId.metadataattri buteID 821 -)))|(% style="width:1178px" %)IMF:SDDS_MSD(1.0).AGENCY_REPORT.COMPILATION 822 -|(% style="width:251px" %)*Dataflow|(% style="width:442px" %)dataflowAgencyId: dataflowId(version)|(% style="width:1178px" %)TFFS:CRED_EXT_DEBT(1.0) 823 -|(% style="width:251px" %)*Provision Agreement|(% style="width:442px" %)((( 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|((( 824 824 provisionAgreementAgencyId:provisionAgreem entId(version) 825 -)))|(% style="width:1178px" %)((( 929 + 930 + 931 +)))|((( 826 826 TFFS:CRED_EXT_DEBT_AB(1.0) 933 + 934 + 935 + 827 827 ))) 828 -|(% style="width:251px" %)((( 829 -*Content Constraint 830 -)))|(% style="width:442px" %)constraintAgencyId:ContentConstraintId(versio n)|(% style="width:1178px" %)TFFS:CREDITOR_DATA_CONTENT(1.0) 831 -|(% style="width:251px" %)((( 832 -*Attachment Constraint 833 -)))|(% style="width:442px" %)((( 937 +|((( 938 +*Content 939 + 940 +Constraint 941 +)))|constraintAgencyId:ContentConstraintId(versio n)|TFFS:CREDITOR_DATA_CONTENT(1.0) 942 +|((( 943 +*Attachment 944 + 945 +Constraint 946 +)))|((( 834 834 constraintAgencyId: 835 835 836 836 attachmentConstraintId(version) 837 -)))| (% style="width:1178px" %)TFFS:CREDITOR_DATA_ATTACHMENT_CONSTRAINT_ONE(1.0)838 -| (% style="width:251px" %)*Metadataflow|(% style="width:442px" %)metadataflowAgencyId: metadataflowId(version)|(% style="width:1178px" %)IMF:SDDS_FLOW(1.0)839 -| (% style="width:251px" %)*StructureSet|(%style="width:442px" %)structureSetAgencyId: structureSetId(version)|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0)840 -| (% style="width:251px" %)StructureMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version). structureMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2841 -| (% style="width:251px" %)Component Map|(% style="width:442px" %)(((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|((( 842 842 structureSetAgencyId: structureSetId(version). 843 843 844 844 structureMapId. componentMapId 845 -)))| (% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).TABLE1_TABLE2. REFAREA_REPCOUNTRY846 -| (% style="width:251px" %)CodelistMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version). codelistMapId|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY847 -| (% style="width:251px" %)CodeMap|(%style="width:442px" %)structureSetAgencyId: structureSetId(version).|(% style="width:1178px" %)SDMX:BOP_STRUCTURES(1.0).CLREFAREA_CLREPCOUNTRY. DE_GER958 +)))|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 848 848 962 + 963 + 849 849 | |((( 850 850 codeListMapId. 851 851 ... ... @@ -852,7 +852,9 @@ 852 852 codeMapId 853 853 )))| 854 854 |((( 855 -CategorySchemeMap 970 +Category 971 + 972 +SchemeMap 856 856 )))|structureSetAgencyId: structureSetId(version). categorySchemeMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT 857 857 |CategoryMap|structureSetAgencyId: structureSetId(version). categorySchemeMapId. categoryMapId|SDMX:BOP_STRUCTURES(1.0).SDMX_EUROSTAT.TOURISM_M AP 858 858 |Organisation SchemeMap|structureSetAgencyId: structureSetId(version). organisationSchemeMapId|SDMX:BOP_STRUCTURES(1.0).DATA_PROVIDER_MAP ... ... @@ -866,53 +866,71 @@ 866 866 structureSetAgencyId: structureSetId(version). conceptSchemeMapId. 867 867 868 868 conceptMapId 986 + 869 869 870 870 )))|SDMX:BOP_STRUCTURES(1.0).SDMX_OECD.COVERAGE_AVAI LABILITY 871 871 |((( 872 -ReportingTaxonomyMap 990 +Reporting 991 + 992 +TaxonomyMap 873 873 )))|structureSetAgencyId: structureSetId(version). reportingTaxonomyMapId|SDMX:BOP_STRUCTURES(1.0).TAXMAP 874 874 |((( 875 -ReportingCategoryMap 995 +Reporting 996 + 997 +CategoryMap 876 876 )))|((( 877 877 structureSetAgencyId: structureSetId(version). 1000 + 878 878 reportngCategoryId 879 879 )))|SDMX:BOP_STRUCTURES(1.0).TAXMAP.TOPCAT 880 880 1004 + 1005 + 881 881 |((( 882 -HybridCodelistMap 883 -)))|structureSetAgencyId: structureSetId(version). 884 -hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 1007 +HybridCodelist 1008 + 1009 +Map 1010 +)))|structureSetAgencyId: structureSetId(version). hybridCodelistMapId.|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP 885 885 |HybridCodeMap|structureSetAgencyId: structureSetId(version). hybridCodelistMapId. hybridCodeMapId|SDMX:BOP_STRUCTURES(1.0).COUNTRY_HIERARCHYMAP.CO DEMAP1 886 886 |*Process|processAgencyId: processId{version]|BIS:PROCESS1(1.0) 887 887 |ProcessStep|((( 888 888 processAgencyId: processId(version). 1015 + 889 889 processStepId 890 890 )))|BIS:PROCESS1(1.0).STEP1 891 891 |Transition|((( 892 892 processAgencyId: processId(version). 1020 + 893 893 processStepId transitionId 894 894 )))|BIS:PROCESS1(1.0).STEP1.TRANSITION1 895 895 |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. 896 896 |((( 897 -*Transformation Scheme 1025 +*Transformation 1026 + 1027 +Scheme 898 898 )))|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0) 899 899 |Transformation|((( 900 900 transformationSchemeAgencyId transformationSchemeId(version) 1031 + 901 901 transformationId 902 902 )))|ECB:TRANSFORMATION_SCHEME(1.0).TRANS_1 903 903 |CustomType Scheme|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0) 904 904 1036 + 1037 + 905 905 |CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0).CUSTOM_TYPE_1 906 906 |((( 907 907 Name 1041 + 908 908 Personalisation 1043 + 909 909 Scheme 910 910 )))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0) 911 911 |((( 912 912 Name 1048 + 913 913 Personalisation 914 -)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) 915 -namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234 1050 +)))|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0).PSN1234 916 916 |VtlMapping Scheme|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0) 917 917 |VtlCodelist Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0).ABZ 918 918 |VtlConcept Mapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0).XYA ... ... @@ -925,12 +925,15 @@ 925 925 |RulesetScheme|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0) 926 926 |Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0).SET111 927 927 |((( 928 -UserDefinedOperatorScheme 1063 +UserDefined 1064 + 1065 +OperatorScheme 929 929 )))|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2) 930 930 |UserDefined Operator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2).OS267 931 931 932 -**Table 3: Table of identification components for SDMX Identifiable Artefacts** 1069 +7**Table 3: Table of identification components for SDMX Identifiable Artefacts** 933 933 1071 + 934 934 = 7 Implementation Notes = 935 935 936 936 == 7.1 Structural Definition Metadata == ... ... @@ -951,72 +951,109 @@ 951 951 952 952 The following table lists the Maintainable Artefacts. 953 953 954 -(% style="width:640.294px" %) 955 -|(% colspan="2" rowspan="1" style="width:186px" %)**Maintainable Artefacts**|(% style="width:206px" %)**Content** 956 -|(% style="width:171px" %)**Abstract Class**|(% style="width:232px" %)**Concrete Class**|(% style="width:206px" %) 957 -|(% style="width:171px" %)Item Scheme|(% style="width:232px" %)Codelist|(% style="width:206px" %)Code 958 -|(% style="width:171px" %) |(% style="width:232px" %)Concept Scheme|(% style="width:206px" %)Concept 959 -|(% style="width:171px" %) |(% style="width:232px" %)Category Scheme|(% style="width:206px" %)Category 960 -|(% style="width:171px" %) |(% style="width:232px" %)Organisation Unit Scheme|(% style="width:206px" %)Organisation Unit 961 -|(% style="width:171px" %) |(% style="width:232px" %)Agency Scheme|(% style="width:206px" %)Agency 962 -|(% style="width:171px" %) |(% style="width:232px" %)Data Provider Scheme|(% style="width:206px" %)Data Provider 963 -|(% style="width:171px" %) |(% style="width:232px" %)Data Consumer Scheme|(% style="width:206px" %)Data Consumer 964 -|(% style="width:171px" %) |(% style="width:232px" %)Reporting Taxonomy|(% style="width:206px" %)Reporting Category 965 -|(% style="width:171px" %) |(% style="width:232px" %)Transformation Scheme|(% style="width:206px" %)Transformation 966 -|(% style="width:171px" %) |(% style="width:232px" %)Custom Type Scheme|(% style="width:206px" %)Custom Type 967 -|(% style="width:171px" %) |(% style="width:232px" %)Name Personalisation Scheme|(% style="width:206px" %)Name Personalisation 968 -|(% style="width:171px" %) |(% style="width:232px" %)Vtl Mapping Scheme|(% style="width:206px" %)Vtl Codelist Mapping 969 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Dataflow Mapping 970 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)Vtl Concept Scheme Mapping 971 -|(% style="width:171px" %) |(% style="width:232px" %)Ruleset Scheme|(% style="width:206px" %)Ruleset 972 -|(% style="width:171px" %) |(% style="width:232px" %)User Defined Operator Scheme|(% style="width:206px" %)User Defined Operator 973 -|(% style="width:171px" %) |(% style="width:232px" %) |(% style="width:206px" %)User Defined Operator 974 -|(% style="width:171px" %)Structure|(% style="width:232px" %)Data Structure Definition|(% style="width:206px" %)((( 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" %)((( 975 975 Dimension Descriptor 1120 + 976 976 Group Dimension 1122 + 977 977 Descriptor 1124 + 978 978 Dimension 1126 + 979 979 Measure Dimension 1128 + 980 980 Time Dimension 1130 + 981 981 Attribute Descriptor 1132 + 982 982 Data Attribute 1134 + 983 983 Measure Descriptor 1136 + 984 984 Primary Measure 985 985 ))) 986 -|(% style="width:171px" %) |(% style="width:232px" %)Metadata Structure Definition|(% style="width:206px" %)((( 987 -Metadata Target, Dimension Descriptor 1139 +| |(% colspan="2" %) |(% colspan="2" %)Metadata Structure Definition|(% colspan="2" %)((( 1140 +Metadata Target, 1141 + 1142 +Dimension Descriptor 1143 + 988 988 Values Target Identifiable 1145 + 989 989 Object Target 1147 + 990 990 Report Period Target 1149 + 991 991 Data SetTarget 1151 + 992 992 Report Structure 1153 + 993 993 Metadata Attribute 994 994 ))) 995 -|(% style="width:171px" %)Structure Usage|(%style="width:232px" %)Dataflow Definition|(%style="width:206px" %)996 -|(% style="width:171px" %) |(%style="width:232px" %)Metadataflow Definition|(%style="width:206px" %)997 -|(% style="width:171px" %)None|(%style="width:232px" %)Process|(%style="width:206px" %)Process Step998 -|(% style="width:171px" %)None|(%style="width:232px" %)Structure Set|(%style="width:206px" %)(((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 Step 1159 +| |(% colspan="2" %)None|(% colspan="2" %)Structure Set|(% colspan="2" %)((( 999 999 Component Map 1161 + 1000 1000 Concept Scheme Map 1163 + 1001 1001 Codelist Map 1165 + 1002 1002 Category Scheme Map 1167 + 1003 1003 Reporting Taxonomy Map 1169 + 1004 1004 Organisation Scheme Map 1171 + 1005 1005 Concept Map 1173 + 1006 1006 Code Map 1175 + 1007 1007 Category Map 1177 + 1008 1008 Organisation Map 1179 + 1009 1009 Reporting Category Map 1181 + 1010 1010 Hybrid Codelist Map 1183 + 1011 1011 Hybrid Code Map 1012 1012 ))) 1013 -|(% style="width:171px" %)None|(%style="width:232px" %)Provision Agreement|(%style="width:206px" %)1014 -|(% style="width:171px" %)None|(%style="width:232px" %)Hierarchical Codelist|(%style="width:206px" %)(((1186 +| |(% colspan="2" %)None|(% colspan="2" %)Provision Agreement|(% colspan="2" %) 1187 +| |(% colspan="2" %)None|(% colspan="2" %)Hierarchical Codelist|(% colspan="2" %)((( 1015 1015 Hierarchy 1189 + 1016 1016 Hierarchical Code 1017 1017 ))) 1192 +| | | | | | | 1018 1018 1019 -**able 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1194 +**Table 4: Table of Maintainable Artefacts for Structural Definition Metadata** 1020 1020 1021 1021 === 7.1.2 Item Scheme, Structure === 1022 1022 ... ... @@ -1023,7 +1023,10 @@ 1023 1023 The artefacts included in the structural definitions are: 1024 1024 1025 1025 * All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme - Agency Scheme, Data Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme) 1026 -* All types of Structure (Data Structure Definition, Metadata Structure Definition) 1201 +* All types of Structure (Data Structure Definition, Metadata Structure 1202 + 1203 +Definition) 1204 + 1027 1027 * All types of Structure Usage (Dataflow Definition, Metadataflow Definition) 1028 1028 1029 1029 === 7.1.3 Structure Usage === ... ... @@ -1042,8 +1042,6 @@ 1042 1042 1043 1043 ==== 7.1.3.3 Structure Usage Model ==== 1044 1044 1045 -[[image:1747829078194-749.png]] 1046 - 1047 1047 **Figure 10: SDMX-IM of links from Structure Usage to Category** 1048 1048 1049 1049 In addition to the maintenance of the Dataflow Definition and the Metadataflow Definition the following links must be maintained in the registry: ... ... @@ -1070,10 +1070,10 @@ 1070 1070 1071 1071 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. 1072 1072 1073 -[[image:1747829109466-595.png]] 1074 1074 1075 1075 **Figure 11: SDMX-IM of the Data Provider** 1076 1076 1252 + 1077 1077 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 1078 1078 1079 1079 [[image:1747824123019-181.jpeg]] ... ... @@ -1082,10 +1082,8 @@ 1082 1082 1083 1083 The diagram below is a logical representation of the data required in order to maintain Provision Agreements. 1084 1084 1085 -[[image:1747829139951-378.png]] 1086 1086 1087 -(% class="wikigeneratedid" id="HFigure13:LogicalclassdiagramoftheinformationcontainedintheProvisionAgreement" %) 1088 -**Figure 13: Logical class diagram of the information contained in the Provision Agreement** 1262 +==== Figure 13: Logical class diagram of the information contained in the Provision Agreement ==== 1089 1089 1090 1090 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. 1091 1091 ... ... @@ -1113,12 +1113,13 @@ 1113 1113 1114 1114 === 7.3.3 Data and Metadata Constraints: Model === 1115 1115 1116 -[[image:1747829204737-370.png]] 1117 1117 1118 -**Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts** 1119 1119 1120 - The class diagramaboveshows that DataProvider, DataflowDefinition, MetadataflowDefinition, ProvisionAgreement,DataStructureDefinition, MetadataStructureDefinition, SimpleDatasource and QueryDatasourceare all concrete sub-classes of ConstrainableArtefactandcan thereforehave Constraints specified. Note that the actual Constraint as submitted is associatedtothe reference classes which inherit from ConstrainableRef:theseare usedto refer to the classes to whichthe Constraintapplies.1292 +==== Figure 15: Logical class diagram showing inheritance between and reference to constrainable artifacts ==== 1121 1121 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 + 1122 1122 The content of the Constraint can be found in the SDMX Information Model document. 1123 1123 1124 1124 == 7.4 Data and Metadata Registration == ... ... @@ -1139,7 +1139,7 @@ 1139 1139 1140 1140 [[image:1747824123025-411.jpeg]] 1141 1141 1142 -**Figure 16: Schematic of the Objects Concerned with Registration** 1317 + **Figure 16: Schematic of the Objects Concerned with Registration** 1143 1143 1144 1144 ==== 7.4.2.2 Registration Request Model ==== 1145 1145 ... ... @@ -1153,14 +1153,11 @@ 1153 1153 1154 1154 The Registration has an action attribute which takes one of the following values: 1155 1155 1156 -(% style="width:970.294px" %) 1157 -|(% style="width:212px" %)**Action Attribute Value**|(% style="width:756px" %)**Behaviour** 1158 -|(% style="width:212px" %)Append|(% style="width:756px" %)Add this Registration to the registry 1159 -|(% style="width:212px" %)Replace|(% style="width:756px" %)Replace the existing Registration with identified by the id in the Registration of the Submit Registration Request 1160 -|(% style="width:212px" %)Delete|(% style="width:756px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request 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 1161 1161 1162 -[[image:1747829290890-122.png]] 1163 - 1164 1164 **Figure 17: Logical Class Diagram of Registration of Data and Metadata** 1165 1165 1166 1166 The Query Datasource is an abstract class that represents a data source which can understand an SDMX-ML query (SOAPDatasource) or RESTful query ... ... @@ -1175,19 +1175,25 @@ 1175 1175 1176 1176 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. 1177 1177 1178 -|(% style="width:185px" %)**Indexing Required**|(% style="width:1686px" %)**Registration Process Activity** 1179 -|(% style="width:185px" %)indexTimeSeries|(% style="width:1686px" %)Extract all the series keys and create a KeySet(s) Constraint. 1180 -|(% style="width:185px" %)indexDataSet|(% style="width:1686px" %)((( 1181 -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. 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. 1182 1182 ))) 1183 -| (% style="width:185px" %)indexReportingPeriod|(% style="width:1686px" %)(((1357 +|indexReportingPeriod|((( 1184 1184 This applies only to a registered dataset. 1359 + 1185 1185 Extract the Reporting Begin and Reporting End from the Header of the Message containing the data set, and create a Reference Period constraint. 1186 1186 ))) 1187 -| (% style="width:185px" %)indexAttributes|(% style="width:1686px" %)(((1362 +|indexAttributes|((( 1188 1188 **Data Set** 1364 + 1189 1189 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 + 1190 1190 **Metadata Set** 1368 + 1191 1191 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. 1192 1192 ))) 1193 1193 ... ... @@ -1197,13 +1197,14 @@ 1197 1197 1198 1198 === 7.4.3 Registration Response === 1199 1199 1200 -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”.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 1201 1201 1380 +“Success”, “Warning” or “Failure”. 1381 + 1202 1202 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. 1203 1203 1204 1204 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: 1205 1205 1206 -[[image:1747829477882-750.png]] 1207 1207 1208 1208 **Figure 18: Logical class diagram showing the registration response** 1209 1209 ... ... @@ -1213,12 +1213,15 @@ 1213 1213 1214 1214 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. 1215 1215 1216 -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”.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 1217 1217 1218 - === 7.5.1SubscriptionLogical Class Diagram ===1397 +“notification”. 1219 1219 1220 - [[image:1747829554603-150.png]]1399 + 7.5.1Subscription Logical Class Diagram 1221 1221 1401 + 1402 +[[image:1747824123028-257.png]] 1403 + 1222 1222 **Figure 19: Logical Class Diagram of the Subscription** 1223 1223 1224 1224 === 7.5.2 Subscription Information === ... ... @@ -1225,58 +1225,73 @@ 1225 1225 1226 1226 Regardless of the type of registry/repository events being observed, a subscription always contains: 1227 1227 1228 -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. 1229 -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. 1230 -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. 1231 -1. A selector which specifies which type of events are of interest. The set of event types is: 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. 1232 1232 1233 -|(% style="width:319px" %)**Event Type**|(% style="width:1553px" %)**Comment** 1234 -|(% style="width:319px" %)STRUCTURAL_REPOSITORY_EVENTS|(% style="width:1553px" %)Life-cycle changes to Maintainable Artefacts in the structural metadata repository. 1235 -|(% 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. 1236 -|(% 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. 1237 -|(% style="width:319px" %)ALL_EVENTS|(% style="width:1553px" %)All events of the specified EventType 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. 1238 1238 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 + 1239 1239 === 7.5.3 Wildcard Facility === 1240 1240 1241 1241 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: 1242 1242 1243 -* agencyID 1244 -* id 1245 -* version 1428 + agencyID 1246 1246 1430 + id 1431 + 1432 + version 1433 + 1247 1247 Examples of wildcarded identifier components for an identified object type of Codelist are shown below. 1248 1248 1249 -//AgencyID = % 1436 +AgencyID = % 1437 + 1250 1250 Id = % 1251 -Version = %// 1252 1252 1440 +Version = % 1441 + 1253 1253 This subscribes to all Codelists of all versions for all agencies. 1254 1254 1255 -//AgencyID = AGENCY1 1444 +AgencyID = AGENCY1 1445 + 1256 1256 Id = CODELIST1 1257 -Version = %// 1258 1258 1448 +Version = % 1449 + 1259 1259 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1260 1260 1261 -//AGENCY1 1452 +AGENCY1 1453 + 1262 1262 AgencyID = AGENCY1 1455 + 1263 1263 Id = % 1264 -Version = %// 1265 1265 1458 +Version = % 1459 + 1266 1266 This subscribes to all versions of all Codelist objects maintained by the agency 1267 1267 1268 -//AGENCY1 1462 +AGENCY1 1463 + 1269 1269 AgencyID = % 1465 + 1270 1270 Id = CODELIST1 1271 -Version = %// 1272 1272 1468 +Version = % 1469 + 1273 1273 This subscribes to all versions of Codelist CODELIST1 maintained by the agency 1274 1274 1275 - //AGENCY1//1472 +AGENCY1 1276 1276 1277 1277 Note that if the subscription is to the latest version then this can be achieved by the * character 1278 1278 1279 - //i.e. Version = *//1476 +i.e. Version = * 1280 1280 1281 1281 Note that a subscription using the URN mechanism cannot use wildcard characters. 1282 1282 ... ... @@ -1288,15 +1288,16 @@ 1288 1288 1289 1289 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: 1290 1290 1291 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1292 -|(% style="width:405px" %)DataProvider|(% style="width:1467px" %)Any datasets or metadata sets registered by the specified data provider will activate the notification. 1293 -|(% style="width:405px" %)ProvisionAgreement|(% style="width:1467px" %)Any datasets or metadata sets registered for the provision agreement will activate the notification. 1294 -|(% style="width:405px" %)Dataflow (&Metadataflow)|(% style="width:1467px" %)Any datasets or metadata sets registered for the specified dataflow (or metadataflow) will activate the notification. 1295 -|(% 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 1296 -|(% style="width:405px" %)**Selector**|(% style="width:1467px" %)**Comment** 1297 -|(% style="width:405px" %) |(% style="width:1467px" %)activate the notification. 1298 -|(% 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. 1299 1299 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 + 1300 1300 The event will also capture the semantic of the registration: deletion or replacement of an existing registration or a new registration. 1301 1301 1302 1302 == 7.6 Notification == ... ... @@ -1303,10 +1303,8 @@ 1303 1303 1304 1304 === 7.6.1 Logical Class Diagram === 1305 1305 1306 -[[image:1747829675568-610.png]] 1307 1307 1308 -(% class="wikigeneratedid" id="HFigure20:LogicalClassDiagramoftheNotification" %) 1309 -**Figure 20: Logical Class Diagram of the Notification** 1505 +==== Figure 20: Logical Class Diagram of the Notification ==== 1310 1310 1311 1311 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. 1312 1312 ... ... @@ -1326,3 +1326,5 @@ 1326 1326 === 7.6.3 Registration Event Component === 1327 1327 1328 1328 The notification will contain the Registration. 1525 + 1526 +
- 1747824504225-229.png
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -xwiki:XWiki.helena - Size
-
... ... @@ -1,1 +1,0 @@ 1 -52.8 KB - Content
- 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