Date

21 Jul 2015

Attendees

Dennis Wisnosky

Decisions

Proceedings20150721 combined FIBO-BE and FIBO-FCB FCT meeting.docx

20150721 combined FIBO-BE and FIBO-FCB FCT meeting

Initial comments (DN): Good to come together and focus on commonalities, interdependncies, testing etc. between the BE domain and the FBC domain.

Being FIBO we would never want to launch silos, so it's important to look at the holistic view of the content we develop, that we have looked at and tested is from a multidomain perspective to the extend the use cases support that. We need to determine what are the goals of this, success criteria and meeting intentions. Goals that hopefully we all share. Hope to hear others' thoughts on this.

EK: Recollection fro DN' email, that his first concern is to get an overview from FBC of content. FBC has worked to derive concepts from BE and to test them fully. To that extent we believe we are aligned in terms of our goals. EK presents slides from 20150720 FBC FCT call, to familiarize David with the work and current state. These are also on the wiki in the FBC page. See Slide 2 in every meeting we run through the JIRA actions, look at summary of the spec and where we are, and look at the issues that are on the table for that week. Then we go through the content of FBC.

Includes high level financial instruments ontologies, and several functional

entities ontologies, which extend material in BE both from Functional Entities and legal Entities areas. See Slide 4 for summary of content.

DN: What do you mean by "to support definition of legal entities?

EK: The LEI ROC database, all the Fed Reserve databases and others, require specific address fields, so we extend the notion of legal registration address to include those kinds of properties.

DN: Whether some of that address extension material might be better positioned in

BE itself?

EK: If we were to move several ontologies, such as registration authorities and business registries, to BE then we could do this. There is a dependency - these are specific to a registry.

MB notes that concepts which are common to all business entities would ideally be in BE while concepts, e.g. registries where it is simply a company which is registered (e.g. Companies House of England and Wales) would ideally belong in BE.

EK notes that changing in this way would hold up delivery of FBC.

DN says we should think about where semantically a given kind of concept should

belong. We should have criteria for figuring this out. So for instance, if the criteria were such, the current disposition might be OK but the real issue is to have a way to determine where things belong.

EK: The elements defined under Functional Entities, all depend on the BE FunctioanlEntities ontology. Registration Authority depends on BE. Business Registries depends on Registration Authority.

DN: Not clear from this why the dependencies would drive us to having these concepts in FBC and not BE.

PR: Given that FBC is already there, even though he agrees with David's

recommendation going forward, it's too late to apply this to FBC. RB seconds this, DW thirds it.

MB notes that the same questions apply wrt Foundations, e.g. there are things in FBC which should really have been in Foundations. The motivation to have concepts where they semantically belong, is in tension with the motivation to have a clean OWL import path. When you add more axioms, you end up with unsupportable import paths, and everything ends up having to be in the most recent ontology you are working on. This will present a challenge when determining where concepts belong. For example Product and Service would belong in Foundations, however the concept of "Product" has some financial industry specific axioms, so these are rightly in FBC but wrongly labeled as merely Product, when there should be a more generic, archetypical Product concept in Foundations which has ONLY the axioms that apply to all product of every type. This is a critical part f the FIBO philosophy for interoperability.

Recommendation: Elisa will move all of Products and Services, and remove the Product Category and anything else that depends on BE out of Product and Services, and rename the module Financial Products and Services, and keep those in FBC.

Elisa would do that if Dennis supports this if there is a delay

MB doesn't see the need for a delay, if we do as described and with his team's

help.

PR notes that this has had a lot of good review of this material

MB: What is in question is not the accuracy of the concepts in FBC but their positioning within the broader framework of abstractions that makes FBO "work". If this can be done quickly, this is our window of opportunity to get this right. That is, we call this Financial Products and Services, and Products and Services with their core properties in Foundations.

EK: this requires considerable rework of VOM diagrams and so on, even if these are only name changes to make the generic Product renamed into a financial specific version of this. MB is on hand to help.

DW: We created this new ontology by making other ontologies smaller. Now are we asking to put them back? FBC is intended, as we all agreed, to have a common Domain for things that relate specifically to finance and are generic to the other instrument classes.

MB: Foundations meanwhile is all the things that are not defined specifically to finance, but are the archetypical concepts in their most atomic form. As such, FND does not refer to anything else these are the axiomatic concepts upon which the meanings of everything else is built on some o the assertions, such as Buy and Sell, belong as part of the archetypical definitions in FND. If we make the proposed changes, would it require an import of BE to FBC?

MB suggests we would not want to have the assertions that refer to BE in the foundations definition of Product, Service etc.

RB notes that this could end up being a refactoring where we end up saying the same things later, which makes for more work we should be careful of taking on such work without reason.

EK can move 3 classes, Goods, Service and Product. But, not Service Provider, since that requires a BE dependency. Service vs. Service Provider is a good example where axioms can be added one at a time.

RB: Suggests EK and MB can come up with a proposal.

