Difference between revisions of "Content Constraint"
(→Usage) |
(→Usage) |
||
| Line 34: | Line 34: | ||
==Usage== | ==Usage== | ||
| − | Constraints can be applied to | + | Constraints can be applied to DSD, Dataflow, Provision Agreement or Data Provider in order to restrict the data being validated or converted. This is to allow organisations flexibility whether to apply constraints and at what level. |
| − | Note that regardless of the artifact to which the Constraint is associated, it is constraining the contents of code lists in the DSD to which the constrained object is related. | + | Note that regardless of the artifact to which the Constraint is associated, it is constraining the contents of code lists in the DSD to which the constrained object is related. |
The Constraint can be of one of two types:<br> | The Constraint can be of one of two types:<br> | ||
| − | * Content | + | * Allowable Content |
| − | * | + | * Actual |
| − | + | ===Allowable Content=== | |
| + | Allowable content (also known as a Reporting Constraint) defines what data can be reported. For example, a constraint could be defined to ensure that a Data Provider situated in France only reports French Balance of Payments data. | ||
| − | ===Rules for a Content Constraint=== | + | Allowable content constraints can also be used to control how Reference Metadata is reported. |
| + | |||
| + | These type of constraints are created and maintained as physical artifacts in the Registry under the Reporting Constraints menu. | ||
| + | |||
| + | ===Actual=== | ||
| + | Actual defines what data actually exists in a data source. This helps with data discovery in that it gives a data consumer information on the scope of data available before querying. The [https://fmrwiki.sdmxcloud.org/Data_Availability_Web_ServiceData Availability API] returns ‘actual’ constraints explaining what codes are available for each dimension. Actual constraints are created on the fly and are not stored as physical artifacts in the Registry.'''??? Ask Glenn | ||
| + | ''' | ||
| + | |||
| + | ==Rules for a Content Constraint=== | ||
==Conventions== | ==Conventions== | ||
Revision as of 03:24, 12 February 2021
Contents
Overview
Content Constraints define restrictions on Codelists or Series for Data Reporting.
Structure Properties
| Structure Type | Standard SDMX Structural Metadata Artefact |
|---|---|
| Maintainable | Yes |
| Identifiable | Yes |
| Item Scheme | No |
| SDMX Information Model Versions | 1.0, 2.0, 2.1 |
| URN - ConceptScheme namespace | urn:sdmx:org.sdmx.infomodel.conceptscheme.ConceptScheme |
| URN - concept namespace | urn:sdmx:org.sdmx.infomodel.concept.Concept |
Context within the SDMX 2.1 Information Model
The schematic illustrates the core artifacts of the SDMX 2.1 Information Model, and how Content Constraints fit in.
Usage
Constraints can be applied to DSD, Dataflow, Provision Agreement or Data Provider in order to restrict the data being validated or converted. This is to allow organisations flexibility whether to apply constraints and at what level.
Note that regardless of the artifact to which the Constraint is associated, it is constraining the contents of code lists in the DSD to which the constrained object is related.
The Constraint can be of one of two types:
- Allowable Content
- Actual
Allowable Content
Allowable content (also known as a Reporting Constraint) defines what data can be reported. For example, a constraint could be defined to ensure that a Data Provider situated in France only reports French Balance of Payments data.
Allowable content constraints can also be used to control how Reference Metadata is reported.
These type of constraints are created and maintained as physical artifacts in the Registry under the Reporting Constraints menu.
Actual
Actual defines what data actually exists in a data source. This helps with data discovery in that it gives a data consumer information on the scope of data available before querying. The Availability API returns ‘actual’ constraints explaining what codes are available for each dimension. Actual constraints are created on the fly and are not stored as physical artifacts in the Registry.??? Ask Glenn
Rules for a Content Constraint=
Conventions
Content Constraint IDs IDs are conventionally uppercase using underscores '_' as separators if required. Examples:
| Agency | Content Constraint ID | Constrained Structure | SDMX-ML |
|---|---|---|---|
| ESTAT | CR_HICP_AP_A | HICP_AP_A[2.0] | [ https://registry.sdmx.org/ws/public/sdmxapi/rest/contentconstraint/UIS/CR_EDUCAT_CLASS_A/1.0 SDMX-ML] |
| UIS | CR_EDUCAT_CLASS_A | EDUCAT_CLASS_A[1.0] | [ https://registry.sdmx.org/ws/public/sdmxapi/rest/contentconstraint/UIS/CR_EDUCAT_CLASS_A/1.0 SDMX-ML] |
| WB | GHA | GHA | [ https://demo.metadatatechnology.com/FusionRegistry/ws/public/sdmxapi/rest/contentconstraint/WB/GHA/1.0 SDMX-ML] |
You can seem more examples and information on Identities in this article.
