Last modified by Artur on 2025/09/30 13:28

From version 21.10
edited by Helena
on 2025/06/08 16:40
Change comment: There is no comment for this version
To version 21.5
edited by Helena
on 2025/06/08 16:29
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -191,7 +191,7 @@
191 191  
192 192  The SDMX structural artefacts that may be queried are defined in the SDMX structure web service specification which is compatible with this release of the standard __[[https:~~/~~/github.com/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[twg/sdmx>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[->>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]][[rest/blob/master/doc/structures.md>>url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]__[[url:https://github.com/sdmx-twg/sdmx-rest/blob/master/doc/structures.md]]
193 193  
194 -=== 5.2.4 Data and Reference Metadata Registration Service ===
194 +===== {{id name="_Toc90798"/}}5.2.4 Data and Reference Metadata Registration Service =====
195 195  
196 196  This service must implement the following Registry Interfaces:
197 197  
... ... @@ -214,24 +214,23 @@
214 214  
215 215  The Registration has an action attribute which takes one of the following values:
216 216  
217 -(% style="width:893.835px" %)
218 -|(% style="width:241px" %)**Action Attribute Value**|(% style="width:650px" %)**Behaviour**
219 -|(% style="width:241px" %)Append|(% style="width:650px" %)Add this registration to the registry
220 -|(% style="width:241px" %)Replace|(% style="width:650px" %)Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
221 -|(% style="width:241px" %)Delete|(% style="width:650px" %)Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
217 +|**Action Attribute Value**|**Behaviour**
218 +|Append|Add this registration to the registry
219 +|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
220 +|Delete|Delete the existing Registration identified by the id in the Registration of the Submit Registration Request
222 222  
223 223  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:
224 224  
225 -(% style="width:896.835px" %)
226 -|**Boolean Attribute**|(% style="width:712px" %)**Behaviour if Value is “true”**
227 -|indexTimeSeries|(% style="width:712px" %)A compliant indexing application must index all the time series keys
228 -|indexDataSet|(% style="width:712px" %)(((
224 +|**Boolean Attribute**|**Behaviour if Value is “true”**
225 +|indexTimeSeries|A compliant indexing application must index all the time series keys
226 +|indexDataSet|(((
229 229  A compliant indexing application must index the range of actual (present) values for each dimension of the Dataset.
228 +
230 230  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
231 231  )))
232 -|indexReportingPeriod|(% style="width:712px" %)A compliant indexing application must index the time period range(s) for which data are present in the Dataset.
231 +|indexReportingPeriod|A compliant indexing application must index the time period range(s) for which data are present in the Dataset.
233 233  
234 -=== 5.2.5 Data Discovery ===
233 +===== {{id name="_Toc90799"/}}5.2.5 Data Discovery =====
235 235  
236 236  The Data Discovery Service implements the following Registry Interfaces:
237 237  
... ... @@ -238,7 +238,7 @@
238 238  * QueryRegistrationRequest
239 239  * QueryRegistrationResponse
240 240  
241 -=== 5.2.6 Subscription and Notification ===
240 +===== {{id name="_Toc90800"/}}5.2.6 Subscription and Notification =====
242 242  
243 243  The Subscription and Notification Service implements the following Registry Interfaces:
244 244  
... ... @@ -257,32 +257,34 @@
257 257  
258 258  Notification requires that the structural metadata repository and the provisioning metadata repository monitor any event which is of interest to a user (the object of a subscription request query), and to issue an SDMX notification document to the endpoints specified in the relevant subscriptions.
259 259  
260 -=== 5.2.7 Registry Behaviour ===
259 +===== {{id name="_Toc90801"/}}5.2.7 Registry Behaviour =====
261 261  
262 262  The following table defines the behaviour of the SDMX Registry for the various Registry Interface messages. It should be noted, though, that as of SDMX 3.0, an extended versioning scheme newly including semantic versioning is foreseen for all Maintainable Artefacts. Moreover, while the old versioning scheme is allowed, given there is no more a "final" flag, there is no way guaranteeing the consistency across version of a Maintainable, unless semantic versioning is used.
263 263  
264 264  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.
265 265  
266 -(% style="width:982.835px" %)
267 -|(% style="width:217px" %)**Interface**|(% style="width:763px" %)**Behaviour**
268 -|(% style="width:217px" %)All|(% style="width:763px" %)(((
265 +|**Interface**|**Behaviour**
266 +|All|(((
269 269  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.
270 270  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.
271 271  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:
272 272  
273 -a) Be a draft version.
274 -b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
271 +1. Be a draft version.
275 275  
273 +b) Not be explicitly^^[[(% class="wikiinternallink wikiinternallink" %)^^1^^>>path:#sdfootnote1sym||name="sdfootnote1anc"]](%%)^^ referenced from any other object in the Registry.
274 +
276 276  4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
277 277  )))
278 -|(% style="width:217px" %)Structure submission|(% style="width:763px" %)(((
279 -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.
277 +|Structure submission|(((
278 +Structures are submitted at the level of the
279 +
280 +Maintainable Artefact and the behaviour in “All” above is therefore at the level of the Maintainable Artefact.
280 280  )))
281 -|(% style="width:217px" %)SubmitRegistrationRequest|(% style="width:763px" %)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.
282 +|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.
282 282  
283 -= 6 Identification of SDMX Objects =
284 += {{id name="_Toc90802"/}}6 Identification of SDMX Objects =
284 284  
285 -== 6.1 Identification, Versioning, and Maintenance ==
286 +=== {{id name="_Toc90803"/}}6.1 Identification, Versioning, and Maintenance ===
286 286  
287 287  All major classes of the SDMX Information model inherit from one of:
288 288  
... ... @@ -291,7 +291,7 @@
291 291  * //**VersionableArtefact**// – this has all of the above features plus a version number, according to the SDMX versioning rules in SDMX Standards Section 6 “Technical Notes”, paragraph “4.3 Versioning”, and a validity period.
292 292  * //**MaintainableArtefact**// – this has all of the above features, plus registry and structure URIs, and an association to the maintenance organisation of the object.
293 293  
294 -=== 6.1.1 Identification, Naming, Versioning, and Maintenance Model ===
295 +===== {{id name="_Toc90804"/}}6.1.1 Identification, Naming, Versioning, and Maintenance Model =====
295 295  
296 296  [[image:SDMX 3.1 Section 5_en_4a9b2cfc.jpg||height="688" width="587"]]
297 297  
... ... @@ -300,11 +300,13 @@
300 300  The table below shows the identification and related data attributes to be stored in a registry for objects that are one of:
301 301  
302 302  * //Annotable//
303 -* //Identifiable//
304 -* //Nameable//
305 -* //Versionable//
306 -* //Maintainable//
307 307  
305 +//Identifiable// • //Nameable//
306 +
307 +• //Versionable//
308 +
309 +• //Maintainable//
310 +
308 308  | |(% colspan="2" %)**Object Type**|(% colspan="2" %)**Data Attributes**|(% colspan="2" %)**Status**|(% colspan="2" %)**Data type**|(% colspan="2" %)**Notes**
309 309  | |(% colspan="2" rowspan="4" %)//Annotable//|(% colspan="2" %)AnnotationTitle|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
310 310  | |(% colspan="2" %)AnnotationType|(% colspan="2" %)C|(% colspan="2" %)string|(% colspan="2" %)
... ... @@ -349,9 +349,9 @@
349 349  
350 350  **Table 1: Common Attributes of Object Types**
351 351  
352 -== 6.2 Unique identification of SDMX objects ==
355 +=== {{id name="_Toc90805"/}}6.2 Unique identification of SDMX objects ===
353 353  
354 -=== 6.2.1 Agencies and Metadata Providers ===
357 +===== {{id name="_Toc90806"/}}6.2.1 Agencies and Metadata Providers =====
355 355  
356 356  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.
357 357  
... ... @@ -384,11 +384,14 @@
384 384  
385 385  The following organizations maintain an Agency Scheme.
386 386  
387 -* SDMX – contains Agencies AA, BB
388 -* AA – contains Agencies CC, DD
389 -* BB – contains Agencies CC, DD
390 -* DD – Contains Agency EE
390 +• SDMX – contains Agencies AA, BB
391 391  
392 +• AA – contains Agencies CC, DD
393 +
394 +• BB – contains Agencies CC, DD
395 +
396 +• DD – Contains Agency EE
397 +
392 392  Each agency is identified by its full hierarchy excluding SDMX.
393 393  
394 394  e.g., the id of EE as an agencyID is AA.DD.EE
... ... @@ -401,13 +401,13 @@
401 401  
402 402  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.
403 403  
404 -=== 6.2.2 Universal Resource Name (URN) ===
410 +===== {{id name="_Toc90807"/}}6.2.2 Universal Resource Name (URN) =====
405 405  
406 -==== 6.2.2.1 Introduction ====
412 +**6.2.2.1 Introduction**
407 407  
408 408  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.).
409 409  
410 -==== 6.2.2.2 URN Structure //__Case Rules for URN__// ====
416 +**6.2.2.2 URN Structure //__Case Rules for URN__//**// //
411 411  
412 412  For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows:
413 413  
... ... @@ -419,7 +419,7 @@
419 419  
420 420  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.
421 421  
422 -==== 6.2.2.3 Explanation of the generic structure ====
428 +**6.2.2.3 Explanation of the generic structure**
423 423  
424 424  In the explanation below the actual object that is the target of the URN is called the **actual object**.
425 425  
... ... @@ -498,103 +498,103 @@
498 498  
499 499  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.
500 500  
501 -=== 6.2.3 Table of SDMX-IM Packages and Classes ===
507 +===== {{id name="_Toc90808"/}}6.2.3 Table of SDMX-IM Packages and Classes =====
502 502  
503 503  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.
504 504  
505 -(% style="width:750.835px" %)
506 -|(% style="width:222px" %)**Package**|(% style="width:526px" %)**URN class name (model class name where this is different)**
507 -|(% style="width:222px" %)base|(% style="width:526px" %)Agency
508 -|(% style="width:222px" %) |(% style="width:526px" %)AgencyScheme
509 -|(% style="width:222px" %) |(% style="width:526px" %)DataConsumer
510 -|(% style="width:222px" %) |(% style="width:526px" %)DataConsumerScheme
511 -|(% style="width:222px" %) |(% style="width:526px" %)DataProvider
512 -|(% style="width:222px" %) |(% style="width:526px" %)DataProviderScheme
513 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataProvider
514 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataProviderScheme
515 -|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnit
516 -|(% style="width:222px" %) |(% style="width:526px" %)OrganisationUnitScheme
517 -|(% style="width:222px" %) |(% style="width:526px" %)
518 -|(% style="width:222px" %)datastructure|(% style="width:526px" %)AttributeDescriptor
519 -|(% style="width:222px" %) |(% style="width:526px" %)DataAttribute
520 -|(% style="width:222px" %) |(% style="width:526px" %)Dataflow
521 -|(% style="width:222px" %) |(% style="width:526px" %)DataStructure (DataStructureDefinition)
522 -|(% style="width:222px" %) |(% style="width:526px" %)Dimension
523 -|(% style="width:222px" %) |(% style="width:526px" %)DimensionDescriptor
524 -|(% style="width:222px" %) |(% style="width:526px" %)GroupDimensionDescriptor
525 -|(% style="width:222px" %) |(% style="width:526px" %)Measure
526 -|(% style="width:222px" %) |(% style="width:526px" %)MeasureDescriptor
527 -|(% style="width:222px" %) |(% style="width:526px" %)TimeDimension
528 -|(% style="width:222px" %) |(% style="width:526px" %)
529 -|(% style="width:222px" %)metadatastructure|(% style="width:526px" %)MetadataAttribute
530 -|(% style="width:222px" %) |(% style="width:526px" %)MetadataAttributeDescriptor
531 -|(% style="width:222px" %) |(% style="width:526px" %)(((
511 +|**Package**|**URN class name (model class name where this is different)**
512 +|base|Agency
513 +| |AgencyScheme
514 +| |DataConsumer
515 +| |DataConsumerScheme
516 +| |DataProvider
517 +| |DataProviderScheme
518 +| |MetadataProvider
519 +| |MetadataProviderScheme
520 +| |OrganisationUnit
521 +| |OrganisationUnitScheme
522 +| |
523 +|datastructure|AttributeDescriptor
524 +| |DataAttribute
525 +| |Dataflow
526 +| |DataStructure (DataStructureDefinition)
527 +| |Dimension
528 +| |DimensionDescriptor
529 +| |GroupDimensionDescriptor
530 +| |Measure
531 +| |MeasureDescriptor
532 +| |TimeDimension
533 +| |
534 +|metadatastructure|MetadataAttribute
535 +| |MetadataAttributeDescriptor
536 +| |(((
532 532  MetadataStructure
533 533  
534 534  (MetadataStructureDefinition)
535 535  )))
536 536  
542 +:
543 +
537 537  (((
538 -(% style="width:751.835px" %)
539 -|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
540 -|(% style="width:221px" %) |(% style="width:528px" %)Metadataflow
541 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataSet
542 -|(% style="width:221px" %) |(% style="width:528px" %)
543 -|(% style="width:221px" %)process|(% style="width:528px" %)Process
544 -|(% style="width:221px" %) |(% style="width:528px" %)ProcessStep
545 -|(% style="width:221px" %) |(% style="width:528px" %)Transition
546 -|(% style="width:221px" %) |(% style="width:528px" %)
547 -|(% style="width:221px" %)registry|(% style="width:528px" %)DataConstraint
548 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataConstraint
549 -|(% style="width:221px" %) |(% style="width:528px" %)MetadataProvisionAgreement
550 -|(% style="width:221px" %) |(% style="width:528px" %)ProvisionAgreement
551 -|(% style="width:221px" %) |(% style="width:528px" %)Subscription
552 -|(% style="width:221px" %) |(% style="width:528px" %)
553 -|(% style="width:221px" %)structuremapping|(% style="width:528px" %)CategorySchemeMap
554 -|(% style="width:221px" %) |(% style="width:528px" %)ConceptSchemeMap
555 -|(% style="width:221px" %) |(% style="width:528px" %)OrganisationSchemeMap
556 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomyMap
557 -|(% style="width:221px" %) |(% style="width:528px" %)RepresentationMap
558 -|(% style="width:221px" %) |(% style="width:528px" %)StructureMap
559 -|(% style="width:221px" %) |(% style="width:528px" %)
560 -|(% style="width:221px" %)codelist|(% style="width:528px" %)Code
561 -|(% style="width:221px" %) |(% style="width:528px" %)Codelist
562 -|(% style="width:221px" %) |(% style="width:528px" %)HierarchicalCode
563 -|(% style="width:221px" %) |(% style="width:528px" %)Hierarchy
564 -|(% style="width:221px" %) |(% style="width:528px" %)HierarchyAssociation
565 -|(% style="width:221px" %) |(% style="width:528px" %)Level
566 -|(% style="width:221px" %) |(% style="width:528px" %)ValueList
567 -|(% style="width:221px" %) |(% style="width:528px" %)
568 -|(% style="width:221px" %)categoryscheme|(% style="width:528px" %)Categorisation
569 -|(% style="width:221px" %) |(% style="width:528px" %)Category
570 -|(% style="width:221px" %) |(% style="width:528px" %)CategoryScheme
571 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingCategory
572 -|(% style="width:221px" %) |(% style="width:528px" %)ReportingTaxonomy
573 -|(% style="width:221px" %)**Package**|(% style="width:528px" %)**URN class name (model class name where this is different)**
574 -|(% style="width:221px" %) |(% style="width:528px" %)
575 -|(% style="width:221px" %)conceptscheme|(% style="width:528px" %)Concept
576 -|(% style="width:221px" %) |(% style="width:528px" %)ConceptScheme
577 -|(% style="width:221px" %) |(% style="width:528px" %)
578 -|(% style="width:221px" %)transformation|(% style="width:528px" %)CustomType
579 -|(% style="width:221px" %) |(% style="width:528px" %)CustomTypeScheme
580 -|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisation
581 -|(% style="width:221px" %) |(% style="width:528px" %)NamePersonalisationScheme
582 -|(% style="width:221px" %) |(% style="width:528px" %)Ruleset
583 -|(% style="width:221px" %) |(% style="width:528px" %)RulesetScheme
584 -|(% style="width:221px" %) |(% style="width:528px" %)Transformation
585 -|(% style="width:221px" %) |(% style="width:528px" %)TransformationScheme
586 -|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperator
587 -|(% style="width:221px" %) |(% style="width:528px" %)UserDefinedOperatorScheme
588 -|(% style="width:221px" %) |(% style="width:528px" %)VtlCodelistMapping
589 -|(% style="width:221px" %) |(% style="width:528px" %)VtlConceptMapping
590 -|(% style="width:221px" %) |(% style="width:528px" %)VtlDataflowMapping
591 -|(% style="width:221px" %) |(% style="width:528px" %)VtlMappingScheme
592 -|(% style="width:221px" %) |(% style="width:528px" %)
545 +|**Package**|**URN class name (model class name where this is different)**
546 +| |Metadataflow
547 +| |MetadataSet
548 +| |
549 +|process|Process
550 +| |ProcessStep
551 +| |Transition
552 +| |
553 +|registry|DataConstraint
554 +| |MetadataConstraint
555 +| |MetadataProvisionAgreement
556 +| |ProvisionAgreement
557 +| |Subscription
558 +| |
559 +|structuremapping|CategorySchemeMap
560 +| |ConceptSchemeMap
561 +| |OrganisationSchemeMap
562 +| |ReportingTaxonomyMap
563 +| |RepresentationMap
564 +| |StructureMap
565 +| |
566 +|codelist|Code
567 +| |Codelist
568 +| |HierarchicalCode
569 +| |Hierarchy
570 +| |HierarchyAssociation
571 +| |Level
572 +| |ValueList
573 +| |
574 +|categoryscheme|Categorisation
575 +| |Category
576 +| |CategoryScheme
577 +| |ReportingCategory
578 +| |ReportingTaxonomy
579 +|**Package**|**URN class name (model class name where this is different)**
580 +| |
581 +|conceptscheme|Concept
582 +| |ConceptScheme
583 +| |
584 +|transformation|CustomType
585 +| |CustomTypeScheme
586 +| |NamePersonalisation
587 +| |NamePersonalisationScheme
588 +| |Ruleset
589 +| |RulesetScheme
590 +| |Transformation
591 +| |TransformationScheme
592 +| |UserDefinedOperator
593 +| |UserDefinedOperatorScheme
594 +| |VtlCodelistMapping
595 +| |VtlConceptMapping
596 +| |VtlDataflowMapping
597 +| |VtlMappingScheme
598 +| |
593 593  )))
594 594  
595 595  **Table 2: SDMX-IM Packages and Contained Classes**
596 596  
597 -=== 6.2.4 URN Identification components of SDMX objects ===
603 +===== {{id name="_Toc90809"/}}6.2.4 URN Identification components of SDMX objects =====
598 598  
599 599  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.
600 600  
... ... @@ -602,56 +602,67 @@
602 602  
603 603  urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
604 604  
605 -(% style="width:1272.83px" %)
606 -|(% style="width:290px" %)**Classname**|(% style="width:649px" %)**Ending URN pattern**|(% style="width:332px" %)**Example**
607 -|(% style="width:290px" %)Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**).AA
608 -|(% style="width:290px" %)//AgencyScheme//|(% style="width:649px" %)agencySchemeAgencyId:**AGENCIES**(**1.0**)|(% style="width:332px" %)ECB:**AGENCIES**(**1.0**)
609 -|(% style="width:290px" %)//Categorisation//|(% style="width:649px" %)categorisationAgencyId:categorisationId(version)|(% style="width:332px" %)IMF:cat001(1.0.0)
610 -|(% style="width:290px" %)Category|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|(% style="width:332px" %)IMF:SDDS(1.0.0):level_1_category.level_2_category …
611 -|(% style="width:290px" %)//CategoryScheme//|(% style="width:649px" %)categorySchemeAgencyId:categorySchemeId(versi on)|(% style="width:332px" %)IMF:SDDS(1.0.0)
611 +|**Classname**|**Ending URN pattern**|**Example**
612 +|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
613 +|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
614 +|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
615 +|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
616 +|//CategoryScheme//|categorySchemeAgencyId:categorySchemeId(versi on)|IMF:SDDS(1.0.0)
612 612  
613 -|(% style="width:292px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
614 -|(% style="width:292px" %)//CategorySchemeMap//|(% style="width:647px" %)(((
615 -catSchemeMapAgencyId:catSchemeMapId(version)
616 -)))|(% style="width:742px" %)SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
617 -|(% style="width:292px" %)Code|(% style="width:647px" %)codeListAgencyId:codelistId(version).codeId|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0).Q
618 -|(% style="width:292px" %)//Codelist//|(% style="width:647px" %)codeListAgencyId:codeListId(version)|(% style="width:742px" %)SDMX:CL_FREQ(1.0.0)
619 -|(% style="width:292px" %)ComponentMap|(% style="width:647px" %)structureMapAgencyId:structureMap(version).com ponentMapId|(% style="width:742px" %)SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
620 -|(% style="width:292px" %)Concept|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
621 -|(% style="width:292px" %)//ConceptScheme//|(% style="width:647px" %)conceptSchemeAgencyId:conceptSchemeId(versio n)|(% style="width:742px" %)SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
622 -|(% style="width:292px" %)//ConceptSchemeMap//|(% style="width:647px" %)(((
623 -conceptSchemeMapAgencyId:conceptSchemeMap Id(version)
624 -)))|(% style="width:742px" %)SDMX:CONCEPT_MAP(1.0.0)
625 -|(% style="width:292px" %)CustomType|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|(% style="width:742px" %)ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
626 -|(% style="width:292px" %)//CustomTypeScheme//|(% style="width:647px" %)customTypeSchemeAgencyId customTypeSchemeId(version)|(% style="width:742px" %)ECB:CUSTOM_TYPE_SCHEME(1.0.0)
627 -|(% style="width:292px" %)DataAttrribute|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).OBS_STATUS
628 -|(% style="width:292px" %)//DataConstraint//|(% style="width:647px" %)dataConstraintAgencyId:dataConstraintId(version)|(% style="width:742px" %)TFFS:CREDITOR_DATA_CONTENT(1.0.0)
618 +|**Classname**|**Ending URN pattern**|**Example**
619 +|//CategorySchemeMap//|(((
620 +catSchemeMapAgencyId:catSchemeMapId(version
629 629  
630 -|(% style="width:294px" %)**Classname**|(% style="width:645px" %)**Ending URN pattern**|(% style="width:742px" %)**Example**
631 -|(% style="width:294px" %)DataConsumer|(% style="width:645px" %)dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
632 -|(% style="width:294px" %)//DataConsumerScheme//|(% style="width:645px" %)(((
633 -dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**)
634 -)))|(% style="width:742px" %)SDMX:**DATA_CONSUMERS**(**1.0**)
635 -|(% style="width:294px" %)//Dataflow//|(% style="width:645px" %)dataflowAgencyId:dataflowId(version)|(% style="width:742px" %)TFFS:CRED_EXT_DEBT(1.0.0)
636 -|(% style="width:294px" %)DataProvider|(% style="width:645px" %)(((
637 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**).dataProviderId
638 -)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
639 -|(% style="width:294px" %)//DataProviderScheme//|(% style="width:645px" %)(((
640 -dataProviderSchemeAgencyId:**DATA_PROVIDERS**(**1.0**)
641 -)))|(% style="width:742px" %)SDMX:**DATA_PROVIDERS**(**1.0**)
642 -|(% style="width:294px" %)//DataStructure//|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0)
643 -|(% style="width:294px" %)Dimension|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).FREQ
644 -|(% style="width:294px" %)(((
622 +)
623 +)))|SDMX:EUROSTAT_SUBJECT_DOMAIN(1.0.0)
624 +|Code|codeListAgencyId:codelistId(version).codeId|SDMX:CL_FREQ(1.0.0).Q
625 +|//Codelist//|codeListAgencyId:codeListId(version)|SDMX:CL_FREQ(1.0.0)
626 +|ComponentMap|structureMapAgencyId:structureMap(version).com ponentMapId|SDMX:BOP_STRUCTURES(1.0.0).REF_AREA_TO_COUNT RY
627 +|Concept|conceptSchemeAgencyId:conceptSchemeId(versio n).conceptId|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0).FREQ
628 +|//ConceptScheme//|conceptSchemeAgencyId:conceptSchemeId(versio n)|SDMX:CROSS_DOMAIN_CONCEPTS(1.0.0)
629 +|//ConceptSchemeMap//|(((
630 +conceptSchemeMapAgencyId:conceptSchemeMap
631 +
632 +Id(version)
633 +)))|SDMX:CONCEPT_MAP(1.0.0)
634 +|CustomType|customTypeSchemeAgencyId customTypeSchemeId(version) customTypeId|ECB: CUSTOM_TYPE_SCHEME(1.0.0).CUSTOM_TYPE_1
635 +|//CustomTypeScheme//|customTypeSchemeAgencyId customTypeSchemeId(version)|ECB:CUSTOM_TYPE_SCHEME(1.0.0)
636 +|DataAttrribute|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dataAttributeId|TFFS:EXT_DEBT(1.0.0).OBS_STATUS
637 +|//DataConstraint//|dataConstraintAgencyId:dataConstraintId(version)|TFFS:CREDITOR_DATA_CONTENT(1.0.0)
638 +
639 +|**Classname**|**Ending URN pattern**|**Example**
640 +|DataConsumer|dataConsumerSchemeAgencyId:**DATA_CONSUME RS**(**1.0**).dataConsumerId|SDMX:**DATA_CONSUMERS**(**1.0**).CONSUMER_1
641 +|//DataConsumerScheme//|(((
642 +dataConsumerSchemeAgencyId:**DATA_CONSUME**
643 +
644 +**RS**(**1.0**)
645 +)))|SDMX:**DATA_CONSUMERS**(**1.0**)
646 +|//Dataflow//|dataflowAgencyId:dataflowId(version)|TFFS:CRED_EXT_DEBT(1.0.0)
647 +|DataProvider|(((
648 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
649 +
650 +**1.0**).dataProviderId
651 +)))|SDMX:**DATA_PROVIDERS**(**1.0**).PROVIDER_1
652 +|//DataProviderScheme//|(((
653 +dataProviderSchemeAgencyId:**DATA_PROVIDERS**(
654 +
655 +**1.0**)
656 +)))|SDMX:**DATA_PROVIDERS**(**1.0**)
657 +|//DataStructure//|dataStructureDefinitionAgencyId:dataStructureDef initionId(version)|TFFS:EXT_DEBT(1.0.0)
658 +|Dimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).dimensionId|TFFS:EXT_DEBT(1.0.0).FREQ
659 +|(((
645 645  DimensionDescriptor
646 646  
647 647  MeasureDescriptor
648 648  
649 649  AttributeDescriptor
650 -)))|(% style="width:645px" %)(((
665 +)))|(((
651 651  dataStructureDefinitionAgencyId:dataStructureDef initionId(version).componentListId
652 652  
653 -where the componentListId is the name of the class (there is only one occurrence of each in the Data Structure Definition)
654 -)))|(% style="width:742px" %)(((
668 +where the componentListId is the name of the class (there is only one occurrence of each in the
669 +
670 +Data Structure Definition)
671 +)))|(((
655 655  TFFS:EXT_DEBT(1.0.0).DimensionDescriptor
656 656  
657 657  TFFS:EXT_DEBT(1.0.0).MeasureDescriptor
... ... @@ -658,81 +658,83 @@
658 658  
659 659  TFFS:EXT_DEBT(1.0.0).AttributeDescriptor
660 660  )))
661 -|(% style="width:294px" %)GroupDimensionDescriptor|(% style="width:645px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|(% style="width:742px" %)TFFS:EXT_DEBT(1.0.0).SIBLING
662 -|(% style="width:294px" %)HierarchicalCode|(% style="width:645px" %)hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|(% style="width:742px" %)UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
678 +|GroupDimensionDescriptor|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).groupDimensionDescriptorId|TFFS:EXT_DEBT(1.0.0).SIBLING
679 +|HierarchicalCode|hierarchyAgencyId:hierarchyId(version).hierarchica lCode.hierarchicalCode|UNESCO:H-C-GOV(1.0.0).GOV_CODE1.GOV_CODE1_1
663 663  
664 -|**Classname**|(% style="width:644px" %)**Ending URN pattern**|(% style="width:743px" %)**Example**
665 -|//Hierarchy//|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version)|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0)
666 -|//HierarchyAssociation//|(% style="width:644px" %)hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|(% style="width:743px" %)UNESCO:CL_EXP_SOURCE(1.0.0)
667 -|Level|(% style="width:644px" %)hierarchyAgencyId:hierarchyId(version).level|(% style="width:743px" %)UNESCO:H-C-GOV(1.0.0).LVL1
668 -|Measure|(% style="width:644px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|(% style="width:743px" %)TFFS:EXT_DEBT(1.0.0).OBS_VALUE
669 -|MetadataAttribute|(% style="width:644px" %)(((
681 +|**Classname**|**Ending URN pattern**|**Example**
682 +|//Hierarchy//|hierarchyAgencyId:hierarchyId(version)|UNESCO:H-C-GOV(1.0.0)
683 +|//HierarchyAssociation//|hierarchyAssociationAgencyId:hierarchyAssociatio nId(version)|UNESCO:CL_EXP_SOURCE(1.0.0)
684 +|Level|hierarchyAgencyId:hierarchyId(version).level|UNESCO:H-C-GOV(1.0.0).LVL1
685 +|Measure|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).measureId|TFFS:EXT_DEBT(1.0.0).OBS_VALUE
686 +|MetadataAttribute|(((
670 670  msdAgencyId:msdId(version).metadataAttributeId.
671 671  
672 672  metadataAttributeId
673 -)))|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
674 -|MetadataAttributeDescriptor|(% style="width:644px" %)msdAgencyId:msdId(version).metadataAttributeDe scriptorId|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
675 -|//MetadataConstraint//|(% style="width:644px" %)metadataConstraintAgencyId:metadataConstraintI d(version)|(% style="width:743px" %)TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
676 -|//Metadataflow//|(% style="width:644px" %)metadataflowAgencyId:metadataflowId(version)|(% style="width:743px" %)IMF:SDDS_MDF(1.0.0)
677 -|MetadataProvider|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
678 -|//MetadataProviderScheme//|(% style="width:644px" %)metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|(% style="width:743px" %)SDMX:**METADATA_PROVIDERS**(**1.0**)
679 -|//MetadataProvisionAgreement//|(% style="width:644px" %)metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|(% style="width:743px" %)IMF:SDDS_MDF_AB(1.0.0)
680 -|//MetadataSet//|(% style="width:644px" %)metadataProviderId:metadataSetId(version)|(% style="width:743px" %)MD_PROVIDER:METADATASET(1.0.0)
681 -|//MetadataStructure//|(% style="width:644px" %)msdAgencyId:msdId(version)|(% style="width:743px" %)IMF:SDDS_MSD(1.0.0)
690 +)))|IMF:SDDS_MSD(1.0.0).COMPILATION.METHOD
691 +|MetadataAttributeDescriptor|msdAgencyId:msdId(version).metadataAttributeDe scriptorId|IMF:SDDS_MSD(1.0.0).MetadataAttributeDescriptor
692 +|//MetadataConstraint//|metadataConstraintAgencyId:metadataConstraintI d(version)|TFFS:CREDITOR_METADATA_CONTENT(1.0.0)
693 +|//Metadataflow//|metadataflowAgencyId:metadataflowId(version)|IMF:SDDS_MDF(1.0.0)
694 +|MetadataProvider|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**).metadataProviderId|SDMX:**METADATA_PROVIDERS**(**1.0**).MD_PROVIDER_1
695 +|//MetadataProviderScheme//|metadataProviderSchemeAgencyId:**METADATA_P ROVIDERS**(**1.0**)|SDMX:**METADATA_PROVIDERS**(**1.0**)
696 +|//MetadataProvisionAgreement//|metadataProvisionAgreementAgencyId:metadataP rovisionAgreementId(version)|IMF:SDDS_MDF_AB(1.0.0)
697 +|//MetadataSet//|metadataProviderId:metadataSetId(version)|MD_PROVIDER:METADATASET(1.0.0)
698 +|//MetadataStructure//|msdAgencyId:msdId(version)|IMF:SDDS_MSD(1.0.0)
682 682  
683 -|(% style="width:296px" %)**Classname**|(% style="width:646px" %)**Ending URN pattern**|(% style="width:739px" %)**Example**
684 -|(% style="width:296px" %)NamePersonalisation|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0).PSN1234
685 -|(% style="width:296px" %)//NamePersonalisationScheme//|(% style="width:646px" %)namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|(% style="width:739px" %)ECB:PSN_SCHEME(1.0.0)
686 -|(% style="width:296px" %)//OrganisationSchemeMap//|(% style="width:646px" %)orgSchemeMapAgencyId:orgSchemeMapId(versio n)|(% style="width:739px" %)SDMX:AGENCIES_PROVIDERS(1.0.0)
687 -|(% style="width:296px" %)OrganisationUnit|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0).1F
688 -|(% style="width:296px" %)//OrganisationUnitScheme//|(% style="width:646px" %)organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|(% style="width:739px" %)ECB:ORGANISATIONS(1.0.0)
689 -|(% style="width:296px" %)//Process//|(% style="width:646px" %)processAgencyId:processId{version)|(% style="width:739px" %)BIS:PROCESS1(1.0.0)
690 -|(% style="width:296px" %)ProcessStep|(% style="width:646px" %)(((
700 +|**Classname**|**Ending URN pattern**|**Example**
701 +|NamePersonalisation|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version) namePersonalisationId|ECB:PSN_SCHEME(1.0.0).PSN1234
702 +|//NamePersonalisationScheme//|namePersonalisationSchemeAgencyId namePersonalisationSchemeId(version)|ECB:PSN_SCHEME(1.0.0)
703 +|//OrganisationSchemeMap//|orgSchemeMapAgencyId:orgSchemeMapId(versio n)|SDMX:AGENCIES_PROVIDERS(1.0.0)
704 +|OrganisationUnit|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version).organisationUnitId|ECB:ORGANISATIONS(1.0.0).1F
705 +|//OrganisationUnitScheme//|organisationUnitSchemeAgencyId:organisationUni tSchemeId(version)|ECB:ORGANISATIONS(1.0.0)
706 +|//Process//|processAgencyId:processId{version)|BIS:PROCESS1(1.0.0)
707 +|ProcessStep|(((
691 691  processAgencyId:processId(version).processStepId.
692 692  
693 693  processStepId
694 -)))|(% style="width:739px" %)BIS:PROCESS1(1.0.0).STEP1.STEP1_1
695 -|(% style="width:296px" %)//ProvisionAgreement//|(% style="width:646px" %)provisionAgreementAgencyId:provisionAgreement Id(version)|(% style="width:739px" %)TFFS:CRED_EXT_DEBT_AB(1.0.0)
696 -|(% style="width:296px" %)ReportingCategory|(% style="width:646px" %)(((
711 +)))|BIS:PROCESS1(1.0.0).STEP1.STEP1_1
712 +|//ProvisionAgreement//|provisionAgreementAgencyId:provisionAgreement Id(version)|TFFS:CRED_EXT_DEBT_AB(1.0.0)
713 +|ReportingCategory|(((
697 697  reportingTaxonomyAgencyId:
698 698  
699 699  reportingTaxonomyId(version).reportingCategoryI d.reportingCategoryId
700 -)))|(% style="width:739px" %)IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
701 -|(% style="width:296px" %)//ReportingTaxonomy//|(% style="width:646px" %)reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|(% style="width:739px" %)IMF:REP_1(1.0.0)
702 -|(% style="width:296px" %)//ReportingTaxonomyMap//|(% style="width:646px" %)repTaxonomyAgencyId:repTaxonomyId(version)|(% style="width:739px" %)SDMX:RT_MAP(1.0.0)
717 +)))|IMF:REP_1(1.0.0):LVL1_REP_CAT.LVL2_REP_CAT
718 +|//ReportingTaxonomy//|reportingTaxonomyAgencyId:reportingTaxonomyI d(version)|IMF:REP_1(1.0.0)
719 +|//ReportingTaxonomyMap//|repTaxonomyAgencyId:repTaxonomyId(version)|SDMX:RT_MAP(1.0.0)
703 703  
704 -|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
705 -|(% style="width:297px" %)//RepresentationMap//|(% style="width:647px" %)repMapAgencyId:repMapId(version)|(% style="width:737px" %)SDMX:REF_AREA_MAPPING(1.0.0)
706 -|(% style="width:297px" %)Ruleset|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|(% style="width:737px" %)ECB:RULESET_23(1.0.0).SET111
707 -|(% style="width:297px" %)//RulesetScheme//|(% style="width:647px" %)rulesetSchemeAgencyId rulesetSchemeId(version)|(% style="width:737px" %)ECB:RULESET_23(1.0.0)
708 -|(% style="width:297px" %)//StructureMap//|(% style="width:647px" %)structureMapAgencyId:structureMap(version)|(% style="width:737px" %)SDMX:BOP_STRUCTURES(1.0.0)
709 -|(% style="width:297px" %)Subscription|(% style="width:647px" %)(((
721 +|**Classname**|**Ending URN pattern**|**Example**
722 +|//RepresentationMap//|repMapAgencyId:repMapId(version)|SDMX:REF_AREA_MAPPING(1.0.0)
723 +|Ruleset|rulesetSchemeAgencyId rulesetSchemeId(version) rulesetId|ECB:RULESET_23(1.0.0).SET111
724 +|//RulesetScheme//|rulesetSchemeAgencyId rulesetSchemeId(version)|ECB:RULESET_23(1.0.0)
725 +|//StructureMap//|structureMapAgencyId:structureMap(version)|SDMX:BOP_STRUCTURES(1.0.0)
726 +|Subscription|(((
710 710  The Subscription is not itself an Identifiable Artefact and therefore it does not follow the rules for URN structure.
728 +
711 711  The name of the URN is registryURN There is no pre-determined format.
712 -)))|(% style="width:737px" %)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.
713 -|(% style="width:297px" %)TimeDimension|(% style="width:647px" %)dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|(% style="width:737px" %)TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
714 -|(% style="width:297px" %)Transformation|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version) transformationId|(% style="width:737px" %)ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
715 -|(% style="width:297px" %)//TransformationScheme//|(% style="width:647px" %)transformationSchemeAgencyId transformationSchemeId(version)|(% style="width:737px" %)ECB: TRANSFORMATION_SCHEME(1.0.0)
716 -|(% style="width:297px" %)**Classname**|(% style="width:647px" %)**Ending URN pattern**|(% style="width:737px" %)**Example**
717 -|(% style="width:297px" %)Transition|(% style="width:647px" %)(((
730 +)))|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.
731 +|TimeDimension|dataStructureDefinitionAgencyId:dataStructureDef initionId(version).timeDimensionId|TFFS:EXT_DEBT(1.0.0).TIME_PERIOD
732 +|Transformation|transformationSchemeAgencyId transformationSchemeId(version) transformationId|ECB:TRANSFORMATION_SCHEME(1.0.0).TRANS_1
733 +|//TransformationScheme//|transformationSchemeAgencyId transformationSchemeId(version)|ECB: TRANSFORMATION_SCHEME(1.0.0)
734 +|**Classname**|**Ending URN pattern**|**Example**
735 +|Transition|(((
718 718  processAgencyId:processId(version).processStepId.
737 +
719 719  transitionId
720 -)))|(% style="width:737px" %)BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
721 -|(% style="width:297px" %)UserDefinedOperator|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|(% style="width:737px" %)ECB:OS_CALC(1.2.0).OS267
722 -|(% style="width:297px" %)//UserDefinedOperatorScheme//|(% style="width:647px" %)userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|(% style="width:737px" %)ECB:OS_CALC(1.2.0)
723 -|(% style="width:297px" %)//ValueList//|(% style="width:647px" %)valuelistAgencyId:valuelistId(version)|(% style="width:737px" %)SDMX:VLIST(1.0.0)
724 -|(% style="width:297px" %)VtlCodelistMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|(% style="width:737px" %)ECB:CLIST_MP(2.0.0).ABZ
725 -|(% style="width:297px" %)VtlConceptMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).XYA
726 -|(% style="width:297px" %)VtlDataflowMapping|(% style="width:647px" %)vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|(% style="width:737px" %)ECB:CLIST_MP(1.0.0).MOQ
727 -|(% style="width:297px" %)//VtlMappingScheme//|(% style="width:647px" %)vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|(% style="width:737px" %)ECB:CLIST_MP(2.0.0)
739 +)))|BIS:PROCESS1(1.0.0).STEP1.TRANSITION1
740 +|UserDefinedOperator|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version) usserDefinedOperatorId|ECB:OS_CALC(1.2.0).OS267
741 +|//UserDefinedOperatorScheme//|userDefinedOperatorSchemeAgencyId userDefinedOperatorSchemeId(version)|ECB:OS_CALC(1.2.0)
742 +|//ValueList//|valuelistAgencyId:valuelistId(version)|SDMX:VLIST(1.0.0)
743 +|VtlCodelistMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlCodelistMappingId|ECB:CLIST_MP(2.0.0).ABZ
744 +|VtlConceptMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlConceptMappingId|ECB:CLIST_MP(1.0.0).XYA
745 +|VtlDataflowMapping|vtlMappingSchemeAgencyId vtlMappingSchemeId(version) vtlDataflowMappingId|ECB:CLIST_MP(1.0.0).MOQ
746 +|//VtlMappingScheme//|vtlMappingSchemeAgencyId VtlMappingSchemeId(version)|ECB:CLIST_MP(2.0.0)
728 728  
729 729  5**Table 3: Table of identification components for SDMX Identifiable Artefacts**
730 730  
731 -= 7 Implementation Notes =
750 += {{id name="_Toc90810"/}}7 Implementation Notes =
732 732  
733 -== 7.1 Structural Definition Metadata ==
752 +=== {{id name="_Toc90811"/}}7.1 Structural Definition Metadata ===
734 734  
735 -=== 7.1.1 Introduction ===
754 +===== {{id name="_Toc90812"/}}7.1.1 Introduction =====
736 736  
737 737  The SDMX Registry must have the ability to support agencies in their role of defining and disseminating structural metadata artefacts. These artefacts include data structure definitions, code lists, concepts etc. and are fully defined in the SDMX-IM. An authenticated agency may submit valid structural metadata definitions which must be stored in the registry. Note that the term “structural metadata” refers as a general term to all structural components (Data Structure Definitions, Metadata Structure Definitions, Code Lists, Concept Schemes, etc.)
738 738  
... ... @@ -748,40 +748,46 @@
748 748  
749 749  The following table lists the Maintainable Artefacts.
750 750  
751 -(% style="width:825.835px" %)
752 -|(% colspan="2" style="width:455px" %)**Maintainable Artefacts**|(% style="width:367px" %)**Content**
753 -|(% style="width:160px" %)**Abstract Class**|(% style="width:295px" %)**Concrete Class**|(% style="width:367px" %)
754 -|(% style="width:160px" %)Item Scheme|(% style="width:295px" %)Codelist|(% style="width:367px" %)Code
755 -|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme|(% style="width:367px" %)Concept
756 -|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme|(% style="width:367px" %)Category
757 -|(% style="width:160px" %) |(% style="width:295px" %)Organisation Unit Scheme|(% style="width:367px" %)Organisation Unit
758 -|(% style="width:160px" %) |(% style="width:295px" %)Agency Scheme|(% style="width:367px" %)Agency
759 -|(% style="width:160px" %) |(% style="width:295px" %)Data Provider Scheme|(% style="width:367px" %)Data Provider
760 -|(% style="width:160px" %) |(% style="width:295px" %)Metadata Provider Scheme|(% style="width:367px" %)Metadata Provider
761 -|(% style="width:160px" %) |(% style="width:295px" %)Data Consumer Scheme|(% style="width:367px" %)Data Consumer
762 -|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy|(% style="width:367px" %)Reporting Category
763 -|(% style="width:160px" %) |(% style="width:295px" %)Transformation Scheme|(% style="width:367px" %)Transformation
764 -|(% style="width:160px" %) |(% style="width:295px" %)Custom Type Scheme|(% style="width:367px" %)Custom Type
765 -|(% style="width:160px" %) |(% style="width:295px" %)Name Personalisation Scheme|(% style="width:367px" %)Name Personalisation
766 -|(% style="width:160px" %) |(% style="width:295px" %)Vtl Mapping Scheme|(% style="width:367px" %)Vtl Codelist Mapping Vtl Concept Mapping
767 -|(% style="width:160px" %) |(% style="width:295px" %)Ruleset Scheme|(% style="width:367px" %)Ruleset
768 -|(% style="width:160px" %) |(% style="width:295px" %)User Defined Operator Scheme|(% style="width:367px" %)User Defined Operator
769 -|(% style="width:160px" %)Enumerated List|(% style="width:295px" %)ValueList|(% style="width:367px" %)Value Item
770 -|(% style="width:160px" %)Structure|(% style="width:295px" %)Data Structure Definition|(% style="width:367px" %)(((
770 +|(% colspan="2" %)**Maintainable Artefacts**|**Content**
771 +|**Abstract Class**|**Concrete Class**|
772 +|Item Scheme|Codelist|Code
773 +| |Concept Scheme|Concept
774 +| |Category Scheme|Category
775 +| |Organisation Unit Scheme|Organisation Unit
776 +| |Agency Scheme|Agency
777 +| |Data Provider Scheme|Data Provider
778 +| |Metadata Provider Scheme|Metadata Provider
779 +| |Data Consumer Scheme|Data Consumer
780 +| |Reporting Taxonomy|Reporting Category
781 +| |Transformation Scheme|Transformation
782 +| |Custom Type Scheme|Custom Type
783 +| |Name Personalisation Scheme|Name Personalisation
784 +| |Vtl Mapping Scheme|Vtl Codelist Mapping Vtl Concept Mapping
785 +| |Ruleset Scheme|Ruleset
786 +| |User Defined Operator Scheme|User Defined Operator
787 +|Enumerated List|ValueList|Value Item
788 +|Structure|Data Structure Definition|(((
771 771  Dimension Descriptor
790 +
772 772  Group Dimension Descriptor
792 +
773 773  Dimension
794 +
774 774  Time Dimension
796 +
775 775  Attribute Descriptor
798 +
776 776  Data Attribute
800 +
777 777  Measure Descriptor
802 +
778 778  Measure
779 779  )))
780 -|(% style="width:160px" %) |(% style="width:295px" %)Metadata Structure Definition|(% style="width:367px" %)Metadata Attribute Descriptor Metadata Attribute
781 -|(% style="width:160px" %)Structure Usage|(% style="width:295px" %)Dataflow|(% style="width:367px" %)
782 -|(% style="width:160px" %) |(% style="width:295px" %)Metadataflow|(% style="width:367px" %)
783 -|(% style="width:160px" %)None|(% style="width:295px" %)Process|(% style="width:367px" %)Process Step
784 -|(% style="width:160px" %)None|(% style="width:295px" %)Structure Map|(% style="width:367px" %)(((
805 +| |Metadata Structure Definition|Metadata Attribute Descriptor Metadata Attribute
806 +|Structure Usage|Dataflow|
807 +| |Metadataflow|
808 +|None|Process|Process Step
809 +|None|Structure Map|(((
785 785  Component Map
786 786  
787 787  Epoch Map
... ... @@ -788,44 +788,44 @@
788 788  
789 789  Date Pattern Map
790 790  )))
791 -|(% style="width:160px" %)None|(% style="width:295px" %)Representation Map|(% style="width:367px" %)Representation Mapping
792 -|(% style="width:160px" %)Item Scheme Map|(% style="width:295px" %)Organisation Scheme Map|(% style="width:367px" %)Item Map
793 -|(% style="width:160px" %) |(% style="width:295px" %)Concept Scheme Map|(% style="width:367px" %)Item Map
794 -|(% style="width:160px" %) |(% style="width:295px" %)Category Scheme Map|(% style="width:367px" %)Item Map
795 -|(% style="width:160px" %) |(% style="width:295px" %)Reporting Taxonomy Map|(% style="width:367px" %)Item Map
796 -|(% style="width:160px" %)None|(% style="width:295px" %)Provision Agreement|(% style="width:367px" %)
797 -|(% style="width:160px" %)None|(% style="width:295px" %)Metadata Provision Agreement|(% style="width:367px" %)
798 -|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy|(% style="width:367px" %)Hierarchical Code
799 -|(% style="width:160px" %)None|(% style="width:295px" %)Hierarchy Association|(% style="width:367px" %)
800 -|(% style="width:160px" %)None|(% style="width:295px" %)Categorisation|(% style="width:367px" %)
801 -|(% style="width:160px" %)Constraint|(% style="width:295px" %)Data Constraint|(% style="width:367px" %)DataKeySet
802 -|(% style="width:160px" %) |(% style="width:295px" %) |(% style="width:367px" %)CubeRegion
803 -|(% style="width:160px" %)Constraint|(% style="width:295px" %)Metadata Constraint|(% style="width:367px" %)MetadataTargetRegion
816 +|None|Representation Map|Representation Mapping
817 +|Item Scheme Map|Organisation Scheme Map|Item Map
818 +| |Concept Scheme Map|Item Map
819 +| |Category Scheme Map|Item Map
820 +| |Reporting Taxonomy Map|Item Map
821 +|None|Provision Agreement|
822 +|None|Metadata Provision Agreement|
823 +|None|Hierarchy|Hierarchical Code
824 +|None|Hierarchy Association|
825 +|None|Categorisation|
826 +|Constraint|Data Constraint|DataKeySet
827 +| | |CubeRegion
828 +|Constraint|Metadata Constraint|MetadataTargetRegion
804 804  
805 805  **Table 4: Table of Maintainable Artefacts for Structural Definition Metadata**
806 806  
807 -=== 7.1.2 Item Scheme, Structure ===
832 +===== {{id name="_Toc90813"/}}7.1.2 Item Scheme, Structure =====
808 808  
809 809  The artefacts included in the structural definitions are:
810 810  
811 811  * 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)
812 -* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
837 +* All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
813 813  * All types of Structure (Data Structure Definition, Metadata Structure Definition)
814 814  * All types of Structure Usage (Dataflow, Metadataflow)
815 815  
816 -=== 7.1.3 Structure Usage ===
841 +===== {{id name="_Toc90814"/}}7.1.3 Structure Usage =====
817 817  
818 -==== 7.1.3.1 Structure Usage: Basic Concepts ====
843 +**7.1.3.1 Structure Usage: Basic Concepts**
819 819  
820 820  The Structure Usage defines, in its concrete classes of Dataflow and Metadataflow, which flows of data and metadata use which specific Structure, and importantly for the support of data and metadata discovery, the Structure Usage can be linked to one or more Category in one or more Category Scheme using the Categorisation mechanism. This gives the ability for an application to discover data and metadata by “drilling down” the Category Schemes.
821 821  
822 -==== 7.1.3.2 Structure Usage Schematic ====
847 +**7.1.3.2 Structure Usage Schematic**
823 823  
824 824  [[image:SDMX 3.1 Section 5_en_9b750e13.jpg||height="246" width="438"]]
825 825  
826 826  **Figure 9: Schematic of Linking the Data and Metadata Flows to Categories and Structure Definitions**
827 827  
828 -==== 7.1.3.3 Structure Usage Model ====
853 +**7.1.3.3 Structure Usage Model**
829 829  
830 830  [[image:SDMX 3.1 Section 5_en_1c94cbe.jpg||height="548" width="578"]]
831 831  
... ... @@ -843,9 +843,9 @@
843 843  1*. Categorisation to Dataflow and Category
844 844  1*. Categorisation to Metadataflow and Category
845 845  
846 -== 7.2 Data and Metadata Provisioning ==
871 +=== {{id name="_Toc90815"/}}7.2 Data and Metadata Provisioning ===
847 847  
848 -=== 7.2.1 Provisioning Agreement: Basic concepts ===
873 +===== {{id name="_Toc90816"/}}7.2.1 Provisioning Agreement: Basic concepts =====
849 849  
850 850  Data/Metadata provisioning defines a framework in which the provision of different types of statistical data and metadata by various data/metadata providers can be specified and controlled. This framework is the basis on which the existence of data can be made known to the SDMX-enabled community and hence the basis on which data can subsequently be discovered. Such a framework can be used to regulate the data content to facilitate the building of intelligent applications. It can also be used to facilitate the processing implied by service level agreements, or other provisioning agreements in those scenarios that are based on legal directives. Additionally, quality and timeliness metadata can be supported by this framework which makes it practical to implement information supply chain monitoring.
851 851  
... ... @@ -853,7 +853,7 @@
853 853  
854 854  Although the Provision Agreement directly supports the data-sharing “pull” model, it is also useful in “push” exchanges (bilateral and gateway scenarios), or in a dissemination environment. It should be noted, too, that in any exchange scenario, the registry functions as a repository of structural metadata.
855 855  
856 -=== 7.2.2 Provisioning Agreement Model – pull use case ===
881 +===== {{id name="_Toc90817"/}}7.2.2 Provisioning Agreement Model – pull use case =====
857 857  
858 858  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.
859 859