2015-09-15 Meeting notes
- Dennis Wisnosky
Date
Attendees
Decisions
Discussion items 
20150915 FIBO-BE FCT
JIRA Updates
BE7 Affiliate refactoring - Still pending. Requires completion of ownership and control.
BE33 allValuFrom in min cardinality restriction in Executives (Pete is assignee). Pete already did the change and submitted pull request. Elisa disagreed with the change and it was rejected. This was because this was not what was in the VOM model. The VOM model didn’t seem right but that was improper representation, not the modeling logic. Given the choice of two solutions, Pete's change was the opposite to the change Mike made in the model using VOM. Need to determine which of the two types, the restriction should be in OWL, and make that change in VOM. Elisa doesn't remember what it was in VOM. David's Protege shows min 1. If Mike changed it to allValuesFrom, we now feel this is wrong. It would be OK to have it as someValuesFrom. We learned yesterday that this is logically equivalent to min1. So the action is to change it to someValuesFrom. This needs to be changed in the formal Pink, not in David's branch. Pete's pull request was to change this to min1. Resolution: change to someValuesFrom. PR: Should this not be min 0 given the comments against allValuesFrom. EK: Every company must have some company bylaws, so someValuesFrom would be appropriate. Company Law doesn't imply that it is only company law, since or example company law could also say you have to comply with all regulatory requirements. Hence someValuesFrom is safe. David will commit this as part of BE33, resolve and move on. Does Pete need to change his Pull Request. This is in a JIRA issue specific branch. If that branch is changed, the pull request can be honored for that change without pulling the rest of David’s branch. Then David can do a pull request into his branch to get that change back. David's branch has other differences e.g. the name of FormallyConstitutedOrganiztion. David wants to pull what's in his branch for all of BE, into Pink. Would like to develop some interim steps to get these aligned. Conclusion: the change will be made by Pete in the JIRA issue specific branch for this JIRA. Status: Resolved given the above pull request against BE33 branch. DONE
BE42 Registered address v postal address. Proposal is to make it a child of Address rather than of PostalAddress. The editorial notes describe both a physical and postal address, and refers to the international standard for defining postal addresses. Why should registered address exist as a class and not have the property that is a relationship to the kind of address. The reason is that Elisa needed something that was a physical kind of address at which papers can be filed. This would be a real address rather than a "Postal address". Since then they have added kinds of addresses in roles, but modeled these as independent things, which MB asserts is incorrect as these are addresses in roles (relative thing). The property for hasRgisteredAddress is already there, and the restriction can be tweaked to say hat kind of address the registered address is, i.e. physical versus postal. EJK: hasRegisteredAdress can easily go away as it is only used in BE. Used in FBO and in LEI as the areas of legal formation. Elisa's team didn't like it in FBC as they needed to define things in terms of their kinds of structure, for example they created registeredAddress in FBC and ignored the class called RgisteredAdress in BE. Then RegisteredAddress in BE as a class can go away. DN: it seems meaningful when you look at a business entity, that the question comes up about what is the registration address. They did the change in FBC because they needed things like address line 1 2 3 4 and city and country code and so on a they needed it in FBC but they did not have time to file proposed changes in BE. Also there was a dependency on the concept of Registry which is also in FBC even though it was not explicitly financial. However BE does not import FBC. DN: still needs as part of BE that something has a registered address. If we want to avoid circular dependencies, we have a challenge here. We do want to specify the areas of legal formation and tie the registered address to the origination without dependency on FBC. If we were to only have financial specific terms and not things like registries, then everything else would need t go in Foundations. There is nothing explicitly financial about companies registries. For example when the company registers with the Secretary of State (in the US) this is for tax purposes. However, for artificial legal persons like a limited liability company, they register directly with the companies registry. Aside from a sole proprietorship, all companies in e.g. CA have to register with the Secretary of State who gives you a license number. DN says the direct interface for the entity during its formation is via the Secretary of State. This is not the case in other jurisdictions such as England and Wales. Either way, you have a Registered Address. It would be a gap if this was removed from BE. Elisa needed additional stuff for FBC and so this was one of the reason we needed FBC. This is now a done deal. MB is disappointed with the scope management we agreed a need for BC, but not for it to be a catchall for stuff not unique to financial instruments. It's a done deal now FBC is being submitted ahead of BE. Meanwhile BE can use a plain vanilla address, which can be specified in FBC. Or in BE there is still an address class (in Foundations) which can be specialized in FBC. David is OK removing the class Registered Address, but the property hasRegisteredAdress is still meaningful and is a vital property of those business entities that are registered e.g. limited liability companies. If we take that away we are removing something that is a necessary condition of a contractually constituted organization. Would be happy to delete Registered Address and make it some physical address. Mike is happy to split Postal Address into physical and postal addresses. Elisa can help identify the best label for US English. Informally the concepts are what we might call street address and post office delivery address. Foundations FCT will work on this in the next session. Now the capacity to sue, not the capacity to be sued, which already exists. David can help Mike with this. Elisa can do it. Why can't Mike do it in VOM" He can, but Elisa still needs to do some reformatting of the headers. We thought the headers business was behind us? Apparently not, according to Elisa. The Serializer is not installed in the process. However, Dean said yesterday that the serlializer has been got working, and can now work in peoples own forks. Agree change. Change can then be made in Protege or in VOM. David can then use the change right away in his branch of BE. This does not depend on the change in VOM with the headers. Mikes team will agree the change on Friday and write out the detailed JIRA issue resolution in RDF, in VOM and in spec language, and will let David and Elisa know what the change is. Elisa would do the VOM model change once Mike's team have agreed the changes.
BE44 complete (mediating patterns) - BE50 is partly linked to this, here we want to make some of the names for sub properties for ownership and control more precise and relevant. Will come back to this group with proposal for naming changes for some properties. Change wording from Lattice Patterns to Mediating Patterns. Does EK have any dependencies in FBC on Ownership and Control? Yes! BE44 is a large change. Will impact FBC significantly. Also impacts IND. Dean and David did search all the their domains to see if there were dependencies and found none for ownership and control. This was some time go so they will look again and will revert to Elisa with any impact they find that would need to be reconciled and retrofitted. Should not prevent us moving FBC forward using ForallyConstitutedOrganiation and can rename it later to the new name. This is used in e.g. registration authority and so on. There are several places in FBC that refer to the concept and so the new name of the class can be referred to from those FBC ontologies. This is manageable. Need a single issue on the renaming, so that FBC doesn't miss it. Then Elisa can reference that issue for making the changes. This needs to be a ingle OMG JIRA issue with a single resolution that can be referenced in the FBC Report as to why it changed. Does EK have any dependencies in FBC on Ownership and Control? Yes! BE44 is a large change. Will impact FBC significantly. Also impacts IND. Dean and David did search all the their domains to see if there were dependencies and found none for ownership and control. This was some time go so they will look again and will revert to Elisa with any impact they find that would need to be reconciled and retrofitted. Should not prevent us moving FBC forward. Can put a placeholder right now as a JIRA issue (EDM JIRA) that certain labels will be changing in BE that will later require renaming in FBC including contractuallyConstitutedOrganization and others. Others can be added as notes to the EDMC JIRA. Are we changing the URI? Yes. When we say we are changing the label, here by label we mean the IRI not just the RDFS Label. This is the name of the concept (what we mean by the word label here). In English this is called a label. Not the same as RDFS Label. EK asserts that this would be a destructive change. Also we can't change PostalAddress we have to deprecate it. The reason is that the IRI is a formal identifier that people would refer to, so it's clearer to deprecate things when we rename them. For PostalAddress we might want to deprecate it, or we might keep the same IRI against the existing concept and add the more refined concept with its own new (non destructive) label. Once David hears back on Friday, we can update this issue with a resolution. Have to attach the updated VOM model and the updated RDF before the EDMC JIRA issue can be closed. This is why changes to the names of things need to be documented. And, people need to be able to vote on whether they like the proposed change. That's why we discuss these JIRA issues in this FCT meeting, to reach consensus on the changes. However, we really need to get bankers on BE. David will talk to Mike A to recruit more banking folks to participate on this. Attorneys are participating off line, via Wells Fargo legal. There is also a foundational data group in Wells who are looking at this and reviewing FIBO (DN Branch? No, the parts of pink David has pulled in from FND, IND, FBC, plus David Newman BE Branch). Was not able to integrate the David Newman BE with the Elisa Kendall FBC (now formal Pink FBC). Can't integrate these because of the conflicts with FormallyConstitutedOrganization. Has to temporarily go in and locally on David Newman FBC change those 4 classes to ContractuallyConstitutedOrganiztion before it even loads. Have we justified the name change? This was discussed in a prior BE session, after MB and DN worked on this and made the recommendation. This is FIBO-BE / BE-74. Any change with a downsream impact on IND or FBC has to be documented so Elisa can do the reconciliation. This has significant impact on the spec as every diagram that has the old class has to be regenerated. So name changes have to be justifiable given their impact. How easy is an RFS Label change without an IRI change? Much easier, but still requires regeneration of diagrams. The reason for the name change was that FormalOrganiation and FormallyConstitutedOrganiation seemed to similar to David, and it made more sense to reflect the meaning in the IRI name, i.e. ContractuallyContitutedOrganiztion. The correct approach to such a change is to rise the usability issue whereby people might be misled by the name and not know how to use it. words: "In order to improve usability". Otherwise there is no visible justificatin. David will include this wording in the JIRA issue. Also that this was seen as highly important fr some users in the banks. This kind of change can't be done once FTF2 is complete (i.e. Final)
BE52 Rationalization of BE. Dean: Thisis to do with the diffs against FBC and others (prior version). This includes the discrepancy between FBC and BE described above, on the name of FormallyConstitutedOrganiztion, among other differences. This JIRA relates to the diffs. Each difference that is coherent will result in a resolution. Then we can apply he changes systematically so people who review the spec can see what words, definitions, etc. are changed. This is a catchall JIRA to do the world. Will the same JIRA issue have a resolutions describing the changes? No, each change will be its own JIRA issues, as it should be. Depends on time availability for Dean. David will try and talk to Dean today and get updates for next week. Recent JIRA issues.
BE70 Political and Governmental entity. Needed for a significant use case for financial industry, for anti bribery and corruption. Requires us to define what a government entity is, and needs us to derive general definition of government entities, and a more extended statutory plugin for governmental entitles. There is a very extensive set of definitions of what government entity is, in these laws. These cut across different countries. UK, Canada, US all have statute on this. Would be great to get perspective fro Canada (Igor) and others. For the US we have examples from Wells internet. Wells bases their definitions for what a government entity is, on a wider set of constructs. See definitions.uslegal.com which has very US centric definitions (and assume that the country in question is a federation). These need to be reactored. The definition from the bank id different to the above US definition, is based on the relevant statute, and is vastly broader. Includes companies of which the US or a non US government has 40% or more of voting stock, along with other men of control (e.g. electing people). So this is much broader than what's generally regarded as government entities. As we've seen before with regulatory definitions, this is much broader than the generally understood meanings of the concept. This is expected (an not a criticism) for any government regulation these necessarily throw the scope of what they cover very broadly, which is why thy are not a good source of meaning. It would then be possible to have sub classes in a plugin, for specific regulations. That would be Governing Entity from the PoV of a particular type of statute. These extensions would not be subclassing, they would need to define unions of the real world concepts they are interested in. Are we saying that NGO is a government entity? That is specifically absurd! Also things like political parties are in the union of things embraced by this specific law. Does this mean we can't model those things in FBC? Do we have to move the ontology? If yes, FBC can't move forward? This is too far reaching. FIBO needs to find an expressive way of helping banks figure what entities banks need to understand to manage corruption. This is clearly jurisdiction specific (and law specific). These need to be a union of the more concise concepts. The point is not that this must be in BE, there are other ontologies that need to know what a governmental agency is. FBC can provide the relevance also. DN: Or as a minimum we create a new sub directory in BE for Government Entity, but perhaps Government Entity could be another domain that includes BE and FBC, as there are parts of both that we will need for governmnt entity. May need to elevate this to a higher level. David has this written up see slide in today's deck. We probably need something that would emerge out of this that might provide a union of BE and FBC and might import both. May be a requirement to append something to FBC. Need to spec that and what it is used for and what the definitions of these things are. Then FBC FCT an look at it. This is all under BE70. David and Elisa may meet off line to talk about this further and see if it needs a change to FBC or BE. How to solve the problem? 1. write down the problem. A thought: pull this out f BE, put it into something else call it e.g. GE, that pulls in BE and FBC. Either way, the roadmap shows this as being in the next phase and not part of BE 1.0. Either way the roadmap is OK.