Changes for page SDMX 3.0 Standards. Section 5. Registry Specification: Logical Functionality

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 1 added, 0 removed)
  • 1747307906944-697.png

Details

Page properties

Content

...	...	@@ -243,23 +243,22 @@
243	243	* that the components (Dimensions, Attributes, Measures, Metadata Attributes, etc.) are consistent with the Data Structure Definition or Metadata Structure Definition;
244	244	* 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:
245	245
246		-|**Action Attribute Value**|**Behaviour**
247		-|Append|Add this registration to the registry
248		-|Replace|Replace the existing Registration with this Registration identified by the id in the Registration of the Submit Registration Request
249		-|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
250	250
251	251	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:
252	252
253		-|**Boolean Attribute**|**Behaviour if Value is “true”**
254		-|indexTimeSeries|A compliant indexing application must index all the time series keys (for a Dataset registration) or metadata target values (for a Metadataset registration)
255		-|indexDataSet|(((
256		-A compliant indexing application must index the range of actual
257		-
258		-(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.
259		-
	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.
260	260	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
261	261	)))
262		-|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.
263	263
264	264	=== {{id name="_Toc93850"/}}5.2.5 Data and Reference Metadata Discovery ===
265	265
...	...	@@ -293,8 +293,9 @@
293	293
294	294	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.
295	295
296		-|**Interface**|**Behaviour**
297		-|All|(((
	295	+(% style="width:757.294px" %)
	296	+|(% style="width:188px" %)**Interface**|(% style="width:542px" %)**Behaviour**
	297	+|(% style="width:188px" %)All|(% style="width:542px" %)(((
298	298	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.
299	299	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.
300	300	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:
...	...	@@ -301,14 +301,14 @@
301	301
302	302	a) Be a draft version.
303	303	)))
304		-|**Interface**|**Behaviour**
305		-| |(((
306		-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.
307	307
308	308	4) The semantic versioning rules in the SDMX documentation MUST be obeyed.
309	309	)))
310		-|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.
311		-|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.
312	312
313	313	= {{id name="_Toc93853"/}}6 Identification of SDMX Objects =
314	314
...	...	@@ -338,27 +338,28 @@
338	338	:
339	339
340	340	(((
341		-|**Object Type**|**Data Attributes**|**Status**|**Data type**|**Notes**
342		-|(% rowspan="4" %)//Annotable//|AnnotationTitle|C|string|
343		-|AnnotationType|C|string|
344		-|AnnotationURN|C|string|
345		-|AnnotationText in the form of InternationalString|C| |This can have languagespecific variants
346		-|(% rowspan="4" %)//Identifiable//|All content as for //Annotable// plus| | |
347		-|id|M|string|
348		-|uri|C|string|
349		-|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.
350		-|(% rowspan="3" %)//Nameable//|All content as for //Identifiable// plus| | |
351		-|Name in the form of InternationalString|M|string|This can have language specific variants.
352		-|Description in the form of InternationalString|C|string|This can have language specific variants.
353		-|(% rowspan="4" %)//Versionable//|All content as for //Identifiable// plus| | |
354		-|version|M|string|This is the version number according to SDMX versioning rules.
355		-|validFrom|C|Date/time|
356		-|validTo|C|Date/time|
357		-|//Maintainable//|All content as for //Versionable// plus| | |
358		-| |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.
359		-| |serviceURL|C|string|The url of the service that can be queried for this resource.
360		-| |structureURL|C|string|The url of the resource.
361		-| |(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.
362	362	)))
363	363
364	364	**Table 1: Common Attributes of Object Types**
...	...	@@ -407,32 +407,8 @@
407	407
408	408	An example of this is shown in the XML snippet below:
409	409
410		-**<str:Codelists>**
	411	+[[image:1747307906944-697.png]]
411	411
412		-**<str:Codelist id="CL_FREQ" agencyID="SDMX" version="1.0.0">**
413		-
414		-**<com:Name xml:lang="en">Standard frequency Codelist</com:Name>**
415		-
416		-**</str:Codelist>**
417		-
418		-**<str:Codelist id="CL_FREQ" agencyID="AA" version="1.0.0">**
419		-
420		-**<com:Name xml:lang="en">Codelist maintained by agency AA</com:Name>**
421		-
422		-**</str:Codelist>**
423		-
424		-**<str:Codelist id="CL_FREQ" agencyID="AA.CC" version="1.0.0">**
425		-
426		-**<com:Name xml:lang="en">Codelist maintained by the AA unit CC</com:Name>**
427		-
428		-**</str:Codelist>**
429		-
430		-**<str:Codelist id="CL_FREQ" agencyID="BB.CC" version="1.0.0">**
431		-
432		-**<com:Name xml:lang="en">Codelist maintained by the BB unit CC</com:Name>**
433		-
434		-**</str:Codelist>**
435		-
436	436	**Figure 8: Example Showing Use of Agency Identifiers**
437	437
438	438	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.
...	...	@@ -439,14 +439,16 @@
439	439
440	440	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.
441	441
442		-===== {{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) =====
	419	+=== {{id name="_Toc93858"/}}6.2.2 Universal Resource Name (URN) ===
443	443
444		-**6.2.2.1 Introduction**
	421	+==== 6.2.2.1 Introduction ====
445	445
446	446	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.).
447	447
448		-**6.2.2.2 URN Structure //__Case Rules for URN__//**//&nbsp;//
	425	+==== 6.2.2.2 URN Structure ====
449	449
	427	+===== **//__Case Rules for URN__//** =====
	428	+
450	450	For the URN, all parts of the string are case sensitive. The generic structure of the URN is as follows:
451	451
452	452	SDMXprefix.SDMX-IM-package-name.class-name=agencyid:maintainedobjectid(maintainedobject-version).*containerobject-id.object-id
...	...	@@ -457,7 +457,7 @@
457	457
458	458	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.
459	459
460		-**6.2.2.3 Explanation of the generic structure**
	439	+==== 6.2.2.3 Explanation of the generic structure ====
461	461
462	462	In the explanation below the actual object that is the target of the URN is called the **actual object**.
463	463
...	...	@@ -467,10 +467,32 @@
467	467
468	468	The packages are:
469	469
470		-base codelist conceptscheme datastructure categoryscheme registry metadatastructure process structuremapping transformation
	449	+base
471	471
472		-**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
473	473
	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	+
474	474	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.
475	475
476	476	For example, the sequence is agency:DSDid(version).DimensionId and not agency:DSDid(version).DimensionDescriptorId.DimensionId.
...	...	@@ -477,7 +477,7 @@
477	477
478	478	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.
479	479
480		-//__**Generic Examples of the URN Structure**__//
	481	+===== //__**Generic Examples of the URN Structure**__// =====
481	481
482	482	__Actual object is a maintainable__
483	483
...	...	@@ -532,85 +532,86 @@
532	532
533	533	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.
534	534
535		-===== {{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 ===
536	536
537	537	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.
538	538
539		-|**Package**|**URN class name (model class name where this is different)**
540		-|base|Agency
541		-| |AgencyScheme
542		-| |DataConsumer
543		-| |DataConsumerScheme
544		-| |DataProvider
545		-| |DataProviderScheme
546		-| |MetadataProvider
547		-| |MetadataProviderScheme
548		-| |OrganisationUnit
549		-| |OrganisationUnitScheme
550		-|datastructure|AttributeDescriptor
551		-| |DataAttribute
552		-| |Dataflow
553		-| |DataStructure (DataStructureDefinition)
554		-| |Dimension
555		-| |DimensionDescriptor
556		-| |GroupDimensionDescriptor
557		-| |Measure
558		-| |MeasureDescriptor
559		-| |TimeDimension
560		-| |
561		-|metadatastructure|MetadataAttribute
562		-| |MetadataAttributeDescriptor
563		-| |MetadataStructure MetadataStructureDefinition)
564		-| |Metadataflow
565		-| |MetadataSet
566		-| |
567		-|process|Process
568		-| |ProcessStep
569		-| |Transition
570		-| |
571		-|registry|DataConstraint
572		-| |MetadataConstraint
573		-| |MetadataProvisionAgreement
574		-| |ProvisionAgreement
575		-| |Subscription
576		-| |
577		-|structuremapping|CategorySchemeMap
578		-| |ConceptSchemeMap
579		-| |OrganisationSchemeMap
580		-| |ReportingTaxonomyMap
581		-| |RepresentationMap
582		-| |StructureMap
583		-| |
584		-|codelist|Code
585		-| |Codelist
586		-| |HierarchicalCode
587		-| |Hierarchy
588		-| |HierarchyAssociation
589		-| |Level
590		-| |ValueList
591		-| |
592		-|categoryscheme|Categorisation
593		-| |Category
594		-| |CategoryScheme
595		-| |ReportingCategory
596		-| |ReportingTaxonomy
597		-|conceptscheme|Concept
598		-| |ConceptScheme
599		-| |
600		-|transformation|CustomType
601		-| |CustomTypeScheme
602		-| |NamePersonalisation
603		-| |NamePersonalisationScheme
604		-| |Ruleset
605		-| |RulesetScheme
606		-| |Transformation
607		-| |TransformationScheme
608		-| |UserDefinedOperator
609		-| |UserDefinedOperatorScheme
610		-| |VtlCodelistMapping
611		-| |VtlConceptMapping
612		-| |VtlDataflowMapping
613		-| |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
614	614
615	615	**Table 2: SDMX-IM Packages and Contained Classes**
616	616
...	...	@@ -623,7 +623,7 @@
623	623	urn:sdmx.org.sdmx.infomodel.{package}.{classname}=
624	624
625	625	|**Classname**|**Ending URN pattern**|**Example**
626		-|Agency^^[[(% class="wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
	628	+|Agency^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^2^^>>path:#sdfootnote2sym||name="sdfootnote2anc"]](%%)^^|agencySchemeAgencyId:**AGENCIES**(**1.0**).agencyId|ECB:**AGENCIES**(**1.0**).AA
627	627	|//AgencyScheme//|agencySchemeAgencyId:**AGENCIES**(**1.0**)|ECB:**AGENCIES**(**1.0**)
628	628	|//Categorisation//|categorisationAgencyId:categorisationId(version)|IMF:cat001(1.0.0)
629	629	|Category|categorySchemeAgencyId:categorySchemeId(versi on).categoryId.categoryId.categoryId etc.|IMF:SDDS(1.0.0):level_1_category.level_2_category …
...	...	@@ -840,7 +840,7 @@
840	840
841	841	• 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)
842	842
843		-• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
	845	+• All types of Enumerated List (ValueList)^^[[(% class="wikiinternallink wikiinternallink wikiinternallink" %)^^3^^>>path:#sdfootnote3sym||name="sdfootnote3anc"]](%%)^^
844	844
845	845	• All types of Structure (Data Structure Definition, Metadata Structure Definition)
846	846
...	...	@@ -1185,3 +1185,5 @@
1185	1185	IMF.SubAgency1
1186	1186
1187	1187	[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] Note that Codelist is also an EnumeratedList.
	1190	+
	1191	+{{putFootnotes/}}

1747307906944-697.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.helena

Size

...	...	@@ -1,0 +1,1 @@
	1	+37.9 KB

Content