Please read this background document to understand the full context for this suggestion:
Introduction
The last couple of months, Statistics Netherlands has been working on an architectural model of the data collection domain, in terms of functions and information objects. The main purpose of this model is to be the starting point for overhauling the application landscape.
Lately, we have made an attempt to map our concepts to GSIM. We are not satisfied with the results of our attempt and are left with quite a number of questions regarding GSIM and its application in our local context.
The purpose of this document is spark discussion in the international community by explaining (in broad terms) our model of the data collection domain and showing a little of the problems that we encounter in our attempt at mapping our model to GSIM.
We believe that part of the problem is the positioning of GSIM as a vocabulary for describing statistical concepts. In the current version of GSIM, we see an unbalance in the degree of abstraction. Certain areas are very abstract, other areas in the model seem to be on a more logical or even almost physical (implementation) level. Also, some parts are very tailored towards certain applications. As our intent is to create a model that is abstract (enough) to cover a number of current and future developments, we see problems in the use of GSIM in those areas that are on a more logical level or that are focused on certain concrete applications. These concrete applications t tend to be current practices rather than future ones.
By “application” in this sense we mean making conceptual functions more specific by describing not only what the function does, but also how it does it, for instance by applying a certain (set of) method(s). Since there are usually many ways in which a conceptual function can be realized, it seems restricting to model only a few possible ways of implementing a certain concept.
Specific Suggestion
While studying GSIM, we found some other areas where we do not clearly understand the definitions and descriptions. We list just a few of them here.
Instrument and Instrument Implementation are GSIM objects that seem to be more concrete in nature than other objects in GSIM. We question whether (in the current state of affairs) detailed modeling of such concepts is needed in GSIM.
2 Comments
user-8e470
16/10:
Instrument looks like CBS concepts like Instruction and Form Design.
The instrument is what brings together how data is collected/acquired. We do need some conceptual objects about that. Instrument Implementation relates to mode, so it becomes more important.
GSIM model is much less detail than the implementation models (for example DDI). ABS in their implementation model have needed to add much more detailed.
Do you want to know there is an instrument or do you want to be able to reuse the parts of an instrument?
This area is more detailed than other areas of GSIM....but leaving it at instrument is a bit too high. You need to have some more detail in what an instrument gives. The parts of the instrument give you the links to the data itself. From a dataset, it will tell you how the data was collected etc.
There is more commonality in some information areas like structures. There are fewer ways to describe these things, but other areas there is a not as much commonality. An example of this is Production Group. Different areas of GSIM need different levels of detail - from the perspective of a business model.
We need enough commonality to be able to relate the national models to each other.
Worried about a lot of detail in certain areas of the production process. Instrument objects do link other information later in the production process (eg links between variables and questions).
user-8e470
Discussion 29/10:
To keep or not to keep them.
This is a well understood in the implementation space and we are adding a conceptual layer to it. We are modelling something we know quite well.
Does the amount of details suggest that you implement GSIM directly?
These objects are for survey instrument. Change to relate to survey instrument not instrument.
What about other instruments? Do these objects generalise across? What is a question for other instrument?
There are some concepts that people really identify with - like questions, we could have explanations of how things relate work (this is how surveys work in this context)
We could make subclass of instrument control called survey instrument control
Options
1: keep as is
2: remove everything under instrument
3: add other sub types
4: remove lower level objects from "info in a stat organisation" section but still in UML
5: take what we currently have and make it more generic, may be similar objects but new names.
** have to make changes with a good business case**
** not going to leave it as it is **
**balance of simple to understand and not leading down the wrong path **
--> Go to Sprint for elaboration