Materials from External Review work at Dagstuhl Sprint |
Virtual MRT meeting 2019-01-30Agenda (as in invite of 2019-01-28)Goal: To have a draft program of work for NADDI Sprint (to submit to EB), and an initial list of proposed tasks.
Suggestions: - Documentation of datum-based model application to examples of event data, aggregates, etc.
- Existing modeling technical requirements/issues
- Others
- Are there ideas/candidate tools which need to be written up/further explored?
- Identify tester and potential testers (We may not get this far, but if we have time it would be good) Minutes DDI4 MRT Virtual meeting 2019-01-30Attendees: Achim, Arofan, Dan G., Flavio, Hilde, Jay, Larry, Oliver, Wendy Apologies: Jon 1. Description of what is needed for organizing NADDI Sprint (from Achim):A goal for the meeting is to have an agreed document regarding the NADDI Sprint planning ready to send to the AG to inform their discussions at their next meeting, and further to apply for funding of the possible sprint. Achim prepared and sent out the document ‘NADDISprintPlanning.docx’ to the srg list in advance of the meeting. This is a shell document where some content of the document needed to be filled in or reviewed and agreed while the meeting. The meeting was structured in three parts: 1) Topics for the possible NADDI Sprint; 2) Review of possible participants and funding; 3) Other organizational issues regarding the possible NADDI Sprint. 1) Topics for the possible NADDI Sprint (see point 2 in the agenda)a) Documentation of datum-based model application to examples of data structures (to be discussed and agreed at the meeting which data structures to focus on at the Sprint). b) Discussion and possible resolution of structural model issues:
Status: Points a) and b) agreed as topics for the possible NADDI Sprint. Discussion and agreements regarding example data structures a) Example data structures (point a) were discussed after the structural model issues (point b). The discussion regarding which data structures to focus on as examples at the possible NADDI Sprint was centered on whether to focus on common vs. complex cases and corner cases. Dan G. pointed out the importance of modelling complex cases, as more common or simple cases would then be solved at the same time. Others pointed out that issues could occur even if a similar approach is used. Agreement was reached to focus on the common cases as a preparation for the possible NADDI Sprint. Status: Agreement was reached to focus on the following common data structures for the possible NADDI Sprint:
Arofan and Wendy pointed out that the Variable Cascade documentation (provided for example in the Variable Cascade presentation from the Dagstuhl workshop DDI Train-the-Trainers 2018) indicates the style and level of information needed for documentation. Status: Wendy will add this as a prototype review comment. After NADDI further data structures may possibly be explored, for example NoSQL (non SQL) data like Hadoop data, graphs etc. Status: Agreed In the Appendix an example from the discussion provided by Larry is found. Discussion and agreements regarding structural model issues b) Structural model issues (point b) were discussed before the example data structures (point a). Conceptual resolution/MRT: Jay brought up the issue if structural issues could be resolved conceptually or by using the MRT approach. Flavio pointed out the need to look at many different examples to check out structural modelling issues. Achim indicated this could be a topic for the possible face to face meeting and something for a work group to focus on in advance. Complexity of the model: Flavio commented that the model is complex because it is made complex. It has multiple levels and covers both common and domain specific needs. To simplify the understanding, some of the content could for example be hidden for specific user groups. Achim asks if the model can be improved by focusing on questions like:
Work regarding the complexity of the model could be done in advance and brought to the sprint. Review of views: The revision of Views is important. Achim points out that even a simple view like the Agency view drives in a lot of classes. Flavio points out that Views are complex because they currently are designed to cover multiple dimensions. The Classification View is for example meant to cover reuse, classification management and publishing. This and other views would need separation into smaller sets to be easier to understand. Larry expresses that the model currently is highly connected but that good documentation can help the understanding. Status: Agreement to focus on the four bullet points under b) above for the planned Sprint. Tasks should be broken up as much as possible. Smaller groups could work on each of those and get back with a proposal for the full group after a week or two. A specific person should be responsible to follow up on the work on each task. 2) Review of list of possible participants and fundingThe following agreement was made: The following people would be available in person for this meeting (their need for funding in parenthesis):
Most of the people would need funding from the DDI Alliance as specified in the NADDISprintPlanning_1_0.docx document. Oliver Hopt would be available by phone. 3) Other organizational issues regarding the possible NADDI SprintPossibilities for meeting location and lodging have been checked out and booked by Flavio and Achim as follows:
Two documents are sent to the AG for their feedback prior to their next meeting (also sent to the srg list):
Further follow-up is required regarding organizing the start-up of the work, and making plans for what needs to be prepared in advance of the possible NADDI Sprint. AppendixExample from Larry related to discussions of point a): With the ability to describe data at the datum level DDI should be able to describe data like that in the following example through transformations from traditional rectangular (wide) layouts into key-value (tall) representations. DDI4 can currently describe the data in the wide layout, but, though we have discussed how to do the tall representation, that work has not been completed in the model. Wide data table: Corresponding tall representation: Transformations between these layouts are common in data software packages. The SAS code below shows the transformation from the wide to the tall. Note that in the Tall representation the column Source is a pointer to a variable in the wide layout. The column Value1 is not a traditional variable, in that there is no one value domain or concept associated with the whole column, instead those things depend on the pointer in Source. If we can properly describe datum level metadata we should be able to describe the value domain and concept associated with the “yes” category label (which is actually a code of 1 in the SAS dataset) in the Value1 column. We should also be able to describe the meaning and units of measurement of the value 185 in the same column. Proc format; value yn 1="yes" 2="no" ; /* example rectangular file */ data fooWide; input Name $ Height Answer; label Name="Person name" Height="height in cm" Answer="Answer to 'Are you hapy?"; format Answer yn.; datalines; Joe 185 1 Mary 160 2 ; run; proc sort data=work.fooRect; by Name; PROC TRANSPOSE DATA=fooWide OUT=WORK.fooTall(LABEL="Transposed WORK.FOORECT") PREFIX=Value NAME=Source LABEL=Label ; BY Name; VAR Height Answer; format Value1 yn |
DDI4 MRT Virtual meeting 2019-01-23Agenda (as in invite of 2019-01-23)Goal: This meeting should get us to the point where we are ready to propose a formalization of this effort to the DDI Executive (or take other steps necessary for approval). To that end, the following agenda is proposed: Agreeing the document as regards: - Organization - Scope - Timeline Details on organization and scope: - MRT Lifecycle feedback loop - Status of the sub-groups (see new version of document, section on organisation and structure, as well as section 4 in the minutes of last meeting). - Alignment of other standards, provenance (see new version of document, section on alignment with metadata structures in DDI4 Core, and discussions in the Appendix of the minutes of last meeting) - Finalizing the document and process for approval: Things to be added, changed or removed – or approve new version as is? Minutes DDI4 MRT Virtual meeting 2019-01-23Attendees: Achim, Arofan, Hilde, Jay, Jon, Larry, Oliver, Wendy Organization and scope:Basis for the discussion: Document updated by Arofan with input from Achim, ‘MRT_DDI4Core_Diff_0_2_and_0_3_JW’, attachment to email from Achim to srg list 2019-01-23. The goal of the meeting was to finalize the MRT-DDI4 Core document to be sent to the Advisory Group for their comments. Jay suggested to start to plan work tasks as well at this meeting. Status: Agreement to take on tasks later on, and to prioritize the finalization of the document at this meeting. Discussions regarding the document:-Organisation and Structure: Achim points out the Core group guides the whole effort, defines sub-tasks and assigns a responsible person for the task who reports back to the full group. The feedback loops should be done in short, iterative cycles. Tasks are not long term, and should be discrete and well-defined. Important that the document reflects this. Status: Agreed -Role of the MRT in the organization: Wendy asks how the MRT relates to other DDI groups. Larry points out that this is a new way of organizing the work of the Modelling Team. Status: Agreement that MRT replaces the Modelling Team. The work of the group should be well aligned with the Advisory Group. -MRT feedback loop: The requirements for the feedback loop were discussed. Achim points out that the requirements are just a repetition of earlier goals of the Moving Forward project. Proposals for amendments to bullet points (for clarification purposes): -Remove ‘if required’ from the ‘looseless roundtrip’ bullet point. -Add ‘Stability’ to the ‘Consistency’ bullet point. -‘Persistence of the model’ change to ‘Persistent expression of the model in canonical form’ (not to be confused with canonical XMI). Status: Agreement to update the bullet points accordingly. -Mapping of DDI4 to earlier versions of DDI: This was discussed at our last meeting (January 16th). Larry points out that conformance and divergence with previous versions of DDI should be clearly defined. Status: Agreed to include a section on this in the document. -Alignment with other metadata standards: Jay asks if SDMX should be mentioned in the list of standards included in the document. Arofan points out that the document indicates ‘at least’ which standards the DDI4 Core should be interoperable with. Status: Agreed to highlight ‘at least’ in the document. -Production process: Jon asks if the production process should be mentioned in the document. Arofan points out that this is a big and important topic that needs to be addressed. We will need to come back to what the options are. Status: Agreement that the production process should be identified in the document as something that would need to be addressed. Timeline:-Timing of the DDI4 Core work. Status: Agreement for the DDI Core work to take place in rapid cycles of weeks, not months. A calendar year is the anticipated goal. Leave wording in the document as stands. -Timing of the finalization of the document: Wendy, Achim and Arofan points out the importance of finalizing the document before the next meeting of the Advisory Group (scheduled to next Wednesday). Status: Agreed to finalise the document for Monday and send to the AG for their comments. Arofan send to the MRT group today (on the 23rd ) for comments. Other:NADDI Sprint: Achim proposes a face-to-face meeting with the group after NADDI, of possibly three days, and asked if people in the group would be interested in this. All participants on the call indicated that they would be interested. Their possibilities for attendance and dependencies are specified below:
Possible topic for the agenda of the NADDI Sprint: Flavio proposes to focus on the modelling requirements. Status: Agreement that Achim follows up regarding the possible NADDI Sprint with the AG, contact the local organisers regarding possible localities etc. |
Agenda (as in meeting notes from of 2019-01-09)Organizational approach of where we are going and how we organize the approach Modeling technical requirements - need to provide a summary for comprehension SPARKX cloud modeling approach for UML modeling https://www.sparxsystems.com.au/enterprise-architect/cloud-services/cloud-services.html Minutes DDI4 MRT Virtual meeting 2019-01-16Attendees:Achim, Arofan, Dan G., Flavio, Hilde, Jay, Larry, Oliver, Wendy Topics:At the meeting the organizational approach was discussed as described below. UML modelling tools was discussed by email between the last meeting and this meeting by Flavio and Achim (see information under 8) below as well as the full correspondence in the appendix). Provenance issues and relationship with other models were also discussed between the meetings by Flavio and Jay (also under 8) below and included in the appendix). Organizational approach:Basis for the discussion: A) Document ‘MRT_DDI4Core_0_2’, attachment in email from Arofan to srg list 2019-09-01. B) Achims questions to be clarified in order to build a good basis for the work next year, in email from Achim to srg list 2018-12-12. Achims questions (1 – 8) and their workflow status are specified below:
Status: Agreed 2. Focus on DDI 4 Core, like Conceptual, Data Description, and Process. These areas are important for any use case perspective. Additional areas can be identified according to business requirements. But the focus on a core increases the chances to have a robust and mature deliverable. Status: Agreed to focus on the core 3. Description of major tasks regarding major modeling issues -Provenance was brought in as a new topic in a discussion between last week’smeeting and this meeting, see point 8) and the appendix. Status: Needs follow-up discussions 4. Participants and their roles/perspectives -Proposal in the ‘MRT_DDI4Core_0_2’ document to have an administration group (coordination team) with sub-groups. Achim suggests that smaller groups can work independently on different things and get back to bigger groups with recommendations. Status: Agreed -Participants of the MRT coordination team: Arofan suggests that this group is the MRT group coordinating team, together with Jon who has also expressed interest in this. Status: Agreed -Sub-teams: In the ‘MRT_DDI4Core_0_2’ document, three possible sub-teams are proposed, all with an identified lead: a modelling sub-team, a representation sub-team (with sub-teams for each representation, xml, RDF, Phyton etc.), a documentation sub-team and a testing and representation sub-team. Larry expresses a concern for the idea of fixed sub-groups due as there may not be enough people for this. Achim proposes to think in terms of more ad hoc task oriented sub groups. Invite external experts when needed. Status: Needs follow-up work -Perspectives: A task proposed by Larry that also regards modeling (question 3 above) is to have DDI2 mapped into the DDI4 Core for the end of the year. Comment from Achim: This work can identify missing pieces and flaws in the modelling. Not sure if all can be resolved by the year, but should be possible to identify them. Do mapping first and then modelling. Comment from Arofan: Transformations should be developed. Flavio: A modelling tool should be used rather than excel for the mapping. Status: Agreement about the requirement about the mapping of DDI2 to DDI4. Needs follow-up work. Task proposed by Achim: Work on data description usage for different representations and data forms, for example unit record data, event long/short, aggregate/cube, single datum in a lake. Detailed tasks should be developed. Example data that can be used for this purpose are data from the Australian Election Study (Larry) and the ESS (Achim), the Alpha Network (Jay), possibly others. The Alpha Network has lots of different data types. Several of the relevant data sets are structured in DDI2. Where real data are difficult to provide or new, like a datum in a lake, made up examples should be provided. Status: Agreement on the task. Needs detailing of sub-tasks , follow-up work, who’s involved etc.. Tools: Flavio: Need to decide which tools to use in our work (see also discussions under 8) and discussion emails in the appendix). Status: Needs follow-up -Administrative work: Hilde does the meeting minutes Status: Agreed Further administrative work, chairing etc. Status: Needs follow up. 5. Is the proposed timeline for a DDI 4 Core at end of 2019 reasonable? Status: Agreed working goal. 6. The development of the business requirements document can be worked on in parallel but is not task of this group. Comment from Arofan: Some requirements identified by this work that affect the core areas could be interpreted as technical requirements and fed back to the MRT group and be a task for the modelers. Comment from Achim: The focus of the MRT approach is the goal of a stable DDI4 core in one year. The focus on business requirements should not be tied to close to the task in order not to delay this process. It would be important to distinguish between what we need to have in to have a functional DDI4 core, and what can be added later. Comment from Flavio: Agrees with Achim. For each step in the MRT cycle it should be decided what it would make sense to include. The MRT Coordination group should decide on this. Status: Achims proposal agreed. 7. Information on these agreements to other groups and DDI Alliance committees A goal is to finalize a document that takes into account the agreements made regarding the MRT approach. The document about agreements which will represent our proposal for the DDI4 core, will be developed and sent to the SB and EB for their approval, as well as to other groups. Achim and Wendy: The timeliness of this document should be decided on the basis of decisions regarding the work of the group. Status: Agreed 8. Identification of issues which can be worked on in the next couple of weeks independently of group meetings. - To do for the next meeting (2019-01-20) Hilde: Will post the minutes Arofan: Will prepare agenda for next week with input from others and send out invitation to the meeting to the srg list with agenda and meeting link prior to the meeting. All: Think about the open issues from this meeting. - Contributions since last week’s meeting (2019-01-09) UML tools discussions between Flavio and Achim: In an email to the srg list of 2019-01-10, Flavio points out that we need to decide on a platform for developing, managing and sharing UML models. He proposes to use EA Sparx. The Canonical XMI support needs to be checked out. As a response to this Achim replies in an email to the srg list of 2019-01-15 that this topic needs to be discussed in the MRT and TC groups. Achim suggests to use an open tools solution, on the background that DDI is a standard, and we cannot risk that a DDI model can be used only in one tool, costs can be an issue regarding commercial tools etc. The Canonical DDI4 XMI has proved importable by many different UML tools. The problem is that most UML tools provide a custom XMI flavor rather than canonical XMI. Achim recommends to look into Eclipse UML tools, which have an XMI flavor that more easily can be bridged to canonical XMI than many other tools. Bridging might be supported by the Eclipse community. The Eclipse tools can do many other different things, for example to enable transformations from PIM to PSM. The slide below provided by Achim that describes possible usages of Eclipse tools for MRT purposes. See the email conversation in the appendix below for the full argumentation. Status: Should be looked further into. Provenance/lineage and relationship with other standards discussions between Flavio and Jay: In an email to the srg list of 2019-01-11 Flavio brings up the question of supporting different types of lineage/provenance, and asks if everything we need to capture can be captured by Prov-O or if different standards are needed. Jay replies to this by providing references to a review of several provenance models, and some articles. Jay proposes further to form a provenance sub-group to look into this. He also raises the issue of DDI should copy or plug and play with other models, for example SDMX. In two different emails to the srg list of 2019-01-16, Flavio replies that he believes there would not be resources available to do the plug and play with standards, and he believes that DDI should specialize in a small, well-design and well-integrated set of classes to cover the aspects of the data (and metadata) lifecycle that other vocabularies either don't cover or cover poorly. See the full discussion in the emails of the appendix. Status: To be discussed AppendixEmail correspondences between meetings between Flavio and Achim on UML tools and Flavio and Jay on provenance and relationship with other tools: UML Tools: Email from Flavio to srg list of 2019-01-10 Hi Achim, We need to make a decision on a platform for developing, managing and sharing UML models. A well-know tool for that purpose is EA Sparx -- We use it at StatCan and in some UNECE HLG projects, e.g. GSIM, CSPA. Sparx allows users to create arbitrary views on-the-fly by dragging and dropping objects from the underlying model. This way it is possible to deal with smalls subsets of the model at a time during development, and also to target different audiences for communication purposes. It also supports BPMN. The model can be exported to multiple programming languages. Here you will find some pricing information for the cloud version: https://sparxsystems.com/products/procloudserver/purchase.html This is for stand alone licenses: https://sparxsystems.com/products/ea/shop/index.html I guess the big technical question, beyond design capabilities, is which version of XMI is supported to make sure we can import/export the model to other platforms. There is some information here, although not conclusive: https://www.sparxsystems.com/enterprise_architect_user_guide/13.5/model_publishing/exporttoxmi.html We can always test it and ask Sparxs for more information on their XMI support. Best, Flavio Email from Achim to srg list of 2019-01-15: Hi Flavio, Thank you for bringing this up. This will be a question to be discussed and decided by the new MRT group and the TC. DDI claims to be a standard. In this sense we should try to use a solution which is open for different usages and different users. We should avoid any dependency of a specific tool. I mean this in the sense that there is a risk that the DDI 4 model can only be used in a chosen UML tool. This might be appropriate to a homogeneous environment like a (large) organization. But the requirement in a standards environment is different. The DDI 4 model is a library. The library should be offered in a way that the library or subsets of it can be used for many purposes. A chosen tool should not be a barrier. The Canonical XMI format proved to be able to be imported successfully in many major UML tools. In this sense, the DDI 4 as Canonical XMI would be the portable format. This is useful for people who are using directly the model with different tools, i.e. for generating a representation or combining the model with other models. The issue with the Canonical XMI format is (currently) that most UML tools don't export Canonical XMI but only a custom XMI flavor. MagicDraw and probably Eclipse are the tools which export a XMI flavor which are closer to Canonical XMI. A general workaround could be to choose a specific UML tool (or to recommend one) and to write a converter from the specific custom XMI to Canonical XMI. (I did this for the XMI flavor which is exported by Lion). This way, both would be available, a UML tool for model development and a portable XMI format which can be imported into other UML tools. Another dimension is the cost issue. Any commercial tool costs something. This might be an issue in the standards environment. Enterprise Architect versions start at 229 USD; additional costs apply to software updates. Enterprise Architect exports to the UML/XMI version 2.4/2.5. (UML 2.4.1 seems to be the most implemented version, 2.5 is the latest.) The issue is that the exported XMI flavor can't be imported in other UML tools. Only MagicDraw offers a custom import of Enterprise Architect XMI 2.1. There might be possibilities to get free licenses from commercial tools for standards development. I heard that regarding MagicDraw. The issue here is that companies would probably offer only very few licenses. This way, not the whole MRT group could use the UML tool. Furthermore, other users of the model would need a paid license to use the model. The free and open-source tool Eclipse Papyrus seems to be a good choice. I suggest to look into the Eclipse UML tools in general. Eclipse UML tools use an own custom format for serialization of models, EMF Ecore (Eclipse Modeling Framework), which is available as XMI. A converter would be required for transforming the Ecore XMI format into Canonical XMI. An additional Ecore serializer could be written for Canonical XMI. This might get support from the Eclipse community. The whole Eclipse UML tools landscape offers much more. There are tools based on the OMG standards QVT Operational (model to model) and MOFM2T (model to text). These tools would enable a transformation from PIM to PSM, and generation of representation encodings (like XSD and OWL). I looked into this a little. My thinking is described in the attached file. There are Eclipse tools like EMFStore ("repository to store, distribute and collaborate on EMF-based entities (a.k.a. data or models)") and EMF Compare (comparison and merge facility for any kind of EMF Model). It sounds promising but I didn't have a closer look into this. It would need more exploration. The DDI 4 model uses only a definitive subset of UML class diagrams. This approach builds the basis to create a robust and easy-to-use model which can be used in multiple environments and which can be represented in multiple encodings (representations). A similar approach should be used regarding the UML tool, i.e. using only core features of the tool. This approach can avoid dependencies. Cheers Achim Provenance and relationship with other tools standards Email from Flavio to srg list of 2019-01-11 I mentioned in the MT call that we needed to support different types of provenance/lineage. In particular, I'm interested in the so-called why and where provenance. For definitions, please see "Provenance in databases - why how and where - FTinDB 2009" (attached), Sections 1.1.1 and 1.1.3. There are many other references, including the original Buneman et al. paper, but this one gives the gist of it. Can we represent everything we need to capture these types of provenance with Prov-O or other standards? If yes, how? Else, what is missing? Food for thought. Flavio Email from Jay to srg list of 2019-01-16 Here is a review of several provenance models including the so-called W7 model that Flavio is interested in: http://dcpapers.dublincore.org/pubs/article/viewFile/3709/1932 Here are a couple of articles that align one of these provenance models — PROV-O — with sensor data description and the Internet of Things (IoT): Sensor Data Provenance: SSNO and PROV-O Together at Last Provenance in Systems for Situation Awareness in Environmental Monitoring I imagine, in line with suggestions made by Arofan, that we will want to form a working group on provenance that will make recommendations. I am thinking that the provenance discussion also raises a larger modeling issue: does DDI intend to copy or plug-and-play other models? We have had this discussion before with Dublin Core. But perhaps we may want to revisit it. That’s because now in DDI 4 we have to decide about SDMX. Because of ongoing UN and EU work, SDMX aggregate data description is sometimes a requirement. In DDI 4 we can continue with the nCubes we currently support in DDI 3.x and perhaps perform an SDMX transformation, we can copy “essential" parts of SDMX or we can perhaps plug-and-play with SDMX. This is really a good use case for thinking about how in the future DDI plans to align itself with other models and standards. Email from Flavio to srg list of 2019-01-16 Thanks Jay. I need to dig deeper on your references to see whether W7 describes provenance at the datum level. Either way, the first reference is a great summary of approaches. Regarding your question about whether DDI should copy or plug-in other models, I tend to lean towards the latter. The large number of use cases and vocabularies out there, most of which are under active development, makes it unfeasible for a small team like ours to replicate in DDI. Besides, there is no need to. We just need to understand the use case, the existing vocabulary we'd like to integrate, and create some minimal anchor objects, if necessary, to be able to plug the vocabulary in. I believe DDI should specialize in a small, well-design and well-integrated set of classes to cover the aspects of the data (and metadata) lifecycle that other vocabularies either don't cover or cover poorly. My five cents. Flavio Email from Flavio to srg list of 2019-01-16 Another vocabulary we probably need to integrate with is PMML, for predictive models: http://dmg.org/pmml/v4-1/GeneralStructure.html Here is an example of what the model looks like, from a work some folks at StatCan are doing on the health domain: https://github.com/Ottawa-mHealth/predictive-algorithms/blob/master/CVDPoRT/Reduced/Female/model.xml Flavio |
ATTENDEES: Arofan, Wendy, Flavio, Larry, Dan G., Jay Technical Business requirements: Technical Modeling Style requirements Organizational design Patterns to help in the tooling so to reflect the pattern base in the representations Arofan's email summarizing business requirements I volunteered on the just-ended call to send out an e-mail regarding the business requirements activity which came out of the Berlin Sprint discussions. Until we organize more formally, this will just be a topic on this (the SRG list) and perhaps we can schedule a call if needed. (I have access to a WebEx so we can do meetings without conflicting with normal DDI calls if that helps). I would like to summarize the things that I am aware of which are relevant to pursuing the creation of a business requirements document which we can put forward for agreement: (1) I wrote a high-level document of feedback from the Cross-Domain (second) Dagstuhl week, during the Sprint. Jon has taken this and started extracting some basic scope for framing up actual business requirements. (2) Flavio has volunteered to document some of the business requirements from an official statistical perspective. Jay, as the DDI liaison to UN/ECE, has offered to help him with this. (3) Kelly identified during the Sprint that the Prototype feedback in fact contains business requirements, which we will need to surface into whatever document we create, at some point. (4) Wendy asked on today's call that we identify any areas where we think there might be dependencies/points of contact between this work and other efforts within the MRT work that is now shaping up. I can see that there will be some - certainly the requirements for the business purpose served by the UML model itself (and the style of it) are already on the table, from the Daghstuhl feedback document. I am sure there are many others. We will need to focus on this as we move forward. (5) It was also suggested on the call (was this Jon?) that the whole MRT proposal, along with this parallel effort regarding business requirements, needs to be presented to the leadership of the Alliance for approval/discussion. This suggests that we may need to create a very short document describing what this activity is and why we see it as important. I am sure other things may be going on in regards this work which I have not mentioned above - please add anything you see as important. I think it is early days to organize a call, especially with the holidays approaching, but we should at least try to figure out how best to move forward in the interim. One major question is finding out who wishes to be involved. The names mentioned above are clearly interested (Jon Johnson, Jay Greenfield, myself, Flavio Rizzolo. hopefully Kelly as project manager) but who else would like to get involved? I am sure this is a broader group. If you are interested in helping frame business requirements - not technical requirements - for the DDI 4 work, please respond to this e-mail. Also, if people think that an organizing discussion before the holidays would be useful, please speak up. We can easily arrange something.
Modeling technical requirements - need to provide a summary for comprehension SPARKX cloud modeling approach for UML modeling https://www.sparxsystems.com.au/enterprise-architect/cloud-services/cloud-services.html |
ATTENDEES: Wendy, Larry, Dan G., Arofan, Achim, Hilde, Jon, Flavio, Kelly, Jay Proposal regarding an MRT group to replace or expand the MT What are the real next steps in December and January. Next meeting January 9 (status check) first working meeting January 16 Email from Achim prior to meeting: |
ATTENDEES: Kelly, Wendy, Jay, Larry, Hilde Agenda: General Updates on content/files - Kelly et al (10 mins):
reStructuredText examples - Kelly (10 mins): Hilde Questions - Hilde (25 mins):
|
ATTENDEES: Kelly, Wendy, Jay, Larry, Oliver, Dan Modifications due to model changes in documentation: Content and format updates |
ATTENDEES: Wendy, Jay, Larry, Oliver, Kelly Kelly will present her organization of work so we can see where we are plugging in Some rules on what type of issues should be filed where so they get addressed by the right group Class level documentation as much as possible in next two weeks Oliver will check on the transformation issue - XML rendering of regular expressions |
ATTENDEES: Wendy, Larry, Jon, Oliver, Kelly Role of dual TC/MT member is TC model reveiw - look at where you can best contribute Meeting schedule through June - We'll meeting next week and the leave scheduled for every other week if needed to verify what has been done, what's being worked on etc. Issues found during write-ups for TC Want to make sure what we have is the most accurate Documentation issues - review documents for current accuracy and move to DVG-27 DVG-27 Use cases / examples DVG-28 |
ATTENDEES: Wendy, Jay, Larry, Dan, Oliver, Kelly Agenda briefly:
2) don't include the class i.e. InstanceVariable and document that this is the linking point to a larger range of packages |
ATTENDEES: Wendy, Jay, Oliver, Larry, Kelly, Dan RectangularLayout becomes UnitSegmentLayout Larry made change and will follow-up with documentation search and fixes If we are going down to the datum and data point we are missing describing the Set of Units. We can say what the population was but we don't have a means of subsetting by definition. Want to lay out the issue. How would this relate to where VariableStatistics would need to be attached. Possibilities would be use of IdentiferViewPoint, Transformation Processes, possible of creating an Index or other means of addressing this. We want to be clear on what the prototype does, what it doesn't do, and issues. How far up the Variable Cascade Use the Variable Cascade as a central hub of where everything plugs in thereby facilitating connection to different parts. Model hangs together how extensions can plug in (different capture modes, different storage modes, etc) Workflow work is now stable - Business Workflow |
ATTENDEES: Wendy, Jay, Larry, Oliver, Dan, Kelly Data Description: Rectangular - does it also include a CSV as long as all lines have the same amount of columns SingleLogicalRecordFile - Flat? UnitRecordFile? MulitpleLogicalRecordFile - Hierarchical/Relational Two things: FlatSegmentLayout Prototype - Cube - dimensional store ACTION: Vocabulary agreement: Items 1 and 2 under Agreed are agreed Under Questions:
How does verification of use cases move into the documentation? |
ATTENDEES: Wendy, Jay, Jon, Oliver, Larry LOGICAL and FORMAT When Jay looks at the model now and the bindings Deirdra has been working with are out of synch and there are still some issues to finalize before entering the changes in Lion. There are lots of collections that bounce up against each other and this is being simplified. Jay has been sending out models of the agreements. He has been testing this model and making examples. DMT-176 One of the big changes we decided that Viewpoints hung off the Unit Record Relation Structure. There are no Viewpoint relation records Simplification resulting from mechanical entry of collections - showed up a number of duplications of activity. These have been cleaned up. Language of object - DMT-177 Move CDE to separate package Workflow/Process - NEXT MEETINGS Get data description nailed down in the next 2 weeks. Need to finish views and enter them by end of January 31. Jay and Larry will talk about how Format relates to logical and present next week. |
ATTENDEES: Wendy, Larry, Jay, Dan, Oliver DMT-182: Format structure issues raised in working on Use Cases. Data Description issue will discuss at next meeting. Darrin's example - can Jay see what you're doing - wendy email get his RDF Wendy will go through remaining views and potential view and draft for discussion DMT-148 - looked at specific issues (skip those in Qualitative) Final review piece is to identify those ComplexDataTypes that are total orphans - find them and isolate - Oliver will write script for validation of this problem Script to identify orphans in general - with package information - Oliver ISSUES for resolution before end of January Extensions to Workflow for Prototype - Jay will gather information, we'll create issue and determine what needs to be discussed Add lists of classes needing documentation in other packages in Prototype |
ATTENDEES: Wendy, Jay, Larry, Dan, Oliver, Kelly Workflows: PENTAHO etc. start with metadata and produce the transformation using that as a driver. Suggest the use of a MetadataDrivenAction. Add the ability to add a correspondence table which would hold the relationships used for recode. The user creates the correspondence table (ex. the IPUMS transformation table). Addresses Joins, recodes, renames Question: Are you aiming at being able to roundtrip and generate the PENTAHO from the DDI? Yes, we can do that. It's JAVA based. These systems also support formulas and can run scripts. They still want to use their statistical packages to do certain things. Don't want to do statistical analysis in a data management environment. Every time they changed data management they had to rewrite the STATA code because no one could understand another's code. If you capture the algorithm and generate the code as opposed to trying to derive the algorithm from the code. You can see what is going on within the eventual code. Jay will send to Wendy and Wendy will put in to verify that what Jay is proposing is clear. LION content: Jay to send Kelly a write up of the decisions made in Dagstuhl regarding the logical data description, some of which have not yet made it into the model. Wendy to follow up with Jay about creating an issue for integrating these decisions in the model. |
ATTENDEES: Wendy, Larry, Jay |
ATTENDEES: Wendy, Larry, Dan, Oliver DMT-141 - change xs:string to ECVE (entered) |
ATTENDEES: Wendy, Larry, Jay, Oliver Annotation Document Information Implications for document information - none at the moment - could leave as in and recommend that for certain RDF instance bindings Right now document information is put into all Views - should this be a deliberate selection based on the need for a persistent document rather than an interchange FOR PROTOTYPE: How would you use this information in a sparkle query? What you could do for instance if you already know something you want to query based on a study series. You know about this one document and you want to find the study identification to find variables. For most cases you would just use it for retrieving the provenance information on the metadata. Annotation usage: What annotation apply to - the metadata object
|
ATTENDEES: Wendy, Jay, Larry, Dan G., Oliver ACTIONS: Dan G. - review the issues at the bottom of the list with ? (100, 115, 141) and confirm that they have been addressed by Data Description. Any documentation should be added to these issues over the next month or so in order to make sure it is available -
OK resolve Wendy - will try to get geography structures ready to look at next week Geography is almost done. It extends CodeList: 2 questions 2) Would an abstract base for a CodeList/Statistical Classification/etc. be easier to handle (limits extension depth, opens up for other forms of signifier/signified options) DMT-159 - resolved Annotation issues: Access issues: access to data, access to metadata, persistent access restrictions/rules, local restrictions/rules In RDF you'd have some general information about a triple store but would not be able to distinguish different sources that different triples hand from. If you do quads you can have identification information on the triples. You are not able to say "give me the document root" you'll always land at the level of the triple store not the package of related triples. https://www.w3.org/2001/12/attributions/ RDF provides not model level division between data and metadata Jay and Oliver will work on this Workflows in on the agenda for next week |
ATTENDEES: Wendy, Jay, Larry, Dan G., Oliver spreadsheet used in discussion Assignments for next week Dan G. - review the issues at the bottom of the list with ? (100, 115, 141) and confirm that they have been addressed by Data Description. Any documentation should be added to these issues over the next month or so in order to make sure it is available All - DMT-157 I've reviewed and made comment so I think we can agree and resolve it. If there is no descent then I'm happy to enter that change. Workflows in on the agenda for next week Wendy - will try to get geography structures ready to look at next week All - review items associated with Annotation/Citation, we need to determine what must be addressed for prototype and what if anything can be delayed. Also, what is modeling and what is documentation. Oliver - add an issue to this Annotation/Citation set that addresses the issue identified in Codebook meeting as well as fuller documentation |
ATTENDEES: Wendy, Jay, Larry, Oliver, Dan G. Codebook will be reviewed for new classes, changes of identifiable to Complex Data Type, etc. Change name of CodeItem to CodeIndicator (done) CodeList - will always have contains with CodeIndicator and may have isStructured: ClassificationRelationStructure which points just to category (done) Instructions should indicate that you must use contains: CodeIndicator for simple and structured CodeLists. If the CodeList is structured use isStructuredBy: ClassificationRelationStructure to provide additional information on complex structure (done) LogicalDataDescription |
ATTENDEES: Wendy, Larry, Jay, Oliver XMI and definition of default values and regular expressions - Larry will send Oliver some XMI examples Start entering following Flavio's review pattern and then realize where needed Add ability to create a variable group and a statistics group (has to relate in some way to a data file) Codebook is down to finishing up relationship to DCAP and whether to include a relationship to Concept |
ATTENDEES: Wendy, Jay, Larry, Dan G., Oliver Codebook View Review: Can I enter collection and realization changes for those classes used by Codebook |
ATTENDEES: Wendy, Jay, Oliver, Larry, Dan G. Current state of Collection revision:
Where do we go from here from this
We need to have a clear workplan and priorities over the next 18 months As we're working on this can we create mini-examples. Oliver will create a means for us to make builds. |
ATTENDEES: Wendy, Jay, Dan G. Discussion of collection realizations:
Jay and Dan G. will walk through the realizations next week. Will also have a discussion during TC meeting period this week as there is no TC meeting Wendy will review what extending Statistical Classification from ColeList would look like. Also explore implication of extending Unit Type, Universe, Population from Concept |
ATTENDEES: Wendy, Jay, Oliver, Larry Went over emails regarding collection model and realization What needs to get done for CodeBook: Documentation of View capture: |
ATTENDEES: Wendy, Oliver, Jay, Dan G. Proposed game plan discussions
Documentation of Views:
Patterns:
Signification Pattern (new issue DMT-137 describing task).
APPROACH:
|
ATTENDEES: Wendy, Dan G., Jay, Larry
Add to NewCollection
|
ATTENDEES: Wendy, Jon, Jay, Oliver, Dan, Larry
Collection Pattern:
ACTION: Wendy will review work and draft summer work plan and send out for comment |
ATTENDEES: Wendy, Jon, Jay, Dan G., Oliver, Larry
Discussed and determined to be part of a larger issue on access restriction
Remaining
|
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
|