2015-11-24 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: 
20151124 FIBO-BE FCT
BE96 work as of last night should include all the recent changes. Update on recent work: Dean had done diffs between a BE91 (David’s fork, Pink branch), versus FIBO Pink versus a common ancestor of the two. A number of collisions were found. Work was to identify what those conflicts were and determine which way to go with each of these. Conflicts were found only in two ontologies: LegalEntities and LEIEntities. Each of the differences was documented in a table on the wiki. We have been working through these differences, the rationale for each option and any JIRA issues covering the net new material. Where there was not such a JIRA, new ones are created and assigned. Also FormalBusinessOrganizations has differences and is in the table as well. See JIRA: Net new JIRA issues: BE104 change of domain of hasAddressOfLegalFormation to be LEI Capable Entity. Is this resulting from the name change to LEI Capable Entity, or is this a proposal to change the meaning of this property? This was a change of scope, since the original relationship was narrower, applying only to entities that had legal personhood and had a registered address since they have legal formation. Is David confident that everything that is eligible to have an LEI, that is everything that is contractually capable, is something with legal personhood, and therefore has an address of legal formation? Jeff notes that if we extend the concept of being registered, and expand the intended meaning of this concept. In LEI it asks for two addresses, the address of legal registration and the headquarters address. So in the sense needed for LEI, there is always an address of some sort that is regarded as an address of some formal registration, which goes beyond simply formation of legal persons as e.g. limited companies. Jeff B is confident that in this new sense, this concept always exists. For example for a fund, this would be registered in some way. The same applies to Trusts. What about local branches? For those, the foreign address of legal registration (that of he entity that this is a branch of) would be given. So in LEI registry, there is always some kind of registered address in this new, broader sense. Are we locking in as necessary something that is not always necessarily the case? Jeff is confident that in this new looser sense there is always something. Given this change of meaning is there a rationale for removing the previous concept? That would be outside of the LEI use case. The original property had the meaning of the address of some legal person. At one point this was a property of "Legal Entity". Before that, it was an object property whose domain was some artificial Legal Person (Juridical Person or something. However, with the earlier removal of Legal Person as a concept before that was reintroduced, the older meaning of the address of incorporation of some legally incorporated entity, was effectively removed when the class Legal Person was removed, before that was reintroduced. Jeff notes that there would be entities with an address of legal registration which are not LEI capable entities. Are there examples of this? Hypercube Ltd would be such an entity. This would be LEI Capable but not LEI Registered Entity. Note that LEI Capable Entity is changed to LEI Eligible Entity. Jeff notes that in the longer term there is no reason for LEI to be limited to financial market participants, but it is limited to entities with registered (in this new sense) addresses. New restrictions to be added, to say that if you had an address of legal formation, you are also an LEI capable entity. This is to validate authenticated entities as opposed to fictitious ones or ones that cannot be validated. Discuss the cardinality of hasAddressOfLegalFormation on LEI Eligible Entity. Max 1? Would imply possibly zero which goes against what Jeff is saying about eligible to validate and verify entities in the LEI system. And you can't have 2. So it should be exactly 1. Caveat: this may not be a legal business register but may be some other publicly accessible location where things can be registered in some way, even when they are not incorporated legal persons. For funds, you can use the address of the management company rather than the entity that is the fund itself. For non incorporated funds etc. there would be different address somewhere where legal papers can be served. For example would you serve papers on the fund management company or some other legal person, when you need to serve legal papers. Otherwise there gets to be some fuzziness. The original concept of Registered Address was specific to legal persons that are incorporated. The new broader property we have now agreed to, would be referring to this same range that is some RegisteredAddress. It was decided this is still appropriate, given that papers would be served on someone somewhere. This adds additional substance to the meaning of LEI Eligible Entity.
BE103 rename instrumentOf to isInstrumentOf. This is per our naming convention to have a verb at the left.
BE102 Treatment of sub funds. Given that sub funds may be assigned LEIs, but are not separately incorporated companies. They are segregated pools of assets. So they met the criteria for LEI assignment. Do thy still meet the criteria we just added above? Original CICI intention was to register umbrella funds, but this is not necessarily recognized. Is this compatible with the new restriction to have a registered address? Yes, it is possible to use the registered address of some responsible entity such as the fund manager. Strike the last sentence about the sub fund name being submitted in a given format. This was stated 2 years ago and is no longer the case in the LEI arrangements. The common data file format has a provision for identifying the parent fund as a separate data element. So the concatenation arrangement given earlier no longer applies in the standard. It was an earlier recommendation out of GMEI but no longer applies. So the recommendation on how to submit the name of the fund is deprecated, in favor of a separate field called the Associated Entity.
BE101 hasSignatory. This was discussed in FND and the conclusion was to not make the change to the meaning of this concept. If we need something that is a person signing on behalf of another person, that should be hasPowerOfAttorney, which exists elsewhere (possible only in Red FIBO?) Delegated of signatory rights to a person is needed and is similar conceptually. This is a delegation of authorization to sign contracts. We do have PowerOfAttorney as a class. David cannot find an Object Property called hasPowerOfAttorney. FND can add hasPowerOfAttorney if it is not already there, and then hasSignatory can be a sub property of that, if it is not already. MB to cover this in today's FND FCT session.
Back to the integration of the diffs, including integrating of concepts that we were previously in the ontology called BusinessEntities, into the LegalPersons ontology. The BusinessEntities ontology is then deprecated. This work is completed. Review in Protege: This is BE96. BE96 has bee completed in Dean and David’s Pink branches. BusinesEntity class was in BusinessEntities, is now in LegalPersons. Along with a number of object properties associated with it such as having limited or unlimited liability. This work has uncovered a number of circular dependencies, and one more change to be carried out that was discussed with Elisa yesterday, related to changes in the modules CorporateBodies and Corporations. Originally CorporateBodies was a sort of umbrella layer, but over time that functionality became less apparent. There may now be only a couple of object properties in CorporateBodies, which are reused in other modules. So a proposal is to merge CorporateBodies and Corporations. We would have to justify this change to the OMG .It would be for simplification, to reduce the module count, remove modules that are no longer clearly differentiated. In addition there was a degree of circularity we are unwinding to make the model more efficient. Completion of this merge was needed before we complete the diffs resolutions. Recap of progress yesterday: completed merger of BusinessEntities into LegalPersons; eliminated some circular references; discussed merging CorporateBodies and Corporations, probably into Corporations, but did not implement this yet. Also identified some namespace problems (concepts with the wrong namespace in the right module; Protege sometimes masks this when things are moved. Dean: Refactoring of CorporateBodies. This may or may not require merging these together. If we can figure out how to refactor it, given we have the same ontologies and the same modules with different content in the different branches. Corporation is currently in CorporateBodies, whereas various kinds of corporations such as privately held ones, are in Corporations. So there are kinds of corporations which span different modules. Hence the need for refactoring. The original intent was that Corporate Bodies was a place to put stuff that was in common with all corporate like things. The original intent was to use the top level one to define all the kinds of way that some legal person can be incorporated, for example by equity, by guarantee and so on, whereas Corporations was intended to be specifically entities incorporated by the issuance of shares. So Partnerships and Trusts were not in the scope of these. Dean: these make a useful guideline. Anything in corporation spans both corporate bodies and corporations. David has not seen any evidence other than one thing that would move to its own module, which is profit corporations. Then anything that spans both of these should come under the same module. There are no overlaps in the present model. Some further analysis is required, but we anticipate being able to merge these two by merging CorporateBodies into Corporations, and deprecate CorporateBodies entirely. The content of that would migrate into Corporation.
This needs to be justified to the AB. We have that justification, we need to write it up. Elisa will have to help us write that up. CorporateBody and corporations now represent concepts that have been unified, where they were not before. So anyone looking at this from the AB would in any case be expected to ask why these were not merged, if we didn't merge them. AB members e.g. Sridhar would be very supportive of this, as it leads to simplification. Other AB reviewers might not. David will also walk through this with Rosario and get her opinion on how to explain this. Part of the justification is making the specification more usable for the user community, and simplifies implementation. This is in the scope of what FTFs are intended to do. Resolutions should be written in such a way as to include those justifications. There is another kind of user which is the business SMEs, however they should not see or care about what is in what module, so this refactoring doesn't impact on that audience. Another part of this diff review, is those changes in each branch which do not conflict with something in the there forks or branches. How to proceed on those? The above change which rightly removes complexity, will make the diffs harder to understand and follow.
Formal Business Organizations next. This depends on LegalPersons. And CorporateBodies depends on that one. This was started, but might not have been finished. This also includes JointVenture. There has been rearrangement of explanatory Note in JointVenture. This is followed by the addition of Non Governmental Organization and Non ProfitOrganiation in the BE96 branch. These are net new. Spreadsheet to have an entry saying to add these things. There is a JIRA ticket two. Are there others in that JIRA? Note there are Goals and Objectives ontologies in Foundations. There is a new property here called hasObjective. Did they reference the Foundations ontology concepts for that? No it is not. It should be. Objective also exists, as well as goal. In the Red FIBO broader framework there are also higher level concepts around objectives. There is PublicPurpose in LP, which is new. This was put under Objective. This is OK. These are all refinements of Objective. The JIRA ticket for bringing in non governmental organizations, should also cover the addition of PublicPurpose as a class. FIBO: Name change to ContractuallyConstitutedOrganisation. Do we need to track down every line number where this is affected? BE73 is the one to which the above objectives are to be added. On the name change diff above: when we say here's a JIRA ticket to change the name of something, this JIRA also covers all the changes to references to this, and references in the specification text if any. So the task for resolving this resolution will be to track down all the references to FCO to CCO.
We will start on Line 381 on BE96 next time. Dean and David will continue to work on this today, and will explain the changes to Elisa afterwards.
Decisions:
Action items
- David Newman David will also walk through this with Rosario and get her opinion on how to explain OMG changes.