You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
• Sub-process 5.3-5.4:(continuing from the previous meeting) change of sub-process names (e.g., “check and validate” instead of “review and validate; “detect” instead of “review and validate”; “treat” instead of “edit and impute”)
Alignment with GSDEM terminology was mentioned, which has terms such as “Check”, “Select” and “Treat”.
Following internal consultation, Italy wishes to retain “Review and validate” for 5.3. For 5.4, the name “Treat” would be okay instead of “Edit and impute”.
Carlo suggested keeping the subprocess names fixed, but improving the descriptive text.
INEGI preferred to keep the names as they are, while INSEE didn’t really mind.
It was decided to keep the names fixed for now.
• Sub-process 5.7. Calculate aggregates
We suggest add the following information in the point 86 “This sub-process refers to two main different finalised data files: the first one is a validated, reviewed and improved micro-data file suitable to derive new variables and units as referred in sub-process 5.5 and the second …” (Portugal)
It was agreed not to implement this.
Aggregates can also be used to review or edit metadata. May be clarify the sub-process by adding that aggregates are not just output for the analyse phase (France)
InKyung already added a line to 6.2 about checking aggregates as a validation for microdata, and it was agreed this addressed this comment.
• Sub-process 5.8 Finalize data files
Renaming might be needed to “data set” instead of “data files” (also: suggestion to apply the term consistently in the whole model) (Hungary)
Finland preferred the term “data set”.
Florian said in DCAT, the file format is not relevant, so the emphasis should be on finalising the data set.
Action: Replace “data file” with “data set” in 5.8.
• Boundary between collect phase
Boundary with collect phase (France): It could be useful to make a clear distinction between the population collected and the population of interest. In which sub-process are we restricted to the population of interest, 4, 5.1 or 5.5 ?
Frame may use dwellings. Some variables only about unemployed, and may refer to specific subpopulations of interest.
Action: Retain the current terminology in phase 5, but consider the use of the terms population collected and target population in earlier phases.
Collect phase
If time permitting, we could start issues under “Collect” Phase, with
• Maybe consider in the ‘collect’ phase of the GSBPM separating out respondent engagement and data collection into 2 components. The idea being that they are two quite separate processes with one about ‘recruiting the respondent’ and the other about ‘administering the instrument’ (or ‘gathering the data’). I think is a growing dichotomy with some agencies moving from face-to-face interview to things like ‘knock to nudge’ where the door-step is used to recruit and provide an access code for subsequent CAWI completion. I think this would help, for example, emphasize risks associated with postal approaches (and other indirect approaches) versus other more direct approaches (like door knocking) in terms of engaging respondents (and hence maintaining response rates etc.). I think it would also highlight that the mode of collection can be independent of the respondent engagement process ( so we can pair digital based collection processes with various possible modes of engagement). (New Zealand)
• Carlo didn’t feel it was necessary to split the phase into 2 parts, especially as this has a big impact on its users. InKyung suggested the user engagement aspects could be part of an overarching process, but also said that phase 4 doesn’t have much detail about talking with survey respondents.
• Trusted smart surveys are another example where communication with respondents may be a separate activity to data collection, since the contact is to set up a kind of provision agreement.
• More description about user engagement in collection phase?
• Florian – 4.2 and 4.3 may already implicitly address these New Zealand comments. For INSEE, for industry surveys, recruiting the contact is part of the normal process.
• Action: InKyung to go back to New Zealand, and say there is not much appetite for their suggested change, but to ask for concrete suggestion for how to improve the descriptive text, to make a proposal.
Sub-process 4.2
• Boundary between Phase 3 - Build and Phase 4 – Collect: In case of administrative data sub-process 4.2 includes making some checks with test files and arranging secure channel. It is unclear to what extent this task could be done as part of 3.5 or 3.6. Is 4.2 just about routine check made prior to launching the collection ? (France)
• Giorgia mentioned that when collecting admin data, the initial data checks are not the same as for survey data.
• InKyung suggested moving “arranging secure channels for transmission of data” from 4.2 to 3.5, as well as the reference to receiving the test file, but saying instead that a routine check that the system is working as expected could be performed in 4.2.
Last Sub-process of phases 3, 4, 5, and 6
• The GSBPM needs to systematically analyse and define what is happening in the "finalise" sub-processes (Phases: 3, 4, 5, 6). (GSBPM "Task" task team)
• Action: Everyone to study the last subprocess in phases 3, 4, 5 and 6 to see if their descriptions can be systemized/harmonized.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Addressing comments under the “Process” Phase:
• Sub-process 5.3-5.4: (continuing from the previous meeting) change of sub-process names (e.g., “check and validate” instead of “review and validate; “detect” instead of “review and validate”; “treat” instead of “edit and impute”)
• Sub-process 5.7. Calculate aggregates
• Sub-process 5.8 Finalize data files
• Boundary between collect phase
Collect phase
If time permitting, we could start issues under “Collect” Phase, with
• Maybe consider in the ‘collect’ phase of the GSBPM separating out respondent engagement and data collection into 2 components. The idea being that they are two quite separate processes with one about ‘recruiting the respondent’ and the other about ‘administering the instrument’ (or ‘gathering the data’). I think is a growing dichotomy with some agencies moving from face-to-face interview to things like ‘knock to nudge’ where the door-step is used to recruit and provide an access code for subsequent CAWI completion. I think this would help, for example, emphasize risks associated with postal approaches (and other indirect approaches) versus other more direct approaches (like door knocking) in terms of engaging respondents (and hence maintaining response rates etc.). I think it would also highlight that the mode of collection can be independent of the respondent engagement process ( so we can pair digital based collection processes with various possible modes of engagement). (New Zealand)
• Carlo didn’t feel it was necessary to split the phase into 2 parts, especially as this has a big impact on its users. InKyung suggested the user engagement aspects could be part of an overarching process, but also said that phase 4 doesn’t have much detail about talking with survey respondents.
• Trusted smart surveys are another example where communication with respondents may be a separate activity to data collection, since the contact is to set up a kind of provision agreement.
• More description about user engagement in collection phase?
• Florian – 4.2 and 4.3 may already implicitly address these New Zealand comments. For INSEE, for industry surveys, recruiting the contact is part of the normal process.
• Action: InKyung to go back to New Zealand, and say there is not much appetite for their suggested change, but to ask for concrete suggestion for how to improve the descriptive text, to make a proposal.
Sub-process 4.2
• Boundary between Phase 3 - Build and Phase 4 – Collect: In case of administrative data sub-process 4.2 includes making some checks with test files and arranging secure channel. It is unclear to what extent this task could be done as part of 3.5 or 3.6. Is 4.2 just about routine check made prior to launching the collection ? (France)
• Giorgia mentioned that when collecting admin data, the initial data checks are not the same as for survey data.
• InKyung suggested moving “arranging secure channels for transmission of data” from 4.2 to 3.5, as well as the reference to receiving the test file, but saying instead that a routine check that the system is working as expected could be performed in 4.2.
Last Sub-process of phases 3, 4, 5, and 6
• The GSBPM needs to systematically analyse and define what is happening in the "finalise" sub-processes (Phases: 3, 4, 5, 6). (GSBPM "Task" task team)
• Action: Everyone to study the last subprocess in phases 3, 4, 5 and 6 to see if their descriptions can be systemized/harmonized.
Beta Was this translation helpful? Give feedback.
All reactions