2015-11-10 Meeting notes
- Dennis Wisnosky
Date
Attendees
- Dean Allemang
- Pete Rivett
- Elisa Kendall
- Lynn Calahan [X] (Unlicensed)
- Former user (Deleted)
- Former user (Deleted)
- David Newman
Agenda:
Proceedings: 
20151110 FIBO-BE FCT
We will focus on what net new content we want to document for the OMG submission. We will still require and appreciate subject matter expertise on these calls. The submission has to be completely done by the 1st week of February.15 Current focus. We are working through the diffs done between the current work in David's Fork, and the prior and parallel work in the Pink FIBO. Where there are conflicts between these, this group will determine which version should take precedence. We will look at each of the elements identified in the conflicts resolution file that comes out of the diff effort, identify what this relates to and either identify a corresponding JIRA issue, or if there was not one, we will raise a new JIRA issue. These are in the EDM Council JIRA. Some changes may have been described very generally in an existing JIRA issue, but we will create new JIRA issues for the specific detail of that element or change. Will assign to different folks to work through a given line item. Priority is terms relating to legal persons, LEIeligible entities. There is an order of priority, starting with the above. We will work through things in the order of priority. Items we do not get to will not be included in this release. Location of the diffs results file is on the BE wiki. Can we have this as a wiki table rather than an Excel spreadsheet? Here is a link to a wiki table. https://wiki.edmcouncil.org/display/FVT/Tool+Support+by+OWL+2+Construct21
If you go into "edit"on that page you can see how to create and edit these.
Pete Rivett: Here's the existing tool matrix https://wiki.edmcouncil.org/display/FVT/Tool+Support+by+Function+for+FIBO+Development
1st issue in this ontology: Pink and original are missing an XSD Base declaration. The note that "I should put that back in and try again" was for Dean to try. Will first get all the diffs back into the Serializer format. Has been working with Tony about that. The Serializer has been not putting the xsd base in. This is not a conceptual issue. Dean will action this.
BE91 net new change to add imports for 3 ontologies. In Protege: Looking at the David’s Pink fork version of LEI Entities that we are looking at. Dean has the 3 way diff set up on this (in Current Pink and David's Fork BE91). Question: Does adding these imports introduce any circularity? Dean has some tests for things like this see spreadsheet, row 1. That was for LegalPersons importing LEI Entities, which is different. That import in Dean's above, was spurious and needed to be removed (the ontologies were not being removed). That did not cause any problems. Status updated for LegalPersons.rdf row in spreadsheet. That completed the actions required on the first spreadsheet row (not delivered yet. Dean will do that this afternoon, now that Seriaizer issues are resolved). Back to the current issue. Business Entities, which is one of the 3 lite ontologies that needed imports, is being removed as an ontology. The content remains, but is somewhere else. DN suggests that we might not need the 3 imports. The things that were needed went to LegalPersons, which is already imported. Concern is that some circularity is created, since Corporation is a sub class of an LEI Entity. We do not need the sub classes of Corporation in this otology. Are there circular imports now? No, in Dean's version there are not. Need to look at what this looks like after the circularity is dealt with. This is assigned to Dean. Added a row to the spreadsheet about this. Summary: suspect these imports would be circular, but also are not needed and may be removed. No need for an OMG JIRA issue on this since there is no net change to that.
BE91: Notes that missing a file for BusinessEntities. But that RDF file no longer exists. Dean BE91 on GitHub did not have these dependencies in it, it just had these imports. We probably deleted this in David Fork since we knew it was going away. New line item added to spreadsheet for this. Next: (no number): "Pink added import for Countries" New line item in spreadsheet. Pete Rivett: Confluence table of the spread sheet created.herehttps://wiki.edmcouncil.org/display/BE/Actions+for+BE+1.0+FTF+Completion+for+Reston+OMG (Note: BE91 identifies David's Pink Fork as a whole). Review: How is Country used, is it necessary? Elisa: hard to understand what the differences are by looking at this. David not seeing ay kind of restriction in the BE91 material. EK: but you would have to look at the rest of the ontology to understand the potential impact. From David's understanding, it is possible we used to be referencing Country, but then we recast Legal Entity as LEI Capable entity, and then added Legal Entity back as another class. So that dependency may not be needed, since they don't have it in the BE91 material. Is there anything in Dean's 3 way diff that points to Country. In Pink, there will have been a merge request. Looking now. PR: We have LEI Capable Entity as a subclass of autonomous agent, which would not include sub funds, which are capable of having an LEI, but are seemingly not autonomous agents. So we are overreaching by saying that each LEI capable entity is inherently an autonomous agent. How would you categorize it? In general any LEI capable entity would also be mixed in with the kinds of things it is, e.g. Corporation. Question whether sub organization is really a kind of autonomous agent depends how tightly we mean "autonomous" at the top of the model). Also subfund is regarded as a kind of organizational sub unit it's not autonomous in the broadest sense but is modeled as a kind of organization sub unit. Funds in general cover several discrete concepts: the pool of assets, that is the fund (or in this case the organizational sub unit) and the tradable unit. Should we define Organization sub fund as simply a kind of "thing"? MB: No, everything must be a kind of something. We should be able to frame this as an organizational sub unit, but if we want to mean something other than that, we have to say what it is that we do mean. PR to raise a JIRA issue to go over this. Refer to draft Funds (CIV) model to see what kinds of things there are and what kind of thing is an organizational sub fund. So far everything that can be given an LEI is a kind of organization so far. If Pete is suggesting that sub fun would need to be e.g. a kind of relative thing, does that mean these are potentially the kinds of thing that can have an LEI? What about relative things for instance? No, per OFR and others, it is necessary that something which is given an LEI is a kind of independent thing. So it is likely this would be an autonomous agent, as defined here. The fund as a thing, with its legal personhood or organizational nature, is actually distinct from the management company, which is a separate company with a role in managing the fund (see CIV model). Raised as
BE102: Added line item. We use the term Legal Entity, but don't have a corresponding definition for LEI Capable Entity need to update the definition and annotations(!) Back to the Country import: Pull Request 175 in June 11. (written on June 4).
Pete has now updated the table so we can move across to that from here on. See link below Pete Rivett: https://wiki.edmcouncil.org/display/BE/Actions+for+BE+1.0+FTF+Completion+for+Reston+OMG.
To insert a row, click "Edit". a toolbar will appear. This has icon for inserting rows below or above.
To Dean's screen: Addition of the import of Countries into LEI Entities. Elisa June 4 note for the above Pull Request. Covers the revision of Sovereign to Sovereign State, which is still the legal entity corresponding to a country. Also added Regional Government Entity. The motivation for adding import of Countries to Legal Entities was to be able to talk about sovereigns and their sub entities. These are now in Government Entities not Legal Persons. We were going to have Sovereign and the new Polity class and the siblings of Sovereign (as a legal entity) in Legal Persons. However, these were instead moved to the new government entities ontology which imports Legal Person. So which one now needs to import Country? Government will need to import the ontology in which country is defined, which is as a geopolitical kind of thing . Therefore LEI Entities no longer needs to import Country. So this dates back to when LEI Entities had more content. As we created more specialization in the other ontologies, this no longer holds. Dean concerned hat we have approved an actioned a pull request in June which we would now be reversing. Elisa and Pete should advise: Do we simply go back and retell the history, or should we track the change and reverse it? EK: the resolution that made this change, that was approved with the pull request, so that we could implement it in FBC, and was also posted to the OMG site but never voted on; that resolution can be modified. However there is a dependency in FBC, since the relevant concepts were moved to be part of LCC, the other OMG spec). Elisa: somethings are already implementing. So we have to have he paper trail to tell those people using it, why that is changed. That might not effect people if they are using the whole import tree, given they will still be seeing country. So it might not impact their implementation but it might, and so they need to understand the changes. Also we are not changing the meaning of anything. Example: if Elisa is working in FBC and depends on a namespace declaration for a given element, then her Model will have the old IRI for that element. So things which have moved will break the contract for the IRI. So we have to document why that IRI has changed. Assign to Elisa? No, this is a joint resolution she needs Dean's assistance on. Does not have ay of the ontologies, only the VOM files for what there once was. Dean will be in SF in 2 weeks, we can do this as a face to face effort then. Has 7 hours set aside for FIBO on Monday 23rd. To be confirmed depending on Elisa's logistics. The outcome of that meeting is to take the two issues and work through the required current state and document the resolution. Will also require David in the room.
BE91 default namespace to get rid of. This is not in the ontology. This is an artifact of something that someone did in Protege. Action is on Dean to get rid of these systemically. This is not a conceptual change. Everything should have the standard FIBO namespace arrangement.
Another line entry added for LEI Capable Entity to make sure definition refers to the right thing (as per the note made in passing above). This now has its own line entry in the spreadsheet. Why is this a new entry and not coming out of the diffs? There is no OMG reference in yellow to LEI Capable Entity as this is a whole new class. Probably need to change the name of the term. It was Legal Entity. We should be aware that there was a separate class in the original submission that was a relative thing. From the diffs, it seems that Contractually Capable Entity appears to have been changed to LEI Capable Entity, whereas in fact what happened was that Contractually Capable Entity, a relative thing was deprecated. And this other one was added. That was in the model as recently as April 6. So we need to document the deprecation of the relative thing that was jurisdiction specific "entity being recognized as being contractually capable in some jurisdiction".
Dean recommends that all the items relating to LEI Capable Entity its introduction, the deprecation of the earlier class, all into one line item on the spreadsheet and one JIRA issue in EMD Council JIRA. MB explains the original rationale for the relative thing above. The deprecation for this is part of BE91 and the rational for deprecating that relative thing needs to be included in the rationale. Since we don't have persistent IRIs or UUIDs for any of our entities, some of Dean's comments were based on a assumption that was incorrect what actually happened was the deprecation of a thing and the creation of a new things, whereas the diff rightly identifies this as a renaming of a single thing. So the line entry in the Diff that says "Contractually capable Entity change to LEIEntity" is incorrect. This is now 2 change. Somewhere around JIRA 74 or 75 there is likely to be a JIRA issue documenting the single change whereby that thing was removed. We need to retrieve the rational for deprecating that element. If that is not in a JIRA ticket, then whoever was involved will need to recall why they deprecated that element.
Next: There are also a number of restrictions, that would be separate items these are now also bundles under the LEI Entity matter, as they are logically the same matter. Looking at it in Protege, these are the restrictions on the class called LEIEntity. For example the cardinality for the number of LEIs a legal entity gets. That is documented in another specific JIRA, with much discussion. For example that it needed to ales to be defined as a functional property (see lastweek's discussion. The gist of it was we wanted to say that an organization which is LEI capable may either not have an LEI, or have one LEI. So if it has one there must be one. Hence Functional. (and / or inverse functional). Doing both gives you a mathematical rejection, which is correct. (meaning that the 2 sets are isomorphic. If anything inverse functional is more important, since each LEI can only refer to one entity. Even if there were duplicates for the entity, (which we won't allow), the identifier may only ever identify one entity. This sums up what we agreed. What about isIdentifiedBy min 1 Organizational Identifier. What about mergers? The original LEI can be exported. So for Organization Identifier more generally, it is possible to have more than one, typically one from each of a number of organization identification schemes, for example dunns umbers tax ID, company registration numbers and so on. These would all still be inverse functional, but not functional. Would "some" be suitable? No, Some means "must be some" How would we code this one to be potentially zero or many? There is nothing we can say about this. We can say Min 0 given our usual operational meaning. Can we even do inverse functional? If 2 schemes then only the combination of the code in conjunction with the scheme, is inverse functional. A code on its own, cannot be guaranteed not to coincide with the code in another scheme for the same organization.
isIdentifiedBy is in FND. Would hesitate to imply that isIdentifiedBy should be inverse functional. To be addressed by FND. EK suggests it is not inverse functional. Invite Dean to the homework meeting where we consider organizational identifiers. There are question marks against some of those restrictions. Dean and David to discuss these later today, including restrictions that can be zero or many.