Meeting notes - August 20th, 2024

[Chris-ECE]

Benefits of standards generally

Although in the previous call, Chris suggested writing a general description of the benefits of standards including SDMX (previously suggested by Andrew) and GSIM, etc (beyond the integration of processes benefit mentioned in the suggestion from Mexico to include in the text of subprocess 2.2). Looking further at the document, there is a lot already written about the purpose of GSBPM (in the introduction), and additional benefits of GSBPM (in a separate section towards the end of the document). Restructuring this material into a general preamble at the start of the introduction would require restructuring this material, and possibly examining in detail which of the identified benefits apply also to other standards apart from GSBPM. At the moment, the first sentence of the introduction to the GSBPM document describes the purpose of GSBPM, which is straight to the point for the reader, and starting with a more general discussion about the benefits of standards generally could be a distraction from the core content. Once we write some text about the benefits of standards, this may also lead to calls to mention extra benefits, which might expand that text.
This was discussed with the group, and it was agreed that a discussion of the benefits of standards generally is outside the scope of the GSBPM document.

2.4

Regarding the comment from Ecuador and from the GSBPM “Task” task team about sampling frames being applicable only to non-survey sources of data, this has already been addressed by changes made on 18 June and 5 July 2024, in response to other feedback. It was agreed no additional change was needed.

2.5

Regarding the comment from France, to add design of matching strategy to the text of 2.5, it was noted that design of data integration from multiple sources is already mentioned in the text. Data integration is understood here to include data matching/linking, and therefore it was agreed that no further change is required.

Regarding the suggestion from Ecuador, to split 2.5 into two separate subprocesses for design of processing, and design of analysis, Carlo expressed reluctance to change the number of subprocesses, as it is a major change that is hard to manage for those using the GSBPM. It was agreed that such a change should only be made if a large number of organizations are calling for it.

Regarding the title of subprocess 2.5, it was suggested that we don’t want to give the idea that we are doing an analysis of the design (rather we are designing the analysis). Gabriel suggested the analysis part of the title might be confusing, as it doesn’t say what’s being analysed. He suggested perhaps Design data processing and analysis, although it was agreed this this might exclude processing of metadata, so this suggestion was discounted.

Since 2.5 relates to the design of the process phase and the analysis phase. – It was therefore proposed to rename subprocess 2.5 to “Design processing and analyse phases”.

Chris suggested that the level-3 tasks could provide more specific detail for those who are seeking it without splitting subprocesses, which already comprises the following:

• 2.5.1 Design specifications for data integration
• 2.5.2 Design specifications for data coding
• 2.5.3 Design specifications for data validation
• 2.5.4 Design specifications for data editing and imputation
• 2.5.5 Design specifications for calculation of weights
• 2.5.6 Design specifications for calculation of aggregates
• 2.5.7 Design methodology of data confidentiality protection
• 2.5.8 Design procedure for production of final outputs
• 2.5.9 Design systems and tools for data processing and analysis

Regarding the suggestion from Hungary, to have a subprocess for designing each phase, changing the title of 2.5 as discussed above might be taking a step in that direction (since there is a subprocess that designs phases 5 and 6). Similarly, subprocess 2.3 designs data acquisition, which is basically phase 4.

However, in previous calls, we decided against having subprocesses for “Design of Evaluation” or “Design of Dissemination”, and it would not make sense to design the Design phase, nor the Specify Needs phase. It was agreed that not all of the phases can be designed in phase 2.

In response to a question from Giorgia, there was discussion of renaming 2.1 to Design outputs and dissemination phase. Gabriel asked if everything that happens in the Disseminate phase can be designed beforehand.
There was then discussion of “Design of Evaluation”, but it was previously decided not to have a subprocess for “Design of Evaluation”.

Carlo said that for 2.1, the design of outputs is more important than the design of the dissemination phase, as the outputs are the basis for designing other things later.

Carlo expressed doubt about mentioning “phases” in the titles of the subprocesses and said this might be accommodated in the descriptive text instead, bearing in the mind the impact of changing subprocess titles on the users of GSBPM. He suggested that you don’t really design the phases themselves, but rather the tools, the systems, the methods. He suggested discussing with the wider group.
Action: It was agreed to prepare a proposals for the other members of the group, and to ask whether reference to phases should be made in titles or in the description text?