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

From version 21.2
edited by Helena
on 2025/05/15 14:07
Change comment: There is no comment for this version
To version 21.11
edited by Helena
on 2025/05/15 14:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -11,7 +11,7 @@
11 11  |(% style="width:188px" %)1.0|(% style="width:205px" %)October 2021|(% style="width:441px" %)Public release for SDMX 3.0
12 12  )))
13 13  
14 -= {{id name="_Toc93831"/}}1 Introduction =
14 += 1 Introduction =
15 15  
16 16  The business vision for SDMX envisages the promotion of a “data sharing” model to facilitate low-cost, high-quality statistical data and metadata exchange. Data sharing reduces the reporting burden of organisations by allowing them to publish data once and let their counterparties “pull” data and related metadata as required. The scenario is based on:
17 17  
... ... @@ -33,12 +33,10 @@
33 33  
34 34  These architectural standards address the ‘how’, rather than the ‘what’, and are aimed at enabling existing SDMX standards to achieve their mission. The architectural standards address registry services, which initially comprise:
35 35  
36 -• structural metadata repository
36 +* structural metadata repository
37 +* data and metadata registration
38 +* query
37 37  
38 -• data and metadata registration
39 -
40 -• query
41 -
42 42  The registry services outlined in this specification are designed to help the SDMX community manage the proliferation of SDMX assets and to support data sharing for reporting and dissemination.
43 43  
44 44  = {{id name="_Toc93832"/}}2 Scope and Normative Status =
... ... @@ -81,7 +81,8 @@
81 81  
82 82  [[image:SDMX 3-0-0 SECTION 5 FINAL-1.0_en_28806f51.jpg||height="539" width="443"]]
83 83  
84 -====== Figure 1: Schematic of the Basic Structural Artefacts in the SDMX-IM ======
82 +(% class="wikigeneratedid" id="HFigure1:SchematicoftheBasicStructuralArtefactsintheSDMX-IM" %)
83 +**Figure 1: Schematic of the Basic Structural Artefacts in the SDMX-IM**
85 85  
86 86  Note that in Figure 1 (but also most of the relevant subsequent figures) terms that include both data and metadata have been used. For example:
87 87  
... ... @@ -108,7 +108,7 @@
108 108  
109 109  Notifying interested parties of newly published or re-published data, reference metadata or changes in structural metadata involves:
110 110  
111 - registry support of a subscription-based notification service which sends an email or notifies an HTTP address announcing all published data that meets the criteria contained in the subscription request.
110 +* registry support of a subscription-based notification service which sends an email or notifies an HTTP address announcing all published data that meets the criteria contained in the subscription request.
112 112  
113 113  == {{id name="_Toc93838"/}}3.5 Discovery ==
114 114  
... ... @@ -167,9 +167,8 @@
167 167  
168 168  The registry interfaces are invoked in one of two ways:
169 169  
170 -*
171 -*1. The interface is the name of the root node of the SDMX-ML document
172 -*1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document.
169 +1. The interface is the name of the root node of the SDMX-ML document
170 +1. The interface is invoked as a child element of the RegistryInterface message where the RegistryInterface is the root node of the SDMX-ML document.
173 173  
174 174  In addition to these interfaces the registry must support a mechanism for submitting and querying for structural metadata. This is detailed in sections 5.2.2 and 5.2.3.
175 175  
... ... @@ -245,23 +245,22 @@
245 245  * that the components (Dimensions, Attributes, Measures, Metadata Attributes, etc.) are consistent with the Data Structure Definition or Metadata Structure Definition;
246 246  * 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. The Registration has an action attribute which takes one of the following values:
247 247  
248 -|**Action Attribute Value**|**Behaviour**
249 -|Append|Add this registration to the registry
250 -|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
251 -|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
246 +(% style="width:755.294px" %)
247 +|(% style="width:187px" %)**Action Attribute Value**|(% style="width:566px" %)**Behaviour**
248 +|(% style="width:187px" %)Append|(% style="width:566px" %)Add this registration to the registry
249 +|(% style="width:187px" %)Replace|(% style="width:566px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
250 +|(% style="width:187px" %)Delete|(% style="width:566px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
252 252  
253 253  The Registration has three Boolean attributes which may be present to determine how an SDMX compliant dataset or metadataset indexing application must index the datasets or metadatasets upon registration. The indexing application behaviour is as follows:
254 254  
255 -|**Boolean Attribute**|**Behaviour if Value is “true”**
256 -|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadataset registration)
257 -|indexDataSet|(((
258 -A compliant indexing application must index the range of actual
259 -
260 -(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.
261 -
254 +(% style="width:759.294px" %)
255 +|(% style="width:191px" %)**Boolean Attribute**|(% style="width:565px" %)**Behaviour if Value is “true”**
256 +|(% style="width:191px" %)indexTimeSeries|(% style="width:565px" %)A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadataset registration)
257 +|(% style="width:191px" %)indexDataSet|(% style="width:565px" %)(((
258 +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.
262 262  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
263 263  )))
264 -|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset. The validity period of the Metadatasets may also be indexed.
261 +|(% style="width:191px" %)indexReportingPeriod|(% style="width:565px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset. The validity period of the Metadatasets may also be indexed.
265 265  
266 266  === {{id name="_Toc93850"/}}5.2.5 Data and Reference Metadata Discovery ===
267 267  
... ... @@ -295,8 +295,9 @@
295 295  
296 296  Given the above, the behaviour described in the following table concerns either draft Artefacts using semantic versioning or any Artefacts using the old versioning scheme. Nevertheless, in the case of semantic versioning the registry must respect the versioning rules when performing the actions below. For example, it is not possible to replace a non-draft Artefact that follows semantic versioning, unless a newer version is introduced according to the semantic versioning rules. Furthermore, even when draft Artefacts are submitted, the registry has to verify semantic versioning is respected against the previous non-draft versions. It is worth noting that the rules for semantic versioning and replacing or maintaining semantically versioned Artefacts applies to externally shared Artefacts. This means that any system may internally perform any change within a version of an Artefact, until the latter is shared outside of that system or becomes public. Then (as also explained in the SDMX Standards Section 6 “Technical Notes”) the Artefacts must adhere to the Semantic Versioning rules.
297 297  
298 -|**Interface**|**Behaviour**
299 -|All|(((
295 +(% style="width:757.294px" %)
296 +|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour**
297 +|(% style="width:188px" %)All|(% style="width:542px" %)(((
300 300  1. If the action is set to “replace” (or a maintainable Artefact is PUT or POSTed) then the entire contents of the existing maintainable object in the Registry MUST be replaced by the object submitted.
301 301  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.
302 302  1. If the action is set to “delete” (or a maintainable Artefact is DELETEd) then the Registry MUST verify that the object can be deleted. In order to qualify for deletion, the object must:
... ... @@ -303,14 +303,14 @@
303 303  
304 304  a) Be a draft version.
305 305  )))
306 -|**Interface**|**Behaviour**
307 -| |(((
308 -b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
304 +|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour**
305 +|(% style="width:188px" %) |(% style="width:542px" %)(((
306 +b) Not be explicitly{{footnote}}With semantic versioning, it is allowed to reference a range of artefacts, e.g., a DSD referencing a Codelist with version 1.2.3+ means all patch versions greater than 1.2.3. This means that deleting 1.2.4-draft does not break integrity of the aforementioned DSD.{{/footnote}} referenced from any other object in the Registry.
309 309  
310 310  4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
311 311  )))
312 -|Structure submission|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.
313 -|SubmitRegistrationRequest|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. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query.
310 +|(% style="width:188px" %)Structure submission|(% style="width:542px" %)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.
311 +|(% style="width:188px" %)SubmitRegistrationRequest|(% style="width:542px" %)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. For a queryable datasource the Registry MAY validate that the source exists and can accept an SDMX data query.
314 314  
315 315  = {{id name="_Toc93853"/}}6 Identification of SDMX Objects =
316 316  
... ... @@ -340,27 +340,28 @@
340 340  :
341 341  
342 342  (((
343 -|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes**
344 -|(% rowspan="4" %)//Annotable//|AnnotationTitle|C|string|
345 -|AnnotationType|C|string|
346 -|AnnotationURN|C|string|
347 -|AnnotationText in the form of InternationalString|C| |This can have languagespecific variants
348 -|(% rowspan="4" %)//Identifiable//|All content as for //Annotable// plus| | |
349 -|id|M|string|
350 -|uri|C|string|
351 -|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.
352 -|(% rowspan="3" %)//Nameable//|All content as for //Identifiable// plus| | |
353 -|Name in the form of InternationalString|M|string|This can have language specific variants.
354 -|Description in the form of InternationalString|C|string|This can have language specific variants.
355 -|(% rowspan="4" %)//Versionable//|All content as for //Identifiable// plus| | |
356 -|version|M|string|This is the version number according to SDMX versioning rules.
357 -|validFrom|C|Date/time|
358 -|validTo|C|Date/time|
359 -|//Maintainable//|All content as for //Versionable// plus| | |
360 -| |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 structureURL, each of which must return a valid SDMX-ML file.
361 -| |serviceURL|C|string|The url of the service that can be queried for this resource.
362 -| |structureURL|C|string|The url of the resource.
363 -| |(Maintenance) organisationId|M|string|The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider.
341 +(% style="width:1052.29px" %)
342 +|**Object Type**|(% style="width:241px" %)**Data Attributes**|(% style="width:156px" %)**Status**|**Data type**|(% style="width:457px" %)**Notes**
343 +|(% rowspan="4" %)//Annotable//|(% style="width:241px" %)AnnotationTitle|(% style="width:156px" %)C|string|(% style="width:457px" %)
344 +|(% style="width:241px" %)AnnotationType|(% style="width:156px" %)C|string|(% style="width:457px" %)
345 +|(% style="width:241px" %)AnnotationURN|(% style="width:156px" %)C|string|(% style="width:457px" %)
346 +|(% style="width:241px" %)AnnotationText in the form of InternationalString|(% style="width:156px" %)C| |(% style="width:457px" %)This can have languagespecific variants
347 +|(% rowspan="4" %)//Identifiable//|(% style="width:241px" %)All content as for //Annotable// plus|(% style="width:156px" %) | |(% style="width:457px" %)
348 +|(% style="width:241px" %)id|(% style="width:156px" %)M|string|(% style="width:457px" %)
349 +|(% style="width:241px" %)uri|(% style="width:156px" %)C|string|(% style="width:457px" %)
350 +|(% style="width:241px" %)urn|(% style="width:156px" %)C|string|(% style="width:457px" %)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.
351 +|(% rowspan="3" %)//Nameable//|(% style="width:241px" %)All content as for //Identifiable// plus|(% style="width:156px" %) | |(% style="width:457px" %)
352 +|(% style="width:241px" %)Name in the form of InternationalString|(% style="width:156px" %)M|string|(% style="width:457px" %)This can have language specific variants.
353 +|(% style="width:241px" %)Description in the form of InternationalString|(% style="width:156px" %)C|string|(% style="width:457px" %)This can have language specific variants.
354 +|(% rowspan="4" %)//Versionable//|(% style="width:241px" %)All content as for //Identifiable// plus|(% style="width:156px" %) | |(% style="width:457px" %)
355 +|(% style="width:241px" %)version|(% style="width:156px" %)M|string|(% style="width:457px" %)This is the version number according to SDMX versioning rules.
356 +|(% style="width:241px" %)validFrom|(% style="width:156px" %)C|Date/time|(% style="width:457px" %)
357 +|(% style="width:241px" %)validTo|(% style="width:156px" %)C|Date/time|(% style="width:457px" %)
358 +|//Maintainable//|(% style="width:241px" %)All content as for //Versionable// plus|(% style="width:156px" %) | |(% style="width:457px" %)
359 +| |(% style="width:241px" %)isExternalReference|(% style="width:156px" %)C|boolean|(% style="width:457px" %)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 structureURL, each of which must return a valid SDMX-ML file.
360 +| |(% style="width:241px" %)serviceURL|(% style="width:156px" %)C|string|(% style="width:457px" %)The url of the service that can be queried for this resource.
361 +| |(% style="width:241px" %)structureURL|(% style="width:156px" %)C|string|(% style="width:457px" %)The url of the resource.
362 +| |(% style="width:241px" %)(Maintenance) organisationId|(% style="width:156px" %)M|string|(% style="width:457px" %)The object must be linked to a maintenance organisation, i.e., Agency or Metadata Provider.
364 364  )))
365 365  
366 366  **Table 1: Common Attributes of Object Types**
... ... @@ -409,32 +409,8 @@
409 409  
410 410  An example of this is shown in the XML snippet below:
411 411  
412 -**<str:Codelists>**
411 +[[image:1747307906944-697.png]]
413 413  
414 -**<str:Codelist id="CL_FREQ" agencyID="SDMX" version="1.0.0">**
415 -
416 -**<com:Name xml:lang="en">Standard frequency Codelist</com:Name>**
417 -
418 -**</str:Codelist>**
419 -
420 -**<str:Codelist id="CL_FREQ" agencyID="AA" version="1.0.0">**
421 -
422 -**<com:Name xml:lang="en">Codelist maintained by agency AA</com:Name>**
423 -
424 -**</str:Codelist>**
425 -
426 -**<str:Codelist id="CL_FREQ" agencyID="AA.CC" version="1.0.0">**
427 -
428 -**<com:Name xml:lang="en">Codelist maintained by the AA unit CC</com:Name>**
429 -
430 -**</str:Codelist>**
431 -
432 -**<str:Codelist id="CL_FREQ" agencyID="BB.CC" version="1.0.0">**
433 -
434 -**<com:Name xml:lang="en">Codelist maintained by the BB unit CC</com:Name>**
435 -
436 -**</str:Codelist>**
437 -
438 438  **Figure 8: Example Showing Use of Agency Identifiers**
439 439  
440 440  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.
... ... @@ -441,14 +441,16 @@
441 441  
442 442  Following the same principles, the Metadata Provider is the maintenance organisation for a special subset of Maintainable Artefacts, i.e., the Metadatasets; the latter are the containers of reference metadata combined with a target that those metadata refer to.
443 443  
444 -===== {{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) =====
419 +=== {{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) ===
445 445  
446 -**6.2.2.1 Introduction**
421 +==== 6.2.2.1 Introduction ====
447 447  
448 448  To provide interoperability between SDMX Registry/Repositories in a distributed network environment, it is important to have a scheme for uniquely identifying (and thus accessing) all first-class (Identifiable) SDMX-IM objects. Most of these unique identifiers are composite (containing maintenance agency, or parent object identifiers), and there is a need to be able to construct a unique reference as a single string. This is achieved by having a globally unique identifier called a universal resource name (URN) which is generated from the actual identification components in the SDMX-RR APIs. In other words, the URN for any Identifiable Artefact is constructed from its component identifiers (agency, id, version etc.).
449 449  
450 -**6.2.2.2 URN Structure //__Case Rules for URN__//**//&nbsp;//
425 +==== 6.2.2.2 URN Structure ====
451 451  
427 +===== **//__Case Rules for URN__//** =====
428 +
452 452  For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows:
453 453  
454 454  SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobjectid(maintainedobject-version).*containerobject-id.object-id
... ... @@ -459,7 +459,7 @@
459 459  
460 460  The Maintenance agency identifier is separated from the maintainable artefact identifier by a colon ‘:’. All other identifiers in the SDMX URN syntax are separated by a period ‘.’. The version information is encapsulated in parentheses ‘()’ and adheres to the SDMX versioning rules, as explained in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning.
461 461  
462 -**6.2.2.3 Explanation of the generic structure**
439 +==== 6.2.2.3 Explanation of the generic structure ====
463 463  
464 464  In the explanation below the actual object that is the target of the URN is called the **actual object**.
465 465  
... ... @@ -469,10 +469,32 @@
469 469  
470 470  The packages are:
471 471  
472 -base codelist conceptscheme datastructure categoryscheme registry metadatastructure process structuremapping transformation
449 +base
473 473  
474 -**maintainable-object-id** is the identifier of the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object. **maintainable-object-version** is the version, according to the SDMX versioning rules, of the maintainable object and is enclosed in parentheses ‘()’, which are always present. **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 (Codelist) and has no intermediary container object, whereas a MetadataAttribute has an intermediary container object (MetadataAttributeDescriptor) and may have an intermediary container object, which is its parent MetadataAttribute. 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 AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor 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 AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor is not included when the actual object is a DataAttribute or a Dimension/ TimeDimension, or a Measure.
451 +codelist
475 475  
453 +conceptscheme
454 +
455 +datastructure
456 +
457 +categoryscheme
458 +
459 +registry
460 +
461 +metadatastructure
462 +
463 +process
464 +
465 +structuremapping
466 +
467 +transformation
468 +
469 +**maintainable-object-id** is the identifier of the maintainable object. This will always be present as all identifiable objects are either a maintainable object or contained in a maintainable object.
470 +
471 +**maintainable-object-version** is the version, according to the SDMX versioning rules, of the maintainable object and is enclosed in parentheses ‘()’, which are always present.
472 +
473 +**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 (Codelist) and has no intermediary container object, whereas a MetadataAttribute has an intermediary container object (MetadataAttributeDescriptor) and may have an intermediary container object, which is its parent MetadataAttribute. 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 AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor 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 AttributeDescriptor, DimensionDescriptor, and MeasureDescriptor is not included when the actual object is a DataAttribute or a Dimension/ TimeDimension, or a Measure.
474 +
476 476  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 containerobject-id.
477 477  
478 478  For example, the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
... ... @@ -479,7 +479,7 @@
479 479  
480 480  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.
481 481  
482 -//__**Generic Examples of the URN Structure**__//
481 +===== //__**Generic Examples of the URN Structure**__// =====
483 483  
484 484  __Actual object is a maintainable__
485 485  
... ... @@ -505,7 +505,7 @@
505 505  
506 506  SDMXPrefix.SDMX-IM-package-name.classname=agencyid:maintained-objectid(version).contained-object-id.contained-object-id contained-objectid.object-id
507 507  
508 -//__**Concrete Examples of the URN Structure**__//
507 +===== //__**Concrete Examples of the URN Structure**__// =====
509 509  
510 510  The Data Structure Definition CRED_EXT_DEBT of legacy version 2.1 maintained by the toplevel Agency TFFS would have the URN:
511 511  
... ... @@ -534,85 +534,86 @@
534 534  
535 535  The SDMX-RR MUST be able to resolve the unique identifier of an SDMX artefact and to produce an SDMX-ML rendering of that artefact if it is located in the Registry.
536 536  
537 -===== {{id name="_Toc93859"/}}6.2.3 Table of SDMX-IM Packages and Classes =====
536 +=== {{id name="_Toc93859"/}}6.2.3 Table of SDMX-IM Packages and Classes ===
538 538  
539 539  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.
540 540  
541 -|**Package**|**URN class name (model class name where this is different)**
542 -|base|Agency
543 -| |AgencyScheme
544 -| |DataConsumer
545 -| |DataConsumerScheme
546 -| |DataProvider
547 -| |DataProviderScheme
548 -| |MetadataProvider
549 -| |MetadataProviderScheme
550 -| |OrganisationUnit
551 -| |OrganisationUnitScheme
552 -|datastructure|AttributeDescriptor
553 -| |DataAttribute
554 -| |Dataflow
555 -| |DataStructure (DataStructureDefinition)
556 -| |Dimension
557 -| |DimensionDescriptor
558 -| |GroupDimensionDescriptor
559 -| |Measure
560 -| |MeasureDescriptor
561 -| |TimeDimension
562 -| |
563 -|metadatastructure|MetadataAttribute
564 -| |MetadataAttributeDescriptor
565 -| |MetadataStructure MetadataStructureDefinition)
566 -| |Metadataflow
567 -| |MetadataSet
568 -| |
569 -|process|Process
570 -| |ProcessStep
571 -| |Transition
572 -| |
573 -|registry|DataConstraint
574 -| |MetadataConstraint
575 -| |MetadataProvisionAgreement
576 -| |ProvisionAgreement
577 -| |Subscription
578 -| |
579 -|structuremapping|CategorySchemeMap
580 -| |ConceptSchemeMap
581 -| |OrganisationSchemeMap
582 -| |ReportingTaxonomyMap
583 -| |RepresentationMap
584 -| |StructureMap
585 -| |
586 -|codelist|Code
587 -| |Codelist
588 -| |HierarchicalCode
589 -| |Hierarchy
590 -| |HierarchyAssociation
591 -| |Level
592 -| |ValueList
593 -| |
594 -|categoryscheme|Categorisation
595 -| |Category
596 -| |CategoryScheme
597 -| |ReportingCategory
598 -| |ReportingTaxonomy
599 -|conceptscheme|Concept
600 -| |ConceptScheme
601 -| |
602 -|transformation|CustomType
603 -| |CustomTypeScheme
604 -| |NamePersonalisation
605 -| |NamePersonalisationScheme
606 -| |Ruleset
607 -| |RulesetScheme
608 -| |Transformation
609 -| |TransformationScheme
610 -| |UserDefinedOperator
611 -| |UserDefinedOperatorScheme
612 -| |VtlCodelistMapping
613 -| |VtlConceptMapping
614 -| |VtlDataflowMapping
615 -| |VtlMappingScheme
540 +(% style="width:651.294px" %)
541 +|(% style="width:134px" %)**Package**|(% style="width:502px" %)**URN class name (model class name where this is different)**
542 +|(% style="width:134px" %)base|(% style="width:502px" %)Agency
543 +|(% style="width:134px" %) |(% style="width:502px" %)AgencyScheme
544 +|(% style="width:134px" %) |(% style="width:502px" %)DataConsumer
545 +|(% style="width:134px" %) |(% style="width:502px" %)DataConsumerScheme
546 +|(% style="width:134px" %) |(% style="width:502px" %)DataProvider
547 +|(% style="width:134px" %) |(% style="width:502px" %)DataProviderScheme
548 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProvider
549 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProviderScheme
550 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationUnit
551 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationUnitScheme
552 +|(% style="width:134px" %)datastructure|(% style="width:502px" %)AttributeDescriptor
553 +|(% style="width:134px" %) |(% style="width:502px" %)DataAttribute
554 +|(% style="width:134px" %) |(% style="width:502px" %)Dataflow
555 +|(% style="width:134px" %) |(% style="width:502px" %)DataStructure (DataStructureDefinition)
556 +|(% style="width:134px" %) |(% style="width:502px" %)Dimension
557 +|(% style="width:134px" %) |(% style="width:502px" %)DimensionDescriptor
558 +|(% style="width:134px" %) |(% style="width:502px" %)GroupDimensionDescriptor
559 +|(% style="width:134px" %) |(% style="width:502px" %)Measure
560 +|(% style="width:134px" %) |(% style="width:502px" %)MeasureDescriptor
561 +|(% style="width:134px" %) |(% style="width:502px" %)TimeDimension
562 +|(% style="width:134px" %) |(% style="width:502px" %)
563 +|(% style="width:134px" %)metadatastructure|(% style="width:502px" %)MetadataAttribute
564 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataAttributeDescriptor
565 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataStructure MetadataStructureDefinition)
566 +|(% style="width:134px" %) |(% style="width:502px" %)Metadataflow
567 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataSet
568 +|(% style="width:134px" %) |(% style="width:502px" %)
569 +|(% style="width:134px" %)process|(% style="width:502px" %)Process
570 +|(% style="width:134px" %) |(% style="width:502px" %)ProcessStep
571 +|(% style="width:134px" %) |(% style="width:502px" %)Transition
572 +|(% style="width:134px" %) |(% style="width:502px" %)
573 +|(% style="width:134px" %)registry|(% style="width:502px" %)DataConstraint
574 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataConstraint
575 +|(% style="width:134px" %) |(% style="width:502px" %)MetadataProvisionAgreement
576 +|(% style="width:134px" %) |(% style="width:502px" %)ProvisionAgreement
577 +|(% style="width:134px" %) |(% style="width:502px" %)Subscription
578 +|(% style="width:134px" %) |(% style="width:502px" %)
579 +|(% style="width:134px" %)structuremapping|(% style="width:502px" %)CategorySchemeMap
580 +|(% style="width:134px" %) |(% style="width:502px" %)ConceptSchemeMap
581 +|(% style="width:134px" %) |(% style="width:502px" %)OrganisationSchemeMap
582 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingTaxonomyMap
583 +|(% style="width:134px" %) |(% style="width:502px" %)RepresentationMap
584 +|(% style="width:134px" %) |(% style="width:502px" %)StructureMap
585 +|(% style="width:134px" %) |(% style="width:502px" %)
586 +|(% style="width:134px" %)codelist|(% style="width:502px" %)Code
587 +|(% style="width:134px" %) |(% style="width:502px" %)Codelist
588 +|(% style="width:134px" %) |(% style="width:502px" %)HierarchicalCode
589 +|(% style="width:134px" %) |(% style="width:502px" %)Hierarchy
590 +|(% style="width:134px" %) |(% style="width:502px" %)HierarchyAssociation
591 +|(% style="width:134px" %) |(% style="width:502px" %)Level
592 +|(% style="width:134px" %) |(% style="width:502px" %)ValueList
593 +|(% style="width:134px" %) |(% style="width:502px" %)
594 +|(% style="width:134px" %)categoryscheme|(% style="width:502px" %)Categorisation
595 +|(% style="width:134px" %) |(% style="width:502px" %)Category
596 +|(% style="width:134px" %) |(% style="width:502px" %)CategoryScheme
597 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingCategory
598 +|(% style="width:134px" %) |(% style="width:502px" %)ReportingTaxonomy
599 +|(% style="width:134px" %)conceptscheme|(% style="width:502px" %)Concept
600 +|(% style="width:134px" %) |(% style="width:502px" %)ConceptScheme
601 +|(% style="width:134px" %) |(% style="width:502px" %)
602 +|(% style="width:134px" %)transformation|(% style="width:502px" %)CustomType
603 +|(% style="width:134px" %) |(% style="width:502px" %)CustomTypeScheme
604 +|(% style="width:134px" %) |(% style="width:502px" %)NamePersonalisation
605 +|(% style="width:134px" %) |(% style="width:502px" %)NamePersonalisationScheme
606 +|(% style="width:134px" %) |(% style="width:502px" %)Ruleset
607 +|(% style="width:134px" %) |(% style="width:502px" %)RulesetScheme
608 +|(% style="width:134px" %) |(% style="width:502px" %)Transformation
609 +|(% style="width:134px" %) |(% style="width:502px" %)TransformationScheme
610 +|(% style="width:134px" %) |(% style="width:502px" %)UserDefinedOperator
611 +|(% style="width:134px" %) |(% style="width:502px" %)UserDefinedOperatorScheme
612 +|(% style="width:134px" %) |(% style="width:502px" %)VtlCodelistMapping
613 +|(% style="width:134px" %) |(% style="width:502px" %)VtlConceptMapping
614 +|(% style="width:134px" %) |(% style="width:502px" %)VtlDataflowMapping
615 +|(% style="width:134px" %) |(% style="width:502px" %)VtlMappingScheme
616 616  
617 617  **Table 2: SDMX-IM Packages and Contained Classes**
618 618  
... ... @@ -624,136 +624,118 @@
624 624  
625 625  urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
626 626  
627 -|**Classname**|**Ending URN pattern**|**Example**
628 -|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
629 -|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
630 -|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
631 -|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
632 -|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0)
627 +(% style="width:1311.29px" %)
628 +|(% style="width:252px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:418px" %)**Example**
629 +|(% style="width:252px" %)Agency{{footnote}}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. For example, a sub-agency of IMF is referred like this: IMF.SubAgency1{{/footnote}}|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**).AA
630 +|(% style="width:252px" %)//AgencyScheme//|(% style="width:639px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:418px" %)ECB:**AGENCIES**(**1.0**)
631 +|(% style="width:252px" %)//Categorisation//|(% style="width:639px" %)categorisationAgencyId:categorisationId(version)|(% style="width:418px" %)IMF:cat001(1.0.0)
632 +|(% style="width:252px" %)Category|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:418px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
633 +|(% style="width:252px" %)//CategoryScheme//|(% style="width:639px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:418px" %)IMF:SDDS(1.0.0)
633 633  
634 -|**Classname**|**Ending URN pattern**|**Example**
635 -|//CategorySchemeMap//|(((
636 -catSchemeMapAgencyId:catSchemeMapId(version
637 -
638 -)
639 -)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
640 -|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q
641 -|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0)
642 -|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
643 -|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
644 -|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
645 -|//ConceptSchemeMap//|(((
635 +|(% style="width:250px" %)**Classname**|(% style="width:639px" %)**Ending URN pattern**|(% style="width:1049px" %)**Example**
636 +|(% style="width:250px" %)//CategorySchemeMap//|(% style="width:639px" %)(((
637 +catSchemeMapAgencyId:catSchemeMapId(version)
638 +)))|(% style="width:1049px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
639 +|(% style="width:250px" %)Code|(% style="width:639px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0).Q
640 +|(% style="width:250px" %)//Codelist//|(% style="width:639px" %)codeListAgencyId:codeListId(version)|(% style="width:1049px" %)SDMX:CL_FREQ(1.0.0)
641 +|(% style="width:250px" %)ComponentMap|(% style="width:639px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:1049px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
642 +|(% style="width:250px" %)Concept|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
643 +|(% style="width:250px" %)//ConceptScheme//|(% style="width:639px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:1049px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
644 +|(% style="width:250px" %)//ConceptSchemeMap//|(% style="width:639px" %)(((
646 646  conceptSchemeMapAgencyId:conceptSchemeMap
647 -
648 648  Id(version)
649 -)))|SDMX:CONCEPT_MAP(1.0.0)
650 -|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
651 -|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0)
652 -|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS
653 -|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0)
647 +)))|(% style="width:1049px" %)SDMX:CONCEPT_MAP(1.0.0)
648 +|(% style="width:250px" %)CustomType|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:1049px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
649 +|(% style="width:250px" %)//CustomTypeScheme//|(% style="width:639px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:1049px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
650 +|(% style="width:250px" %)DataAttrribute|(% style="width:639px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:1049px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
651 +|(% style="width:250px" %)//DataConstraint//|(% style="width:639px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:1049px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
654 654  
655 -|**Classname**|**Ending URN pattern**|**Example**
656 -|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
657 -|//DataConsumerScheme//|(((
658 -dataConsumerSchemeAgencyId:**DATA_CONSUME**
659 -
660 -**RS**(**1.0**)
661 -)))|SDMX:**DATA_CONSUMERS**(**1.0**)
662 -|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0)
663 -|DataProvider|(((
664 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
665 -
666 -**1.0**).dataProviderId
667 -)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
668 -|//DataProviderScheme//|(((
669 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
670 -
671 -**1.0**)
672 -)))|SDMX:**DATA_PROVIDERS**(**1.0**)
673 -|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0)
674 -|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ
675 -|(((
653 +|(% style="width:248px" %)**Classname**|(% style="width:643px" %)**Ending URN pattern**|(% style="width:1047px" %)**Example**
654 +|(% style="width:248px" %)DataConsumer|(% style="width:643px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
655 +|(% style="width:248px" %)//DataConsumerScheme//|(% style="width:643px" %)(((
656 +dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
657 +)))|(% style="width:1047px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
658 +|(% style="width:248px" %)//Dataflow//|(% style="width:643px" %)dataflowAgencyId:dataflowId(version)|(% style="width:1047px" %)TFFS:CRED_EXT_DEBT(1.0.0)
659 +|(% style="width:248px" %)DataProvider|(% style="width:643px" %)(((
660 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
661 +)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
662 +|(% style="width:248px" %)//DataProviderScheme//|(% style="width:643px" %)(((
663 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
664 +)))|(% style="width:1047px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
665 +|(% style="width:248px" %)//DataStructure//|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0)
666 +|(% style="width:248px" %)Dimension|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).FREQ
667 +|(% style="width:248px" %)(((
676 676  DimensionDescriptor
677 -
678 678  MeasureDescriptor
679 -
680 680  AttributeDescriptor
681 -)))|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(((
671 +)))|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)|(% style="width:1047px" %)(((
682 682  TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
683 -
684 684  TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
685 -
686 686  TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
687 687  )))
688 -|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING
689 -|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
676 +|(% style="width:248px" %)GroupDimensionDescriptor|(% style="width:643px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:1047px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
677 +|(% style="width:248px" %)HierarchicalCode|(% style="width:643px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:1047px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
690 690  
691 -|**Classname**|**Ending URN pattern**|**Example**
692 -|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0)
693 -|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0)
694 -|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1
695 -|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE
696 -|MetadataAttribute|(((
679 +|(% style="width:248px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:1044px" %)**Example**
680 +|(% style="width:248px" %)//Hierarchy//|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0)
681 +|(% style="width:248px" %)//HierarchyAssociation//|(% style="width:646px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:1044px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
682 +|(% style="width:248px" %)Level|(% style="width:646px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:1044px" %)UNESCO:H-C-GOV(1.0.0).LVL1
683 +|(% style="width:248px" %)Measure|(% style="width:646px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:1044px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
684 +|(% style="width:248px" %)MetadataAttribute|(% style="width:646px" %)(((
697 697  msdAgencyId:msdId(version).metadataAttributeId.
698 -
699 699  metadataAttributeId
700 -)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
701 -|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
702 -|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
703 -|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0)
704 -|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
705 -|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**)
706 -|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0)
707 -|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0)
708 -|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0)
687 +)))|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
688 +|(% style="width:248px" %)MetadataAttributeDescriptor|(% style="width:646px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
689 +|(% style="width:248px" %)//MetadataConstraint//|(% style="width:646px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:1044px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
690 +|(% style="width:248px" %)//Metadataflow//|(% style="width:646px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:1044px" %)IMF:SDDS_MDF(1.0.0)
691 +|(% style="width:248px" %)MetadataProvider|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
692 +|(% style="width:248px" %)//MetadataProviderScheme//|(% style="width:646px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:1044px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
693 +|(% style="width:248px" %)//MetadataProvisionAgreement//|(% style="width:646px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:1044px" %)IMF:SDDS_MDF_AB(1.0.0)
694 +|(% style="width:248px" %)//MetadataSet//|(% style="width:646px" %)metadataProviderId:metadataSetId(version)|(% style="width:1044px" %)MD_PROVIDER:METADATASET(1.0.0)
695 +|(% style="width:248px" %)//MetadataStructure//|(% style="width:646px" %)msdAgencyId:msdId(version)|(% style="width:1044px" %)IMF:SDDS_MSD(1.0.0)
709 709  
710 -|**Classname**|**Ending URN pattern**|**Example**
711 -|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234
712 -|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0)
713 -|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0)
714 -|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F
715 -|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0)
716 -|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0)
717 -|ProcessStep|(((
697 +|(% style="width:248px" %)**Classname**|(% style="width:629px" %)**Ending URN pattern**|(% style="width:1061px" %)**Example**
698 +|(% style="width:248px" %)NamePersonalisation|(% style="width:629px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:1061px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
699 +|(% style="width:248px" %)//NamePersonalisationScheme//|(% style="width:629px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:1061px" %)ECB:PSN_SCHEME(1.0.0)
700 +|(% style="width:248px" %)//OrganisationSchemeMap//|(% style="width:629px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:1061px" %)SDMX:AGENCIES_PROVIDERS(1.0.0)
701 +|(% style="width:248px" %)OrganisationUnit|(% style="width:629px" %)organisationUnitSchemeAgencyId:organisationUnitSchemeId(version).organisationUnitId|(% style="width:1061px" %)ECB:ORGANISATIONS(1.0.0).1F
702 +|(% style="width:248px" %)//OrganisationUnitScheme//|(% style="width:629px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:1061px" %)ECB:ORGANISATIONS(1.0.0)
703 +|(% style="width:248px" %)//Process//|(% style="width:629px" %)processAgencyId:processId{version)|(% style="width:1061px" %)BIS:PROCESS1(1.0.0)
704 +|(% style="width:248px" %)ProcessStep|(% style="width:629px" %)(((
718 718  processAgencyId:processId(version).processStepId.
719 -
720 720  processStepId
721 -)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1
722 -|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0)
723 -|ReportingCategory|(((
707 +)))|(% style="width:1061px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1
708 +|(% style="width:248px" %)//ProvisionAgreement//|(% style="width:629px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:1061px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)
709 +|(% style="width:248px" %)ReportingCategory|(% style="width:629px" %)(((
724 724  reportingTaxonomyAgencyId:
725 -
726 726  reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId
727 -)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
728 -|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0)
729 -|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0)
712 +)))|(% style="width:1061px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
713 +|(% style="width:248px" %)//ReportingTaxonomy//|(% style="width:629px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:1061px" %)IMF:REP_1(1.0.0)
714 +|(% style="width:248px" %)//ReportingTaxonomyMap//|(% style="width:629px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:1061px" %)SDMX:RT_MAP(1.0.0)
730 730  
731 -|**Classname**|**Ending URN pattern**|**Example**
732 -|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0)
733 -|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111
734 -|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0)
735 -|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0)
736 -|Subscription|(((
716 +|(% style="width:247px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:1042px" %)**Example**
717 +|(% style="width:247px" %)//RepresentationMap//|(% style="width:649px" %)repMapAgencyId:repMapId(version)|(% style="width:1042px" %)SDMX:REF_AREA_MAPPING(1.0.0)
718 +|(% style="width:247px" %)Ruleset|(% style="width:649px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:1042px" %)ECB:RULESET_23(1.0.0).SET111
719 +|(% style="width:247px" %)//RulesetScheme//|(% style="width:649px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:1042px" %)ECB:RULESET_23(1.0.0)
720 +|(% style="width:247px" %)//StructureMap//|(% style="width:649px" %)structureMapAgencyId:structureMap(version)|(% style="width:1042px" %)SDMX:BOP_STRUCTURES(1.0.0)
721 +|(% style="width:247px" %)Subscription|(% style="width:649px" %)(((
737 737  The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure.
738 -
739 739  The name of the URN is registryURN There is no pre-determined format.
740 -)))|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 registry URN that is returned from the registry in the subscription response message.
741 -|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
742 -|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
743 -|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0)
744 -|**Classname**|**Ending URN pattern**|**Example**
745 -|Transition|(((
724 +)))|(% style="width:1042px" %)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 registry URN that is returned from the registry in the subscription response message.
725 +|(% style="width:247px" %)TimeDimension|(% style="width:649px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:1042px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
726 +|(% style="width:247px" %)Transformation|(% style="width:649px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:1042px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
727 +|(% style="width:247px" %)//TransformationScheme//|(% style="width:649px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:1042px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)
728 +|(% style="width:247px" %)Transition|(% style="width:649px" %)(((
746 746  processAgencyId:processId(version).processStepId.
747 -
748 748  transitionId
749 -)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
750 -|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267
751 -|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0)
752 -|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0)
753 -|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ
754 -|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA
755 -|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ
756 -|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0)
731 +)))|(% style="width:1042px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
732 +|(% style="width:247px" %)UserDefinedOperator|(% style="width:649px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:1042px" %)ECB:OS_CALC(1.2.0).OS267
733 +|(% style="width:247px" %)//UserDefinedOperatorScheme//|(% style="width:649px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:1042px" %)ECB:OS_CALC(1.2.0)
734 +|(% style="width:247px" %)//ValueList//|(% style="width:649px" %)valuelistAgencyId:valuelistId(version)|(% style="width:1042px" %)SDMX:VLIST(1.0.0)
735 +|(% style="width:247px" %)VtlCodelistMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:1042px" %)ECB:CLIST_MP(2.0.0).ABZ
736 +|(% style="width:247px" %)VtlConceptMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:1042px" %)ECB:CLIST_MP(1.0.0).XYA
737 +|(% style="width:247px" %)VtlDataflowMapping|(% style="width:649px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:1042px" %)ECB:CLIST_MP(1.0.0).MOQ
738 +|(% style="width:247px" %)//VtlMappingScheme//|(% style="width:649px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:1042px" %)ECB:CLIST_MP(2.0.0)
757 757  
758 758  **Table 3: Table of identification components for SDMX Identifiable Artefacts**
759 759  
... ... @@ -777,62 +777,54 @@
777 777  
778 778  The following table lists the Maintainable Artefacts.
779 779  
780 -|(% colspan="2" %)**Maintainable Artefacts**|**Content**
781 -|**Abstract Class**|**Concrete Class**|
782 -|Item Scheme|Codelist|Code
783 -| |Concept Scheme|Concept
784 -| |Category Scheme|Category
785 -| |Organisation Unit Scheme|Organisation Unit
786 -| |Agency Scheme|Agency
787 -| |Data Provider Scheme|Data Provider
788 -| |Metadata Provider Scheme|Metadata Provider
789 -| |Data Consumer Scheme|Data Consumer
790 -| |Reporting Taxonomy|Reporting Category
791 -| |Transformation Scheme|Transformation
792 -| |Custom Type Scheme|Custom Type
793 -| |Name Personalisation Scheme|Name Personalisation
794 -| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping
795 -| |Ruleset Scheme|Ruleset
796 -| |User Defined Operator Scheme|User Defined Operator
797 -|Enumerated List|ValueList|Value Item
798 -|Structure|Data Structure Definition|(((
762 +(% style="width:881.294px" %)
763 +|(% colspan="2" style="width:522px" %)**Maintainable Artefacts**|(% style="width:490px" %)**Content**
764 +|(% style="width:198px" %)**Abstract Class**|(% style="width:324px" %)**Concrete Class**|(% style="width:490px" %)
765 +|(% style="width:198px" %)Item Scheme|(% style="width:324px" %)Codelist|(% style="width:490px" %)Code
766 +|(% style="width:198px" %) |(% style="width:324px" %)Concept Scheme|(% style="width:490px" %)Concept
767 +|(% style="width:198px" %) |(% style="width:324px" %)Category Scheme|(% style="width:490px" %)Category
768 +|(% style="width:198px" %) |(% style="width:324px" %)Organisation Unit Scheme|(% style="width:490px" %)Organisation Unit
769 +|(% style="width:198px" %) |(% style="width:324px" %)Agency Scheme|(% style="width:490px" %)Agency
770 +|(% style="width:198px" %) |(% style="width:324px" %)Data Provider Scheme|(% style="width:490px" %)Data Provider
771 +|(% style="width:198px" %) |(% style="width:324px" %)Metadata Provider Scheme|(% style="width:490px" %)Metadata Provider
772 +|(% style="width:198px" %) |(% style="width:324px" %)Data Consumer Scheme|(% style="width:490px" %)Data Consumer
773 +|(% style="width:198px" %) |(% style="width:324px" %)Reporting Taxonomy|(% style="width:490px" %)Reporting Category
774 +|(% style="width:198px" %) |(% style="width:324px" %)Transformation Scheme|(% style="width:490px" %)Transformation
775 +|(% style="width:198px" %) |(% style="width:324px" %)Custom Type Scheme|(% style="width:490px" %)Custom Type
776 +|(% style="width:198px" %) |(% style="width:324px" %)Name Personalisation Scheme|(% style="width:490px" %)Name Personalisation
777 +|(% style="width:198px" %) |(% style="width:324px" %)Vtl Mapping Scheme|(% style="width:490px" %)Vtl Codelist Mapping Vtl Concept Mapping
778 +|(% style="width:198px" %) |(% style="width:324px" %)Ruleset Scheme|(% style="width:490px" %)Ruleset
779 +|(% style="width:198px" %) |(% style="width:324px" %)User Defined Operator Scheme|(% style="width:490px" %)User Defined Operator
780 +|(% style="width:198px" %)Enumerated List|(% style="width:324px" %)ValueList|(% style="width:490px" %)Value Item
781 +|(% style="width:198px" %)Structure|(% style="width:324px" %)Data Structure Definition|(% style="width:490px" %)(((
799 799  Dimension Descriptor
800 -
801 801  Group Dimension Descriptor
802 -
803 803  Dimension
804 -
805 805  Time Dimension
806 -
807 807  Attribute Descriptor
808 -
809 809  Data Attribute
810 -
811 811  Measure Descriptor
812 -
813 813  Measure
814 814  )))
815 -| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute
816 -|Structure Usage|Dataflow|
817 -| |Metadataflow|
818 -|None|Process|Process Step
819 -|None|Structure Map|(((
791 +|(% style="width:198px" %) |(% style="width:324px" %)Metadata Structure Definition|(% style="width:490px" %)Metadata Attribute Descriptor Metadata Attribute
792 +|(% style="width:198px" %)Structure Usage|(% style="width:324px" %)Dataflow|(% style="width:490px" %)
793 +|(% style="width:198px" %) |(% style="width:324px" %)Metadataflow|(% style="width:490px" %)
794 +|(% style="width:198px" %)None|(% style="width:324px" %)Process|(% style="width:490px" %)Process Step
795 +|(% style="width:198px" %)None|(% style="width:324px" %)Structure Map|(% style="width:490px" %)(((
820 820  Component Map
821 -
822 822  Epoch Map
823 -
824 824  Date Pattern Map
825 825  )))
826 -|None|Representation Map|Representation Mapping
827 -|Item Scheme Map|Organisation Scheme Map|Item Map
828 -| |Concept Scheme Map|Item Map
829 -| |Category Scheme Map|Item Map
830 -| |Reporting Taxonomy Map|Item Map
831 -|None|Provision Agreement|
832 -|None|Metadata Provision Agreement|
833 -|None|Hierarchy|Hierarchical Code
834 -|None|Hierarchy Association|
835 -|None|Categorisation|
800 +|(% style="width:198px" %)None|(% style="width:324px" %)Representation Map|(% style="width:490px" %)Representation Mapping
801 +|(% style="width:198px" %)Item Scheme Map|(% style="width:324px" %)Organisation Scheme Map|(% style="width:490px" %)Item Map
802 +|(% style="width:198px" %) |(% style="width:324px" %)Concept Scheme Map|(% style="width:490px" %)Item Map
803 +|(% style="width:198px" %) |(% style="width:324px" %)Category Scheme Map|(% style="width:490px" %)Item Map
804 +|(% style="width:198px" %) |(% style="width:324px" %)Reporting Taxonomy Map|(% style="width:490px" %)Item Map
805 +|(% style="width:198px" %)None|(% style="width:324px" %)Provision Agreement|(% style="width:490px" %)
806 +|(% style="width:198px" %)None|(% style="width:324px" %)Metadata Provision Agreement|(% style="width:490px" %)
807 +|(% style="width:198px" %)None|(% style="width:324px" %)Hierarchy|(% style="width:490px" %)Hierarchical Code
808 +|(% style="width:198px" %)None|(% style="width:324px" %)Hierarchy Association|(% style="width:490px" %)
809 +|(% style="width:198px" %)None|(% style="width:324px" %)Categorisation|(% style="width:490px" %)
836 836  
837 837  **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
838 838  
... ... @@ -842,7 +842,7 @@
842 842  
843 843  • All types of Item Scheme (Codelist, Concept Scheme, Category Scheme, Organisation Scheme, Agency Scheme, Data Provider Scheme, Metadata Provider Scheme, Data Consumer Scheme, Organisation Unit Scheme, Transformation Scheme, Name Personalisation Scheme, Custom Type Scheme, Vtl Mapping Scheme, Ruleset Scheme, User Defined Operator Scheme)
844 844  
845 -• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
819 +• All types of Enumerated List (ValueList){{footnote}}Note that Codelist is also an EnumeratedList.{{/footnote}}
846 846  
847 847  • All types of Structure (Data Structure Definition, Metadata Structure Definition)
848 848  
... ... @@ -1187,3 +1187,5 @@
1187 1187  IMF.SubAgency1
1188 1188  
1189 1189  [[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList.
1164 +
1165 +{{putFootnotes/}}
1747307906944-697.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.helena
Size
... ... @@ -1,0 +1,1 @@
1 +37.9 KB
Content