When justifying changes to GSIM, I would find it very useful to understand how the proposed objects relate not just to other GSIM objects, but also to GSBPM sub-processes (as per the diagram below, from the GSIM documentation). This will help make it clear how the object will be used in statistical processes. If an object can not be related to any GSBPM sub-process, I would suggest that it is not a candidate for inclusion in GSIM.

  • No labels

2 Comments

  1. Alistair Hamilton

    This broadly makes sense to me.  Some GSIM Objects (eg Population and Unit) can be associated with many GSBPM sub-processes.  I doubt we will have completely new "ubiquitous" objects for future versions of GSIM, however, so most completely new objects probably will be associated with a few GSBPM sub-processes rather than many.

    In addition we may have cases where to model existing "ubiquitous" objects properly we need to introduce a new object (eg Unit Type).  In those cases we might consider we've already agreed a number of objects need to be represented in GSIM, so if we find we need to add a further object to make the modelling of existing objects work properly in practice then the requirement to identify their connection with specific GSBPM sub-processes may not be quite such a prominent consideration - the additional object is required to make GSIM as currently specified work.  Then again, even objects introduced for this reason (eg Unit Type) can have examples of GSBPM sub-processes where the need is particularly prominent.  

     

  2. Steven Vale

    Agreed that this is a principle we should follow.

    There is a caution not to take to the extreme. GSIM is looking at GSBPM as it should be (ie future looking).

    We should be transparent about future looking nature of some objects.