Core And Local Representations In A Data Structure Definition¶

This page expands on the brief introduction in Create A Simple DSD. It explains how a DSD component gets its value domain, and what changes when you define a local representation in the DSD itself.

Overview¶

In a Data Structure Definition (DSD), each component such as a dimension, attribute or measure is linked to a Concept.

That Concept may already define a representation:

an enumeration, usually through a Codelist, for coded values; or
a text format, such as String, Integer, Decimal or DateTime, optionally with further restrictions such as minimum or maximum length.

When a component uses the representation defined by its Concept, that inherited representation is called the core representation.

Sometimes, however, the DSD needs to apply a different or narrower value domain for a specific use case. In that case, the component can define its own local representation.

Core representation¶

The core representation comes from the Concept, not from the DSD.

This is useful when the same Concept is reused across several structures and should normally carry the same meaning and value domain everywhere it appears. For example, a FREQ Concept may be associated with a frequency codelist and reused in many DSDs.

If a component has no local representation, the core representation is the one that constrains the values that may be reported.

Local representation¶

A local representation is defined on the component inside the DSD. It allows the DSD to override or refine the Concept's default representation for that one component.

Typical reasons for using a local representation are:

to restrict a broad Concept-level codelist to the subset needed in one DSD;
to replace a Concept-level representation with a different one for a specific structure; or
to apply a more specific text format, such as a fixed-length string or a numeric format with tighter rules.

The key point is that the local representation applies only within that DSD. It does not change the underlying Concept.

Which representation constrains the component?¶

The inheritance rules follow the SDMX 3 information model:

If there is a core representation, but no local representation and no text format, the core representation constrains the component.
If there is a core representation and a local representation, but no text format, the local representation constrains the component.
If there is a core representation, no local representation, but there is a text format, the text format constrains the component.
If there is a core representation, a local representation and a text format, the local representation constrains the component. In this case the text format is informational only.

In practice, this means that when both are present, the local representation takes precedence over the inherited core representation.

How this appears in the DSD wizard¶

In FMR, this information is maintained in Step 3 of the DSD wizard.

The example above shows a DSD in which local representations have been defined for all components. This lets the DSD specify exactly which values are allowed for each component, even when the linked Concepts have their own core representations.

SDMX-ML serialisation¶

In SDMX-ML 3.0, a local representation is serialised within the component definition. In the example below, the FREQ dimension has a local enumeration and an enumeration format:

<message:Structures>
    <str:DataStructures>
        <str:DataStructure urn="urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=BIS:BIS_CBS(1.0)" isExternalReference="false" agencyID="BIS" id="BIS_CBS" version="1.0">
        <com:Name xml:lang="en">Consolidated Banking Statistics</com:Name>
            <str:DataStructureComponents>
                <str:DimensionList urn="urn:sdmx:org.sdmx.infomodel.datastructure.DimensionDescriptor=BIS:BIS_CBS(1.0).DimensionDescriptor" id="DimensionDescriptor">
                    <str:Dimension urn="urn:sdmx:org.sdmx.infomodel.datastructure.Dimension=BIS:BIS_CBS(1.0).FREQ" id="FREQ" position="1">
                        <str:ConceptIdentity>urn:sdmx:org.sdmx.infomodel.conceptscheme.Concept=BIS:STANDALONE_CONCEPT_SCHEME(1.0).FREQ</str:ConceptIdentity>
                        <str:LocalRepresentation>
                            <str:Enumeration>urn:sdmx:org.sdmx.infomodel.codelist.Codelist=BIS:CL_FREQ(1.0)</str:Enumeration>
                            <str:EnumerationFormat minLength="1" textType="String" maxLength="1"/>
                        </str:LocalRepresentation>
                    </str:Dimension>

This tells us that the FREQ component is constrained by the local representation defined in the DSD, rather than only by whatever representation may be associated with the FREQ Concept itself.