...
...
...
...
| Info | ||
|---|---|---|
| ||
| Expand | ||
|---|---|---|
| ||
Participants: Dan Gillman Jay Greenfield Larry Hoyle
Discussion: We discussed the Codebook example Larry put together based on the Australian National Election Study. The file and another example can be found at the Simple Codebook View team page (https://ddi-alliance.atlassian.net/wiki/spaces/DDI4/pages/491676/Simple+Codebook+View+Team). The file for ANES is ANES2017.xml and the original codebook from the study is the file ADA.CODEBOOK.01259Highlighted.pdf The ANES example, built using Oxygen, is pretty complete. Larry led us through a discussion of each element and where each description went. We found a few things Larry forgot including Variable Groups. In the new View, these are called Variable Collections after the Collections Pattern. The new Variables Collection allows one to form a group with variables from anywhere in the cascade. So, the type (conceptual, represented, and instance) can be mixed. In DDI 2.x, this cannot be done. We wondered if the name, Variables Collection, should be changed to the DDI 2.x name, Variables Group. Since the functionality has expanded, it might be good to accept the name change. The modeling Team needs to take a look at this. |
| Expand | ||
|---|---|---|
| ||
Simple Codebook Meeting 2017-08-15 Attendees: Dan Gillman, Larry Hoyle We discussed the classes imported from DDI3.2 used for variable statistics, currently residing in the SimpleCodebook Package. After discussion we decided that these classes should be added to the SimpleCodebookView. That has been done. |
| Expand | ||
|---|---|---|
| ||
Simple Codebook Meeting 2017-03-28 Attendees: Dan Gillman, Larry Hoyle, Jared Lyle, Oliver Hopt Discussion on an issue in Jira concerning the pysical data description within SC, (CWG-8) displaying the relation to DataDescriptionView - Result was, that all classes listed there should be in SimpleCodebookView so Larry will add them. Looking back at the work in the Norway Sprint, saying that, we could cover all DDI-C elements into DDI-V classes. - This might convince DDI-C users to upgrade, especially if we offer a more user friendly access to the mapping, that we created. - It will also be important to show, how actual examples wil look like, without all the extra attributes within the classes, that are not applicable within a certain view. - This is also a strength of the views in general. - And tools will help with hiding complexity. A tool for editing SimpleCodebookView metadata might look exactly the same as a DDI-C tool. - From that point on, we could start to show, what the benefit would be from switching to DDI-V by making visible, what then would be possible. |
| Expand | ||
|---|---|---|
| ||
Simple Codebook Meeting 2017-03-14 Attendees: Dan Gillman, Larry Hoyle, Oliver Hopt Looking into Larry's YAML template, which is very usefull for identifying classes with to much detail modeled. Reduction is absolutly neccessary A lot of things could be reduced to just a URI. This will include ExternalControlledVocabulary, ExternalMaterial. If interoperability is needed for the content of these classes, it will be possible to download through the URI. The most cases with interoperability will be those that rely on DDI data, which will be identified directly by the prefix of the URI. This is to be discused within the modelling team. |
| Expand | ||
|---|---|---|
| ||
Simple Codebook Meeting 2017-01-17 Attendees: Jared Lyle, Dan Gillman, Larry Hoyle The group discussed the remaining needed information items for simple codebook from the google sheet https://docs.google.com/spreadsheets/d/1VDbVz2KRRSX_KEf0IfuE-QqMyTDupftCZfBdBM6VPT8/edit#gid=294218085 We discussed Embargo and Security. Do these need to be attached to more than Study and InstanceVariable? For the Methodology related items we discussed creating realizations of the Methodology class. This raised questions to be raised with the Modeling group: Where does Embargo go? (one proposal: in Annotation) Or Embargo relationship from InstanceVariable Where should security information go? (one proposal: in Annotation) Access from InstanceVariable Make a Methodology realization to use overview for: TimeMethodology (0..1) SamplingMethodology (0..1) DataCollectMethodology (0..1) … (more) OtherMethodology (0..n) InstanceVariable (ConceptualVariable?) points to derivationMethodology Need Methodology at the high level - do we need all of the classes it relates to as well? For derivation we need to add Design and Algorithm General question for modeling- how do you add in just part of a pattern? |
| Expand | ||
|---|---|---|
| ||
Simple Codebook Meeting 2016-11-22 Attendees: Dan Gilman, Oliver Hopt, Larry Hoyle We discussed a YAML template of the codebook view and looked at it in NotePad++. This revealed the complexity of the model (20992 lines in the template) which should probably be discussed in the Modeling Team. The YAML template was produced by a small Python program that reads the xmi.xml from the lion site, parses it and produces the YAML. We discussed the possibility of having a YAML template accessible for each DDI4 class either through the nightly build or from lion. The codebook YAML template is available in the list of files on the Simple Codebook Team page. |
| Expand | ||
|---|---|---|
| ||
Notes on Codebook meeting 13 September 2016 Participants: Dan Gillman, Steve McEachern, Larry Hoyle, Gillian Kerr Review of missing content in Data Description required by Codebook 1. Embargo for variables: Security, embargoes, access: 2. Variable "interval" Note that both of the above have "primitive data types" in ISO11404 (nominal - state, 3. Variable files suggest leaving this out and see if this is needed in the review. Note that the codebook approach here may be counter to the modelling strategy we have for DDI4 - it also makes reuse problematic. 4. Summary statistics suggest leaving this out of review and note that it has to be developed. We could note what they will be, and where they may be located (on the DataStore??). Suggest looking at how Lifecycle handles them (similar to a key-value pair) after the review is completed. (Conversation following with Wendy: probably attach with the physical file, but should not be tightly integrated). 5. Derivation Description (and related): suggest to be addressed by Methodology and Process Methodology items: need to be addressed by the Methodology group Other items: ACTION ITEM: responseUnit and analysisUnit should be discussed via email in the next two weeks |
...
| 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:
|
...