Date

03 Nov 2015

Attendees

Dennis Wisnosky

David Newman

Decisions Dean will complete the LEIENtities diff, will put all these on the wiki, and then David's homework before tomorrow's meeting is to walk through anything corresponding to BE91 and identify the JIRA ticket. Some of these might be mistakes where something drifted from one file to another. Elisa would do the same for the ones identified with Pink as a test for the diffs.

Leave Affiliate definition alone for now.

On LEI - All agreed to have max 1 and also make hasLegalEntityIdentifier functional. Whether to make it also inverse functional (one of the 2 options above), required more thought.

Proceedings:

20151103 FIBO-BE FCT

DW: Absolutely need to focus on OMG submission. PR if we don't submit a report in March the whole specification is dead. Feb 15 is the 4 week deadline. If we reduce what we have to something that can definitely go through this time, everything will go through. If we do nothing now, we will end up with a giant thing for Feb.14 La Jolla is December, deadline is Nov 9 (next Monday). Start with the issues in the OMG JIRA for BE. The deliverable would be an FTF report with the open OMG JIRA issues closed. That does not necessarily mean we can submit something. The diff should focus only on what we didn't get done last time. PR: We can't do the FTF report in December AND March whatever we submit, on one only of those cycles, is the final definitive FIBOBE. However, this is not the last FIBO=BE, it is the first one. Subsequent submissions would build on that. This will be the formal FIBOBE that has our seal of approval and people will want to start using it for production projects. So this is us saying this is as good as it gets. So if there are any gaping holes, would we be happy to use this in production without those gaping holes fixed? The conclusion is, we can't submit something in December and then submit something in March.18 If we submit in December this would become the official BE 1.0 Final, and we would that charter an RTF. Could be June rather than March, to do a 1.1. And once we publish this Final 1.0, future changes may only be additive, i.e. we can't do destructive changes.

DW: this is the start of a process. If we take a small chunk now (December) and it is rejected, we would still have March. Then what do we have for March? We would charter another start, as an RTF. However, PR reminds us, if we do that we would be hard pushed to have something in March as we need time to digest issues that people raise. We need to ensure that we would not have major changes in that future stuff, if that causes people to have to make destructive changes to their implementations of 1.0. So a lot depends on what is in the diffs. If we go forward with what we have as minor changes in Dec, then we would be impacted for any of the minor changes we would want to make for March or June. Suppose we give it our best shot in March: assuming we do our best job in March. Is there any reason the AB might not accept it? No reason why they should not. The key things are traceability of changes, and not adding huge amounts of new functionality that goes beyond the stated scope.26 So far it seems our current additions in Government Entities are within the stated scope, so there is no potential hazard there. So if everything is frozen and we concentrate our efforts on a polished submission with all change traceability, all the rights content in the spec, having prioritized what is most important, leaving out the stuff we are less sure of then? Additional stuff we can still put into the OMG system with a status of "deferred" and put those things into the RTF. DW notes we did the same thing in March, June, and last December. We kicked the ball into the next quarter. Pete's recommendation of our best shot at complete and fully supportable BE 1.0 for March, which would not need to be massively revised later we have one shot for this. Why would we not try to do just the minimum that we have right now? (DW). Because it is much much harder to make change later. Clarify from Pete: you get more leeway as an FTF than in an RTF, in terms of major change and refactoring. FTF is about implementability, whereas RTF has to be about fixing very precise problems. Those problems may be big or small. However, refactoring does not count as something an RTF should be doing. That would include moving stuff from one ontology to another. RTF should not be doing that. DW it is all the same problem. PR this is not the case, there is different leeway in terms of refactoring. DW has noted people doing a range of different things to get around these constraints. DW has not seen the difference that Pete describes.

The worry is that we get to March and are still in the same position we are in now. DN our only focus between now and then is on creating the OMG submission. The time will be spent working on the BE models in VOM. The hard part is the decisions these diffs refer to. Includes some of the unresolved questions like relative to relative relations. DN we have made the decisions and these are all reflected in David Newman fork, Pink branch. We do not anticipate revisiting those decisions, the question is only how much of that to include in a March release. DN What do others think? DW we need to see what Dean's diffs tell us. Can't make decision a priori without looking at that.

