2015-10-20 Meeting notes

Date

20 Oct 2015

Attendees

Dennis Wisnosky

• Tahoe Blue

• Anthony Coates
• David Newman
• Mike Bennett
• Pete Rivett

Decisions

Decision: We will move Polity into Legal Person, and the rest will be in the Government Entities RDF which will be retained and moved forward on the proposal. 

Decision:  We do not need a JIRA issue to add Municipal entity.  We do need a JIRA to add Municipal Government. David will add a Comment to that to remind himself to make sure that Municipal Entity is also present in the go­forward ontology.    This is BE-97. 

Discussion items 

20151020 FIBO-BE FCT

Agenda: Identify the right content needed for submission to OMG for this release. That means no net new. Additional work will be addressing issues and any refactoring required.  See for example BE­96.  New new content can be added to BE Yellow as long as it is not a new ontology (guidelines, per Elisa); adding new ontologies would be a tough fight within the OMG process. Can only be done judiciously.  We eliminated one ontology called Business Entities that has generic content around business objectives, groups of entities that are considered companies or business entities. That material has been rolled into another Legal Persons ontology.  That is, there is a balance of when to keep the purity of the ontology intact (independent module (or ontology) versus folding material into an existing RDF file where the content doesn’t completely align, but the process becomes easier to manage.  So for net new material, if we can conceptually integrate the material into an existing ontology we should.  That is a change we can do going forward.  Another change is in the area of government entities. This was briefly suggested as a domain in its own right then reconsidered that and folded Government Entities back into BE.  Reason: initially we were going to have dependencies from Government Entities onto FBC, where there are statutory classes we would eventually build into government entities for e.g. anticorruption legislation (which casts the net wider than conventional government entity concepts. The proposal (from Pete) was to the additional material for anticorruption, as a separate plugin.  Therefore the core government related concepts go in BE itself.  This is currently a separate RDF file. The open question is to whether to keep this segregated, or if we need to fold the content into an existing RDF file such as Legal Entities.  We need to discuss this with Elisa in terms of the required OMG process, and potentially assistance in helping us get this through if we do decide to have it in its own separate ontology.  What are people's views: independent RDF file or fold the content into existing ontologies? 

MB: Makes sense to keep Government Entity as part of the general business entity context.  Government Entity is a kind of juridical person and also a kind of formal organization.  There are concepts including the gov itself, agencies, dept and instrumentalities.  That is the batch of concepts we are considering.  Polity: needs to go in legal Persons as this is a legal person, as is Sovereign which is a child of it.  Government Entity is a broader class of thing ­ covers formal organization, juridical persons and so on.  The requirements for what goes where in the type hierarchy, and where things go from a module / ontology organization. POV are 2 separate questions.  The real question is whether we can extend the scope of the ontology, not whether or not they go in a separate ontology. Having things in an existing ontology does not really address the question of whether we are adding scope and whether we are allowed to in the OMG process.  There needs to be a formal OMG issue saying that government entities needed to be added to the scope. 

What about Polity?  This is needed to support the existing class Sovereign and other future classes that are themselves kinds of Polity.  Re­addressing the question to Pete: Elisa says there would be friction if we introduced new ontologies but not if we smuggled those elements into existing ontologies.  Pete: this is not a written policy thing.  Depends on how the concept is introduced. There is more leeway in an FTF than there would be in an RTF.  If you do introduce something new, it's pretty arbitrary whether this is introduced as a new ontology or added to an existing one.  The question is, for government Entities ­ conceptually these are a set of constructs that all seem to belong together. Makes sense to package them in a Government entities RDF file rather than as part of legal persons.  GEs are not only legal persons but also LEI capable entities, formal organizations and so on.  The Polity question is separate from these others.  Pete: More important is the change to scope, not where they are put.  If there is a whole bunch of classes introduced the AB won't care if they are a new ontology or in an existing one. The real question is whether this is net new scope.  JB: economically it makes sense to include these.  The name Business Entities is slightly misleading since it covers more than just commercial entities.  Economic Entities would have been a better name. It fits into the general scope of FIBO.  There is more leeway since an RFC doesn't depend on an original RFP that would have defined its scope.  So we can define our own scope.  We should adhere to the scope statement of the adopted specification.  It is the declared scope that counts.  So if these are within the declared scope we are fine.  If these are in scope, an FTF can introduce more concepts, within that scope, to make the thing more workable.  Looking at the published Scope statement in the RFC document:  Can we also revise the Scope statement if we needed to? Yes.  "All terms relating to and or definitive of business entities and legal entities considered relevant in the financial domain [examples are given].  Also terms specific to trusts, ownership and control and so on. Entities defined not by structure but by role.  Including specific mention of government entities!  So these are explicitly in scope for the published BE RFC anyway!  So we can add these.  And, we can decide where they go in terms of structure. 

Decision: We will move Polity into Legal Person, and the rest will be in the Government Entities RDF which will be retained and moved forward on the proposal.

Polity is moved in order to avoid circular dependencies between legal persons and government entitie.  However, Polity has isRepresentedBy some Government, which does give it a dependency on GE anyway.  That might be a problem.  Sovereign has been renamed to Sovereign State, but means the same thing.  That means that Sovereign would also move into Government Entities.  We need to do impact analysis on whether Sovereign was ever previously referenced in other ontologies.  Sovereign appears in LEI Entities and in US Regulatory Entities.  These are in FBC.  LEI Entities has disjointed with Sovereign State.  (in existing FIBO not in David's branch). This is LEI Entities in BE in Pink.  There seems to be no dependency between LEI Entity and these.  Used to have Municipality and Sovereign in Legal Persons but it seems these have not been referenced.  There is a MunicipalEntity ­ is this a renamed Municipality?  There is a distinction in Pink between LEI Entity and MunicipalEntity, or Sovereign Entity, which seems to be a mistake. There is a radical difference between David's Branch and Pink.  We could introduce MunicipalEntity into the GovernmentEntity ontology alongside SovereignState (previously Sovereign and the other kinds of Polity.  Municipality is currently not in David's Branch as anything ­ it should be a kind of Polity along side SovereignState and TribalEntity and so on as the legal person that has the debt in muni deb securities.  We should add MunicipalEntity into Polity and add MunicipalGovernment into Government.  This is a gap otherwise ­ since there are many municipal bonds in the bonds markets, and the thing of which it is the debt is the Municipality.  This would not need an issue since this concept is already in Pink.  we just need to make sure that David's Branch reintroduces the concept that was in Pink.  We would not raise formal issues against David's Branch.  DN: What is in his branch over­rides what is in pink and therefore we should raise formal issues against what he has, as if it were Pink. Including the absence of things that are already in Pink.  The plan is that David's Branch is the go­forward ontology. There is no plan to merge this with Pink, this one would simply be taken forward as if it were Pink.  Therefore formal issues are raised against David’s Branch, as if it were pink.  The diffs would only be used to figure out anything that might have been dropped.  Some difference in perception between what Pete sees as the process between Pink and David’s Branch, and what David and Dean are planning to do.  JIRA needs to end up describing all the differences and the Beta2.  The diff will identify each of the changes.  Each such change needs to be described in a JIRA issue, however broadly.  The deliverable of the FTF will include every change between what is in Beta2 and to final go­forward ontology.  This should be against Yellow, not against Pink.  In the case of Municipal Entity, this may have dropped out.  Has there been any work in Pink that needs to be accounted for?  Elisa may have made some changes in order to support FBC. We need to identify those and make sure that the go­forward ontology does not break FBC.  FBC will also change to align with the new track for BE, as Elisa has agreed to.  So an additional diff with pink would identify and parallel changes that FBC might need in the Final version.  The JIRA issues need to cover every difference between Go­forward and Yellow (not pink).  Sovereign and Municipal Entity are in Yellow.

Decision:  We do not need a JIRA issue to add Municipal entity.  We do need a JIRA to add Municipal Government. David will add a Comment to that to remind himself to make sure that Municipal Entity is also present in the go­forward ontology.  This is BE-97. 

Other set of change (the only other sets) that we may want t make, is in naming of Ownership and Control constructs.  We want to make sure we retain a clear conceptual partitioning between ownership, control, so these don't cross wires, until we get to the intersection between ownership and control. There are cases where we have named controlling interest relations within ownership type constructs.  Within control itself, we can't say anything about ownership and vice versa for ownership.  Only when we have both, can we say things about ownership and control. We need to review those areas.  Is there any fundamental difference between the intersection, and use of the separate concepts separately?  Why not refer to them separately?  Clarify the question.  Should we have an ownership and control intersection (class) or not? Is there any separate or additional meaning for the intersection?  Yes! Because we can now talk about the relationship between ownership and control.  If we looked at control relations alone, we would see assertions purely about control without reference to ownership.  Likewise with ownership relationships we can’t imply anything about control.  Can then talk about how different levels or degrees of ownership can influence levels of control, and so we can talk more broadly about the relationship between ownership and control.  Ownership is something with rights and beneficial interest, whereas control has the concept of authority and power. Out of those two, the intersection is where ownership also includes control and vice versa.  E.G. voting share is an instrument that gives you both ownership and control.  For example different classes of shares would give the holder different levels of control independent of the beneficial ownership they give the holder.  PR suggests that a class of share can be modeled with reference both to the control and to the ownership separately ­ not clear what we gain from an intersection of the two.  Controlling interest ­ how can we infer that if we know about ownership but don't know about the meaning of control. So the intersection lets us make assertions that take into account the meanings of both ownership and of control.  If we only knew about ownership you can't make a statement about control. The intersection lets us make a statement about the inter­relationships between ownership and control. Can then make assertions about control as a causal relationship with the level and degree of control.  Model how ControllingInterst as a sub class of Ownership. We all agree this is wrong.  Should also maintain a clear semantic difference between controlling interests and defacto control, as these are semantically distinct. We need to make sure the labels reflect this distinction at least as clearly as the difference between ownership and control.  The mediating patterns that would define "Owner" and so on, we do not have time to do in this round.  What we do want to have is a number of concepts we can ensure are vetted.  There would be no net inputs to BE. We are allowed to remove stuff, e.g. the relative classes like Owner, Affiliate, Controlling Entity and so on. These would be removed from Beta1 to Final, in David's recommendation. Yes, FTFs can remove things.  We would need to add these in Version 2.  Also in Version 2, we can do more to derive controlling interests from issued voting shares.  At that point we would have the various classes of shares and so on that are the instruments by which controlling interest exists.

Walk­through of these control concepts in the model.  Control (per FND) has a definition, and is in a mediating pattern.  This links to Control itself, that is the mediating thing. And there is the relationship to the relative thing (the party in control) and the controlled thing (thing in a role).  This is broader than control of business, and is control in any sense.  The definition in Foundations is too specific as it relates to the management and policies.  Should be to direct the activities of a thing.  Raise a JIRA issue in FND.  Should be to direct the activities of a thing.  Control at its most general needs to be central both to de jure controlling interest and to de facto control, so it must be general enough to cover those concepts.  FND to work on the difference between the restrictions and the definition. FND will be introducing more meaningful restrictions based on capacities to dispose of, to direct the affairs of and so on, place of the current arrangement that bases it on some circular / displacement of concept on the isPlayedBy relation.  ControllingCapacity already exists an is what we would use for that. De Jure Control and de Facto Control should be kinds of Control not (as at present) kinds of Controlling Capacity. then Controlling Capacity itself is the range of the property that defines Control, kinds of control and so on.  This lets us define what is the meaning of control, in terms of capacity. New capacity in terms of governance, direction and so on.  Controlling capacity is where we ground out the definitions. There will be additional kinds of those, used to refine the differences between kinds of control and so on.  This is preferable to trying to ground the meaning simply in "Control" with its verbal definition trying to cover something.  The capacities themselves will be where a human understanding of the concept, with reference to Searle and so on.  There is precedent for these whereby we have legal capacities we used to define things like LegalPerson.  David agrees.  Pete questions what is the difference between Control and ControllingCapacity.  Mike will present the proposed completed ontology in Foundations, which will hopefulyl make it clearer how these concepts are grounded at the boundary of the ontology.  There are also sub classes of ControllingCapacity in BE, but these are the things we agreed should be sub classes of control instead. 

So there will be some changes in BE once the FND stuff is done.  We will look at that next week.  FND FCT will discuss these proposals in the mean time,  David will address many  to the outstanding JIRA issues in the mean time.

Action items

• Mike Bennett  Work on JIRA issue to direct the activities of a thing. 
  Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.