RAIRD changes the traditional process of statistical production (see Annex B in 9. Links and attachments) , by bringing the consumer of statistical products into the production flow, offering them the ability to better meet their own needs by assuming some of the tasks traditionally carried out within SSB. This change can be seen by showing where, in the traditional process as described by Statistics Norway’s Business Process Model, the end-user either participates with or replaces the SSB in performing some functions.

The end-users in question are more statistically literate than typical consumers of statistical products – because they are researchers associated with accredited research institutions, they have a level of skill in terms of working with input data that goes beyond the capabilities of most journalists or policy makers. This is a class of users that also has the most specific demands in terms of the statistical products they wish to see.

RAIRD – by offering the creation of specific statistical products as a service to end-users – represents a different paradigm, in which both SSB and the end users benefit. SSB benefits because the end users assume some of the tasks performed today by SSB staff. Thus, the resources needed to meet the end-users demands are less. For the end users, they will be able to get what they want quicker, based on real-time interactions on a larger set of source data.

GSIM Coverage 

Note that there are three very different – but related – types of data structures in this process. The data loaded into RAIRD has a very event-history-based structure, with a single datum recorded for each available event. The Analysis Data Set has a different structure, organized into traditional rows and columns – what GSIM calls a Unit Data Set. The results of statistical operations may be tabular, but more typically as estimates of statistical model parameters and graphical displays – what GSIM describes as a Presentation. The RAIRD Information Model describes all of these, using what GSIM offers, but extending it to cover event-history data.

Further, we have many different examples of processing: the loading process, data catalogue browsing, data selection, data processing, data analysis, and the application of disclosure control. These processes will be modeled using the information objects supplied by GSIM.

Other functions (institutional accreditation, user management) are not as well-described in GSIM, and will require RAIRD-specific extensions.

Annex D Technical Considerations of Mapping RIM to DDI

In order to understand how the Data Documentation Initiative (DDI) standard can be used to implement RIM, we must first ask “Which parts of RIM require the functionality offered by DDI?” Typically, a standard such as DDI is most relevant where metadata is required in a structured, machine-actionable form. This occurs where metadata (and often the data it describes) are passed from one institution to another.

In the case of RAIRD, this occurs during the load process, where the data collected and cleaned within SSB is passed into the Event History Data Store. DDI documentation might also be useful for describing the Final Outputs delivered to the researchers. Everywhere else, the data and metadata within RAIRD exists within a single implementation environment, where a serialization in XML or similar implementation syntax are generally not needed.

When we consider the requirements for the loading of metadata into the Event History Data Store (the Input Metadata Set) we find that several parts of the RIM could usefully be mapped against DDI:

• Concepts and concept systems, with links to variables and external documentation
• Variable descriptions with labels and definitions
• Pre-assessment values for disclosure control, assigned to variables
• Codelists and classifications
• Links to external documentation
• Unit types and associated logical record structures (which variables are associated with which units)
• Relationships between Unit types

Given this set of information, in the XML syntax of the DDI Lifecycle standard we find the ability to describe almost all of the needed information. The only requirement we see here that DDI Lifecycle does not support is the ability to capture pre-assessment values for disclosure control at the level of the variable – this could be handled with some simple extensions to the standard, however, using the extension mechanism recommended in DDI Lifecycle. (DDI Codebook cannot describe the relationships between unit types, nor the pre-assessment values for disclosure control.)

In most cases, the use of DDI Lifecycle for describing this metadata is obvious: the DDI ConceptScheme can describe concept systems, and links with variables and external documentation are supported (DDI Variables reference Concepts, and DDI OtherMaterials can be linked to DDI Concepts as well). DDI offers a rich description for Variables – for the RIM, this will cover all of the different types of variables (GSIM Variable. Represented Variable, and Instance Variable map to DDI’s ConceptualVariable, RepresentedVariable, and Variable constructs, respectively; to support variable-level pre-assessment values, the Data Element construct would need to be extended.)

Codelists and classifications are both present in DDI Lifecycle, and map cleanly to GSIM. Unit Types are associated with Variables in DDI, and the Variables are assembled into Logical Records – these constructs can be used to support the needed description of unit types and record structures. Further, the linkages between unit types can be described in DDI Lifecycle using the RecordRelationship construct.

It should be mentioned that the variable and record descriptions are needed only to the logical level – the load process for the Event History Data Store does not require physical descriptions of the data.

There have been some standard DDI Lifecycle profiles created by UN/ECE for representing GSIM information objects, and these standard prfiles cover almost all of the metadata required for the load process. These can be found at: http://www1.unece.org/stat/platform/display/gsim/DDI+Profiles. These do not cover everything which is needed (especially when it comes to concept systems) but do cover most of the needed constructs from DDI Lifecycle.

For describing the Final Outputs using DDI, we would need to add the physical description of the data and use the DDI Lifecycle NCube construct. This is probably not of value to the researchers, although it might be desireable from the perspective of the organizations archiving the researcher’s work (such as NSD).     

.

RIM Design Principles

The design principles for RIM listed below are based on the design principles in GSIM v0.8 and the design principles for DDI.

RAIRD Information Model v1.0

This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. If you re-use all or part of this work, please attribute it jointly to Statistics Norway and the Norwegian Social Science Data Services.