Materials from External Review work at Dagstuhl Sprint |
ATTENDEES: Wendy, Oliver, Jay, Larry |
ATTENDEES: Wendy, Jay, Larry Collections
Sprint prep:
to do before sprint
|
ATTENDEES: Wendy, Dan G., Jay
Collection model discussion Discussed relation to Node/NodeSet |
NOTE there was not meeting 2017-04-05 due to the NADDI Conference ATTENDEES: Wendy, Jay, Larry, Oliver
Questioned whether for a codebook which is retrospective (or at least descriptively focused) there is a need for multiple moods. Oliver won't be available next week. Primitive data types - send Oliver issue number |
ATTENDEES: Wendy, Larry, Dan, Jay, Oliver, Jon NO MEETING NEXT WEEK - NADDI |
ATTENDES: Wendy, Oliver, Larry, Jay |
ATTENDEES: Wendy, Jon, Dan G., Oliver Update on Lion Server from Oliver:
10 remaining D4Q2 issues
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
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. 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? 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. |
ATTENDEES: Wendy, Larry, Jay
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. |
ATTENDEES: Wendy, Jon, Jay, Dan G., Oliver, Larry
Both specific issues and general approaches were discussed. The following are comments from the discussion in the order they appeared. They have been labeled to facilitate the work of DMT-120 in preparation for the IASSIST Sprint
General Issue Description:
Possible approach:
Use cases:
Possible approach:
Specific issue:
Future work:
General Issue Description:
Ideas for unification:
FUTURE AGENDAS:
Agenda item for IASSIST Sprint for MT:
|
ATTENDEES: Wendy, Jay, Oliver, Larry, Dan G., Jon
Reviewed document for DMT-105, this will be revised for terminology. A number of consistency review issues were noted.
|
ATTENDEES: Wendy, Larry, Dan G., Oliver, Jay Server issues: Reviewed issues currently being worked on (listed below and updated where we are) How to handle issues ready for entry review:
NEXT WEEK: |
ATTENDEES: Wendy, Oliver, Jon, Dan G. Jay, Larry Discussion
DMT-117
NEXT WEEK: ACTION: Wendy will summarize above discussion and provide text for various uses. These will reviewed next week for agreement and specific actions |
ATTENDEES: Wendy, Jon, Larry, Oliver, Dan G. |
ATTENDEES: Larry, Dan G., Jay Reviewed the proposed Descriptive Methodology. Recommended name change. Added Issue to MWG |
ATTENDEES: Wendy, Larry, Jay
ACTION:
Background information from emails below: |
ATTENDEES: Wendy, Jon, Oliver, Jay, Larry, Flavio
ACTION:
NOTE: Flavio will be unavailable until later in the spring |
ATTENDEES: Wendy, Dan S., Flavio, Oliver, Jon, Larry, Guillaume, Barry, Jay AGENDA: DMT-102, DMT-96 (detail notes are on DMT-102)
|
ATTENDEES: Wendy, Flavio, Jay, Larry List issues we need to talk about with Flavio CategoryItem and CodeItem solution - look for this (Dan G. conversation) - related to signification pattern Linked DMT-102 and DMT-96 comment from Jay regarding Workflow See DMT-96 for discussion Relook at level of relations between patterns (extension of classes between patterns) Review need of identifier in realization of pattern where an object is not identifiable (leave as associations until review is done) Patterns vs. Realizations and the use of generic realizations * At the Workflow level - any issues where there is daylight between what is in the realized and what is needed by Instrument we need to remove the daylight - for example make an InstrumentFlow rather than a generic Workflow * Really mitigates against have "generic" realizations and having specific use realization (collection is an example of this because the realizations are use specific How to deal with the second workflow type by starting an Instrument Flow package and allowing Workflow to remain more generic ACTION: Flavio will get the binding piece into Drupal so that we can update the FV so it can be tested. |
ATTENDEES: Wendy, Dan S., Oliver, Larry, Guillaume, Flavio DMT-108 entered in Drupal GitHub as Issue 61 DMT-80
DMT-96 - notes also added to issue Clarify what this is trying to accomplish Dan S. -
Binding
General question in point. Was thinking that Workflows implementation should be the basis of all of the processes we have. Everyone will have to create their own conditional constructs. Workflows is the base of what can be extended for different usages. There are a lot of things in there that deal with more than just the workflow aspects. Services, precondition, design, algorithm used, etc. Focus on Information Flow, control features, etc. i.e. a question doesn't have a process framework. Or instructional command, command code, etc. Act in Methodology might be "we did a pretest" which don't need an instructional command. Very concerned that process is becoming so generic ACTION: Flavio will rework the bindings and parameters based on this discussion Wendy will review workflow for making it leaner and more focused |
ATTENDEES: Wendy, Larry, Oliver, Dan G., Flavio, Jon Larry: Manual template for an instance variable in YAML then used his python program to produce a YAML template for each view One of the issues is how to represent repeating elements in YAML Larry will share when its complete That becomes a definition of a JSON schema so it shouldn't be hard to produce a JSON output/binding DMT-100 Dan will talk to Barry et al to get more information DMT-102, 96 Flavio will try to have ready for next week; contact Dan Smith to join if this is on agenda DMT-97
DMT-101 Yes its wrong - Flavio has been assigned DMT-99 Larry is working on DMT-98 done Added DMT-109 regarding clear definition of Functional Views DMT-108 Oliver will put on Drupal issue list DMT-107 Wendy will provide background DMT-105 Wendy will try to have for next week NEXT WEEK AGENDA: DMT-102, 96 |
ATTENDEES: Wendy, Jon, Larry, Oliver, Dan G., Flavio DOC: Short discussion of templates for Use Cases - problems in terms of size and usability NodePad++ - YAML editor https://notepad-plus-plus.org/ JSON also a possibility but its easier to add comments in YAML DMT-103 resolved: primary issue referred to DOC-12; added issue DMT-105 review of abstract class usage and content DMT-95 closed DMT-102 went over with Flavio, he will create the two possible approaches to revising workflow; Wendy will draft up review of Abstracts and rules for use outside of Patterns |
ATTENDEES: Wendy, Larry, Dan G., Oliver, Flavio Went through new issues from Dagstuhl. Priority is DMT-102 and DMT-96. See JIRA issues for details. DMT-102 Get Flavio and Jay to look at workflow issues and come back with a recommendation DMT-96 Binding set up meeting - Input/Output/Binding Flavio will begin discussion with Dan Smith to clarify what is needed, what didn't get into Drupal. Dan Smith should be involved in this discussion. Send out note to small group to get this started. DMT-103 Pattern issues - Oliver will create a list using XSLT and Wendy will do a first past for review DMT-95 Check with Barry about meeting times. Oliver/Wendy DMT-98 Wendy will do it Next Weeks Agenda Flavio should have some content for DMT-102 or DMT-96 |
ATTENDEES: Wendy, Larry, Jon, Dan G., Oliver Finalizing package for TC:
|
ATTENDEES: Wendy, Larry, Jon, Dan, Jay Reviewing what needs to get done to send TC
|
ATTENDEES: Wendy, Larry, Oliver, Flavio, Dan G. Quick question:
Methodology in or out?
ACTION: We need a roadmap - Notify AG Make them a Jira task list Patterns Document:
Reviewed DMT-89
|
ATTENDEES: Wendy, Dan G., Flavio, Larry, Jay Flavio: Process Document
Asymmetric Relations:
Process Pattern:
Other:
Jay's review of DD - he seems happy with what he is seeing; just need to note coverage etc. Layering on Run time - not committed for Q2 Review DMT-89 NEXT WEEKS AGENDA: DMT-90 is on Codebook (lower priority - does not effect Q2) |
ATTENDEES: Arofan, Wendy, Larry, Dan G., Oliver, Flavio AGENDA:
Timing of review
Patterns
Data Description
Questions for content group chairs and MT to be sent out by TC:
Process Pattern Service, Input/Output, Workflow Steps Design time and run time
NEXT WEEK AGENDA:
|
ATTENDEES: Arofan, Dan G., Flavio, Oliver, Jon, Larry AGENDA: Review of the Process Pattern and Workflow object properties. Process Pattern: Service object, processPeriod property. - Decision: The Service object in the Process Pattern will not talk about time (processPeriod property). This will be moved to more concrete classes. There are three applications of time: Effective time (Availability), Historic time, and Expected Time. Look at estimatedDuiration in the WorkflowService object. - Service inputs and outputs? Service does not relate correctly to Process Step. Leave as an open issue. Service needs a more complete review, but we should wait until we see how people implement it (regarding what properties they need.) There are also issues with the relationship between process step and service. The process step references the service - is the directionality right? And how does the interface property inform this relationship? Should location and interface be controlled vocabularies? Is a Service actually an Agent? Put these questions on teh agenda for next week. Review the definitions. Workflow: Workflow Step. We seemed OK with the existing property set. Workflow: Binding. Remove usage property. If anyone needs it, they will tell us. Workflow: Input and Output Parameters. Need a DDIObjectType property (controlled vocabulary). This is not used for specific instances, but we may add a run-time parameter. This is for design time. Value will be the type of any DDI object (including abstract classes and those found in patterns). Add purpose and usage properties. Flavio will update the patterns document to include the Workflow realization of the Process pattern. May include a Data Capture example in future. The pattern document could be the basis of less-technical end-user documentation in future. |
ATTENDEES: Arofan, Wendy, Flavio, Dan G., Oliver, Larry Review of new patterns: Process Pattern
Signification Pattern
Methodology Pattern
AGENDA FOR NEXT WEEK:
|
ATTENDEES: Wendy, Flavio, Larry, Oliver, Dan G. (second half) AGNEDA:
Process Pattern
ACTION: Flavio will render new Pattern package in Drupal moving classes to the appropriate locations; any emptied packages will be deprecated Sign/Signified
ACTION: Make sign and signified into a pattern as it separates the existence of concept from the notion of creating a sign (Flavio) |
ATTENDEES: Wendy, Flavio, Jon, Larry Basic rules regarding realizations:
Put a statement in asking for review/suggestions for dealing with this DECISION: Add the InformationFlow (see image) and send out for comments PRIOR to next meeting. We need to get feedback quickly as many are not available for meetings in summer. Issue around what checks we need to be doing need to be added to XML binding specification Write up rules for what is needed
Is the pattern based on anything or just a flower of Flavio's imagination? Based on discussions of MT and goal to make Pattern classes very generic and need to keep some classes outside rather than inside the pattern Sign and Signified: Changing Sign and Signify to a Pattern This way a Concept can play the role of Signify when a code realizes a sign This means that Concept would now extend Signified, which would imply that all Concepts are now Signified. I don't think that's what we want to say. A Concept is a Signified only in the context of having a Designation that denotes it. One way of addressing that is to make "Sign - denotes -> Signified" into a pattern that Designation and Concept realize (in the picture, the isA relationship from Designation to Sign and from Concept to Signified would become realizations). That way, Designation and Concept would still extend Annotated Identifiable and we would support the fact that a Concept is not a Signified until a Designation denotes it. DECISION: Do it and make it a pattern. Put it into Lion. High level documentation needs revision based on these changes Who is the audience for the documentation: content provider or the software creator How to review the XML Binding:
|
ATTENDEES: Arofan, Wendy, Larry, Flavio, Dan G. AGENDA:
1 -
2 -
3 - Flavio will send something out for next week to review 4 - Review during week and raise any issues - on next weeks agenda for approval Note: DD is meeting Thursday and will hopefully provide content for Q2 review as a result |
ATTENDEES: Dan G. and Flavio. We discussed the Designations and Code Item document that Flavio started. The document provides a general introduction to modelling Signifier, Signified and Sign and some of its subclasses. Dan agreed with most of the proposed model, except for the issues below. Flavio's model had associations to both Code and Category that are specializations of those in Node for Designation and Concept. Dan raised the point that it could be confusing to have those specialization and proposed to add a constraint to the documentation to deal with the fact that the potentially multiple Designations and Codes associated to a Code Item have to refer to the same unique Category. Flavio agreed. Dan's constraint is the following: Code Item must contain:
In addition, Flavio's model is an attempt to simplify how Signifier is represented. The notion of a Signifier is too abstract for most modelers and users. Flavio's proposal is to make the Signifier into a property of Sign called representation. The alternative is to make Signifier into a separate class. The former approach is simpler but it can be limiting for some application. For instance, as Dan pointed out, it’s easier to perform lexicographical analysis (e.g. homograph identification, stop words removal, stemming, term categorization) when Signifiers are first class objects and therefore can be more easily manipulated. After some discussion Dan and Flavio noticed that the issue was really more about a physical representation rather than a conceptual one so they decided to have the simpler representation with Signifier as a Data Type in the conceptual/logical model and clarify in the documentation that people have the option of making Signifier into a class in their physical implementation. ACTION: Flavio will update the document and model, send it one last time to Dan for review and present it in the next modelling meeting. Flavio will start the cleanup of the Drupal after that. |
ATTENDEES: Wendy, Flavio, Dan G., Oliver, Achim Cardinality discussion
Specific points in discussion:
ACTIONS:
DECISIONS:
|
ATTENDEES: Wendy, Flavio, Oliver, Larry ACTION:
PATTERNS:
ACTION: For Collection
ACTION: For process and methodology
ACTION:
BINDING:
DOCUMENTATION: wish list
|
ATTENDEES: Arofan, Wendy, Flavio, Larry, Dan G. Reviewed the following documents, edited, and posted:
ACTION: Implement decision regarding Identifiable and Annotation - completed 2016-07-06 wlt NEXT WEEK: Pattern Review |
ATTENDEES: Wendy, Flavio, Achim, Jon, Larry, Oliver, Dan G. (Arofan had a work conflict) AGENDA:
Pattern realization issues arising from Flavio's work
In UML patterns should be interfaces
Change of Member to realize
Idea that NodeSet and Node are a type of pattern
We have datatypes and value domains in the model but they are not related
NEXT WEEKS AGENDA and FOLLOW-UP WORK:
|
ATTENDEES: Wendy, Arofan, Flavio, Jon, Larry, Oliver DMT-75 OK change Member to Identifiable Done How to realize the pattern in Drupal -
What else should be a pattern? Methodology -
Cascade - next week List of relationships - when and how used...good documentation
Cardinality - TC will discuss tomorrow and get to MT after meeting |
ATTENDEES: Arofan, Wendy, Achim, Jon, Oliver, Larry, Flavio, Dan G. AGENDA Idea that Jon had in Edmonton on how we packaged the documentation and schema so they make sense to the user
Document on Use of Standard Properties in DDI 4
ACTION: Create clear location on Modeling Team page and circulate document along with link
AGENDA next week:
|
ATTENDEES: Wendy, Arofan, Achim, Flavio, Oliver, Larry, Dan G., Jon
Realization of a FV that was complete:
|
ATTENDEES: Wendy, Flavio, Larry Reviewed a draft (verbally related) of the details of how to go about selecting and entering Functional View content. Looked at the list made by Codebook group as well as the tool Larry has been developing. Instructions will focus on the intellectual side of selecting classes for entry, decision points, and documenting. Mention will be made of work being done on tools to facilitate this but specifics won't be added until tool availability is more stable and Drupal is altered. Looked at bindings and talked about draft of recommendation for Binding changes. This involved a recommendation to change Member to Identifiable and short discussion of reviewing patterns to see where these could be stripped down so that simple usage did not carry as much baggage. Recommendation was entered as a DMT issue. |
ATTENDEES: Arofan, Wendy, Larry, Jay, Oliver AGENDA:
Regarding Views:
Larry will add new issue on purpose of DocumentInformation and its use
|
ATTENDEES: Wendy, Dan G., Jon, Flavio, Oliver, Larry ITEMS for next weeks agenda:
Dipsosition of remaining issues from last weeks review for Q2
Codebook
Later
|
ATTENDEES: Wendy, Flavio, Dan G., Oliver, Larry, Achim Realizing a pattern - as a class, in a view
Creating a View:
Additional notes for documentation:
CommandCode:
Goal:
Before Q2:
Before Codebook:
|
ATTENDEES: Arofan, Wendy, Dan G., Larry Discussed organization of NADDI Sprint including draft of content, ground rules, and priorities Added DMT-10 as a critical issue: versioning of the model Wendy will review issues to see which have summaries and recommendations (primarily those from TC review Q1 results) and identify those that need this done Larry will prepare a summary for DMT-10 Very ambitious schedule requiring some ground rules:
|
ATTENDEES: Arofan, Wendy, Oliver, Flavio, Larry, Dan G., Jon AGENDA: Process model update (Action items in bold)
|
ATTENDEES: Wendy, Flavio, Larry, Oliver, Johan Discussed updated document on Processing Model and issues arising in Methodology Team work Methodology model suggested changes: (note that Methodology Group has not discussed this proposed model change yet. It was brought to MT because of impact on Core Process relationship between Process and ProcessStep) see Methodology Group minutes for 2016-03-21
Core Processing Model:
Document:
|
ATTENDEES: Arofan, Wendy, Dan S., Oliver, Johan, Larry, Flavio, Jon DMT-58:
Dan Smith:
Solution:
|
ATTENDEES: Arofan, Wendy, Larry, Jon, Flavio, Oliver, Dan G. Collection Pattern:
Issue from Codebook:
Process Pattern:
|
ATTENDEES: Wendy, Larry, Achim, Oliver, Flavio, Dan G., Jay AGENDA:
Additions to Collections document
ACTION:
Start on Processing document three images from email
ACTION: Develop list of examples Issue DMT-58
|
ATTENDEES: Arofan, Wendy, Dan G., Achim, Flavio, Oliver, Johan, Larry Flavio's DDI Patterns document
Will need a similar piece for the process pattern. Flavio may be able to start but Jay will need to fill in the gaps. Add to model review: make sure cardinality supports production process AGENDA for next week: |
ATTENDEES: Arofan, Wendy, Oliver, Jon, Dan G., Flavio, Larry, Achim, Jay Flavio Images on Relations Binary Relation - Introduce the Symmetric Binary Relation and the Antisymmetric Binary Relation
DECISION: Generalize Antisymmetric Binary to Asymmetric Binary and the Ordered Pair; Anti-part is specified in the child classes Binary to N-ary relationships (image with note)
DECSION: Directionality is correct MAJOR ANNOUNCEMENT: Arofan CONCEDES THE POINT to Flavio!!
ACTION: There is general agreement with the change. Can we get it documented and move forward in Lion? Flavio will update in Lion and verify that the classes are used in the right way. Whole thing could take 3 weeks. First couple pages for next week so we can review as he writes. FUTURE AGENDA ITEMS: DMT-58
|
ATTENDEES: Arofan, Wendy, Larry, Jon, Achim, Flavio, Oliver, Johan, Dan G. AGENDA:
Round-Trip Issues:
DECISION
NADDI Sprint:
NEXT WEEK:
|
ATTENDEES: Arofan, Wendy, Larry, Jon, Flavio, Dan G. AGENDA:
Continuation of DMT-48
NADDI
|
ATTENDEES: Arofan, Wendy, Flavio, Dan G., Jay, Jon, Larry, Johan AGENDA:
Review Relations and Correspondences to see if there is anything we need to change SEE DMT-48
Added DMT-48 to track the following work:
|
ATTENDEES: Wendy, Larry, Oliver, Flavio Agenda: Review list of tasks for priorities, note any additional issues
For next week:
Oliver not available the next two weeks. |
ATTENDEES: Wendy, Achim, Larry, Flavio, Oliver, Dan G., Dan S.
|
ATTENDEES: Wendy, Larry, Dan G., Johan, Flavio Discussion of:
ACTION: File issue for Lion - Although "include in build" is checked on the Edit page it does not appear on the general view for a Functional View (wlt) |
ATTENDEES: Wendy, Larry, Oliver, Flavio Moved the changes from Dagstuhl into Drupal
Do we need a review process? What is being looked at? Use Case application? |
ATTENDEES: Wendy, Larry, Flavio, Oliver, Dan G. Reviewed issues in DMT and assigned priorities. Issues 13 and 14 were determined as done due to actions of other groups. |
ATTENDEES: Wendy, Dan G., Oliver, Larry Discusses what needs to be dealt with at Dagstuhl Sprint.
Issues:
Presentations:
|
ATTENDEES: Arofan, Wendy, Larry, Johan, Dan G. Qualitative review of model (see .pdf files on Qualitative page)
Modeling Team needs to set up a group of use cases and get back to the qualitative group to review and test. Evening session at Dagstuhl to review with outside groups and people who haven't previously looked at the General
|
ATTENDEES: Arofan, Wendy, Flavio, Johan, Larry, Oliver Order Relationship:
Make better use of JIRA DMT project
Qualitative (Larry sent email and posted proposed model to Qualitative Team page)
|
ATTENDEES: Wendy, Flavio, Larry, Oliver Regrets: Arofan, Jay Reviewed relations types on spreadsheet adding some additional subclasses to create so that we could cover Allen's Interval Algebra and RCC8 (geospatial relationships). These relationship descriptions will be useful parts of the descriptions as they are expressions that many users are familiar with. The work will be continued based on use cases that arise. For now we could go forward with the example types we have identified after we complete the grid contents for each. |
ATTENDEES: Wendy, Larry, Oliver, Dan G. Agenda: Work examples from last week in detail. Larry and Jay DDI4 and Qualitative Data.pptx
Documentation issue to hand to Jon:
ACTIONS:
|
ATTENDEES: Falvio, Wendy, Dan G. Oliver, Johan, Larry, Arofan
Decision:
|
ATTENDEES: Arofan, Wendy, Dan G., Oliver, Jay, Johan, Larry, Flavio Agenda
Jay modeled a sampling methodology based on Dan G. Sampling Plan Design
Flavio work on Classification and order relations
Larry - Order Relations Qualitative Files
NOTE: Oliver will send something on schema creation by the end of the week. Agenda items for next week:
|
Modeling Meeting Minutes 2015-07-29 Flavio's model as discussed above: |
ATTENDEES: Arofan, Achim, Flavio, Johan, Larry, Wendy, Jay, Dan G. Site update - reorganization has been done but need to review items in the JIRA list from London and document locations Ordering: how do we go about structurally talking ordering options fall into the usage of subtypes or attributes or combination of the two Attributes:
If you are declaring an ordering it is transitive Currently this information is related in different ways in the model Do we want to change what is there? add, remove? ( emails from Flavio and Jay) We want consistency
Five options were listed in minutes of 2015-07-08 Alternatives: (1) We have a single OrderRelation class in the pattern, and rely on its definition when realized to determine whether it is partial, transitive, reflexive, etc. The review process would guarantee that definitions are rigorous. (2) We expand OrderRelation in the pattern with a set of useful sub-classes, which specify transitivity, reflexivity, etc., and these are the classes in the pattern which are realized instead of OrderRelation. (3) A variation of 2: We have the OrderRelation class, as well as completely defined useful subclasses, but we allow any of them to be realization points in the pattern. People who don’t understand the subclasses would just realize OrderRelation directly, and the review process would correct any misuse. (4) We have a class OrderRelation with a set of attribute which specify whole/part, transitivity, reflexivity, etc. (5) Variation of 4: We have these attributes on OrderRelation, but we do not require that they be specified. Discussion:
We need relation object (assign attributes as optional things according to discussion results)
Order relations is a subclass that are antiSymmetric and Transitive (others option
Symetric, Reflexive and Transitive (can be total or partial - is this important, trivial?) Some attributes are constant in a given class Wrapping up:
|
Notes from Modeler’s meeting 2015-07-15 Attending: Arofan, Larry, Dan G., Wendy, Flavio, Larry OrderRelations have semantic types: Currently: Sequence, Parent-child, Part-whole, Relationship These semantic types are the basis for extensions of the abstract OrderRelation class. OrderRelations also have 4 dimensions as properties. isPartial (yes, no, unspecified) isTransitive (yes, no, neither?, unspecified) IsSymmetric (yes, no, neither?, unspecified) IsReflexive (yes, no, neither?, unspecified) There was some question as to whether the neither option is needed. We need to be clear about what these options mean. Would (always, never, neither) be clearer? For some order relations no transitive relationship is true: Scissor>Paper Paper>Stone Stone>Scissor Scissor>Paper and Paper>Stone but not Scissor>Stone Paper>Stone and Stone>Scissor but not Paper>Scissor Stone>Scissor and Scissor>Paper but not Stone>Paper In other cases some might be true and some not (e.g. sporting results):
Modelers developing classes might set a fixed value on a dimension (e.g. Parent-child is not transitive) or leave the option up to end-users (a sequence might be required to be transitive or not). Default is unspecified (value is required) Dan will lay out useful combinations. |
2015-07-08 Modeling Meeting Attending: Flavio Rizzolo, Arofan Gregory, Dan Gilman, Jay Greenfield, Larry Hoyle, Olaf Olsson Should we use “realizes” for classes like OrderRelation (using them as interfaces) rather than as inheritance? We need to be able to annotate that this is an interface in Drupal. The pattern is set out with a relationship to another class as a realization of an interface. With an interface the only use is through a realization. It can’t be extended by a class. Is this a problem? First we should describe a set of Boolean attributes to define the sub-types of order relations. Then the question is whether to do this through properties vs inherited classes Total-partial Transitive-not Reflexive-not (Sequence, Parent-child, Part-whole, Relationship) Not all combinations are possible. Will setting these as properties be very difficult for users? Issues How we define the model The rules we put forth What does it look like to an implementer? Making things explicit puts constraints on use (avoids people breaking things). Some of this modeling will take place in the transition between Platform Independent to Platform Specific. In RDF the names of the predicates imply (through definition) all of the properties. Alternatives: (1) We have a single OrderRelation class in the pattern, and rely on its definition when realized to determine whether it is partial, transitive, reflexive, etc. The review process would guarantee that definitions are rigorous. (2) We expand OrderRelation in the pattern with a set of useful sub-classes, which specify transitivity, reflexivity, etc., and these are the classes in the pattern which are realized instead of OrderRelation. (3) A variation of 2: We have the OrderRelation class, as well as completely defined useful subclasses, but we allow any of them to be realization points in the pattern. People who don’t understand the subclasses would just realize OrderRelation directly, and the review process would correct any misuse. (4) We have a class OrderRelation with a set of attribute which specify whole/part, transitivity, reflexivity, etc. (5) Variation of 4: We have these attributes on OrderRelation, but we do not require that they be specified. Arofan suggested that 1 and 5 above may be the best choices. Too much specificity will be a turn-off for some users , others will want the specificity Separate issue: Is equality an order relation – no |
ATTENDEES: Wendy, Olof, Larry Sphinx Reviewed Sphinx and discussed use in building the documentation for DDI 4 (comments) https://ddi4.readthedocs.org/en/latest/About/documentationSyntax.html
Olof will set up some shared screen time with Jon to go over the structure and tags. Modeling Team should look at this as a possible means of creating Modeling Guidelines and keeping them available and current. This issue will be raised by TC as a result of review comments. On-going question is what goes into Drupal and what goes into these documents in order to facilitate a smooth build process for all products, for example XML examples and RDF or other binding type examples. BINDINGS: The question of RDF production was raised. Olof suggested that one means of addressing this would be to offer a small grant to create the initial RDF mapping and syntax binding work. Wendy will bring this idea to the AG. |
ATTENDEES: Wendy, Flavio, Jay, Oliver, Olof, Larry Agenda: Methodology and Core Process Core Process is still being reviewed particularly in terms of Input, Output and binding Methodology in Lion:
How to go about cleaning up the model:
Sphinx structure - install instructions People review and be prepared to discuss any questions next week https://ddi4.readthedocs.org/en/latest/About/documentationSyntax.html Live screen demo by Olof IN TWO WEEKS: Update on Collection and Process Model VACATIONS: Oliver July 1, 8, 15 |
ATTENDEES: Wendy, Achim, Larry, Jay, Oliver, Dan G., Flavio Update on what's going on with the Qualitative model (separate groups) Implications for defining a segment in text and a physical object Agenda: Flavio's document on Views
Mechanism for expressing the view and the XML bindings
Need to check these process out in different bindings (XML, RDF, Java)
Next week: Jay and Flavio's work on methodology and core process |
ATTENDEES: Wendy, Flavio, Dan G., Oliver, Jay, Johan, Larry Issues raised by Codebook:
Low lying issues:
Definition of a view - Flavio document
Layout of Modelling Team pages
Standard information to have in views
NEXT Weeks Agenda:
NOTE: Johan on vacation from June 14 - July 19 |
Sprint 2015-05-26 Versioning discussion 2015-05-26 Release policy? Frequency Intervals of releases? How to implement? What is released? What is in XMI? What is binding? Same view different versions of classes? Different Views have different versions of a given class? Interest groups what would there release policy preference be?: Motivated Developer Normal Developer Management Researchers? Release numbers may be important for software providers to be able to describe compatibility Rule Any official release of a view must be consistent with all other views. A class in one view needs to have the same version as that class in the other views. Separate association to external objects from a view (Flavio)? Release policy?1) Big bang 2) Small pieces (some views) with affected views (all dependencies when calluses not backward compatible) 3) Only release changed views – allow inconsistency among views 4) Big bang releases , minor releases, bug fixes, nightly builds When PIM interval changes change a version number in the PSM What is backward compatibility – instances stay valid or only previously required properties still there? Stable namespace? Time intervals are a good idea, is it possible to implement? |
ATTENDEES: Arofan, Wendy, Dan G., Johan, Larry, Jay, Jannik, Flavio Sprint notes:
Frame work from last week and envision what release packages would like Versioning in the sense of a View:
PROPOSED: What we propose to have in Drupal is that we keep track of every time period for a class. When we release its a 2.1 associated with a point in time. What we have in the release is identifiers (version qualified name). What we want to expose in the binding is the NAME. One proposal is that when you version a View the class is the version number of the View. This is a problem when you have multiple views with one or more versions all using the same class by reference but now with multiple namespaces. Discussion:
Walked through the process:
Many types of users:
PROPOSAL
Need change rules:
Experiment, look at the patterns and use these to generate rules. Example, the change from Universe to Population. If the relationship changes as of a certain time you will need to create a new class if you need both content.
ACTION: Whoever wants to should do it so we have several examples. Flavio, Wendy, plus. Include rules for defining change (version, extension, new class), Additional comments:
|
ATTENDEES: Arofan, Wendy, Dan G., Oliver, Jay, Johan, Larry, Flavio, some Mexican parrot Announcements
Evolution of classes
ACTION: Requested that Johan take this discussion back to Olof for him to consider implications for Drupal.
EMAIL DIALOG REGARDING PAPER I’ve been thinking about the implications of the implication of our versioning approach for developers trying to handle importing DDI-MD as it evolves. I think that we will want to have much stronger recommendations and "How to" documentation for those producing export instances of DDI intended for import by others.
In fact, I believe that if we assume that changes to relationships don't change the owner classes in any circumstance, then the model is simplified considerably given that you avoid the cascade effect described in the document. That is what I called the canonical temporal (or evolution) model. The "becomes" is in fact the same as a "comes from" just pointing in the opposite direction, so we could use either. For richer temporal semantics, the paper I referenced has the notions of "split", "merge", "detach" and "join", defined from the "becames", a partitive relationship and the temporal intervals of the participating classes, and they can be reversed as well. |
Cancelled due to meeting conflicts - Jay and Flavio will use the time to work up the example we dscussed during this week’s meeting. |
Attendees: Wendy Thomas, Flavio Rizzo, Jay Greenfield, Oliver Hopt, Arofan Gregory, Dan Gillman First Issue: Versioning and effect on bindings - Discussion at NADDI lead to the comment that the current discussion of Versioning (as summarized in Achim's paper of a few weeks ago) could produce some difficulties with the binding in XML and RDF, such as having to put version numbers into the element names. A more elegant binding for this needs to be determined. Discussion of this lead to a broader discussion about how versioning would work in reality. - Consensus seemed to be that this is a "graph problem" and thus should be subject to a similar "graph solution" - this would consist of an object having a relationship to the object of which it is a revision. - Jay and Flavio volunteered to come up with an example, so that we could try to apply different rules in a more ralistic way, and to see what impact this would hav on the bindings. Second Issue: Release of the bindings for Q1 - When will we be ready to release the bindings for the Q1 material? For the XML, we think this will be soon. Wendy will determine the date on which Jon produced the documentation for hat has already been released, and Oliver will apply the latest XML bindings to the XMI from that date. He will circulate to the group. Once reviewed, the schemas will go to Achim so he can produce the clickable HTML field level documentation. - There is still a question about the RDF binding and how it would be documented. Arofan will circulate to the group the e-mail discussion with Franc Cotton, which might suggest some useful ways to document the RDF for review. We need also to check with Achim that the OWL is ready for review. - There was some discussion about the changes which may result from the versioning discussion to the current bindings, and whether these were significant enough to hold up release of the bindings. General feeling was that we should not let the versioning discussion hold up the relase. - There was a strong comment that we needed to explain to reviewers how different the design of the XML will be. This could be incorporated into the User's Guide, which Jon is still working on, but which has not yet been released. - The timing of the bindings release vis-a-vis other releases for review will be raised by Wendy in both the TC and AG meetings. - It was decided that the binding release was an additive part of the Q1 release- "Q1b", and should be treated that way as much as possible. Third Issue: When do we un-freeze Drupal? - We decided to keep Drupal frozen during the Q1 review period, so that it stays in sync with the material now being reviewed. |
Attendees: Wendy, Olof, Larry, Johan, Jay, Jannik, Oliver, Flavio, Arofan NOTE: Olof has asked to attend these meetings to assist in the maintenance of Drupal. We're glad he can join us! Versioning:
Schemas:
Customized Metadata - unforseen metadata
Review - what's needed from the Modelers perspective for the "read me" document:
|
Cancelled due to NADDI |
Attendees: Wendy, Dan G. Jon, Larry, Arofan
|
Attendees: Wendy, Flavio, Larry, Jon, Oliver, Jannik, Jay, Dan UberView Notes from TC on UberView
Discussion
AG framing document
Olof added some objects from Drupal that we wanted in the XMI for documentation purposes What is going into Q1:
Flavio's Notes on Relationships
Drupal will be set after the freeze to just include those to be published (published switch) |
Attendees: Arofan, Wendy, Flavio, Dan G, Oliver, Larry, Jay Issue of bi-directional and non-directional associations expressed in model
Olivers issue
Continue to meet at the designated CET time during DST |
Attendees: Flavio, Wendy, Dan G., Larry, Oliver, Johan Agenda: Complete Flavio's question list, follow up on Larry's DDI Report on cardinality Flavio's Question 9. Why does it have a StandardKeyValuePair? Because it is available in all standard statistical packages on the variable and on the store
Cardinality Review (Larry's DDIReport)
|
Attendees: Arofan, Wendy, Jannik, Johan, Dan G. Jay, Flavio, Oliver, Achim 1) Representations:
Description should be programatically generated by the cardinality at some point. Some associations are not displayed at all
Are we rendering a 0..n relationship correctly? Is 1..n consistent with an open diamond
2) Flavio's question list 7-9
NEXT WEEKS AGENDA: Tabled discussion on bi-directional relationships (see above) TC will put Versioning paper on agenda AGENDA March 11 - Versioning |
Attendees: Flavio, Arofan, Wendy, Jay, Johan 1) Representations: Larry, Jay and Dan will meet later today 2) Flavio's use case on Concept system, classification
3) UML does not support specialization and add constraints and some other language
Design Principle: We should leave as much richness in the model (i.e. restrictions) even though some implementations can't express it. Depending on the implementation technology you will have different problems. Instead of working to the lowest common denominator you design the model correctly and deal with the specific implementation problems in the binding.
1. Shouldn’t ClassificationFamily have a relationship to ClassificationIndexes rather than ClassificationIndexEntries? Having a direct relationship to ClassificationIndexEntry seems wrong. CHANGE |
Attendees: Arofan, Wendy, Johan, Oliver, Dan, Flavio, Jay, Achim. Larry XSLT schema production work: Oliver can work on this next week; make sure everything is OK; Achim will send Oliver list 1) Documentation XHTML tags
ACTION: Achim will continue to look at this focusing on OWL and how a merge can be done as a second step (schemas created and documentation merged in) ACTION: Achim will come back with a complete proposal 2) Object review
ACTION: Go over questions in Flavio's list next meeting 3) Universe, Population, Unit
4) Process
5) Specialization
|
Attendees: Arofan, Wendy, Larry, Johan, Oliver, Dan Olof is all out of time in February so won't be able to do anything to Drupal until March Requests should also go in bug tracking for Drupal https://github.com/ddialliance/lion Requirements for specialization (summarized by wlt)
Changes for Agent
Look at the list of Required objects and make a recommendation for action:
Discovery View doesn't have a "thing" to view or discovery
ADDED NOTES FROM EMAIL FOLLOWING CALL Hi Folks, A Concept System is a Collection, but it's not just a Collection. Therefore, its Concepts are Members, but not just Members. As a consequence, the contains relationship in Concept System needs to be specialized (restricted) to the subclass of Members that are relevant to the Concept System, that is Concepts. Conceptually, that is what we want to say in our model; as long as we say it, the model is fine. The problem is that the language we want to use to say it (UML) doesn't support specializations of relationships. We had a similar problem with the former order relation: we couldn't say that parent-child in NodeSet was a specialization of predecessor-successor in Collection, which forced us to reify the relationship into a new class: OrderRelation. That is a well-known workaround to specialize relationships in UML, i.e. making them into classes. We don't need to do that in other languages, like RDFS, which supports in fact specialization of relationships (in fact, in RDFS they are first-class citizens). Now, we have two cases of specialization: (1) of relationships with the same name, (2) of relationships with different names. Arofan's document addresses (1) by means of overriding the same name relationship with the a new target class. For (2) we don't have a solution yet since overriding works only with relationships with the same name. For instance, in our UML model, the parent relationship in NodeParentChild is formally not a specialization of predecessor in OrderRelation, regardless of what the description says -- it's just a new relationship that stands side by side with predecessor inherited from OrderRelation. In other words, NodeParentChild has currently four relationships: parent, child, predecessor and successor. There is no way in UML to formally say that parent is a specialization of predecessor. If we cannot live with that issue, then I believe there are only four solutions, three within UML and one outside of it. Within UML: (a) Get rid of generic Collections, Correspondences and any other class that requires specialization of relationships. Drastic but effective. (b) Get rid of the relationships with different names in the specialized classes and use Arofan's solution. Relationship names are not going to be as meaningful as they are today, since parent will be replaced by predecessor, etc. But correct. (c) Apply reification again and make the relationship into classes, e.g. ParentClass, ChildClass, etc. and use the usual specialization mechanism for UML classes. Cumbersome, ugly, but correct. Outside UML: (d) Use a constraint language to say what we cannot say in UML, e.g. OCL. Cumbersome, but correct... and already discarded. Now, please tell me if all this was already discussed and I will stop babbling :) Cheers, Flavio PS: to answer your question Larry, I think your diagram is correct. (referencing Larry's diagram added to Arofan's paper) |
Attendees: Arofan, Wendy, Flavio, Larry, Dan, Jay, Johan, Jon, Jannik (1) Jay’s re-modeling in the process area
(2) Contact info cardinality
ACTION: Wendy will look at ISO 19773, revise and provide and provide a model for approval by the group (3) Achim-related points which came up last week (XMI export)
(4) Universe, Unit, Population, etc. (review of that part of Drupal)
ACTION: Flavio will revise model based on this discussion and send to group |
Attendees: Arofan, Flavio, Jay, Johan, Larry, Oliver, Jannik, Wendy
|
Attendees: Arofan, Jay, Larry, Jannik, Oliver, Johan Decision points from today’s meeting:
|
Attendees: Arofan, Wendy, Achim, Larry AGENDA OF TO-DO ITEMS - Please address what you can over the holidays and make comments as noted (1) Review Jay’s process model proposal based on this week’s discussion - (this document will be coming over the next few weeks, keep an eye out for it in the sandbox. Use the comment section of the sandbox and note the name of the document in the first line of your comment) (2) Look at the Conceptual package in Drupal, especially with an eye towards nodeset/classification and value domain-related objects - add comments to Drupal (3) Look at the Representations package regarding the use of Collections in Nodeset - add comments to Drupal (4) Look at the cluster of Universe-Unit-UnitType-Population - add comments to specific objects in Drupal (5) Review Complex Data Types - put in comments in Drupal
(6) Any of Achim’s issues based on his research into XMI and how Drupal is working - Issues in Jira document (summary below)
(7) Review of the work on implementing the Process Model (document in the Sandbox) Using the DDI 4 Process Model to Describe Historical and Prescriptive Processes_0_1.docx (8) Review of the Communications document (add comments to the sandbox page referencing communications document in first line) To Do List Enter PairedCodeValueType and change property name to extent - done Kelly - change meeting time of Modelling team to 13:00-14:00 - done |
Attendees: Arofan, Wendy, Larry, Jay, Achim Question regarding AgentAssociation
Note there is now a link from the modelers page to issues in JIRA (see bottom of Modelers page) Review Communications document:
Issues from Sprint
Agenda for next week:
|
Attendees: Wendy, Therese, Larry, Flavio, Jay Agenda:
Drupal List:
Communications Issues:
Collection:
Process:
Epic 3 has been updated with process items and To Do's |
Attendees: Arofan, Larry, Jay, Therese, Wendy Agenda:
Library objects
Collection
Processing model - In/Out Parameters
Discovery
ACTION ITEMS Questions for Drupal - Wendy DONE
Add issues page to Modeling Team page for content people - Therese DONE
Communications Document for content Modelers
Agenda next week:
|
AGENDA:
Summary of Actions Requested Library Structure How do we get an organizational structure for objects Criteria: Organization within Drupal that is good for maintenance and good for deliver of the entire example: Process will be used in a number of views
Identification:
Properties and Relationships
Managed objects
Get rid of Name use a local ID (currently userID)
Label - refine definition to remove
Description - same set of attribute as a label make it repeatable Definition as proposed "Make it so" Decisions:
Action items:
|
Attending: Arofan, Jay, Dan, Barry, Jeremy, Wendy, Achim, Jon, Larry, Kelly Prioritized action items:
Other topics:
|
Attending: Arofan, Wendy, Larry, Jannik, Jay, Flavio Update on Classification
RDF mappings in Drupal
Modeling questions raised in Simple Instrument: 1 - if we are going to do one thing only - there should only be one way to do any one thing Statements, Instructions, Related materials are these the same or different and how they fit into a process model and possibly question
|
Attendees: Arofan, Wendy, Jay, Oliver Put on to do list: Review papers from Toronto and determine the organization of the packages in the library
Conceptual
Agents
Arofan will send out message regarding weekly meetings and try to get agendas out earlier to group |
Attendees: Arofan (chair), Wendy, Jannik, Oliver, Larry, Jay Agenda: Status of each packages for Review 1:
Question to Jon - whats been added drupal make sure there are instructions for their use? TO DO LIST:
Work plan: |
Attendees: Wendy, Larry, Jannik Issue to note
|
Attendees: Wendy, Flavio, Jay, Johan Procedural Issues
Things to address in a game plan
ACTION ITEMS
|
Attendees: Wendy, Oliver, Larry, Jannik Update on elements from other standards
TOPICS for next meeting:
Flesh out and add to the following base list:
To Do's Oliver will look at the technical issues - for capturing information in Drupal (see item 1) |
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:
Elements from other standards Reuse of elements from other standards:
How do we reference other standards in Drupal
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
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 |
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. |
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. |
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: Modelling Team Meeting Minutes). Wendy will review this document to make sure that it is up to date and correct. The review works was allocated out as follows:
Jon will look at everything from a documentation rather than modelling perspective. Johan will go on holiday The group agreed to meeting in 2 - 3 weeks to discuss results of the reviewing work. |
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
DISCUSSION Modeling Bags
Extensions
Schemes in DDI 3
Communicating with Modelers re: Seeming Duplication Across Teams
|
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
Wendy Achim All
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. 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. Level of Extensibility 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.
Continue grouping mechanisms discussion |
DDI TC Meeting
|