Email thread on 'assumes' relation
- Mike Bennett
MU>
We agreed to remove the restriction from MortgageLoanContract to InsuranceContract since insurance is not a focus of HMDA. There were a handful of insurance-relaeted classes and properties that were created, but the only place they were used was on this restriction. So should I just remove all the insurance related stuff for now (putting it in a place where I can recover it easily).
LC>
Yes
MU>
Good, I'll do that.
One more thing for you to vet. I made hasClosingDate a subproperty of hasEffectiveDate, which is defined to be: "the date a contract, relationship, or policy comes into force".
That seems spot on to me, do you agree?
. . . . . . . . .
MU>
I created a new property: 'assumes' and adapted the definition to AssumedMortgage as follows:
" Connects a new mortgage contract to an existing loan contract with a different borrower. The new contract is created via a legally binding process that assumes the terms of the existing loan contract."
Feel free to edit it and I'll paste it in.
Also, I wonder if "assumes" might be a subproperty of "ctr:supercedes" which is defined to be: "the or any earlier contract which this contract supersedes"
It is close, but may not be quite right.
LC>
I would say "previous loan contract":
I would maybe use something more distinct so that the property is not mixed up with the vernacular "assuming something." Perhaps "hasAssumedTerms"?
"Supercedes" is a different legal concept and I would not introduce it here. It would be inaccurate.
MU>
I created a property called “assumes” which means:
"Connects a new mortgage contract to a previous loan contract made to a different borrower for the same property. The new contract is created via a legally binding process where the new borrower assumes the terms of the previous loan contract."
I wanted to connect it to a parent property, and ctr:supercedes was fairly close: “the or any earlier contract which this contract supersedes”. Lynn says this is not accurate.
QUESTIONs:
- Is there a generic property that should be added to the contracts ontology that can be a parent property for assumes, or is assumes highly specific to loans?
- is there another property anywhere in FIBO that I can connect loan:assumes to as a subproperty?
LC>
It would be nice to have a parent property for loan that is something like “RelatedTo.” I could see us making this more specific for Assumptions, but also for Modifications, as well as Piggy-back scenarios, where it is necessary to understand the two loans together.
MU>
Regarding Lynn’s suggestion to use a property like: RelatedTo, it is very tempting because that is how we think of it, and a synonym would be ‘isAssociatedWith”. The problem with these suggestions is that they don’t convey any meaning about the nature of the relationship.
LC>
My thought is that we can further explain the exact relationship through other means.
In MISMO, we call these relationships “Related Loan.” And then we can describe the relationship more fully with other characteristics, like the lien position, temporal data, and other status information. For instance, a HARP loan would be refinance, and would have some kind of indicator that it is part of the HARP program. The original loan would have characteristics showing that it is being paid off by the subject transaction, and that it is a loan for the same persons and property. One one would be able to infer that the relationship between the two loans is one of HARP refinance.
Another situation would be modification. One would be able to see that a modification had been requested and is in process. The current loan and the potential new modified loan would have the same obligor and property. The status on the current loan would be delinquent and possibly in some stage of foreclosure. One would be able to infer that the relationship is one of modification.
MB>
Yes, in general there are many kinds of formal relationships between contracts. As well as assumption there is novation and there is some kind of transference. Novation is quite big in the OTC Derivatives world. Then there are also the relationships between contracts that between them make up parts of the same agreement between the parties (one reason we originally treated Agreement and Contract as separate things).
The trick is identifying which ones have something in common and which ones don’t. Of the ones we have talked about so far, some involve having the same terms but a different counterparty, and some involve having the same parties but different terms (in the latter case, some loan contracts allow the lender to vary the terms – meaning it is the same contract when those terms change. In other cases it isn’t).
EK>
In Relations we have "refersTo", and as a child of that class, we have "appliesTo". These might be along the lines of what Michael was looking for. Also in Relations we have isIssuedBy, isManagedBy, and related properties that may be useful for identifying the originator of the mortgage and perhaps the organization that manages it.
Hope those are helpful,
MU>Without any distinguishing meaning, they are logically equivalent to owl:topObjectProperty. We also have struggled with this at semantic arts having used at one time or another properties called “connectedTo” or “regarding”.
MB> To Michael’s point – one challenge with FIBO as a conceptual ontology is that in many cases there are things which we know are different, but it would be difficult to formally state that difference without introducing some very nuanced and abstract concepts into the ontology. Eventually we will put some of these in. As a minimum, John Searle’s ontology of social constructs. Of course these are never stood up in data, and so are beyond the reach of ontology-based reasoning, but that’s one good reason the conceptual ontology is an entirely different kind of thing from an ontology for reasoning based applications. So in practice, we introduce new classes and properties even when there is nothing in the technology stack to distinguish them from Thing or topObjectProperty.
MB>
The proposal we came up with was for a new parent property, of which the existing supersedes would be a child, as well as the one you are after for ‘assumption’. More likely ,assumption itself is one of many ways in which contracts can have a similar (not supersession) legal relationship to other contracts, and that’s where more work is required.
I’ll post the slides shortly – given the detail of this conversation I’ll add the diagrams we worked on as well, before doing so. I have to go out in a bit but this will be up later today.
MU> MB: Thanks, this would be good.
. . . . .
MB>
I posted the slides from the FIBO Foundations work in this area, at the following link yesterday:
MU>
I had a quick look through the deck, the contract properties look just fine. I see you systematically looked at a bunch of other upper concepts that loans needs/wants. Is that process done now, or still underway? I should let you know that I have an updated list of such concepts with a more sensible naming convention. I took off my initials. See attached spreadsheet. The 2nd tab is the one you care about, AddToFIBO.
Per a discussion we had a while ago at an FLT meeting, once these things are taken care of on your end, there needs to be a reliable process for tossing it back over the fence to me so I can update the loans ontology accordingly. For example, what is the mechanism for my being informed that the new contracts properties are now in a new version of the ontology that I can then download and use moving forward?
On the suggestion to add a class for Specification, slide 28 says it is already in Documents. Where? What ontology is that? Maybe is it very new, I never saw it. I’m still on a Dec 3 version of the ontologies.
I did see a property called specifies in FBC/FCT/RA but there is no meaning specified in OWL, just than an annotation: “states a fact about something”. I’m not sure what the intended meaning is, but it does not seem a dead ringer for what I have in mind. I have a more detailed suggestion, as discussed on this wiki page.
SPECIFICATION: A body of information specifying what properties, structure and/or results something should or must have after it has been built, fulfilled or completed. The thing may be physical (a building), organizational (a management structure), computational (a program), job or task related (e.g., a CEO, Chief Judge) or changing oil in a car.
In addition to Goals, Objectives, Agreements and Commitments, it would also include any sort of guidelines, processes, procedures or regulations, templates etc. We could put MonetaryAmount under Specification, while AmountOfMoney goes under EconomicResource (or Asset?) or wherever.