Dean: the diffs. Good news ( to follow). The process: very similar to what he did in August. Two tips of the process: EDM Council Pink (result of all accepted pull requests); the other is BE91/Davids Fork (intended t be frozen a week and a half ago). Common ancestor, as identified in August, hasn't changed. The common ancestor was in Pink at Aprll 6. Reflected what is in BE Yellow? No, BE Yellow has an earlier ancestor, and has changed since then. BE Yellow is from February. Process was to serialize all 3 of these things, using Tony's serializer. There are a couple of cases where the serializer behaved in an instable way. In the vast majority of cases the behavior was stable. This means in most of the cases, changes made in each place did not affect work done elsewhere. Therefore most of these don't require heavy decision making, they just require the documentation to track the changes. there were 2 files (plus the About file), that had actual conflict. The conflicts were to do with renaming. Renaming is hard to track. It was in these cases that the output from the Serializer was not helpful, including different names for blank nodes. So the same blank nodes will have been awarded different names by the serializer. Went back to the TopBraid serializer (more stable, as is Turtle). The 2 files are: LegalPersons.rdf and LEIEntities.rdf. No other files had conflicts. Q: There were many other changes in many other files. These did show up as a diff, but did not show up as a conflict. A conflict is where 2 people have made different changes of the same things. Git can deal with changes that are not in conflict with other changes. They are still diffs, but not conflicts. The conflict will require decision making to arbitrate between the proposed changes. LEIEntities not yet finished. Plan is to put these on the wiki for conflict, and Dean, David and Elisa can work on these tomorrow. Will then come to a plan for how to action these conflicts. Meanwhile the long slog workwise is to document the changes in the non conflict changes. Each of those changes needs to be process as a JIRA issue, changes documented and so on. These will require no decisions but extensive documentation work.

JB notes a conflict around contractually capable entity versus LEI entity. These are not the same thing. In the original those two concepts were conflated on the belief they were coextensive. Given this question from Jeff, we should probably walk through all the things on the screen quickly and look for SME reactions. Suggestion: the context of the change was not clear in the above. A simple followon to document the context in which each change occurred, would make the process less confusing. This kind of information Dean does not have. There ought to be a JIRA ticket for each of these, identifying the thinking at the time a given change was proposed or made. Would like to walk through all these with reference to the relevant JIRA tickets, if theyexist. A simple text diff cannot be expected to identify the thinking behind the change. The changes in David Newman branch would need documentation from avid, and the differences in Pink would likely be in the EDM Council JIRA. David will create JIRAs for any changes in his branch that don't currently have them. The next step is the 3 way meeting of David, Dan and Elisa, to go through all of these.

After this call, Dean will complete the LEIENtities diff, will put all these on the wiki, and then David's homework before tomorrow's meeting is to walk through anything corresponding to BE91 and identify the JIRA ticket. Some of these might be mistakes where something drifted from one file to another. Elisa would do the same for the ones identified with Pink as a test for the diffs.

Can we remember the class we deleted and had to add back in" We deleted LegalEntity and did not put that back. We also deleted LegalPErson and reintrodued that later with different content. There was also MunicipalEntity , which was in the Pink (as Municipality possibly). Did that come up in the diff? Yes. MuiicipalEntity is missing from BE91. PR is reassured that Dean's diff picked this up. The other thing we did was identify the elements that FBC uses that changed, e.g. the change of name of FormallyConstitutedOrganization which was renamed to ContractullyConstitutedOrganization. So there are changes that will be needed in FB FBC. NaturalPerson was also renamed / redefined and needs a change of reference in FBC. So the other challenge we have in packaging this is that when we submit BE with these changes, FBC will require a revision to track those dependencies. How would we orchestrate that. FBC s submitted to OMG did make reference to things in BE that were not in BE. This was something identified as needing to be fixed in the FBC FTF. So it is possible that some of the changes needed in FBC would not be required as they may already have anticipated the proposed end state of BE. DN believes there may be some other changes that have not been anticipated in FBC. The changes around Sovereign will have anticipated the proposed changes in BE that are not in the current official BE. That change id not seen as a conflict in the diff (regional, or sovereign). Regional governmental Entity and Sovereign State were referenced from FBC with their anticipated new names. Municipal Entity may also have been renamed from Municipality at some point. There is RegionalGovernment, and FBC is referring to RegionalGoernmentalEntity, which is a different concept. Anticipate that that is in the proposed BE. Called it RegionalState in this version. These are distinct things. They did identify the correct differences between FBC and BEDavids Fork. See email forward rom Pete, for the 2 names. The less problematic diffs, that require documentation Dean has not prepared that yet. Will have that available for tomorrow's meeting. Also relates to changes to all the various legal forms, in terms of new content not in BE Yellow. There were also new files, then there weren't. Dean needs guidance on how to address those.

Back to the prioritization question: if we were to assume that we can slip the 4 week deadline by 1 week, do we know how much can be done within that time frame? Depends on the JIRA issues we prioritize today. Many of these can be deferred to another release. The biggest thing seems to be the structure around ownership and control. DN proposes that those are deferred out to a future iteration. The names of properties in ownership and control need to be made more consistent. If we were to complete everything for OMG and still had bandwidth, we would still be able to squeeze those in, if we want for March for the definitive Final 1.0.