EK we already have that proposal, which is to move those 3 classes. Does not see the benefit of making that change for minimal benefit. About a day and half of work to ensure everything retests properly. The change scope would still be in FBC as an addition to FND.

DW: is DN happy with what Elisa proposes? DN: Yes. MB also happy with this.

Decision: We need guidelines both for where we put things, and for determining what are the abstractions for which a given kind of thing is a sub type.

Action: What we agreed: these changes are minimal with MB's help. EK will create a new ontology with the new foundations concepts Mike was offering to do this but Elisa needs to do it for some technical reason.

NEW TOPIC:

MB: Where in FBC should BE be referring to things? EK: You shouldn't; FBC should be referring to BE not the other way around.

DN queries if there is something in BE that refers to FBC? For instance we have investment funds, investment companies. We should move TrustFunTrust from BE to FBC. So BE would have only the basic independent definitions of Trust. Meanwhile many of the forms that Trusts take, are Functional Entities, and should (all or mostly) be in FBC, given that they are participants in the financial system.

Trust in and of itself is a contractually capable entity that has no legal personhood, but is still an independent thing. Examples: Trust Funds, Trust Companies etc. that fit in the Functional Entity category, under Financial Services. Examples include Non Depositary Trust Company, which is a Functional Entity. As is an Investment Trust.

We seem to all agree that these functional entities that are framed as trust, are all in FBC.

DN: There is an opportunity for us to work together to determine what are the trust types or roles, functions, that now should belong in FBC. The relative things in this case would be in FBC. There may be cases where BE needs reference to FBC. David is concerned that such a reverse dependency might arise.

MB is confident it will not, but David makes the point that until we do this we don't

know if that will happen.

EK: How soon can we talk about Trusts with WF? Very soon, DN has met with the attorneys this morning and started talking about trusts.

DN: Next week BE session will look at the diffs and also will look at Trusts. There should be some low hanging fruit to move into FBC. Example where BE may need a trust: you can have a general partner that is the trustee.

MB: that is not a problem provided the Trusts a an Independent Thing not functional entity. So we need to be aware of the risk of reverse dependencies but if we keep a clear head we should be OK e.g. all legal forms go in BE, all financial industry specific functional entities go in FBC. SPVs must be in FBC.

EK: they already are, with detail.

NEW TOPIC

DN: Domain and ranges of properties that in most case should be Independent Thing, but in some cases appear in FBC as Relative Things. Sells to, buys from and so on, for example. We need to revisit the logic to make sure we are not reusing some properties both with independent and relative things. If we need to talk of buys and sells both from the independent and relative perspective, these should be separate concepts. Do we need both?

EK demonstrates an example where a relative entity provides the services that

Citi provides, and is insured by FDIC on a given date and so on, and has all the other features of it in its function as a bank, then has a buys and sells relationship. So we do need that property. We need something as a property whose domain is Functional Entity. This relates to where we already have buyer, customer, etc. in the PrtyInRole area. These HAVE to be distinct from the similar property that has a domain of Independent Thing. We must not cross these.

So we have a labeling challenge and a need for a new set of properties, built into the patterns for what kinds of relative thing can have these properties. This model comes directly from the party model that has been in the OMG for years.

DN: What's the connection between the buyer relative thing and the citibank as a bank functional entity relative thing?

EK: These are separate kinds of relative thing (functional versus party in role). In a transaction the buyer would be the relative thing that is the buyer. You would do that in the context of the data you would say that citibank NA is buying a product, and is purchasing from XYZ which is an investment bank and so on.

PR: Is Citibank na the holding company?

EK: No. We made all these inferences work, Needs one more property from ownership and control. Holding company is a functional entity, via financial holding company. The hasIdentytyof, that is Citigroup Inc. in NY.

Pete's question was, in the given example, if citibank is the buyer of the bond, you have citi as a relative thing and buyer as a relative thing. How are these related?

EK: If you use the buys property the reasoner can infer. Need a pattern high up, that shows how the relationship between the 2 kinds of relative thing stack up.

DWiz: SUMMARIZE

We need to ensure that what goes in is minimal an useful but we don't make

mistakes we can't back out of. While we know that OMG has a workaround for ontologiest hat is not applicable for other models, whereby a thing can be marked deprecated, this is still our goal for FCB and other ontos.

Action: Elisa will reconcile current BE with FBC because FBC uses BE Pink, but BE Pink has many differences between what we've been working on in David’s Fork in GitHub, complare to the main branch of BE in Pink.

Action items

Elisa Kendall
Action: Elisa will reconcile current BE with FBC because FBC uses BE Pink, but BE Pink has many differences between what we've been working on in David’s Fork in GitHub, complare to the main branch of BE in Pink
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
.
Elisa Kendall Mike Bennett : What we agreed: these changes are minimal with MB's help. EK will create a new ontology with the new foundations concepts Mike was offering to do this but Elisa needs to do it for some technical reason. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Dennis Wisnosky
Decision: We need guidelines both for where we put things, and for determining what are the abstractions for which a given kind of thing is a sub type. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Browser not supported