Skip to end of metadata
Go to start of metadata

40. In order to effectively implement GSIM at a technical level, it should be implemented at a business level first. GSIM does not provide any standard representation of its own, and is intended to be implemented using existing external standards and models, which support technical implementation. This may involve mapping to internal data models or implementation standards used within an organization.

41. Organizations implementing GSIM will need to map the GSIM objects against their implementation models. In doing this, gaps between GSIM and the implementation standards or internal models will need to be identified. Mappings of GSIM to an organization's internal models can be shared with the community via the Global Artefact Catalogue (to be developed in 2014).

GSIM Mapping to SDMX and DDI

42. For some common standard models, GSIM mappings have been provided. The design of GSIM takes into account the possibility to map to implementation models, such as SDMX or DDI. Such a mapping can be used to establish a link between GSIM and its technical implementation. GSIM thus helps to:

  • Compare IT approaches;
  • Detect double work in legacy systems
  • Avoid double work in new systems.

43. Mapping tables have been developed which show how GSIM objects correspond to their counterparts in the SDMX and DDI standards 1 .

DDI Profiles for Use with GSIM Implementations

44. DDI is a very flexible and complex standard, and even within the mappings from GSIM which have been developed, there is still the possibility that two GSIM implementations using DDI might not interoperate. DDI itself provides a mechanism for solving this problem – a feature of the standard known as "DDI Profiles". It is thought that the publication of standard DDI profiles will facilitate the harmonisation of the use of DDI in statistical organisations.

What is a DDI Profile?

45. According to the DDI 3.2 documentation, a DDI profile "describes the subset of valid DDI objects used by an agency for a specified purpose."  This is documented in an XML format (part of the DDI specification) which allows a set of declarations to be made, identifying specific fields in the DDI which are "Used" or "Not Used". Various other qualifications can be made to restrict or default permitted values for specific elements, and human-readable documentation can be added.
46. Thus, an organization or application can specify exactly how it uses the DDI  XML formats.  It is anticipated that as organizations implement GSIM, these standard profiles can be used to form a base set of DDI elements for interoperable use.
47. Examples of some of the profiles 2 which have been developed include:
    BTO Profile: The first profile is "Basic Technical Objects" (BTO). There are a small set of technical objects that are used in DDI to support identification, referencing, dates, external controlled vocabularies, string content, and the basic features of ISO/IEC 11179-5 (Name, Label, Description). This profile provides guidance for the best practice usage of these technical objects to support interoperability. In particular it identifies those objects which should be considered interoperable and applied in a consistent manner, and those that contain primarily local information.
    Variable Profile: This profile covers those DDI objects required to support the Variable, Population and Concept objects in GSIM.
    Represented Variable Profile: This profile covers those DDI objects required to support the Represented Variable, Enumerated Value Domain, Described Value Domain and Unit of Measure objects in GSIM.
    Questionnaire Profile: This is the definition of a 3.2 DDI profile for business questionnaire - test version. This profile includes all the objects, schemes and 'packaging' information needed to create a complete questionnaire, including Questions, Question Groups and Blocks, Statements, Interviewer Instructions, Controls and Instrument.
    Codelist Profile: This profile covers those DDI objects required to support Code Lists and Category Sets in GSIM. 

Common Statistical Production Architecture (CSPA)

48. CSPA is the industry architecture for the official statistics industry. An industry architecture is a set of agreed common principles and standards designed to promote greater interoperability within and between the different stakeholders that make up an "industry", where an industry is defined as a set of organizations with similar inputs, processes, outputs and goals (in this case official statistics).

49. CSPA builds on and uses existing frameworks, notably the GSBPM and GSIM, as the necessary shared industry vocabulary. CSPA complements and uses these pre-existing frameworks by describing the mechanisms to design, build and share components with well-defined functionality that can be integrated in multiple processes easily.

50. For the purposes of developing sharable, interoperable GSIM-based services and applications, the use of the technical standards SDMX and DDI is envisioned, along with some other standards for specific parts of GSIM such as BPEL (Business Process Execution Language), etc.

51.There is a need to do more than simply refer to relevant existing standards such as SDMX and DDI. The CSPA implementation specification for Statistical Services will specify:

  • whether SDMX, DDI or a custom schema should be used for representing a particular GSIM information object, and
  • exactly how the chosen schema will be applied for the particular purpose. In many instances there are multiple technically compliant means of achieving the same business purpose, the implementation specification will specify which should be used.

52.Implementation specifications mean CSPA is prescriptive in regard to some practical details. While it would be simpler to align with CSPA if it was less prescriptive, the practical value from alignment would be much less. It is often the case that two developments that have a "common conceptual basis", but were implemented using completely unrelated approaches, are difficult and expensive to make interoperable and/or sharable (if it is possible at all).

53.In addition, an organization that has already implemented a different standard, or a local specification, can "map" their existing approach to the relevant implementation specification – they are not required to "rebuild" from first principles.

54.CSPA implementation specifications specify approaches that will support maximum interoperability/sharability on a cost effective basis. In particular cases it may be difficult for an organization to fully comply with a CSPA implementation specification (due to operational constraints). In these cases, compliance to the extent practical will, generally, still realize significant benefits. In other words, while CSPA implementation specifications set the bar reasonably (but not unreasonably!) high, it is recognized not all implementations may be able to achieve it fully in practice.

  • No labels