(feedback from Linking GSBPM and GSIM task team; May 2020)

Task team on Linking GSBPM and GSIM (2019-20) under the Supporting Standards Group is working on identifying information needed for GSBPM sub-processes and representing them as GSIM information objects. The team has found few issues related to using Process Inputs and Process Outputs in context of non-Process GSBPM Phase (e.g. Design Phase, Analyse Phase).


One of most notable issues is about how to interpret Parameter Input. Definition of Parameter Input (GSIM v1.2) states “Inputs used to specify which configuration should be used for a specific Process Step which has been designed to be configurable.” While many activities in GSBPM Process Phase are “configurable” (e.g. editing based on certain threshold, aggregating using certain weighting scheme), the “configurable” part of sub-process is not clear in other GSBPM phases. For example, in GSBPM Sub-process 2.4 “Design Frame and Sample” (in Design Phase), “regulations, guidelines or policies” do change how we design frame and sample (e.g. if there is guideline not to overburden respondents, design should incorporate sampling strategy that does not include units that are already included in other surveys). Then these regulations and guidelines are “configuring” this sub-process in a sense that they change how the sub-process is done. Similarly, in GSBPM Sub-process 6.2 “Validate Output” (in Analyse Phase), “assumptions, user needs for quality of the output” configure the sub-process in a way because depending on the user needs, validation sub-process might change [2].

Definition, explanatory text and attributes of Parameter Input seem rather Process Phase-oriented, shouldn’t they be extended to be more applicable in other phases with different natures (e.g. include explanation what “configurable” part means or non-machine actionable information (e.g. document describing user needs, policies) as examples)?

[1] task team meeting (May 5 2020)

[2] task team meeting (April 14 2020)

  • No labels