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