Date

10 Sep 2015

Attendees

Lynn Calahan [X] (Unlicensed)

Decisions:

Discussion items:

20150910 FIBO-Loans FCT

https://wiki.edmcouncil.org/display/LOAN/FCTLOAN

Subject to comments by email, this meeting will move to Thursdays at 3pm Eastern Time beginning

MeetingDeck09102015.ppt

JIRA Issues LOAN15 Roadmap is in progress. JIRA issue remains open for now as we intend to supplement with a finer level of detail, OR close this one for having actioned this and raise a new JIRA for the finer tuning.

LOAN16 This is a reference to using the new process and collapsing the 2 meetings and working through ur process of having diagrams for the group to see that integrate to the actual OWL ontologies. We are still working on that remains open. This relates to the balance between showing views that are comprehensible to business experts in the group, and what corresponds to the OMG submission ontologies. Agreed this remains open.

LOAN17 Perpetual notes. Open action on Jeff Baswell. Technical review? Backed up a bit to look at the bigger picture. Need to get a sense of how these things fit into the larger whole. Michael U has been working on that. Once that is done, will rereview the HMDA etc. use cases with this group. Will then look to hang the detailed concepts for HMDA etc. to that new scaffolding.

Slide 10 Michael U presenting on the work that was done for the high level scaffolding. Q: (Viesters) seems to be some confusion between what is the core underlying data and what are the instances of the data e.g. appraisal as a form versus the data you fill out in the form. Presumably the ontology should represent just the data that is described whereas the use cases are more document focused. Is that right?

To clarify: It seems there are elements in the ontology which seem to represent forms or artifacts within the form, along with notes etc. This is distinct from the underlying data that goes in those. A: We want both in the ontology the idea that there is a document or a form, or for example a credit appraisal document. Once it comes in, it is a document with information on it. To the extent that information needs to be digitized, there will be information that needs to be in the ontology. There are data concepts that will necessarily be present in multiple documents. If the model reflects that the concept is contained within one document, that would be limiting. Is this what Viesturs is asking about?

Yes, are we looking to describe the underlying data and structure that in some way, or are we aiming to describe what goes in what form? Viesturs' view is we should be describing the kinds of concept, not having these linked to the place in the workflow or the workflow artifacts like forms.

Lynn: there are use cases which include the need to retain evidence, which requires the modeling of document artifact concepts.

MB notes that in legacy ontology we represented information artifacts as a distinct kind of thing for this exact reason. MU sees things in this same way there is a generic thing, artifact or document, there is the concept referred to by that artifact. That is, the information artifact is an ontological thing as well (for discovery). The core notion behind this is the concept of a "Document", and there is reference data which is part of this document. The document "refers to" those things. On top of that, all that stuff is the meat of what goes into the document. For example a Loan Contract.

Is the reference data more like metadata that describes the documents? No. When you fill out a form on line, every field in the form is backed up by an ontology.You can then generate the document from the ontology + data as needed. The "real deal" is currently the piece of paper, but from the company perspective the real deal is the data in the database.

Larry: when we look at e.g. a credit check and a balance sheet, those are things that are always being measured against a party, and change day by day. So the document represents a point of observation of that variable. A snap shot of the credit rating, balance, valuation of the collateral (house etc) similarly changes day by day, but there is an observation of this, which is an appraisal at a point in time, which is the documentary evidence we are looking for. An observation is a kind of information artifact. It has a date and who did the observing and what they were observing (which is the variable, that itself has the subject of e.g. the borrower or the collateral). The concepts themselves are independent of any particular representation in the document, but the conflict is that in the way we are depicting it in the framework today it makes it seem that it is directly connected to the documentation, rather than being what the documentation was "about" and when and by whom. So forms are kinds of observation. Some of these forms are standard e.g. application forms, but there are also a lot of nonstandard forms, even where the data that would be required is the same, and should be part of the ontology and should be independent of the form. The ontology should reflect the real stuff.

As for managing data, the system managing the data should have its own physical arrangements for evidence and compliance, workflow and so on - MB clarifies, FIBO can represent activities, workflows and processes as well as static things. It can also represent "obervations" and so on, and other kind of records, to the extent that there is some commonality in these that would be appropriate to standardize. For example things in the regulations that you have to do in specific limited times and so on.We would only seek to standardize these at the level where they are common to all of what industry participants do.

Michael Uschold: I'd like to move on now. A simple workflow would be e.g. a contractual agreement between parties. Also pre and post adjudication, acceptance of an offer, and processing after these are invariable. Depends on the role you play within a process. Similarly well defined process flows within the secondary market (see legacy FIBO MBS and ABS models for these). 2 outcomes from the above: 1. Recognize there is core data that needs to be represented, versus documents, which may have that data in them at some level. 2. process agreement that we don't want to build out detailed process models but we recognize the need for limited amounts of process information.

Lynn adds: one more thing is that what people are asking for is a repeatable or consistent way of denoting those 3 things within the architecture. The 3 things being concepts, data and the document. This is so we do this consistently across all of the loans areas.

