2015-12-15 Meeting notes
- Dennis Wisnosky
Date
Attendees
Agenda:
1) Use Case reminder.
2) Where we are on our road map.
3) Open Action Items
4 ) JIRA Issues Review
5) Todays content discussion.
UML
Spreadsheet
Protege
6) For next week.
Proceedings: 
20151215 12 FIBO-BE FCT
Focus between now an early Feb is the construction of the OMG submission (Finalization Task Force Report). No new creative work will be done in this time frame. Business domain experts are welcome to join in but it may or may not be the best use of their time. BE is frozen as of several weeks ago.
Progress: Dean sent an email to Elisa last night. Would like to review the approach he is taking, today. Other things to cover today: Complete the diffs in Partnerships and Trusts.
First Dean will talk about what he did. Dean screen: Actions to organize things up to the formal resolution stage. Dean has numbered the rows in the wiki table, for the action. Color codes identify things by file (one color per file, alternating for visual clarity). Examples to review? See DiffNotes, Details, Affected Elements columns. Diff notes have the detail. April 6 version is the one we will make the resolutions against. Where a whole set of actions are against the same entity see e.g. Juridical Persons. Some were in EDMC JIRA, some not. Also some reversed out. Rolled these together, identified as one resolution.
Meanwhile some issues span several files, for example the ones about "objective" for various kinds of entity e.g. with religious objective, non profit and the like. This change spans several files. These are rolled together. On the resolution side, there is a short title, which can be the title of an EDM Council JIRA. David is to track down the rationale. Would include source, e.g. interview with lawyers, research on line etc.
Next, outlined all the rows of the spreadsheet that correspond to a given issue (ten in this Objective related one). This work needs to be proof read.
Next step: has taken each of the rows identified in the Resolution description, hop across to the detail column in Row 19, which should already say exactly what needs to happen. Thereby, Bobbin can navigate from the list in the Resolution entry, hop across to the table, look at the actions details, and use this to describe the resolution details. Then Elisa can do the VOM diagrams to correspond to these. Needs to then go back to Row 19 and put a check mark there, showing which resolution(s) covers it. Some rows will relate to more than one resolution. Usually these resolutions can be done independently of each other.
Chapter and Verse: Bobbin needs to take the baseline spec, and describe with section numbers, table numbers and diagram numbers what is to be changed. These are to take the form of detailed editorial descriptions. For a net add, will need to say e.g. "in the clause called objectives, add a clause called BusinessObjective" etc. Except, that if the change is a class or property, this is a change within a table, not a new clause. For tables, there is a change of format. We would do the Chapter and Verse using table lines in the Issue Resolution. The subsequent Redline can have one new table, with the IDs of each JIRA at the top of that table.
BusinessObjective is net new and will be a new row in the relevant table for the Classes in that ontology. There is also a parent column, which in this case would give 'Objective' since this is the parent class in Foundations. We do not need a separate row entry for the Objective class since that is in Foundations itself.
Question on Resolutions: Do you have to describe the use of the new thing across ever instance it cuts into? That is, is it more than just describing it as a new entry? Anywhere where we have used the new material, is itself a part of this change. For example if we introduce PrifitObjective, do we need to list every usage where ProfitObjective is referenced? That is a lot to do. So for instance in other modules we have introduced new classes and added restrictions that refer to that new Profit Objective. DN suggests that would be easier to write up as a separate resolution. DA disagrees, since if you had these as separate resolutions, this creates a huge chain of dependencies to manage.
What the AB is looking for? Something they can vote on, on its own. That is, one theme describing one change, which can be voted on as a whole. Dean argues for big resolutions. This avoids circular dependencies. Make all the changes in one resolution, for one issue. Also all redline in the written spec, must have a JIRA number above it. Also each JIRA is subject to one vote by the FTF. The AB will satisfy themselves that the voting was on identifiable issues. So to clarify, given a new item, if there are other restrictions and things which have been changed to make use of that new item, then each of those is a change resulting from the issue resolution, and so will need to have the JIRA number above it in the specification text.
The strategy outlined above will be no surprise to seasoned OMG veterans. Dean's experience on timing is about on a par with the FND FTF work. There is a worry that further resolutions may be more complex than these first sample ones though. So there is still some unknown in terms of timing. Dean is rolling together things that are independent and can thereby be combined thematically, for a single coherent resolution. The two Dean has looked at so far are independent. for example the merges of files CorporateBodies and Corporations. Other resolutions have assumed that this was done. So if it wasn't, there would an issue with dependency.
Where there are dependencies, these need to be in separate ballot. So once a resolution has been accepted (or not) THEN the next resolution can be put in a subsequent ballot. In some cases, Dean can do these either way around, but sometimes the second resolution would be more work if there was a given outcome to the other one. In this example: merging ontologies is less important, but makes less work in the subsequent resolution. So Dean will prioritize those resolutions that introduce new content, whereas the file merges are less important even though these might result in more work in the subsequent issue's resolution (i.e. merging more new material after that was added in the separate files).
Given the risks and time fames for VOM merges of ontologies specifically, these will need to be a lower priority than the new material. VOM in particular hs challenges in renaming or moving things. CCM can do this however, the diagram format is not an OMG standard whereas ODM is. If CCM did ODM then it would be a tool we could use to move things about more easily.
Is the ODM diagram style an issue? There is flexibility on that, and it is not necessarily the case that we can't evolve the ODM diagramming style to be easier for either the business or the OWL technical audience. DA if it is the case that the merge is a huge amount of work, why not put that out there and get it done as a priority? Proposes not to defer these out. Present this to the FTF. We would not expect the FTF to reject these two ontology merges. The FTF is us.
One of the merges is easier than the other, since one involves a new ontology whereas the other is making a change to what was already submitted. What row were we talking about for that? This was a note not a line item. See Action 6 under the Actions list for this change. The winner in this merge is the one called Corporations. This was in is own module, also called corporations. Or are we retaining the corporations module and getting rid of CorporateBodies underLegalEntities? We are integrating and merging CorporateBodies and Corporations. Corporations remains in the module called Corporations. Corporate bodies goes away (Delete the Clause), and everything in it has its urI changed.
Note that downstream changes do NOT include a change to every item that now refers to the new namespace of something whose namespace has changed, as long as its own name hasn't changed.
Next up: Trusts! In Trusts, there has been no change in the subsequent Pink ontologies since the baseline. So the changes in trusts are all in David's Fork. However there may also be impacts of the name change of FormallyContitutedOrganization, if this is referred to in Trusts. (we also didn't finish Partnership, can do later). Pink has no changes v Yellow, for Trusts.
BE96 adds an import to LEIEntities. This is so that a BusinessTrust is a sub class of a LEICapableEntity. BusinessTrust is net new.
Not all trusts are LEICapableentities, since Personal Trusts are regarded as not being eligible for an LEI. Previously all items which could undertake contractual commitments, were considered LEI Capable. So the Issue description could be a single one to add a whole bunch of new types of trusts. There is also change in Trust itself. Is that dependent on the above? No!
DWiz: Even though the FTF are our friends, there is a limit to what new material the FTF would absorb. We can prime the pump, and add considerable new material in a BE1.1. If we throw all of this stuff at it at once, this will cause us concerns. Particularly if the newer stuff is less finished. Here we have 5 net new things (new types for trust). If there are 5 new things like these Trusts, that's probably not to much to expect the FTF to vote Yes on. If we we’re introducing 50 distinct new concepts, we could expect the FTF to push back.
DN: We understand that we don't want to give the FTF too much to take on. We will work through all the proposed new material and identify what to put forward to the FTF. For example we might do away with some of the more exotic types of Trustsbut there are some basic ones the industry needs before BE can be considered usable.
The original submission had a minimum of trust terms which were considered to be universally applicable, but David feels this was not enough for a usable spec. David will therefore prioritize these. Common Trust and Charitable Trust both refer to Irrevocable Trust and Trust fund Trust, so these being in alphabetical order, are not in order of dependency.
There are 9 new trust types in all. Also these don't have logical discriminants, only natural language discriminants. This indicates we did not do the full job on these yet. BusinessTrust does have logical discriminants though, and could be kept in any scenario.
The ones without logical discriminants, indicate these ones are not ready for this release.
When Dean writes up the resolution, he will certainly keep BusinessTrust, as it has logical discriminants. IrrovableTrust is probably important but does not have discriminants. So that would be additional semantics work. Also how many of these are globally applicable concepts as distinct from jurisdiction specific types of trust? Answer: all of these are globally applicable types of trust. Trust Fund Trust is really there, and this is needed for financial work, since these are big in the UK. The definition in Trust Fund trust has been extended with explanatory stuff, which should really be in Explanatory notes. The above will need to be a JIRA issue for the RTF to deal with, as we don't need to deal with it right away for this kind of editorial change.
Decisions:
Action items
- Mike Bennett Elisa Kendall Dean Allemang Bobbin Teegarden (Unlicensed) Review these notes.