Message-ID: <772946252.22435.1412181806674.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_22434_10775654.1412181806426" ------=_Part_22434_10775654.1412181806426 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Attendees: Barry, Hilde, Jannik, Sophia, Steve, Jon, Guillaume
Agenda: Reviewing issues raised by Guillaume and Hilde
(1) Represented question. In the simple model now, the distinction betwe= en represented and instance isn't needed? Yet if, when extended to the comp= lex, if this causes problem then we should include it. According to Jannik,= there is nothing in the current Simple Instrument model (using Views and P= ackages) that prohibits reusability. However, this has not been= clarified by the overall modelling group.
(2) Question Grids, Blocks. Grids are basically a way of describing a ta= ble and cells and their location in a self-administered or face-to-face mod= e. E.g., a question is a 1x1 grid. Included.
(3) Redefine Statement to include capture instructions.
(3a) External aids can be referenced by either InstrumentControl and Que=
stion. Jannik says being able to do this 2 different ways, is a problem. Th=
ere are 2 ways to do this because of the need to be reusable in both Instru=
mentControl and Question. Again the issue of reusability is determinant.
(4) RepresentedQuestion/ConceptualVariable. A design pattern (at a highe= r level of abstraction) trumps the need to include language, time, etc. at = the lower (simple level). The design pattern is referring to Sophia's point= that there are 4 properties of Groups (Panel, Language, Geography, Time). = See the principle in (1) that Jannik made about modelling principles, in wh= ich characteristics that are shared across Views or other Simple Objects sh= ould be modeled at a higher level. This is the same issue as reusability; i= s this something that has to be dealt with at a lower granular level. <= strong>Table for the overall modeling group.
(Other issues from Hilde's email)
Revised Simple Instrument Objectives:
Attendees: Barry, Jon, Sophia
(1) Continue discussion of how to use Hilde and Sohpia's document to des= cribe the objects in simple and complex instruments.
(2) Individually grind through the objects in our current diagram and re= solve any controversies or disagreements.
Revised Simple Instrument Objectives:
Attendees: Barry, Sophia, Steve, Jon
(1) Review Hilde and Sohpia's document detailing simple and complex char= acteristics.
(2) Determine what else our object model needs in order to send to model= ler (Jannik).
assign to Parking Lot
(1) Add In/Out column to Hilde/Sophia's document and distribute to the g= roup 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 tim= e that isn't inconvenient for someone.
Hi Group! Here is the document from Hilde and Sophia:
Attendees: Barry, Sophia, Hilde,
Agenda: Discuss the definition of simple vs. complex instrument; Review = Hilde and Sohpia's document detailing simple and complex characteristics.= p>
Barry will send annotated document back to Sophia and Hilde who will mod= ify it once more before distributing it to the wider group.=20
(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 expecte= d task, distinguishing between Simple Instrument use case and Complex Instr= ument; update our description in Drupal and Wiki.
Is SimpleInstrument really meant to d= escribe a simple survey, and ComplexInstrument meant to describe nearly eve= rything else? Or do simple and complex exist as opposite ends of a continuu= m that is defined by the amount of InstrumentControl that is required to fi= eld or describe the instrument?
One of the modelling principles assum= ed by the Moving Forward project is that elements in a simple object will b= e 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 Questio= n per se.
(2) How to update the Drupal diagram.
Brigitte and Olof helped fix = Statement-InstrumentControl and Capture-Response domain relationships. Doin= g this we found that Drupal is not accurately rendering relationships (arro= ws and diamonds are on the wrong ends), based on the specification and desc= ription of the relationship.
Relatedly, should Measure have th= e same relationships to other elements as Question does? if so, why disting= uish between the two; why not just have another superclass that combines th= em?
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 m= odel Content? Are UML diagrams appropriate at this point, or should we empl= oy 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<= span> from Thomas Bosch).
(3) Review and discuss our task - to what exte= nt do we consider ComplexInstrument characteristics?= p>
Develop a robust model that is comprised of core elements that= ably describe a simple survey instrument, but which doesn't break down whe= n applied or extended to more complex situations.=
"Capture" is an abstract class.= span>
Diagram is incorrect:
Statement should have a different relationship to InstrumentCo= ntrol (InstrumentControl uses= Statement)
Also, Capture uses ResponseDomain - need to change the dir= ection of the arrow.
Include a new Instrument class called "other data sources= ?" Keep in mind that Measurement was originally intended as a 'placeho= lder' for more complex data capture contexts. For now, we will table (or pu= t in the parking lot) Measurement and other complex data captures, and conc= entrate on a truly simple survey instrument, but Measurement may have very = similar relationships to other elements and end up acting much like Questio= n.
(1) Define our tas= k! Hilde and Sophia work together to define characteristics which distingui= sh simple from complex instruments.
(2) Sophia and Gui= llaume determine what elements should be (temporarily) assigned to the Park= ing Lot and determine how to create folders to store such things (there was= more to this, but I can't recall).
(2) Barry will fig= ure out how to log into Drupal and clean up incorrect relationships.=
(3) All will try t= o 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 foun= dational objects.