Hi Group! Here is the document from Hilde and Sophia:
GTM Meeting - 6/19/14
Attendees: Barry, Sophia, Hilde,
Agenda: Discuss the definition of simple vs. complex instrument; Review Hilde and Sohpia's document detailing simple and complex characteristics.
- The document is only to describe the characteristics of a simple instrument - modelling will occurr after the group has had a chance to review this document.
- Approaching this task as bottom-up, not top-down. Domain-specific experts describe the problem, then modelers create the software/standard. The simple instrument implies a questionnaire or survey, but this should not hinder or limit the extension of simple to more complex and non-survey instrument models.
Barry will send annotated document back to Sophia and Hilde who will modify it once more before distributing it to the wider group.
GTM Meeting (Toronto) - ??/??/14
(1) Simple Instrument modelling is tentatively scheduled to be completed Sept., 2014.
(2) "Content" which is what we are modelling (i.e. Simple Instrument) is also known in the Moving Forward project as a "Functional View".
(1) Update from Sophia and Hilde: Description of our expected task, distinguishing between Simple Instrument use case and Complex Instrument; update our description in Drupal and Wiki.
Is SimpleInstrument really meant to describe a simple survey, and ComplexInstrument meant to describe nearly everything else? Or do simple and complex exist as opposite ends of a continuum that is defined by the amount of InstrumentControl that is required to field or describe the instrument?
One of the modelling principles assumed by the Moving Forward project is that elements in a simple object will be present in the complex object. This could pose a problem in the future, i.e. a complex data capture such as biomarker collection may not use Question per se.
(2) How to update the Drupal diagram.
Brigitte and Olof helped fix Statement-InstrumentControl and Capture-Response domain relationships. Doing this we found that Drupal is not accurately rendering relationships (arrows and diamonds are on the wrong ends), based on the specification and description of the relationship.
Relatedly, should Measure have the same relationships to other elements as Question does? if so, why distinguish between the two; why not just have another superclass that combines them?
GTM Meeting - 5/16/14
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.
(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.
Expanded view of SimpleInstrument and how it relates to other foundational objects.