2017-11-28 Meeting notes
Date
Attendees
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/FCP/issues/FCP-4?filter=allopenissues
5) Todays content discussion.
SMIF OWL-UML
SKOS
RDF/S
6) For next week.
Proceedings:
Elisa has made changes and will attempt to commit DER 31 today. Remainder depends on EK and MB working together on relationships between Product and Financial Instrument. DN would like this today so that DA can update the DD file. EK needs time with DA to accomplish this today. DN doing demo Nov 29th and would like to have this in the demo correct for interest rate and currency. EK That piece is correct in GitHub. Then Dean can use this. It is fixed. Will be done today.
ACTION DA and EK today to do the above.
DN to EK What is next to do. A bit with Trades. DN Excellent Elisa.
DN When we see certain elements in aggregations and want to do analytics do we have all that we need to show decomposition of all elements of a report? Has EK done concrete examples Sith individuals? This will be very important to auto generate reports. Need this for use of FIBO operationally. Don't need complex math.
EK shows that FND has the notion of "an expression". For example determining the employment population. All of this is in FIBO Protege. This is used in FIBO IND. There is a lot of math in the model.
Jeff B There is a big opportunity here to derive much what is already in FIBO. EK Yes, we have tested this with BLS.
EK OWL is not the best language to do complicated math. DN Yes, don't expect OWL to do the calculation, but if we have the formula then we can execute the calculation in another app. Need a lower lever of precision than we now have to do complex non OWL math. EK Lucy Opstnik did much of this work. DN to EK it would be helpful to have a math ontology in FIBO. Perhaps Jeff could help.
Jeff FIBO + ACTUS algorithms + scenarios/monte carlo/risk assumptions => multi-scenario, forward-looking events/cashflows => results data lake => regtech reporting and aggregation. Calculation schedule can be produced with current contractual parameters + instrument algorithm.
DN to DA Need labels and definitions for the predicates. DN doing this manually now. Need RDF labels automatically.
ACTION Dean.
DN runs a Fixed Float query. Missing Interest calculation schedule. DA This needs an annotation as one of the properties that should be kept. DN We are also not showing inheritance. ACTION DA can add this in one of two ways. DN it would be good to have the option. DA Yes but the properties will be seen again and again and again. Will need to be filtered by user. DA will do it this way at least for now.
EK The underlayer is inherited. DN Why would it be a concrete element in the DD? EK This is part of chain of properties. DN generated as part of an annotation. DN We will need to let DA know when to use Cardinality. DN asks JN what he thinks is important. JN Yes it is important. Helps to tell what exactly the viewer is seeing. Will answer questions right tup front.
ACTION DA to generate cardinality as a label the way that CCM does this. DN could generate as a prefLabel. DA Where would the label "has exactly one principle" go. Would be ugly. Would need to reify and that is not good. DA could generate new properties and put the cardinality on them. This is like FIBO-V works in DN's version. This damages the semantics of the output model, but that does not matter in this graph. Could link back to the original. DN Could be sub properties of the original properties. DA will put them all there and conserve a bit of the semantics. Then the query can sort it out.
DA 1 add cardinlaiies. 2 Bring in inheritance through subsumption hierarchy. 3 Figure out hasInterest Calculation schedule issue. DA will preserve the original subclass structure. 4 Materialze inherited relationships as separate triples/erited relationships as separate triples
DN and DA A question is will this be only a DN product or a general FIBO product? DN This could be a data access inventory catalog.
DN Still struggling with interestRate observable. EK The interestRate deliverable in FND and in CFTC spread sheet has this at a higher level. DN What do we need this? Jeff explains that it is because it is a classifier of the contract. There are many different types of underlyers. DN If this is not derivable then it makes sense.
Jeff Look at ANNA Derivative Service Bureau ISIN classification of derivatives.
Decisions:
Action items
- Dean Allemang 1 add cardinlaiies. 2 Bring in inheritance through subsumption hierarchy. 3 Figure out hasInterest Calculation schedule issue. DA will preserve the original subclass structure. 4 Materialze inherited relationships as separate triples.
- Elisa Kendallr Complete the Der work and commit to GitHub. Dean Allemang Honor the pull request and do the work that DN needs for his demo.