1) Use Case reminder.
2) Where we are on our road map.
3) Open Action Items
4 ) JIRA Issues Review
5) Todays content discussion.
6) For next week.
20160405 FIBO-BE FCT
Agenda is to discuss next OMG content submission. This is for June Orlando meeting. Could be all of E and all of K and maybe more. But, more possible is something much much smaller. Elisa has a proposal that DN likes.
Elisa thinks E is too big for now. Look at what K needs from E. What is the dependency? Not all related to liability capacity. Must be precise for an RTF. DN: Need to look carefully at subclasses of subclasses. Elisa: Deprecate that with nothing to do about Liability Capacity. MB: Could model distinctly the inherent capacity of how an org carries liability. Or, how liability of one organization affects another. That is, isolate how liability of one organization affects another. Strip away who or what isolates liability for now makes the model much more simple. This is what Elisa is saying.
DN: Attorneys talk about who do you name in a law suit and who do you drag into court. So BE defines unlimited liability on the corporation itself - that is on entity. And limited liability that is distributed based on how an entity is formed. The Protege shows these relationships. E.G., share holders can't lose more than their investment. MB: don't need to go that deep. DN shows examples where there are various partnerships that have very complicated liability capacities. Therefore, the model does describe reality.
DA: This is a peculiar relationship, but it is correct. MB: As long as it is clear that these properties are distinct, this does work. DN: Need to check that we tied the legal name to be the entity. MB needs to review to see what is related to the issue and what is not? DA: Wanted to avoid a huge proliferation of classes.
Elisa: Watch for stuff out of scope. Needs justification and maybe a separate issue. MB: Given the clear blue sky between these things, it should be possible to non destructively add the layer on top. DN: Needed to deprecate some abstractions. Needed to differentiate partnerships from corporations, for example. The structure now is much more meaningful. Need to curate to see what abstractions should be sure deprecated.
Elisa: just be sure that what is asked to be changed is justifiable under the resolution. Or, do a separate resolution, or do not include it at all. DN: leaning toward a proposal as small as possible. Elisa, willing to go broader if need to deal with a particular dependency. Maybe there are dependencies on FND or IND. Need to look at that.
DN: Has no band width for anything but the most simple changes. Zero time for enhancements to OMG documentation. If others have this, ok. But, DN has no bandwidth.
Elisa: Need DA and DN to propose the resolutions. Need work done for IND. Elisa will look at what she needs. Elisa and DA will go offline to see what diffs she needs.
MB: There maybe things that now need to be deleted. There should be separate JIRA issues for each to justify and review the change. If there is no time to do this. Don't.
DA: Liability resolution, Gov entity resolution - what does Elisa need? What are concepts that can be deprecated resolution. These are clearly distinct. Then, model changes should not be hard. Elisa and DA can do this.
Elisa: May not want to create an independent module. Instead, add an ontology to legal entities. DN: Depends on where we want to go in the longer run. Leverage Gov Entities for example as an independent module. Not have Gov Entities in E. Just K. Two resolutions under E and one under K.
DN to Elisa: What exactly do you need. Only E, not K. Then K is off the table for June, except for a small subset. Needs some Gov Entities - those that are jurisdictions. Needs to work with MB carefully to understand.
Elisa happy with most of Gov Entitles. Eliminate dependency on E. DN: Made changes to be clear what is a Corporation. Eliminated Company. Elisa: If I do K and add that naming, then there is an imbalance. DA: Make E follow K and E is more coherent. DN agrees.
MB: Could make more simple by distinguishing between assigner and assignee. Separate kinds of entities from what the entities do. Don’t do IS A. DN: A Polity is a juridical person, not a Gov Entity. MB misremembered what happened earlier that he had agreed with. MB: Now agrees except WRT to Gov Entity which he can make more simple with no IS A. DN: But Gov Entity is also a Juridical Person.
MB: Why not use Body, not Entity. Makes it more clear. Gov Body, not entity. DN: We could discuss this looking at what is going on in the world. MB: Discuss meaning, not the word. DN: "Gov Body works for me".
DN: Relative things add complexity. MB: says introducing the relative eliminates the need for duplication. DN: "Rename Gov Entity to Gov Body and call it a day."
Elisa: Need elements under Polity and maybe Gov Body to deal with FANNIE MAE and FREDDIE MAC. Needs to dig in. DN to Elisa: Pls look at this for next week.
DN: Some issues with LCC such as Country and CountrySubdivision seems to be in conflict with FND? Should we reconcile these? What if some user does OWL equivalent relations on these? The Reasoners go really really slow.
Elisa: LCC is an independent spec. LCC runs quickly by itself. We could do equivalents. But, slows down both HERMIT and PALLET. Stardog is fast. MB and Elisa: "This has nothing to do with a conceptual ontology." DN: Trying to grapple with FIBO classes and LCC classes.
Elisa: ISO3166 is LCC correct. FIBO is not. FIBO is more narrow. Pete: Maybe need a JIRA issue to align the two. Elisa: Could be done, but separate from the instant need described above.
MB to DN: Pls add this to the cross reference wiki. Elisa: DN and Elisa - Rem to separate E and K relationships. DN: Can't do anything till Elisa says what wants and does not want. Elisa on vacation next week. Elisa will make a proposal in an independent MS word doc.