2015-10-15 Meeting notes

Date

15 Oct 2015

Attendees

Decisions:

Discussion items:

Dennis reportback: EDM Council meeting in NYC very well attended. Was the coming out party for the DCAM survey results. Also the EDM Council now has175 members. New FIBO hats will be on order. Dennis also sat in on this morning's DCAM training session 45 people (sold out). Training material was high quality and well presented by Mike Atkin and john Bottega. We also expect to start seeing more EDM Council briefings on the West Coast in future.

Wiki question: where are the diagrams? These are attachments to the 10/15 Meeting Notes. The link to this is not on the page tree and has to be accessed from the list at the bottom of the generic "Meeting Notes" page.

Roadmap: OMG Dry Run for December will go through the process. Will pay attention to the use cases, of which we have 2 (schema.org and HMDA). HMDA Rule final was posted today may result in some changes. We will come back to these things after the dry run.

JIRA Skipped over for today. Today's main thing: review of the scaffolding / framework of concepts. Lynn has created some informal definitions of the scaffolding terms for comments. Comments will be taken down as formal issues so we can process them over the next few meetings. See spreadsheet. Material added to this spreadsheet to show similar or equivalent terms in MISMO, along with other context information and a column for comments.

Spreadsheet orientation. FIBO Domain identifies which of the FIBO domains the concept is native to. Loan means it is in Loans, and FIBO means it is in some other ontology or domain in FIBO. Needs to be updated with the actual ontology or domain name. This is intended to assist implementers in creating an ontology for a given use case.

Question: Is asset in Foundations? There are 2 concepts of Asset, Jeff asks for clarification on which one this refers to something owned or something else. The material in the "Plain English definition" is written by Lynn, to help people understand which is the actual concept in the upper ontology. Is Asset an accounting concept of a thing or is it something that is explicitly owned by someone these are both concepts that can be labeled asset. The definition here suggests the former sense, whereas FIBO Foundations uses the other concept against this term name. David: has Lynn been able to vet the pain English definition with the definitions in Foundations? No. Lynn does not have a copy of Foundations. Note that the concept defined in words here, is not Asset in FIBO Foundations, it is "Economic Resource "in FIBO Foundations (Red / future). David: the aim is to use the FIBO Foundations concept of Asset as a building block, and only subclass it if there is an extension to the meaning in Loans, for example using the MISMO definition and putting a line to where you got it from MISMO as a pointer. Then the process would be to decide when to extend such a concept. In a mortgage, Asset can be considered a collateral and could also be considered as borrower's reserves. These are separate concepts. There is a gotcha to look out for: you would only extend the concept as a sub class if it is really the same concept being specialized. Asset is a good example, whereby you would need to understand the concept before extending it.

On the specific example of Asset, see last week's notes. This illustrates the general question about how and when to extend concepts. So the other concept can be thought of as "Valuable Thing' i.e. Economic Resource. Mike Bennett - Loan: do we have an intermediate concept between loan and mortgage loan? So we can abstract up those concepts that are common, to the common layer? Yes see diagram. Jeff Braswell -To repeat/reiterate distinctions are clear.

Mike Bennett - Where are the areas that might be holding us back?. Lynn - One is the use of hasPart as a generic way to link things in a relationship to one another. Also some of the usages of hasPart does not seem to intuitively reflect the relationship it is modeling. Terms of a contract: in the Foundations model there is a property hasTerms which is used to reflect the terms and provisions, conditions etc. of a contract. So we should use the object properties that are intended to be more explicit representations of the relationship between a contract and its terms etc. (see Foundations Agreements ontology). This will be added as an issue to review and update the relationship hasPart in the loan classes. Foundations is the pattern, and this has been applied consistently in Derivatives, which we can look at for reference. Some of the uses of hasPart are other things that are not in Foundations Contract ontology, such as relationships to other things, processes and so on.

Q: In Derivatives, did they get into pretrade and the like? The other documents that come before and after the trade? DN: they started to look at these, but the immediate use case was closer to trade conformation, as per FpML. Have recognized the need for additional material on lifecycle events for the derivative. We will need to do similar for loan origination and the loan lifecycle and process. However, we need to prioritize these steps. Initial focus is on HMDA reporting. The initial concepts we need are the terms of the contract. Then the other kinds of concept e.g. lifecycle concepts can be added. Other members of this group have been thinking about these concepts and have put together some ideas in a datalike view, which we will look at next week to help evolve this picture. In this diagram, where "FIBO" is shown, this indicates that the concept is somewhere in the rest of FIBO. Monetary Amount: in FIBO already (actually 2 separate concepts). In some of the pictures we have seen, amount of money is a very general label. In the mortgage industry we give certain values names, which are countable as currency amounts. for example Asset Cash or Market Value Amount and so on. Also loan amounts, balance amounts and so on, which each have specific meanings. So where we have "amount of money" here, maybe we mean an amount of money with another meaning, for example being the value of something e.g. an asset, a balance, a payment amount and so on. These are measurements.

What is best practice in terms of connecting this currency type of field to the upper ontology while including the other business knowledge? DN: there are a number of concepts we would link to in foundations and elsewhere, which we need to walk through. Again, see how we made use of the structure of the contract in derivatives, as a model for loans.

