Contents

8.1 Introduction

In this version of SDMX the Constraints is a Maintainable Artefact can be associated to one or more of:

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. This does not apply, of course, to a Data Provider as the Data Provider can be associated, via the Provision Agreement, to many DSDs. Hence the reason for the restriction on the type of Constraint that can be attached to a Data Provider.

8.2 Types of Constraint

The Constraint can be of one of two types:

The attachable constraint is used to define “cube slices” which identify sub sets of data in terms of series keys or dimension values. The purpose of this is to enable metadata to be attached to the constraint, and thereby to the cube slices defined in the Constraint. The metadata can be attached via the “reference metadata” mechanism – MSD and Metadata Set – or via a Group in the DSD. Below is snippet of the schema for a DSD that shows the constructs that enable the Constraint to referenced from a Group in a DSD.

1748248970469-631.png

Figure 9: Extract from the SDMX-ML Schema showing reference to Attachment Constraint

For the Content Constraint specific “inheritance” rules apply and these are detailed below.

8.3 Rules for a Content Constraint

8.3.1 Scope of a Content Constraint

A Content Constraint is used specify the content of a data or metadata source in terms of the component values or the keys. 

In terms of data the components are:

And the keys are the content of the KeyDescriptor – i.e. the series keys composed, for each key, by a value for each Dimension and Measure Dimension

In terms of reference metadata the components are:

  • Target Object which is one of:
    • Key Descriptor Values o Data Set o Report Period
    • IdentifiableObject
  • Metadata Attribute

The “key” is therefore the combination of the Target Objects that are defined for the Metadata Target.

For a Constraint based on a DSD the Content Constraint can reference one or more of:

For a Constraint based on an MSD the Content Constraint can reference one or more of:

Furthermore, there can be more than one Content Constraint specified for a specific object e.g. more than one Constraint for a specific DSD.

In view of the flexibility of constraints attachment, clear rules on their usage are required. These are elaborated below.

8.3.2 Multiple Content Constraints

There can be many Content Constraint for any Constrainable Artefact (e.g. DSD), subject to the following restrictions:

8.3.2.1 Cube Region

  1. The constraint can contain multiple Member Selections (e.g. Dimension) but:
  2. A specific Member Selection (e.g. Dimension FREQ) can only be contained in one Content Constraint for any one attached object (e.g. a specific DSD or specific Dataflow)

8.3.2.2 Key Set

Key Sets will be processed in the order they appear in the Constraint and wildcards can be used (e.g. any key position not reference explicitly is deemed to be “all values”). As the Key Sets can be “included” or “excluded” it is recommended that Key Sets with wildcards are declared before KeySets with specific series keys. This will minimize the risk that keys are inadvertently included or excluded.

8.3.3 Inheritance of a Content Constraint

8.3.3.1 Attachment levels of a Content Constraint

There are three levels of constraint attachment for which these inheritance rules apply:

Note that these rules do not apply to the Simple Datasoucre or Queryable Datasource: the Content Constraint(s) attached to these artefacts are resolved for this artefact only and do not take into account Constraint attached to other artefacts (e.g. Provision Agreement. Dataflow, DSD).

It is not necessary for a Content Constraint to be attached to higher level artifact. e.g. it is valid to have a Content Constraint for a Provision Agreement where there are no constraints attached the relevant dataflow or DSD.

8.3.3.2 Cascade rules for processing Constraints

The processing of the constraints on either Dataflow/Metadataflow or Provision Agreement must take into account the constraints declared at higher levels. The rules for the lower level constraints (attached to Dataflow/ Metadataflow and Provision Agreement) are detailed below.

Note that there can be a situation where a constraint is specified at a lower level before a constraint is specified at a higher level. Therefore, it is possible that a higher level constraint makes a lower level constraint invalid. SDMX makes no rules on how such a conflict should be handled when processing the constraint for attachment. However, the cascade rules on evaluating constraints for usage are clear - the higher level constraint takes precedence in any conflicts that result in a less restrictive specification at the lower level. 

