Logical information model LIM Geneva 22 24 june

Logical information model LIM Geneva 22 -24 june

Why LIM • The gap between the conceptual nature of the GSIM and the practical implementation focus of the CSPA was too wide. • To bridge this gap, a new layer, a Logical Information Model (LIM), was needed.

CSPA Service st e b e k a e m h o t t n How f GSIM i A P o use xt of CS e cont Stats Agency Environment

E U GL

CSPA Logical Information Model

LIM • The aim of the LIM is to translate the conceptual GSIM information objects into physical specifications of the information that flows in and out of statistical services. • LIM describes the information objects and logical relationships required to support a CSPA service, in a manner which is consistent with GSIM. • LIM is independent of the terminology used in existing standards such as SDMX and DDI.

Scope for LIM • Not all GSIM information objects will make it to LIM. • The LIM is only concerned with the service and as such will not be taking all GSIM information objects down to LIM level.

The way forward: Build the LIM as we need it!

LIM development criteria • CSPA services development roadmap • Statistical agencies internal service development roadmap • Reusability factor • Coverage provided by existing standards

LIM possible physical representations

Adding attributes to existing GSIM classes: Base classes and Code List • • All attributes in Identifiable Artefact, except local ID, are mandatory. This required a change in the cardinality of some attributes w. r. t. GSIM and the moving of some attributes to other information objects. After mapping to DDI, three new attributes were added: Local ID, Version Date and Version Rationale. A Code List is a type of Node Set that contain Code Items, i. e. a combination of the meaning of a Category with a Code representation. Specific Code Items can be created to support imputation of missing values. The Code List inherits all identification and administrative information from Identifiable Artefact.

Adding class extensions to GSIM: Process Execution • • • A Process Control defines the flow within Process Steps and between different Process Steps. In particular, it can describe the flow within a service and also between different services. Process Input and Process Output are used to identify the information objects to be passed across the service boundary. There are three types of Process Input in LIM: Transformable Inputs, Process Support Inputs, and Parameter Inputs. And three types of Process Output: Transformed Output, Process Execution Log and Process Metric. These six classes are additions to GSIM 1. 1.

Developing LIM for each service: • Stage 1: – Determine the information inputs and outputs (GSIM objects) – Check if the inputs/outputs are covered by LIM • If yes, service builder uses relevant part of the LIM, as well as a recommended physical representation • If no, contact CSPA implementation group for guidance, possible LIM development – Look at which standards are in scope of the request • Stage 2: – LIM development team consults more broadly on needs – On acceptance of development, make it CSPA mandated

Status for LIM

Candidate Services

Further development of LIM • CSPA Implemention group • Subgroup LIM • Variables identified as high priority – Help avoid risk of implementors using different Variable incorrectly -> easier to share services – Neuchâtel terminology model definitions

Where to find information http: //www 1. unece. org/stat/platform/display/CSPA/Common+Statistical+P roduction+Architecture

Thank you! • • Eva Holm - Statistics Sweden David Barraclough – OECD Flavio Rizzolo – Statistics Canada Based on original slides by Therese Lalor