Skip to end of metadata
Go to start of metadata


Link to Modelling Team page

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.



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.



Check up upon the TIC Name/Label/Description discussion

Virtual meeting 24 July

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



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




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.


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.



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



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


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

Secretary: Elise Dunham


Moving forward: grouping mechanisms


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


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.


  • 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.


  • 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

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

Secretary: Elise Dunham


Moving forward: grouping mechanisms


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

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

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



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


Continue grouping mechanisms discussion



TC Meeting of 20140612 regarding Modeling Issues

DDI TC Meeting
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 
Name, Label, Description
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. 

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 

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

  • No labels