/
2017-07-27 Meeting notes

2017-07-27 Meeting notes

Owned by Dennis Wisnosky
Last updated: Sep 07, 2017

Date

Attendees



Agenda


1) Where we are on our road map. 

2) Open Action Items

3) JIRA Issues Review - https://jira.edmcouncil.org/projects/RDFKIT/issues

4) Todays content discussion.


5) For next week.

Proceedings:

20170727 FIBO FPT RDF ToolKit

 

Today talk about documentation for OMG.   And, open actions from Cambridge meeting (JG).

 

1. Cambridge meeting (14 July) - FLT agreed with proposals coming out of that meeting, but suggested possible intermediate steps. 

2. JG action from that meeting. 

Also (3) MB and DW have been corresponding with Juergen at OMG about RTF closure requirements and FIBO 2.0 submission. Outcome: it is possible to let the 3 existing RTFs lapse (there are no open issues on them). Then whatever we do in FIBO 2.0 refers back to the existing baselines for those specs.   DW still to communicate the details of this to EK. 

 

 PR on Monday FLT talked about automating the documentation. Ideally we should not have to any further work after we publish the EDM Council spec quarterly release - so how do we derive the OMG Specification documentation from that?

 

Alternatives to letting them lapse is to do an RTF report that defers all the issues to FIBO 2.  This is what DW and MB expected them to tell us to do. 

Given there are no issues there is nothing to defer.  Need to generate and write as much of the spec as we can to submit to the FDTF at Sept OMG meeting.

 

MB:  It is odd that the RTFs do not even have JIRA projects, since we would normally have copied our issues from EDMC JIRA into those JIRA projects.   We can't even generate the RTF report to say nothing, given we have no JIRA projects. 

 

Next up: generating the specification.   ODM v SMIF - since OWL is the normative form of our material, it would not be a problem to not have ODM.   In FIBO1 we had several normative deliverables of which one was definitive. There is no reason to replicate this in FIBO 2.   Suggest that we recognize the diagrams as non normative, and only the OWL be both normative and definitive.   All agree that diagrams can be non normative. 

 

JG:  Why OMG at all?   DW has corresponded with Mike Atkin on this.   IF or when we are ready for the EDM Council to become a standards body, we would not need OMG. Until then we do. 

 

How would we generate the documentation?   JG:  Git is our authoritative source for FIBO. Any artifacts we can derive from that. Then for the front matter pages, we can store something in git and append to that.   MB not sure we can do a whole ISO template spec in MarkDown.  JG: Can use MarkDown for cross references and so on. Is it very complex?   CC: the format is very detailed and complex. This is very difficult to create a report that fits into the OMG template. It has to either be in OpenDoc format or Frame-maker with specific templates. The templates are taken care of in the MagicDraw report generator (this would give you the diagrams as well). 

 

What is the input to the tool?  This is the CCM model.   We would either have to originate stuff in CCM and make really sure that the OWL is generated exactly the same, OR we originate material from the OWL.   JG we might need to add some matter to the OWL ontologies to support this.  This could be in the OWL itself or as separate text documents or markdown fragments (ASCII not Binary) in GitHub.  We don't really want to have a binary format in Git.   CC: We don't have much choice on that. The written spec will need to be a binary file.   JG it should be a requirement that what we generate is based in Git. 

 

DW  The happy path is through CCM.  Start in Git, transform this to CCM, do the diagrams etc., and generate the report. Any issue with that?    JG: this will work if all content ends up in the documents.  CC: if this follows the ingest rather than outputting then even if this is a one-off file it will be usable in this way.  DW  Assuming CC is correct, what do we have to do?   We can store binary blobs in GitHub knowing that we can't merge these or have multiple people working on it. Neither of which is an issue 

 

MB can work on the written specification matter.    Section 8 should be replaced with a report on the Artifacts ontology. Other sections can be simplified. 

 

ACTION:  MB will write up FIBO 2.0 submission for Sept OMG.  CC will coordinate with MB.  EK and DA will focus on resolution of EKs issues.  MB and MU will coordinate with DA and EK.  JG and TC will watch this process and continue to work out automation paying particular attention to testing.

 

This JG and TC action leads us to Actions from Cambridge

 

