...
| Warning | ||
|---|---|---|
| ||
Materials from External Review work at Dagstuhl Sprint |
| Expand | ||
|---|---|---|
| ||
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 |
| Expand | ||
|---|---|---|
| ||
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 |
...