Meeting notes - November 14th, 2023

[Chris-ECE]

Numbering of GSBPM subprocesses

• Chris revisited the issue of the numbering of GSBPM subprocesses, based on previous discussions and proposals from ILO and Statistics Canada.
• Feedback shows many people are assuming that the subprocesses (or at least the phases) of GSBPM are sequential.
• One alternative option could be to completely remove the numbering of subprocesses.
• Edgardo pointed out that unlike phase names, the subprocess names are verbose and potentially similar.
• Regarding the (counter-) proposal to use phase prefixes to differentiate change processes and ongoing processes, Edgardo suggested an example where a phase that is ostensibly a “change” phase (e.g. Build) could be ongoing (i.e. in an agile development context). It was agreed not to separate change and ongoing phases of GSBPM, as this may depend on the situation.
• Edgardo explained the aim behind the ILO naming proposal, to make the alphabetical characters mnemonic
• Joni highlighted the aim of aligning GSBPM with GAMSO, which doesn’t have an explicit numbering system.
• Andrew and Cory didn’t have strong feelings, but it was suggested to think about it longer.
• Chris asked whether COOS could introduce its own identifiers. Florian responded that for GAMSO, there are just numbers in sequence. To change the identifier scheme one can just change the property. Franck (in the COOS team) generally suggests that identifiers should not be too meaningful, as you don’t want to change the URIs. One can change the identifier without changing the URIs. Updating COOS would normally be quite light, whatever naming system or identifier are used.
• Edgardo suggested a short abbreviation, for example that Design Outputs could be “DesOut” if we wish to make the URIs meaningful. He was hesitant about the idea of having an arbitrary numbering system such as suggested for GAMSO, and suggested contacting Franck for his opinion.
• Franck subsequently responded to this by saying a change to the numbering wouldn’t have an important impact on COOS, and suggested avoiding meaningful URIs for elements that the core ontology would refer to (GSBPM subprocesses).
• Chris agreed to follow up with the group by email.

Boundary between phases 4 and 5 (first bullet)

• Regarding the first bullet (from Sweden) suggesting an extra subprocess “compile and make data sources available” as well as coding and editing data in phase 4 (as soon as it comes into the office), there was agreement that the proximity of coding and editing to the point of collection does not justify moving tasks between phases, as this is addressed by the non-sequential nature of GSBPM subprocesses.
• Regarding the suggestion for an extra subprocess, there wasn’t a strong appetite for adopting this suggestion, partly as the meaning of the extra subprocess wasn’t obvious without a specific use case to illustrate its meaning (beyond the general point about it referring to administrative data). There was discussion of renaming the final phase 4 subprocess to “compile and finalise”, but some felt that the word “compile” suggests an amount of processing, which could get confusing with the Process phase.

Collect – Boundary between 2 and 4

• Based on the comment from Hungary, it was decided to move the bullet on Preparing a collection strategy from 4.2 to 2.3. This should also help to make 2.3 less instrument-focused.
• It was agreed to add something to 2.3 to mention design of fieldwork or operational planning, etc for survey collections, to address the comment of Mexico.
• There was discussion of rewording the bullet in 4.2 to “reviewing” or “implementing” the collection strategy (after it had been prepared in 2.3) but the reviewing or implementation might take place in multiple subprocesses.

Geospatial

• Feedback from Hungary was agreed.
  Action: Throughout document change “geo-coding” to “geocoding”, and change “geographical” to “geospatial”.