Jennifer BC adds the need to stay away from adjudication as this has a specific connotation that something is being administered through a judiciary process, which is not what is meant here. So we need more of a process or lifecycle related term for this concept. Further comments to MU by email please, or on the wiki.

Obligations (see next slide). Names to be changed to align with FIBO upper levels so "Obligation" here is synonymous with "Commitment" in FIBO Foundations. These terms and labels will adjust as we align to the upper level of FIBO. MU will set up a meeting next week to do that.

VOM diagram slide Uses hasPart relationship for the relation between the loan contract and the commitments (obligation here). Sub classing is shown via nesting. OWL restrictions are on the hasPart relation, meaning that the loan contract has parts and those parts are commitments (obligations) of the kinds shown. This view can be used to generate an OWL ontology. Uses the Manchester syntax. So a loan contract is a member of the set of things that have a part that is an obligation to fund. That is if you find something that has parts and one of those parts is an obligation to fund, then that thing is a loan contract. Note it is also a sub class of FIBO Contract, so everything true of all contracts is true of the Loan Contract.

Geekery: the VOM presentation of restrictions is a detailed reflection of the logic that underlies a restriction, and is required for people who are to build applications, but the business meanings are not very clear from that kind of view. This corresponds to the text in the serializaton of the file in turtle syntax in this case.

Slide 291- Does this fit into how people see a mortgage? Valuation is a very general term for anything that is a valuation (e.g. valuation of an artwork or coin collection), of which Appraisal is a kind. Here the lifecycle is important. Process always impinges on the ontology. We try to model ontologically, the basic concepts of events, kinds of events and subkinds of those kinds of events, such as inspection as being part of the process of an appraisal. We may have a small number of lifecycle concepts that we agree are necessary. Similarly, some elements of a process would require inputs e.g. the application document. Similarly some process elements will output (produce) kinds of information artifact or other things.

Q: One of the things that is confusing from a business perspective, is the use of hasPart for events, for documents, for pieces of things and so on. These all seem to be the same thing whereas in the business these are seen as distinctly different relationships. May need to discuss this. Sometimes what appears to be a different relationship is actually the same relationships participating in different things. Foor instance hasBrother and hasSister are different, but they are kinds of a more general relationship that we would call hasSibling. These can be seen as the same relationship in terms of its nature.

Lynn notes that it seems to put very detailed properties (such as date of birth, eye color etc.) in this example), as being on the same plane as the more fundamental "hasSibling" property. This seems to mix different levels of detail. Does that mean that e.g. date of birth, eye color and siblinghood should be represented by a property at the same level. MU, the alternative in e.g. a car do we need "hasWheel", hasSteeringwheel" and so on? MU is happy to use the relations with more detail if people want that. Paul: when we start talking of activities, state, event etc. at the same level as artifacts about the data itself, then it feels that the hasPart relation has been framed too broadly or used too extensively. There was previously an agreed guideline about this. There is in any case a mismatch between the diagram on Slide 20 and the ontology. Mortgage is sometimes something that is referred to as a Collateral Contract. The model has been updated; the diagram was not updated.

Slide 31 the mortgage itself is really a kind of collateral agreement, not the loan that has that as collateral. Then Mortgage Loan Contract is a kind of Loan Contract. It also has a part which is the Mortgage itself (the collateral contract as noted above). With different aspects as per the slide. Some of the properties that are being called hasPart might be meaningfully defined as things like "securedBy". So there are relationships or properties which are currently shown as hasPart, where we may be able to articulate a more meaningful relationship (which may or may not be a sub property of hasPart). This allows us to reason more about those things i.e. considering properties other than parthood, and thereby analyzing more aspects about what it means to be a given thing, aside from parthod. isSecuriedBy is a meaningful property which we would want to stand up.

Can we update the model to reflect this, as distinct from hasPart. As the red FIBO already does. Jennifer BC adds that some of these things depend on the perspective of the party to a contract, e.g. whether collateral is pledged by them or secured by them.

MU is open to making the hasParts more specific, however, in this case as raised by Jennifer above, there is a dependency on the role and party. MB adds we need to ensure that concepts in FIBO are not partyspecific, other than as a separate set of partyspecific "aspects" of these if and only if we needed those. All concepts should be modeled in the round, not partyspecifically. So any loan is secured by collateral, and that collateral has subordination to other leans, other collateral and so on. There are interloan contractual agreements that can impact intraloan relationships. This is similar to how tranches of securities have a tiering, waterfall models for cashflow rights. Also there are things like this in the RePo market. Might want to look at that piece of the model. See how those kind of situations are articulated in th current constructs.

Barrett, Matthew: We may need to consider the use of the term collateral. MU: Question on earlier point by Liju: Text definitions for the classes and properties, and have the words in those refer to the other classes and properties as they are more precise? Yes! Mike U agrees.

Barrett, Matthew: There are multiple places in the lending process where the term collateral may introduce ambiguities. There is a balance between something very precise for a technical person, and something more general. Barrett, Matthew: Collateral = Note?, Appraisal of the Collateral (property)?, etc.

Larry Mitchell: Isn't insurance a property of the collateral?

Action items

Browser not supported