8.3.3.3 Cube Region

  1. It is not necessary to have a constraint on the higher level artifact (e.g. DSD referenced by the Dataflow) but if there is such a constraint at the higher level(s) then:
    a. The lower level constraint cannot be less restrictive than the constraint specified for the same Member Selection (e.g. Dimension) at the next higher level which constraint that Member Selection (e.g. if the Dimension FREQ is constrained to A, Q in a DSD then the constraint at the Dataflow or Provision Agreement cannot be A, Q, M or even just M – it can only further constrain A,Q).
    b. The constraint at the lower level for any one Member Selection further constrains the content for the same Member Selection at the higher level(s).
  2. Any Member Selection which is not referenced in a Content Constraint is deemed to be constrained according to the Content Constraint specified at the next higher level which constraint that Member Selection.
  3. If there is a conflict when resolving the constraint in terms of a lower-level constraint being less restrictive than a higher-level constraint then the constraint at the higher-level is used.

Note that it is possible for a Content Constraint at a higher level to constrain, say, four Dimensions in a single constraint, and a Content Constraint at a lower level to constrain the same four in two, three, or four Content Constraint. 

8.3.3.4 Key Set

  1. It is not necessary to have a constraint on the higher level artefact (e.g. DSD referenced by the Dataflow) but if there is such a constraint at the higher level(s) then:
    a. The lower level constraint cannot be less restrictive than the constraint specified at the higher level.
    b. The constraint at the lower level for any one Member Selection further constrains the keys specified at the higher level(s).
  2. Any Member Selection which is not referenced in a Content Constraint is deemed to be constrained according to the Content Constraint specified at the next higher level which constraints that Member Selection.
  3. If there is a conflict when resolving the keys in the constraint at two levels, in terms of a lower-level constraint being less restrictive than a higher-level constraint, then the offending keys specified at the lower level are not deemed part of the constraint. 

Note that a Key in a Key Set can have wildcarded Components. For instance the constraint may simply constrain the Dimension FREQ to “A”, and all keys where the FREQ=A are therefore valid. 

The following logic explains how the inheritance mechanism works. Note that this is conceptual logic and actual systems may differ in the way this is implemented.

  1. Determine all possible keys that are valid at the higher level.
  2. These keys are deemed to be inherited by the lower level constrained object, subject to the constraints specified at the lower level.
  3. Determine all possible keys that are possible using the constraints specified at the lower level.
  4. At the lower level inherit all keys that match with the higher level constraint.
  5. If there are keys in the lower level constraint that are not inherited then the key is invalid (i.e. it is less restrictive).

8.3.4 Constraints Examples

The following scenario is used.

DSD

This contains the following Dimensions:

  • GEO – Geography
  • SEX – Sex
  • AGE – Age
  • CAS – Current Activity Status

In the DSD common code lists are used and the requirement is to restrict these at various levels to specify the actual code that are valid for the object to which the Content Constraint is attached.

1748249001970-773.png

Figure 10: Example Scenario for Constraints

Constraints are declared as follows:

1748249024975-276.png

Figure 11: Example Content Constraints

Notes:

  1. AGE is constrained for the DSD and is further restricted for the Dataflow CENSUS_CUBE1.
  2. The same Constraint applies to both Provision Agreements.

The cascade rules elaborated above result as follows:

DSD

1. Constrained by eliminating code 001 from the code list for the AGE Dimension.

Dataflow CENSUS_CUBE1

  1. Constrained by restricting the code list for the AGE Dimension to codes 002 and 003(note that this is a more restrictive constraint than that declared for the DSD which specifies all codes except code 001).
  2. Restricts the CAS codes to 003 and 004.

Dataflow CENSUS_CUBE2

  1. Restricts the code list for the CAS Dimension to codes TOT and NAP.
  2. Inherits the AGE constraint applied at the level of the DSD.

Provision Agreements CENSUS_CUBE1_IT

  1. Restricts the codes for the GEO Dimension to IT and its children.
  2. Inherits the constraints from Dataflow CENSUS_CUBE1 for the AGE and CAS Dimensions.

Provision Agreements CENSUS_CUBE2_IT

  1. Restricts the codes for the GEO Dimension to IT and its children.
  2. Inherits the constraints from Dataflow CENSUS_CUBE2 for the CAS Dimension.
  3. Inherits the AGE constraint applied at the level of the DSD.

The constraints are defined as follows:

DSD Constraint

1748249060184-684.png

Dataflow Constraints

1748249096448-329.png

1748249111945-807.png

Provision Agreement Constraint

1748249134379-722.png