JIRA BE7 Affiliate: Currently in Yellow. Is limited in what it describes. Anticipate that a lager module for Reg W Affiliate would be more expressive. The current definition is very narrow, whereas Affiliate is typically much broader. Will it hurt to leave in the current limited bu not wrong definition, and defer the expanded update of Affiliate to a later time. Wasn't there a lot of work on defining Affiliate, with rules? Yes, that was in Reg W Affiliate. DN proposes this is not critical. MB suggests that we need a strong, simple industry definition of a term, which would not be the same as the way that regulations define their use of a given word, the latter is typically a union of various other concepts and subtype thereof. JB surely the need is to provide the broadest possible meaning, not something that is narrow and needs to be broadened alter. Current definition does not include indirect control of the parent or subsidiary. We need the concept to be as broad as possible, as a single simple concept, so that any further changes become additive. What we must not do is consider something that we would come back and change later, since 1.0 stability requires that future changes are additive only. Proposal for now is to leave that alone. There was some work in May for Reg W, including rules. Is that the existing definition, or the one we will hold off and bring in later on? It is the one we would hold off because this requires more work. DN believes that what we have is not wrong and will not hurt us to take it forward. The definition is currently limited in that it does not include many of the indirect control relations, which can legitimately be seen as part of an Affiliate definition, not just in the regulations.

BE35 LEI the exactly one LEI question. Where this says has identifier min 1 identifier, we could say hasIdentifier min 0identifier, meaning that an org may not necessary have an identifier. There are LIE capable entities which are not yet registered. From the LEI end, it should identify exactly one organization. So you don't have to have one but if there is one it must of one organization. JB: Cardinality is either 0 or 1. Definition of LEI Capable is that you could have one. So property cardinality is 0 or 1. In protege, David goes though proposals, for both LEI Identifier and OrganizationIdentifier. hasLegalEntityIdentifier exactly 1 LEI. Doe this mean that it does or that it could? Does exactly 1 imply min 1 and max 1? Dean; Yes, Pete is right about the implications of this assertion. So the assertion is inconsistent. The aim is that if you have an LEI it must be exactly one. If you have one it must be exactly one" does not make sense. If you are going to have an LEI you can't have 2 or 3 it must be exactly 1" Is 0 allowed? Yes. So it is 0 or 1. So Max 1 is the right thing. If we change it to max 1, then we would have to make hasLegalEntityIdentiier a functional property. this is needed to support inferences, to differentiate the entities. Don't we want this inverse functional? DA: Yes. We want the LEI to be a prime key, effectively, so that needs inverse functional. Might want it to be functional as well. DN we need it functional as well, since when we did not have it as functional the reasoner was not able to differentiate between the object. If we want both functional and inverse functions, then when it exists, it is 1. So we need the functional, the inverse functional, and the max 1. Does functional require a value or not? Can there still not be a value? No, Functional says that if I have a value, and if I have another value then those 2 values are the same. Functional does not relate to the domain, only about identity. If 2 entities with different names have the same LEI then the reasoner must infer that those entities are the same thing This is done as sameAs (not domain inference). Subject, not domain, is correct. So, have Max 1, make it functional and EITHER. make it also inverse functional OR make the inverse property functional. This is a choice to be made. Issue was originally whether to be able to model the instable (incorrect) work situation where things wrongly had 2 LEIs. We came down on the side of representing the desired state. In that state everything has exactly 1. We now are also talking about the state where a company exists but does not have an LEI. This is not the same as the undesired state of having 2 LEIs. We did talk about having an additional property, to support folks like Mirek who are processing the dumps, and may need a different less restrictive property, to represent what is actually there. Pete agrees this would be a separate property and can be added in the future. All agreed to have max 1 and also make hasLegalEntityIdentifier functional. Whether to make it also inverse functional (one of the 2 options above), required more thought. A practical note: for the changes we are taking about now, should we defer these until after the diff material has been processed? We should essentially be in code freeze right now, so we can't do the changes we just talked about. DN: this is a high priority JIRA issue we do not need to touch any of the others. But we must process this one. Given we are in code freeze, how we will have to weave this in to the submission. Will have to work out how to do this, after tomorrow's diffs meeting. The current code has 1 issue in that it does not allow for the optional case, where an entity exists but does not have an LEI. DN proposal is a minimal change, to has isDeentifiedBy min 0 organizationIdentifier But that is also a change. Just bite the bullet and just do this change, on top of the stable code base that will emerge from tomorrow's meeting. Change to be made Thursday earliest.

Action items

Browser not supported