/
2015-11-17 Meeting notes

2015-11-17 Meeting notes

Owned by Dennis Wisnosky
Last updated: Jun 07, 2016Version comment

Date

Attendees

 

Dennis Wisnosky

 

Agenda:

Task report

https://jira.edmcouncil.org/browse/BE/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel

Proceedings:  

20151117 FIBO-BE FCT       

 

Update: David, Dean and Elisa have been working through the change conflicts(under BE­91 = David's Pink fork) versus prior work and common ancestor. Focus of previous discussion was on legal persons and LEI Entities. Next action would be to go through the diffs. Dean ­ cleaner / more up to date version of the diffs. These have been run subsequent to Tony fixing the issues with the serializer, with some exceptions. The ones on which the new serializer have been run are the ones we discussed last week. The only collisions were on LEI Entities and on Legal Persons, for work done since April.  For the others, there are no collisions but we will still need to identify the changes in each and ensure these are documented in JIRA. David wants to go through these results and make sure we did not miss anything ­that's today's meeting.

 

See wiki based table.  Will have a JIRA issue for every element.  Will then determine who will be assigned, status, dates for completion, creating the formal resolution for the OMG JIRA process. Q: JIRA issues per "Issue" (problem description) versus JIRA issues per element, which is not the normal usage of a change management system.  David clarifies that we will do some of both, thereby making use of existing JIRA issues that are on a per issue or requirement basis. Newer ones may be on a per element basis instead, thereby bundling conceptually aligned questions. Where there are multiple changes impacting the same class, these would be documented as different resolutions in the normal way.

 

Last time we covered Legal Person and were just getting on to LEI Entities.  Elisa and David finished LEI Entities last week. Will walk through this today. Difference statement: BE­91 is missing file for Business Entities".  This is because we took the content that was in business Entities and rolled it into Legal Entities. This has been done and Dean is looking at this in TopBraid.  Change statement change of name of ContractuallyCapableEntitiy to LEICapableEntity.  This was changed along with the definition. Also changed restrictions for LEICapableEntity.

 

In Protege:  Shows the hasLegalEntityIentifier exactly 1. This takes care of the open world scenario ­ even if we are not aware that an entity has registered and do not know its LEI, if it did have one it would be exactly 1. This came out of discussion with Elisa, Dean and David last Wednesday, where they confirmed the appropriateness of interpreting this in the light of the OWA. Do we have closure on this? Yes! Diff statement: missing namespace declaration. Things like this have been captured. (in the Wiki table). Where these are noted in the wiki table, these are things that would be included in the go­forward material. Not that "MunicipalIdentity" reference is not really a change in the ontology, it refers to the removal of MunicipalEntity not MunicipalIdentity. The actual element (not the typo) was moved from one ontology to another, not removed. The appearance of this in the other file would not show up in the diff. But we believe it was moved.  EK notes that if it wasn’t replace somewhere, it would need an isDeprecatedindication. However the note does show where it was migrated to. See wiki table. This will show as a net new item in the diffs. FIBO­BE_2 in OMG JIRA refers. Similarly Sovereign was renamed and moved. RegionalGovernmentEntity renamed to RegionalGovernment.  SupranationalEntity needs to be a sub class of Juridical person, and then LEI Entities would import LegalPerson, and LEIEntities would introduce the sub class relation for SupranationalEntity, as being a sub class ofLEICapableEntity. So those are 2 sub class relations? Dean needs to address access to the OMG Solitaire thing for JIRA issues.

 

PR: Not convinced by the decision about the OWA described above, for when something has an LEI. Had thought this should be max 1 not exactly 1. The justification for exactly 1, per Elisa, is that since we are calling this class an LEICapableEntity, and given this is a class which is intended to be given an LEI, and therefore in the OWA these are considered as entities which "should" have one. This would change the meaning of the class. MB notes that IF we now say we mean something different by this class, as being something that has explicitly been identified as being about to be given an LEI, then Exactly 1 would be appropriate. However, if we mean what the class originally means (some entity that is capable of entering into contracts) then the vast majority of such entities will never have an LEI. Under the OWA, we should only say what is always true even when we don't have the data to prove it We should not be reflecting what is not necessarily true.  So there are two concepts to choose between ­ do we mean something capable of having an LEI, or something which should? Or, we should have both concepts so that this conversation never happens again. Wolfe the CEO of GLEIF, was insistent that we reflect the exactly one. Resolution: create both classes, and figure out their names. Then put to Steffan Wolfe which class is the one he is interested in. David prefers that we do not add the additional class but use an explanatory note. David feels that having the 2 classes would cause confusion. Pete and Mike disagree ­ having both classes makes it a lot clearer what the intended membership of each class would be. For example Hypercube Ltd, is contractually capable but it not about to participate in the financial markets and would not ever get an LEI. David agrees to disagree and proposes we move on. We can remediate this later on. Elisa was not privy to the earlier discussion and agrees with Pete's assessment that if something is legally capable it should have max 1. Is happy we go either way as long a we explain the meaning of this class. We use this class all over the place where we had Legal Entity before. Some of those may not yet, or may never, have an LEI. Dean reminds us that the GLEIF chap feels very strongly that there is a class he cares about having exactly 1. Meanwhile for the many ways in which we have referred to something that is merely contractually or legally capable, should be a separate class that is also of relevance. We have done all the modeling work for both classes, all we haven't done is named it, or them.

 

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
David: Elisa to write up a good explanatory note on the discussion that Elisa and Dean and David had last week (even though Elisa now agrees with Dean and Pete and Mike). EK suggests that if you have a company that is legally capable but which would never get an LEI, then that should be defined as a Juridical Person instead. Calling something else, e.g. Legal Entity or LEI Legal Entity would be clearer ­ since we are describing an entity that DOES have an LEI. Or e.g. LEI Registered Entity. This class also needs to have the exactly one and the inverse functional.  Proposal ­ change this to LEI Registered Entity. All agree. We then choose not to mention the existence of something that is merely capable of having an LEI.  Meanwhile there will be considerable usage of the more general concept of something that can enter into a contract. So someone needs to do detailed impact analysis on this, and ether replace those references with reference to FormalOrganization or some other class that will always be true for those usages. LEI Registered Entity will definitely NOT be the suitable range for the properties that once referred to this. Or, some of those properties may need to refer to an anonymous union of legal persons and non incorporated entities of some sort.  Elisa and Dean will rename the class, look at all the references that previous used it and amend these to what they need to be now, and will write up the explanatory note.  This will the final dispensation on this concept or concepts.  

 

Next difference hasAddressOfLegalformation range change.  This is one where the changes will need to be made as a result of the previous decision.  This concept was introduced by Elisa, for specifically entities that have LEIs, to have an address for legal formation which might be different from their registered address. So this one, at least, would still be appropriate for LEI Registered Entity.  Discussion on whether for this property, LEI Registered Entity should always have one.  Should it be max 1 or min 1? Can't have more than one registered address.  David tests the inferences that follow from the way this is now modeled.  Max 1 allows for it to not be there.  So this is OK.  The range of this is already registered address.  However there was a change to the range of hasRegisteredAddress, in Foundations in response to JIRA issue on Registered Address as requested by this group.  This was to do with PostalAddress. RegistrationAddress was introduced in FBC and comes under PostalAddress, which was wrong (as the label suggested it included PO boxes). Action: MB to get back to this group with the proposed solution to the JIRA issue as proposed by the Foundations FCT, since this was resolved differently to what was expected (uses a range of physical location concept instead of introducing a more refined address concept).  Dean notes we have had a lot of feedback on how we use qualified cardinality restrictions.  If an object property already has the range, it becomes redundant to then have a restriction giving the same range.  Dean's proposal is to avoid redundancy that we would have by explicitly stating the range.  David suggests this is beneficial and at best harmless. When you generate the SKOS definitions for FIBO Vocabulary, when you look at restrictions, in most cases the restrictions have a range specified in the OWL, so you can generate SKOS relations right away from the restrictions.  If we removed that, you would need more complex logic, and we would have to know in the case of a cardinality restriction without the range specified, you would have to search for the range of that property, before you can determine what the concept would be in the SKOS vocabulary extraction.  Dean not convinced. The issue is how to interpret things that are narrower (bearing in mind there are no inferences in SKOS). However it is logically weird to do that. So Max 1 of some class could till imply any number of some other class. The range would restrict this but the cardinality does not. We would end up destroying some information when we go into SKOS. It would make the transformation more straight forward. 

 

Do we have a guiding principle here?  Is it a principle, or a guideline, not to include redundant information?  David prefers to err on the side of more expressivity.  Keep in mind that max 1 is subtle in OWL, and doesn’t exclude other things, but people who do not know OWL would interpret these cardinality a being exclusive when they are not. So that will not be clear to people to whom we show the OWL models.  Adding the extra information would be redundant, and can be inferred anyway.  Another concern is change management ­ if we decided to make a change where there is redundancy, we would have to make the change in 2 places. 

 

Dean ­ this is not necessarily the case. Gives an example. Also given the exercise on impact analysis for LEI Registered Entity ­ if we had the 2 concepts the change management becomes easier So in general, where there is seemingly redundant stuff, then for unknown future changes we will have made ourselves future proof, provided we started with the broader, sweeping statement.  So a change management argument can cut either way.  Redundant here means logically redundant (not rhetorically redundant). That is, any assertion which can be inferred. From a rhetorical perspective, i.e. explaining how the world is, something which is logically redundant may not be rhetorically redundant. 

 

Last item:  instrumentOf needs to be renamed to start with a verb.  Note this is the instrumentality of a government entity, as intended here.  This was renamed to meet our naming requirement.  See BE­103.  This work should be completed before the end of November.

 

Dean and Elisa and David will have working meetings this week to continue on the diffs. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Decisions:

 

Action items