Skip to end of metadata
Go to start of metadata

 

Link to Modelling Team page

Virtual meeting 27 August

Attendees: Wendy, Flavio, Jay, Johan

 Procedural Issues

  • There was concern about time-lines for some of the content group activities, how much could actually be achieved by end of September
  • Informed them of discussion in AG regarding a change in the publication time- schedule
    • Will inform AG that other teams should be informed about the state of this discussion as it effects their work - we want them to keep working hard but not stress for no reason
  • As the modelers group we need a game plan
    • We have been working on specific topics but don't know how and when they will be tied together
    • Communications within modelers team and between modelers and other teams needs to be clearer so they will know when we are discussing certain topics and they can make us aware of upcoming topics

Things to address in a game plan

  • Capturing more of the conceptual information going into decisions which may be useful to other groups (i.e. Simple vs. Complex)
  • Use of sessions (calls) to discuss dependencies between packages and views
  • Develop an agenda to tackle those dependencies
  • Individual groups need a means of informing modelers of rethinking of content which may effect other groups
    • Example: Simple data description will revisit the instance variable, represented variable, etc to see if they are complete/do what needed for their use case
    • As soon as some idea comes through that touches other packages it needs to be put on the modelers agenda
    • Need an input structure for communications
  • It has to be someone's role to manage the agenda of the group - don't need a modeler to do that
    • The modeler creates the agenda item but the manager gets it appropriately slotted into the agenda and does the follow-up to make sure it is addressed

ACTION ITEMS

  • Inform AG that it would be useful to share information on revision of schedule even before finalized - realize the message is important, but teams  need a head-up that they aren't looking at as strict a deadline as currently (Wendy)
  • Send out a list of what needs to be in a game plan to the modelers for discussion and expansion (Wendy)

 

Virtual meeting 20 Aug

Attendees: Wendy, Oliver, Larry, Jannik

Update on elements from other standards

  • This was part of a broader discussion in the AG and there will be a statement out soon regarding current agreements and points that require clarification or implementation
  • Relayed the general consensus from is and earlier discussion that with the possible exception of primitive types and xhtml, DDI would no longer use native elements from other namespaces in its model
    • xml has been included in Drupal so they can be used as data types but the folder of individual objects is not uploaded to EA for inclusion as DDI namespaced objects
    • Dublin Core will no longer be used as native elements which will require the clear mapping of all DC elements we need to be able to populate from DDI
  • Relayed the sense of the discussion on the need for clear means of capturing equivalence and similarity and how this would work to ensure that it syncs with the process for producing the RDF binding

TOPICS for next meeting:

  1. Equivalence - could people with some knowledge of how technical side works for relaying information for RDF binding in particular; how does this get captured for documentation purposes
  2. Review of Report to Modelers - accept? edit? what are the implications in terms of what needs to get done
  3. What is the check list for getting a prototype (package one)

Flesh out and add to the following base list:

  • Finish reviewing the individual package content
  • Cross review for consistency
  • Implement whatever is required by accepting/editing the Report Modelers
  • Implement the means of indicating equivilent objects in other namespaces namespace
  • Technical workflow of moving from Drupal to Bindings

To Do's
Automatic output from EA to xsd and rdf and creating several pictures from Drupal still needs some refinements

Oliver will look at the technical issues - for capturing information in Drupal (see item 1)
Review and OK or raise specific issues for discussion (see item 2)
Automatic output from EA to xsd and rdf and creating several pictures from Drupal still needs some refinements - Jannik will bring this up at the Tools meeting tomorrow

Virtual meeting 6 Aug

 Attendees: Jon, Larry, Wendy, Jannik

Simple vs. complex in discovery and instrument packages

Agreement upon: More complete package instead of simple and complex versions of packages.

In terms of developing the packages the iteration process from simple implementation towards a more complete complex ending.

 

Discovery

Presentation by Larry of Discovery spreedsheet from email 20140803 containing DISCO elements and discussion

Agreement upon including the missing elements from DISCO not presently in DDI4

 

Simple vs. special case

E.g. is discovery a special case ?

Views define special cases

 

Special cases:

  • E.g. describing information from a special software package
  • E.g. describing data from a special field of science e.g. outer space science

 

Elements from other standards

Reuse of elements from other standards:

  • DCTerms
  • PROV
  • FOAF

 

How do we reference other standards in Drupal

  • Yes as RDF

 

How do we implement this in the model ?

In the RDF implementations it is strength forward via equivalent

In XML there are some possible implementations that can be persuaded in the implementation part

  1. Bring in the namespace and use the element directly
  2. Use a DDI4 namespace and deliver a separate documentation with the mappings that way systems can export to specific other elements
  3. And not going the ddi3 way with a mix of both 1 and 2

 

