2018-06-05 Meeting notes

Date

05 Jun 2018

Attendees

• Dennis Wisnosky

• Dean Allemang

• David Newman
• Elisa Kendall
• John Nowlin
• Maxwell Gillmore (Unlicensed)

Agenda

1) Use Case reminder

2) Where we are on our road map. 

3) Open Action Items

4) JIRA Issues Review - https://jira.edmcouncil.org/projects/DER/issues/DER-10?filter=allopenissues

5) Todays content discussion.

6) For next week.

Proceedings:

DN had a good meeting with CFTC person John Paul who really likes Semantics and FIBO.

DN to EK Have you updated the Unique Swap Identifier? EK We have the Financial Instrument Identifier. Need more work on USI and Unique Trade Identifier and some other open issues. Has done some, but blocked by PR's not going through. Tony says to roll back to a serializer that works.

DN, what about the  obverse of isIdentifiedBy? DN If we don't have the obverse of the inverse, then we have a situation where no identifier for a swap is materialized. EK, understand why SPARQL can't do this, but a Reasoner can. DN it seems to work in some cases and not others. Need to work out when to used explicitly or not. EK Could add Min 0 but then need to write up why for every instance. DN We can't expect that ever user will run a reasoner, or even a SPARQL query. EK For Financial Instrument , yes. But not for other classes like humans and some others. DN Where these relations are important for use cases for financial instruments then we should use Min 0 where a relationship might exist. 

EK We don't have the concept of a contractID. A Swap is not a financial Instrument. At least not all Swaps are financial Instruments. EK looks at DER and says that DN is right. All Swaps are Financial Instruments. EK needs to fix the OWL so that it imports IND and Swaps. Will make an about file that does this. 

Dean is working on the Serializer issue and running it again. Rolled back and EK PR is running again past point of failure. TC has all necessary rights to figure out the issue. EK is unblocked now. This will take some hours. No enhancements, but version 1.8 works. So, EK no longer blocked. Failure was at the isDefinedby links. Now it is running through them. Unblocked. 

Dean Would be ok to not update desk tops. EK has version 15 May. DA has 16 May. These and MB have each the same version. NO ONE TO UPDATE to TC latest version. We have in our process that when TC makes a Serializer change he informs DA. DA runs a mock PR and if it works, then tells all to update. If it does not work, then tells TC and TC fixes and then the process is repeated.  This did not happen for release 1.9. DA has no evidence that TC communicated the new version to him.

After the 4 current PRs run, EK will then re baseline. 

Riata working on DER-52 and 45. When this is done, then will move on. Level 2 LEIs and Sec and Equity  and MICs codes next priority. 

JN joins. DN informs JN on work agreed in the above. Particularly the idea to put in min 0 in some cases so that a Reasoner is not always necessary to have a reasoner for understanding. Reasoner ok for logical consistency. JN From CFTC point of view, the perfect is the enemy of the good enough. If a field is missing, can always follow up with the submitter. EK The challenge is to train people to NOT put the explicit into the ontology. DA If we see this as a maintenance issue, not a build issue, this makes sense. Putting all of the data in makes long term maintainability difficult.  EK Operationally production quality reasoners resolve the DN issues.  It marks those materialized as inferred. If we do this, then we get the inference every time. DA But can get inferences that are not important and need to then make those decisions. DN Then the choice is to "cherry pick" those where the explicit MUST be understood. Could annotate that the obverse case of the inverse is in the model. 

ACTION: EK will do an annotation in the class financialInstruments. Every FI will say, "don't do this".  DA This will be a deprecated label.

DW This is a FIBO anti policy. EK the policy for the identifier is that unless it has an intrinsic feature then implement the restriction. There are two policies that we need to consider when we create any class. 

ACTION:  DW to take these 3 statements and to update previous policy decisions for more discussion based on these. 1. Be as terse as possible - don't add content that can be inferred because it adds technical debt unnecessarily. 2. The definition of any concept should only include intrinsic properties, not extrinsic properties, so for example, if an identifier is not intrinsic to the nature of something, do not add x isIdentified by y to the set of restrictions on that thing. Because an identifier intrinsically identifies something, the inverse will be inferred. 3. If a concept commonly has some feature, but not always, and if that feature is required for common use cases, then one could add a restriction on the concept that is a min 0 value restriction to highlight that feature.

JN Can the ontology be looked at with the reasoner and without. DA Yes, but it is more work. 

JN Has made some progress in CFTC. Needs to talk about the project in the pipeline off line. Looking at several use cases. 

Decisions:

Action items

• Elisa Kendall will do an annotation in the class financialInstruments. Every FI will say, "don't do this".  DA This will be a deprecated label.
• Dennis Wisnosky   take these 3 statements and to update previous policy decisions for more discussion based on these. 1. Be as terse as possible - don't add content that can be inferred because it adds technical debt unnecessarily. 2. The definition of any concept should only include intrinsic properties, not extrinsic properties, so for example, if an identifier is not intrinsic to the nature of something, do not add x isIdentified by y to the set of restrictions on that thing. Because an identifier intrinsically identifies something, the inverse will be inferred. 3. If a concept commonly has some feature, but not always, and if that feature is required for common use cases, then one could add a restriction on the concept that is a min 0 value restriction to highlight that feature.