Versions Compared

Old Version 143

changes.mady.by.user Wendy Thomas

Saved on

compared with

New Version 144

changes.mady.by.user Wendy Thomas

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleVirtual meeting 2017-03-15

ATTENDEES: Wendy, Jon, Dan G., Oliver

Update on Lion Server from Oliver:

  • Could be the possibility of getting Lion on the cloud very quickly. There is already a means of moving it up there.
  • Will try to get John Shepherdson for a time and try to get this set up in the cloud. If it doesn't work, then go to GESIS IT department for a short term without the political issues.
  • The cost shouldn't be over about $20/month (traffic would vary but should not really be high)

10 remaining D4Q2 issues

  • These can all be completed before or during the IASSIST Sprint
  • Any issues unresolved prior to the sprint should be well-structured and prepared in order to complete during sprint

DDI and GSIM

The following discussion regards the relationship between DDI and GSIM, what needs to be done to clarify the relationship and a possible work plan to address this. Related issues from DMT 

  • DMT-119 Relationship of Process Pattern in DDI with GSIM
  • DMT-66 Population time space and Unit
  • DMT-67 Implementation of Design Patterns
  • DMT-114 Review of Representation and its use in Statistical Classification View
  • DMT-18 Adoption of GSIM terminology

In terms of GSIM we seem to tie ourselves in knots when our class diagrams do not look the same between DDI and GSIM. Relationship between these need to be in terms of functionality, not replicating the model. A more flexible way of conforming to GSIM. The GSIM model provides the requirements but DDI needs to model the functionality. We need to look at this, write it down, and describe the differences. This requires documentation at a variety of levels. The functional requirements of GSIM and if you have an interface that implements this will DDI provide the same functions? That is the criteria. It would be difficult to go through both models and check that. Could we devote a week to this form of comparison with about 4 people. Does DDI have the functionality to support this.

How to approach this.
1 - idea of taking a group at Dagstuhl to do this would be great, but it would have to be a dedicated group without distractions
2 - splitting into parts makes sense because GSIM has discrete parts and scheduling a day of dedicated work with meetings. We are looking at GSIM and finding stuff in DDI. We could then claim that DDI is an ISO 10000 (technical report) implementation of GSIM (one standard or spec of another if it conforms to that standard if it satisfies the requirements). If we can actually prove we satisfy that requirement it is all we have to say
Spread it out with 3 hour meeting times over the course of several months. Anyone with knowledge of both systems. Need people who know GSIM and people who know DDI. People who worked on various aspects of GSIM: Dan G. conceptual group, J Gager, Arofan, Flavio, Rob McKlelland(?) stats can, Alistair Hamilton, Franck Cotton, Guillaume

ACTION: Dan will check on others who were engaged in GSIM in each of those groups

Can we do the same things in DDI as we can do in GSIM?
The summer sounds like a good idea but we need to lay out the work plan for this carefully. Do we want to involve externals in this or not. Part of this is where HLG stands. If we use the 2 phase approach getting the GSIM people in early we could possibly use Dagstuhl to wrap it. We need to be able to say that we conform. We cannot do this without this type of detailed look. The fact there will be tools made for this specification means that doing this would be an incredible step up. CSPA logical model
HLG is only looking from the point of view of the national statistical offices but their own work is being done by people outside of their own limited community. The next HLG meeting is in November. If we could prove conformity over the summer we could contact HLG.
We have the capability and Dan can go to the HLG meeting. This work would put us in a very good position.

ACTION: Wendy will draft up a work plan, identifying any gaps in DDI we need to get done ahead of this work. We're at the point of proving things work the way we intend them to and making sure we are efficient. We need a work plan that is clear, well-structured, and achievable. Needs to be outcome driven. GSIM: 4 main groups and a underlying infrastructure. We have the same thing in DDI. It should be doable. They could work concurrently and not have to interact much.

Expand
titleVirtual meeting 2017-03-08

ATTENDEES: Wendy, Larry, Jay
Inheritance issues from codebook:

  • Inherited relations that point to different classes they should clearly identify that they overwrite or use a different relationship name
  • Instance question does not inherit from represented question forcing you to have both - file with DCAT

Discussion of DMT-67

What Jay was meaning to do was to first look at a larger problem and solution to look at some of the more specific problems. Looking at an approach.

Need to look at the changes that Flavio made and that some of the work Arofan did may be less applicable. Based on the minutes of the last meeting several issues were raised about some realization packages in the context of Codebook and other use cases. By creating the MethodologyOverview we also created a kind of Pandora's Box. The larger question of how people are going to use this model has been raised. Methodology is rather critical to everything and so how do you get enough "specifics" without having a general purpose realization.

There are people who are interested in higher level descriptions and people who are interested in more specific description or machine actionable content. How to use thing for just "overview". How to simplify (reduce content). As you design something you often start from very general and then flesh it out. Similar to extending from Codebook to Lifecycle. They want to do a Lifecycle thing with specific nodes.

Concerned about us ever being able to cover all types of methodologies. This is why we created the MethodologyOverview. Dan's stitch that could point to any detail.

Maybe it shouldn't be a Methodology realization but a simple overview and how you relate to any extension. You may have to create abstract extension heads.

May need to explore the production issue so that we could extend from pattern abstracts. Or create some none pattern abstract or non-abstract extension bases.

If these things are connectors we should think about whether they need to realize a pattern and just a level of generics layered in like a summary description level that could be used at the design phase of a study. We would also look at whether this would also act as a retrospective summary. What is the impact on Bindings that allowed you to look at a process in real time, retrospectively. [Planning to do (i.e. this is the process that is to be applied); applied use of process (current inputs and outputs); runtime variations; retrospective summary]. Similar to CDISK model (planning, scheduling, ...) Begin with something that is conceptual and then extend it.

Jay could layout the four pillars from CDISK Bridge model and then apply that to our methodology/process model and then see if we could take the same approach.
One of the things you have to decide is where Process belongs. Methodology or Process Pattern? Should these be put together to form a continuous pattern.
Address the issue of being able to use the same content in different views (slices of the model library)
As work gets done post it on DMT-67.

...