A as the implementations are derived from the model a possible solution is to make both implementations in the XML space and decide later via reviews.

 

Review from documentation prospective

Quick look revealed room for improvement.

Documenting views would improve by clear use cases.

Inheritance of documentation from other views how is this solved.

 

Homework

Check up upon the TIC Name/Label/Description discussion


Virtual meeting 24 July

Attendees: Jay, Larry, Achim, Oliver. Thérèse

 

Discovery

The Discovery view is a bit confusing at the moment. There is a view called Discovery and there are also two package - Discovery and New Objects for Discovery. It seems like 3 disjointed chunks. What should there be? The view can only reference objects that are already existing (because all it gives you when editing is a checklist of all existing objects. So for the moment there should be a view called Discovery and one package called Discovery. The Discovery view may reference objects which are in packages other than the Discovery package (for example conceptual objects).

There is a great deal of cross over in the objects. Larry will start to clean up discovery

Action: Larry will start to work on the discovery view.

 

Mapping to other standards

The discussion about discovery raised an issue about how we are relating to other standards. Currently no mechanism at model level to map to other specifications. How do we eliminate duplication with Dublin core?

Should we externalise the mapping to other objects or do the mapping within our model. We could map outside of the model. This raises the question of what happens if there is only a representation in XML or RDF. Or we could put them in model where in both XML and RDF representations exist.

It depends on the stability of the standard we are talking about. Ok for DC but problem for less stable standards or standards that might be replaced (foaf?).

We could do mapping via Structured comments in object description? But what about cardinalities? Perhaps we could add a column in Drupal to note things like "mappable to Foaf: person".

We should write a proposal for how to handle this.

 Action: Oliver and Achim to make a proposal about the related standards to circulate to group. Larry would like to be involved in the initial discussions as well


An extended discovery view

The current discovery view does not cover everything. There were some other things that people want. For example role of agents or of use of variables in data analysis model, hypothesis. This should be added to the product backlog.

 

Action items from last meeting

Action: Arofan will go through the Agent package and clean it up. - Arofan not at the meeting

 

Action: Remove Service object and fix relationships to Machine and fix verb tense in relationships in Process package

Action: Create "Complex Process" package and move objects that are not part of the simple - Jay - Jay will do this next week

Action: Arofan to lead the writing on the paper on process. - Arofan not at the meeting


Action: Rename Node in Drupal - Jon DONE

Action: Ask Classifications team to help with GSIM mapping work. Classifications meeting is next week, will ask then


Action: Wendy to frame discussion on universe, population etc.

Wendy circulated a document (Object_Universe_PopulationUnit). This gives some descriptions of the objects but there is a more to discussed. For example, the distinction between target universe and the universe actually measured and relationships to represented variable and instance variable work. Does the term “Population” tie DDI too much to surveys of people?


Action: Oliver will have a look at the variable objects.

Conceptual variable and Represented variable only description and name  - do these need other properties? Where is instance variable? In which package should this live? At the moment it is in Simple data description?

The InstanceVariable / field / variable / column issue needs discussion. We need to be clear for end users of DDI4 about the distinctions between represented variables and instance variables.

Jay has example of conceptual variable (structural equation modeling latent variables are conceptual, manifest variables are represented)

 

Next meetings

Flavio is going to be the modeller for the Classifications group so we will ask him to join these meetings. We need to set a regular time for these meetings. Thursdays are no good as Wendy can't attend. Thérèse will circulate a poll trying to find a better time.

Virtual meeting 11 July

Attendees: Jay, Arofan, Larry, Oliver, Wendy, Jon, Marcel, Thérèse

 

Notes:

Agent

Oliver looked at the Agent package in Drupal. He noticed that there was a pattern in what was modelled. Entities with properties that may change over time had been externalised to a property container (example was Individual Name Type). This container can be changed over time. The other approach is to collapse everything into the main object (Example: Individual). It was pointed out that there is a design principle that states that we only model "real" things. A decision was taken to simplify/collapse the objects in the Agent package.

Action: Arofan will go through the Agent package and clean it up.

Process

The Service object is a duplication of the Machine object in the Agent package. The Service object should be removed and the relationship made to the Machine object.

Some of the relationships are expressed in past tense. These should be changed to present tense

It was agreed that the objects in the Process package should only support a simple process. There are a number of objects that relate to the paralell processing use case (example: Split, Split/Join). These should be moved to a separate package called (for the moment) "Complex Process". A paper should be written that shows how to describe processes in other views. Arofan will write it, with input from Jay. Steve McE would also be a good person to be involved. Larry is interested in reviewing the paper.

Action: Remove Service object and fix relationships to Machine

Action: Fix verb tense in relationships

Action: Create "Complex Process" package and move objects that are not part of the simple - Jay

Action: Arofan to lead the writing on the paper on process.

 

Conceptual

There is a problem having an object called "Node". It breaks the graphs in Drupal. It was agreed to rename the object "Nodec" until a more permenant solution can be found.

There are some issues with the alignment of the DDI 4 modelling and GSIM. There is sometimes a conflict between GSIM and the way it works in DDI 3.2 now. A decision has to be made in each of these instances as to why there is a difference (wither from GSIM or DDI). We need people to go through and carefully check each object.

There is a conceptual variable and a represented variable, but we could not see where the instance variable is. It looks like it belongs to another team (Simple Data Description). Oliver will have a look at what is going on.  

There was a question about the Universe, Population and Units objects. We need to make sure that we get these basic objects right. A discussion should be had with people like Arofan, Wendy, Jay, Dan G and Jenny Linnerud. Jenny had some problems implementing these objects from GSIM so may have some useful info to add to the discussion. Wendy will write something to frame the discussion.

Action: Rename Node in Drupal - Jon

Action: Ask Classifications team to help with GSIM mapping work.

Action: Oliver will have a look at the variable objects.

Action: Wendy to frame discussion on universe, population etc.

 

 

Virtual Meeting 17 June

Attendees: Jay, Larry, Jannik, Johan, Oliver, Wendy Jon, Thérèse

 

Notes:

The Agent, Process, Conceptual parts of the library and the discovery view were created in Drupal during the Toronto sprint. They are now ready to be reviewed by the modelling team. There are notes on the wiki which should help you to know what needs to be checked in Drupal and what conventions have been agreed (see: Drupal Conventions). Wendy will review this document to make sure that it is up to date and correct.

The review works was allocated out as follows:

  • Agent = Oliver
  • Process = Jannik
  • Conceptual = Jay
  • Discovery = Larry

Jon will look at everything from a documentation rather than modelling perspective. Johan will go on holiday (tongue)

The group agreed to meeting in 2 - 3 weeks to discuss results of the reviewing work.

 

TC modeling related meeting 7 August

DDI TC Meeting Minutes

2014-08-07 

In Attendance: Wendy Thomas (organizer), Johan Fihn, Dan Gillman, Arofan Gregory, Larry Hoyle, Jon Johnson, Flavio Rizzolo, Dan Smith 

Secretary: Elise Dunham

AGENDA

Moving forward: grouping mechanisms

HOMEWORK

  • Look over Wendy?s Groups/Collections of Study Units document. (Sent to DDI-SRG on 2014-08-06)

DISCUSSION

Modeling Bags

  • One idea: define order at the item level. Rather than asking the collection if it has an order, ask the items if they have relationships to one another.
  • Reasons for asserting order at the group level:
    • An item may belong to multiple groups.
    • Groups are reusable.

Extensions

  • Need to identify the generic bag types. Already know we need one basic bag and one for order.
  • We can consider a certain set of privileged bag types (controlled vocab) and then allow people to make their own.
  • Another requirement is a non-maintainable group, ex: for things that are transitory during production.
  • Type-extension of bags will not require that all possible collections be specializations of the defined generic bags. For example, questionnaire objects will maintain their own semantics and function outside of these specializations.

Schemes in DDI 3

  • Need to walk through DDI 3 and identify schemes and groups that are actually modules/views (artificial constructs). We won?t be maintaining this kind of thing in 4.
  • Need to identify what we modeled in 3 as groups within schemes and test using 11404 concepts.
    • Model the minimum bag, and pile on top of it to explain the kinds of grouped things, then extend to other grouped things already in the model.
    • Take all the grouping requirements from 3 and move on to include all the additional things we want to group in 4.

Communicating with Modelers re: Seeming Duplication Across Teams

  • The top-down approach makes duplication unavoidable during initial start-up phases.
  • Behooves us to get through the start-up phase quickly by communicating effectively with content teams and documenting decisions.
  • This is an important discussion, and it belongs with the modelers group. Not for TC agenda.


NEXT WEEK

  • Walk through the types of collections we need
  • Discuss how many/what forms of basic bags we need
  • Discuss process for developing modeling guidelines on grouping mechanism.
TC Meeting 31 July regarding modeling

DDI TC Meeting Minutes
2014-07-31

In Attendance: Wendy Thomas (organizer), Dan Gillman, Jay Greenfield, Larry Hoyle, Flavio Rizzolo, Achim Wackerow

Secretary: Elise Dunham


AGENDA

Moving forward: grouping mechanisms


ACTIONS

Wendy
-Revisit documentation & work done on pulling together use cases around groups of study units and different ways of grouping study units. Start a thought piece and send around so others can review and add on.
-Assist Achim with DDI -> 11404 & Smalltalk mapping if needed.

Achim
-Look at existing groups types in DDI 3 and experiment with mapping to ISO 11404 and Smalltalk.

All
-Send out any thoughts/musings on grouping mechanisms over the next week.


DISCUSSION

Bindings

-Jay sent a document highlighting the importance of de-coupling data models from bindings/encodings. There’s agreement that the grouping mechanisms discussion needs to happen from the modeling perspective rather than the binding; doing bindings is something that should happen independently of the modeling work.
-It’s important for us to be aware of the struggle associated with transitioning from XML to UML—when modeling from an XML perspective binding and modeling happened together, but now, in UML separating them is one of our design criteria.

Abstract Bag

-Need to agree on the features of the bag and need to come up with extensions on that for specific types of collection purposes.
-In order to frame this discussion and bring it from the abstract to something practical, Achim volunteered to map group types on DDI 3 to 11404 and SmallTalk.
-"Why are we grouping things?" needs to be one of the driving questions framing this discussion
and informing decisions.

Level of Extensibility
 
-How do we limit application of these grouping mechanisms to prevent creation of groups that shouldn’t be created? Ex: ResponseDomain and CodeList don’t need groups around them. Is it possible to identify a limited set of groups, or is it not feasible to identify all of the use cases? Should we leave the opportunity to use a group for a purpose that is currently unknown?
-Achim’s mapping will help frame the discussion on striking this balance.

Challenges of UML -> Relational Mapping

-The conceptual constructs we’ve been using so far won’t be able to be expressed in relational. The aggregations, additional semantics, doesn’t map cleanly, the more object-oriented it becomes the more problematic it will be for relational expression. It’s something we need to consider.
-Would IDEF-1x be better?
-This is something we should keep on the radar and perhaps bring to a different group for consideration.


NEXT WEEK

Continue grouping mechanisms discussion

 

 

TC Meeting of 20140612 regarding Modeling Issues

DDI TC Meeting
2014-06-12 
In Attendance: Wendy Thomas (organizer), Johan Fihn, Dan Gillman, Jay Greenfield, Jeremy Iverson, Jon Johnson, Dan Smith 
Secretary: Elise Dunham 

TC used this meeting time to advance work commitments to the DDI 4 Moving Forward Project 
AGENDA: 
Name, Label, Description
Identifiers
Containment and Reference/What do we reference?* 
*TC decided to begin referring to the Containment and Reference portion of their work as "What do we reference?" at the 2014-06-12 meeting. 

Actions
Dan Gillman: Write up a document about his ideas on approaching the name, label, description issue in a rigorous manner 
All: Review and send in feedback on GSIM 1.1 to DDI 3.2 mapping document 

Discussion
Name, Label, Description
Frame of discussion/background: in previous versions of DDI, we've used ISO/IEC 11179-5 as the basis for our approach. This included a set of 3 objects: Name, Label, and Description. For Name we used a NameType, with each object having a specific name of type="NameType" (i.e. VariableName, ConceptName, etc.) We've made the decision to just use Name as a direct property of the object. Questions are:

  1. What objects should we be using this with?
  2. Is the full triple always required?


Dan Gillman would like to see us put more structure around names, concepts, labels, and designations. He will write up a document where he'll lay out his ideas on this issue to give a sense of what the distinctions are and how to structure them. Aiming for early next week; send any questions to Dan in the meantime. The group consents to this plan and will use this document when making its proposal to the modeler group. 
Identifiers
Dan Smith wrote up a document on this issue and discussed each section of it with the group. Highlights from this discussion:

  • Group agrees on requirements Dan outlined in this document
  • Character restrictions: in 4 we will lift character restrictions to allow for support of localized identification schemas. The historical reason for character restrictions is now managed by the ability to capture a DDI lifecycle URN in 2.5: identifiers in 4 will still be able to be represented in Codebook.
  • When we get back to working on administrative metadata we need to pay attention to potential overloading.
  • XML serialization and RDF serialization: Dan has outlined 2 potential strategies for doing this, and says it could be done with either approach or a combination of them. The group responsible for determining the approach are the groups doing the transformations.
  • Dan's document is ready to be presented; it's meant to describe the how's, not the what's—that's for the modelers; the how and the application are intentionally being treated as two separate functions in this workflow.


Containment and Reference/What do we reference?

  • Will discuss fully in another meeting.
  • Changed what we refer to this discussion as to "What do we reference?"


Other TC Business
Dan Smith put out a call on the DDI-user list that starts the mapping of the GSIM 1.1 to DDI 3.2. He asks that everyone look that over and send in any comments. If there's feedback, Wendy will put on the agenda for next week's TC meeting. 
Plans for Next Week
Back to TC 3.2 work: Sampling, weighting and questionnaire development.