JG Need to use Git tags - things that were called "latest" to be replaced by the proper tag that reflects the version number.  In Cambridge we came up with a scheme for tags. These include the quarterly releases and possible tags for special events.   For this you switch to the relevant branch and then set the tag. The tag would be prefixed with the branded name e.g. master-specialTryoutVersion or whatever.   That name is taken out of the tag name by the Jenkins publish job and used in place of what was "latest" Correction  it is master underscore.    i.e. master_ThisThing

 

The official release is a very simple tag:  2017Q3

 

The above detail is only if we needed to have specific releases for special events.   We can also put out more than one release in a quarter - these would then have 1 2 3 etc. (single digit) but in general we would not want to have more than one release in a quarter.   The Publish thing does not care what happens after the underscore - this can be whatever. This means we can create e.g. special event releases master_EDW or so on. 

 

JG recommends this be in something other than the Master branch, so master has only the Q1 etc. tags.   MB This is new since Cambridge, but makes sense. 

 

ACTION:   JG complete his Cambridge assignment.

 

Cory Casanave By the way, the "most compatible" tool for OMG specifications is "LibraOffice" - it reduces issues to use this rather then word. Note that both tools have merge capability.

 

DW We still struggle with the need for continuous coagulation.   When we make any small change we need to test the whole thing.   We don’t have a proper test framework yet for integration test.   Usually you would segregate Unit Test and Integration Test.   In software development, you typically run the unit test before you commit. Then after you commit and push you repeat the Unit Test and also the Integration Test.   DW we may end up doing these unit tests every day. People in GIT would need to be using the right FIBO Master.   Should be a proactive that if you have a fork you should always do a git pull from Master to have the most recent.   Is there a way of policing that? 

 

JG  GitHub will tell you when you create a pull request that the pull request can't be honored. 

 

MB we can't rely on the inability to honor a pull request as it is possible that many changes have happened but not enough to cause an inability to honor the pull request.   For instance, the resulting graph might be semantically wrong but not logically inconsistent.   JG we need a set of test scripts in Git, that have a set of SPARQL statements that we maintain.   CC there are tools for managing test cases.   MB if these include test driven development tools then this brings us into correct Agile use.   There are tools for ontology test - see Guarino and Welty 2002 (OntoClean)

 

MB: also need to consider the overall processes we follow, and later how to police these with e.g. Jenkins.   JG: need to follow the user story approach. Can define the US as text in a file. can use SPARQL to translate that user story to a definitive test. 

 

DW in practice we have turned out not to be very good at that. DW has been using user stories but in this group, we have not been good at this. 

MB if we identify the physical process a human should follow, we should then be able to get Jenkins to have hooks where you ensure that for a given thing that a person needed to do, there is documentary evidence that they did that thing.   CC the tools and community understanding for doing this in Java is so mature, can we front end this from Java and adapt for the kinds of tests we need for the OWL.   JG the tooling is the least of our problems. The main issue is what we want to accomplish with the tests, and this requires user stories. 

 

DW What does a user story even look like in OWL?   MB this covers integration mapping etc., as well as answering competency questions. The existing user stories are broader than just OWLy application stuff.   So we need to ensure consistency and so on. This is the easy bit.   The main discussion is what is FIBO delivering to the customer. 

 

MB this includes mapping and integration as well as semantic querying. These are user stories.   This is about providing the consistent concepts and terminology.   JG does not agree with what MB said about the user story including mapping and integration. JG sees it as answering competency questions and the user stories are those questions.   MB says this is a sub set of the overall use cases that include mapping, integration and reporting.   So the operational kind is equally valid but is only a part of the overall usage of FIBO,  e.g. "give me the parties to that trade" is one of the JG type of user stories. 

 

Cory Casanave This is chipping away at the operational ontology focus!  DW, Yes and FIBO is not intended to be an operational ontology.  DW we need to know what the consistent model is. For instance, conversation about whether a deal is a kind of facility. 

 

JG We need real world test data for those things - need special test data files.  DW yes, we do, but that has been on the “too hard” list for us.

 

What we have agreed today:

 

  1. MB focus on documentation for FIBO 2.0 for August 4 week deadline (22 Aug?)
  2. Elisa and Dean will focus on the Sept EDMC FIBO publication
  3. JG will finish the changes agreed in Cambridge. 
  4. Open question how to test intermediate parts of FIBO as FIBO changes on a daily basis. 
  5. At 2017-731 FLT, MB will lead the FLT through use of latest TWC and CCM together.  CC will assist.

Decisions:

Action items