Skip to end of metadata
Go to start of metadata

 

Link to Simple Instrument Team page

Next meeting
 Barry: When you are in "edit" mode, copy and paste this box, then put your new minutes into the new "ui-expand" box that appears (smile)
GTM meeting - 9/9/14

GTM Meeting - 9/9/14

Attendees: Barry, Jon, Sophia

Agenda:

(1) Continue discussion of how to use Hilde and Sohpia's document to describe the objects in simple and complex instruments.

  • We don't have a quorum, but need to make progress. There are a few characteristics to resolve in Hilde/Sophia's document; should these be hashed out at Dagstuhl.

(2) Individually grind through the objects in our current diagram and resolve any controversies or disagreements.

  • Flesh out Drupal objects, roll document characteristics into Drupal, more use cases, examples, descriptions.
  • Need modelers input; modeler needs to be part of our conversation as we think about these different objects, their definitions and how they related to each other
    • That said, we think we are nearly ready to hand this off to a modeler for input - we have had modeler types already opine about this (Sophia, Guillaume, Brigitte)
  • How many of the objects are solid; of course there will be quibbling about minor issues, but we think the model is robust; let's see if it can be broken.
  • Sophia: could benefit from modeller - our instrument is small part of larger picture.
    • DDI has 800+ objects - are other 'somethings' (datasets, etc.) being modeled similarly? Are those groups using similar processes?
GTM meeting - 8/27/14

GTM Meeting - 8/27/14

Attendees: Barry, Sophia, Steve, Jon

Agenda:

(1) Review Hilde and Sohpia's document detailing simple and complex characteristics.

  • Does this document help to define our task? If not, how can it be improved?
    • Yes, it is helpful by arraying both simple and complex side by side.
  • Review Achim's email. Does this help define our task? 
    • Yes, we take a step back.
  • Perhaps "Simple" can be further defined by what it is NOT?
    • Sophia: if we have problems in common (simple vs. complex) perhaps someone can come up with guidelines.
      • We need to discuss/review the document with the whole group.
    • Barry: Simple vs. Complex are not explicit easily-defined distinct categories - better to think of them as ends of a continuum.
      • How should we use the document?
    • Jon: we have to decide where the line is, knowing there is some margin of error.
      • The boundary between simple/complex is informed by the knowledge that we have to extend the model at some point.
    • Steve: the distinction has hindered progress.
      • Need to know what the complex case is before defining simple; we should almost do this backward modelling from complex to simple, drawing a line around the simple case.
      • Data description group is doing something like this.

(2) Determine what else our object model needs in order to send to modeller (Jannik).

  • Walk thru each object and relationship one-at-a-time.
    • Walking thru Hilde and Sophias' document
  • Determine which objects which are hindering progress, and either:
    • resolve to everyones satisfaction, or

assign to Parking Lot

Action Items:

(1) Add In/Out column to Hilde/Sophia's document and distribute to the group for discussion.

(2) Explain our philosophy that we really need to start with the complex and then subset the simple case.

(3) Determine pain points in the current model figure - go through each one-by-one and try to resolve those pain points.

(4) Schedule another GTM meeting for 2 weeks, same time. There is no time that isn't inconvenient for someone.

 

GTM Meeting - 6/19/14

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 toronto

GTM Meeting (Toronto) - ??/??/14

Attendees:

News:

(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".

Goals:

(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

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.

 

 

Expanded view of SimpleInstrument and how it relates to other foundational objects.

 

3 Comments

  1. Added some images from Dagstuhl. Testing this Wiki's capabilities.

    1. Hi Barry, I moved things around a little to display the information better. I used a PDF macro (type {the start to type the name of the macro or click insert then select "open macro browser" and resized the pictures a little. Hope this is helpful (smile)

      1. Thanks Therese, I'm groping my way through this, my first Wiki, so this IS helpful.