2014-10-24 meeting notes day 5

Owned by Wiki Editor (Unlicensed)
Last updated: Oct 24, 2014
3 min read

Date

Attendees

  • Ornulf, Wolfgang

Goals

  • Detect links between SimpleCodebook and DataDescription and Instrument

Work

1) The Codebook use case implies that we need a lot of information about a dataset, its variables, and their question texts/descriptions

2) To find these additions to the Study level information in the codebook, a link is needed from the StudyUnit object, containing a DataCollection activity, to the dataset as modelled by the DataDescription group

3) The DataDescription package contains an object DataSet that in the simple case can be an equivalent to a data file (but also data stream etc...). Via DataSetStructure that is related to InstanceVariabe, which is the object that can give the Codebook most of the Variable object information that is needed.

4) Rather than linking directly fro StudyUnit-DataCollection to DataSet it would be possible to go the path via the Instrument as Defined by the DataCapture group. There is the object ConceptualInstrument that has an ImplementedInstrument with one or more ProcessSteps. These ProcessSteps can be an InstrumentComponent that may be a Capture that may be a Question which has e.g. a text property. The Capture (ans thus the Question) has a link to an InstanceVariable, and from there we can get all the Variable object information for the Codebook that is needed.

5) Due to simplicity of the model only on link from the StudyUnit to the needed objects should be modelled - if suffiecient. That would imply to use the latter (4) link in the model.

6) The Codebook use case could start with the object "DataSet" and get all information needed from there.

7) From Barry: My thinking is that it makes sense to 'derive' or arrive at a variable using the path Ornulg and Wolfgang propose: the end-point, a Variable, contained in a Dataset, derived from a Capture (Question, Measure, etc.), which resides in a ImplementedInstrument, which is an instantiated ConceptualInstrument, which is the data collection plan of a StudyUnit. There seems a logical sequence in play here and thus one logical way to 'link' from higher level object like StudyUnit to a more granular level object like Variable. Instead of linking directly between the two, follow the natural progression or path between them.

Additional information:

  • The SimpleCodebook group should keep separate the following things:
    • to model the StudyUnit - DataCollectionDesign objects and their links to others in a way that several use cases / views can make use of them 
    • to create a CodebookView that makes use in a specific way of these objects for the Codebook use case
  • In drupal the DataCollection object is now renamed to DataCollectionDesign. This one is related to the StudyDesign object in the Methodology package (the StudyDesign object already has a link to the ConceptualInstrument object of the DataCapture group)
  • There might be a discussion in the Methodology group about the Methodolgy objects that are needed. For a study description part of a codebook we will need some descriptive properties from there, but the SimpleCodebook group currently does not go into the modelling aspects here.

Open issues:

a) The use case list of elements from IHSN was not yet completely included into the excel list of necessary elements. This should be completed. (SimpleCodebook group)

b) There were no properties and relationships of the objects in the SimpleCodebook package which were imported from the DDI3 (StudyUnit etc.) deleted: The not needed ones could be needed by other use cases. Decision must be made how to proceed (DDI4 project)

c) The SimpleCodebook View is not yet defined on the drupal site. It should be defined for ojects that already are finished. (SimpleCodebook group)