Message-ID: <1738122236.4632.1455079806989.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4631_2122926842.1455079806989" ------=_Part_4631_2122926842.1455079806989 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Please read this background d= ocument to understand the full context for this suggestion:
The last couple of months, Statistics Netherlands has been working on an= architectural model of the data collection domain, in terms of functions a= nd information objects. The main purpose of this model is to be the startin= g 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 co= mmunity by explaining (in broad terms) our model of the data collection dom= ain and showing a little of the problems that we encounter in our attempt a= t mapping our model to GSIM.
We believe that part of the problem is the positioning of GSIM as a voca= bulary for describing statistical concepts. In the current version of GSIM,= we see an unbalance in the degree of abstraction. Certain areas are very a= bstract, other areas in the model seem to be on a more logical or even almo= st physical (implementation) level. Also, some parts are very tailored towa= rds certain applications. As our intent is to create a model that is abstra= ct (enough) to cover a number of current and future developments, we see pr= oblems in the use of GSIM in those areas that are on a more logical level o= r that are focused on certain concrete applications. These concrete applica= tions t tend to be current practices rather than future ones.
By =E2=80=9Capplication=E2=80=9D 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 i= n which a conceptual function can be realized, it seems restricting to mode= l only a few possible ways of implementing a certain concept.
While studying GSIM, we found some other areas where we do not clearly u= nderstand the definitions and descriptions. We list just a few of them here= .
Instrument and Instrument Implementation are GSIM objects that seem to b= e more concrete in nature than other objects in GSIM. We question whether (= in the current state of affairs) detailed modeling of such concepts is need= ed in GSIM.