| Info | ||
|---|---|---|
| ||
| Expand | ||
|---|---|---|
| ||
Meeting Minutes, 5 July 2016 Attendees: Dan Gillman, Michelle Edwards, Larry Hoyle, Gillian Kerr, Steve McEachern The meeting focussed on reviewed the output of the previous meeting (see minutes below) for those who were unable to attend previously. As noted in the previous minutes, there are three core areas of decisions to be made by this group to progress for the Q3 release. Each are considered below.
Decisions for Modelling group 1. Optional vs mandatory content It appears to be that focus will be on making everything optional. Wendy Thomas has circulated a document on this through the SRG. Larry commented that we need to consider what content is being imported into the Codebook view when we import the packages that we rely on - particularly those classes that are not appropriate or relevant. Gillian also noted on mandatory content that if it IS mandatory, then people will often include nonsense content to comply with the field requirements - REDUCING data quality. Suggested that content might be better managed by making it optional, and then enabling links to reference content (e.g. ORCID for author/investigator information). Dan noted that content could be supported by VALUE or by REFERENCE - which would be one means of enabling this. 2. Citations Should we retain the text string citation, or just use constructed citations In Norway, the preference was to remove the text string. However there are cases where there may be recommended text that a data producer requires. 3. Access conditions Decisions for the SimpleCodebook group (or for referral by SC to other teams) 1. Geographic polygons Why opt these out? Can include by reference? 2. Variable metadata There is content from 2.5 that is basically describing fixed width files. If we want to include something along these lines (and this was agreed by consensus from the Codebook group - although we may improve upon the current handling within 2.5) then the DataDescription group needs to address this. (Steve to include in next DD agenda) Larry noted that we probably should include the relevant PhysicalLayout classes and attributes (contributes :-) 3. ResponseUnit and AnalysisUnit These are rather mixed up in Codebook. Dan suggested referring back to the Unit/UnitType/Population/Universe content in the Conceptual package. But we need to carefully specify the relationships. Going forward: - Draw on the existing content on Access Conditions and the available classes from the Data Description To do: |
| Expand | ||
|---|---|---|
| ||
Minutes of Simple Codebook group, Tuesday June 21, 2016 Attendees: Steve McEachern, Larry Hoyle, Oliver Hopt Review of the output from Norway continued. The group focussed on how to resolve the outstanding fields identified in the DDI-C profile (from the Google spreadsheet here: The proposal was for the remaining content to be addressed through three mechanisms: 2. Variable metadata: 3. ResponseUnit and AnalysisUnit (and Unit of Measurement) Variable content characteristics may be best addressed now: - VariableInterval, Recommended for deferral - All fields within Methodology section of DDI-C - Also includes Imputation This requires output of Methodology team 2. PhysicalLayout
|
...
| Expand | ||
|---|---|---|
| ||
Codebook meeting 2 February 2016 Attending: Dan, Michelle, Steve, Oliver, Jon, Larry, Jared There’s some lack of clarity about where this group is at. Discussed what to include in simple codebooks. One idea is to review the spreadsheet of common elements (summary of CESSDA) and build on that. Essentials seem to include: enough information to read the data into statistical package, label values, understand universe, understand what measure means so you can interpret the data, attribution information. Another idea is to look at examples of simple codebooks, identify what they use, and then map to a model. We need to be careful to keep things simple. Even older versions of DDI 2 weren’t exactly simple. If we nail down definitions, then do we make instances of previous versions incompatible? As we define what information elements we want in DDI 4.0, we can specify which element you want in 2 if you’re going backwards. Next steps:
|
...