How were the Contract concepts oriented in Derivatives? In Derivatives there are 2 parties to a contract, so we showed that a derivative is a contact which is a kind of derivative, and then a particular kind of derivatives e.g. IR swap contract, goes in a taxonomic (hierarchical) relationship with these. Then show the exchange of commitments between the contract parties, with HMDA in mind. Consider this as a pattern. A Loan Contract is shown as a kind of Agreement, but there are intermediary layers e.g. Contract, which we need to integrate with This lets us inherit the properties of those upper level abstractions that are already modeled. Saves time. So Loan, like Derivative, would be modeled as an exchange of 2 commitmnts. See blue boxes in this diagram which however are connected to the loan contract via the hasPart relation. So for instance a loan contract has to include an obligation to fund.

What do we need for HMDA? Can we identify 20 40 elements that we need for HM\DA and work out how to apply our common patterns with this? The original FIBO was top down because there were not specific use cases. We can use HMDA to enable a bottom up approach. Given we have what is effectively a new ontology from Michael Uschold we now need to work out how to attach it to the upper ontologies. Reminder: part of the weekly process is to remind ourselves of the use cases. Begin with those but remember there is an upper ontology to connect to. It would be good to know how these diagrams are generated and from what OWL e.g. is this link in to the existing FIBO or not? (No this was created prior to the session abut how to connect the concepts to the upper ontology). Michael and Mike B had a session this week to review the relevant upper ontology elements to connect to, so this process is under way. It would go a lot faster if we linked to the concepts that already exist in the RDF/OWL. As well as discussions per the MU/MB discussions noted above, it will also be valuable to actually open up Protege and create the relationships as needed. You would also be able to test those linkages by running a reasoner, and also be able to use test data. Looking at the Protege view of MU's ontology, this seems to be independent of FIBO. We have probably gone as far as we can with this model. Reminder of what we already said: when linking to a concept in the upper ontology it inherits the properties that are already there. Then only need to add those relations that are unique to the loan or kind of loan. Would also need to ensure that the definitions of the concepts conform with what we would want to extend from the upper ontology. This is why we have the written definitions in the spreadsheet. This is what will be reviewed. For instance looking at the definitions would make it clear what is a role and what is a kind of thing, and so on. For example we would know whether to make real estate as a sub class of asset or not, depending on the definitions of both real estate and of asset. Next steps: have an off line conversation about the idiosyncratic approach and how to get to the kind of paradigms that have been discussed here. Regard ontology as a kind of semantic data model. While this is happening Lynn will update the use cases. Meanwhile MU knows what to do, which will be a real ontology that ties into what we already have.

Would it make sense for people to understand what are the hooks in the upper ontology? Yes. See PowerPoint view last week, and subsequent work that Michael U will present on when he gets back. Then we would need to do the actual linkage and mapping. Once we know what concepts we need, we would then identify the required OWL imports. DN can help with this, in Protege. We also need to connect the more detailed content that is reflected in the spreadsheet, to the real ontologies as well. Users have having difficulty with importing because the URLs don't resolve. Has there been any movement from OMG on this? At present we would not be taking material from the OGM URIs anyway, we would use the pink FIBO which has the edmcouncil.org namespace. We should work only in the pink environment. This is challenge for those who don't have access to the pink models.

Paul K: have been trying to use the green FIBO and has found it difficult to evangelize for FIBO when people can't get it to work out of the box. OMG are working on this, which will help on the uptake side, but this doesn't affect our work in the FCT, where we must work in pink. We may also need to do some kind of tutorial for everyone. Would cover use of GitHub, SourceTree, etc. Also what if we release a seed version of what you need to do to have a base for what you need to work on for any given releae.:48 Also helping people bring FIBO into their own environments in a way that works. GitHub is virtually a universal standard for this kind of activity. You can pull it down from GitHub but there are things you have to put in place (SME’s, ontology etc.) Is access to GitHub only for ontolgists? No, anyone who requests it can have access to all the material in GitHub. Paul K will send an email about what specifically is causing them trouble using FIBO.

Action items: Any other comments or issues? None!

James Dean Cooper has additional thing he can look at between now and next time which will help us focus on the HMDA stuff.:

DN: there is a lot of good content in the spreadsheet, so we will want to copy and paste these into the element annotations for new elements we will add to the model. For examples adapted from: MISMO.

Is there a way to identify where a definition came from? Yes, there are standard FIBO definitions for termOrigin, definitionOrigin, adaptedFrom, and so on. These are in the FIBO AV. FIBO already has standardized usage both of the existing SKOS elements, and the FIBO AV extensions of SKOS and of Dublin Core. So there is not really a question of using other approaches to annotation in other ontologies. This is separate from the use of SKOS in the FIBO Vocabulary efforts. Here we are talking about how FIBO already has a standard approach to annotation, based both on specific SKOS elements and on DC.

Action items

Michael Review and update the relationship hasPart in the loan classes.
Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Former user (Deleted) S Unable to locate Jira server for this macro. It may be due to Application Link configuration. end an email about what specifically is causing them trouble using FIBO.