| Info | ||
|---|---|---|
| ||
| Expand | ||
|---|---|---|
| ||
Sprint Meeting to finalize DataCapture DataDescription and Methodology (Dagstuhl, Germany) - 10/-18/15-15 thru 10-23-15. DataCapture attendees: Barry, Flavio, Dan, Jon Process Model Issues The Process Model does not allow the use of sequences to operate in the same way as it does in DDI-L. This requires a change to the process model so that a sequence contains a Process Step, and that the other structures in ControlConstruct can similarly be contained. The lack of an "if-then-else" ControlConstruct would make many situations overly complicated, so it need to be restored back into ControlConstruct. A process step can either be a Control Construct or an Act. Control Construct is a designates flow and Act is a particular activity such as the capture of data. This was the outcome of the changes required to the Process Model
In addition, it was suggested that Split be added to the Process Model, this was a suggestion from Dan Smith (but the reason was not captured) Changes to the Data Capture model The model was revisited in light of the changes made to Drupal not reflecting the intentions at the last Sprint. The main innovation was the evolution of thinking to retain Question as a "first class citizen" and create a similar structure for other forms of data capture. As a consequence, this meant that hasResponseDomain, and hasConcept could be moved to Capture rather than being repeated in Question, and hasInstruction and hasExternal Aid could also be moved from Question to Capture so that it is reusable across all Capture types. The consequence of this is additional structures (a Question and a separate element called Measurement), but it would simplify / clarify documentation of Capture where both Question and another Capture were used sequentially, such as in the administration of a test within a survey. Renaming Question to be RepresentedQuestion mimics / is analagous to the design pattern used in the Variable Cascade. As such both Question and Measurement have Represented and Instance elements. More work needs to do be done on RepresentedMeasurement, so that it is able to support other non-Question use cases, such as protocol (blood pressure measurement), data linkage, etc. One promising alternative–one that might satisfy adherents of QuestionGrid/Block–is to extend Measurment with controlled vocabularies that describe the myriad of other non-Question and non-survey data capture types. Reminder note: Not every InstrumentComponent has a Capture (e.g., it could just have a Statement or an Instruction). This is obviously important to have a flexible flow during the conduct of a Capture.
|
...
| Expand | ||
|---|---|---|
| ||
GTM Meeting - 5/16/14 Attendees: Barry (meeting minutes), Achim, Sophia, Guillaume, Hilde Goals of this meeting: (1) How best to use our Wiki space? Is viewable by anyone who knows the URL. All information (conversation) is documented and does not get lost. Organize by topic; datestamp and initial contributions; (2) What technique is the best way for us to model Content? Are UML diagrams appropriate at this point, or should we employ a less technical approach (use simple text, flow chart, etc.)? - draw freehand diagrams to begin discussion; when we draw an arrow we add text to explain the arrow or relationship. See how the text in example below describes the relationships.
- group members become literate in UML (see useful UML quick reference from Thomas Bosch). (3) Review and discuss our task - to what extent do we consider ComplexInstrument characteristics? Describe our task: to describe a simple survey instrument (need to define: what is simple survey instrument compared to complex survey instrument?) Develop a robust model that is comprised of core elements that ably describe a simple survey instrument, but which doesn't break down when applied or extended to more complex situations. "Capture" is an abstract class. Diagram is incorrect: Statement should have a different relationship to InstrumentControl (InstrumentControl uses Statement) Also, Capture uses ResponseDomain - need to change the direction of the arrow. Include a new Instrument class called "other data sources?" Keep in mind that Measurement was originally intended as a 'placeholder' for more complex data capture contexts. For now, we will table (or put in the parking lot) Measurement and other complex data captures, and concentrate on a truly simple survey instrument, but Measurement may have very similar relationships to other elements and end up acting much like Question. Homework: (1) Define our task! Hilde and Sophia work together to define characteristics which distinguish simple from complex instruments. (2) Sophia and Guillaume determine what elements should be (temporarily) assigned to the Parking Lot and determine how to create folders to store such things (there was more to this, but I can't recall). (2) Barry will figure out how to log into Drupal and clean up incorrect relationships. (3) All will try to schedule another GTM during the Toronto sprint. Barry will send a Doodle poll to non-Sprinters and talk to Therese about a venue at Toronoto.
|
| Expand | ||||
|---|---|---|---|---|
| ||||
Diagram as of 10/3/14
Expanded view of SimpleInstrument and how it relates to other foundational objects.
|
...