Status
This feedback is based on the version of FIBO BE & FND & FND that I got from David Newman on December 3, 2015. Some this may need to be updated.
Request for Clarification
...
What if any relationship is there between IndependentParty and AutonomousAgent? It makes sense that every IndependentParty is an AutonomousAgent, but that subclass relationship is not there.
Occurrence, OccurrenceKind & TransactionEvent
- Occurrence and OccurrenceKind are not clearly distinct. Why is a Transaction event not just a subclass of Occurrence? It fits the definition.
Payment and Payment Event
- What is the difference - the English definition does not adequately distiguish the meanings of these two.
Recommended Changes
Definition not match axioms
- oc:Occurrence definition says there is both a date and a location, but there is no restriction for a date. Should be added.
"An Occurrence is a happening of an OccurrenceKind. Each Occurrence has a DateTimeStamp, which identifies when the Occurrence happened, and a Location"
Making things simpler
Contract and ContractTermsSet
- The LOAN SMEs want the ability to directly link a contract to a single term, not requiring an intermediate ContractTermSet. However it is represented, an individual term usually/always amounts to a specification of an obligation that applies to one or both parties.
- I suggest ContractTermSet be subclass of fnd-arr-arr:Collection linked to individual terms using rel:hasMember. EK suggested as much in a comment.
- Is it ok for a Contract to have no terms? If not, then add hasTerms min 1 restriction.
- there is a restriction: [rel:hasPart only ContractTermsSet]. It is highly peculiar that a set of terms and conditions, if it had a part, that part could only be another SET of terms and conditions. More natural to say a TermSet hasMember [an individual] Term.
- Is a term of a contract text, or is it the obligation itself? This is analogous to the distinction between a creative work like “Moby Dick” vs. the specific rendition as text. The commitment is analogous to the work, the contract term is text.
Restrictions that should be min 0
...
- Suggest move the hasName data property to the relations ontology. Many things that are not agents have names . Then there may be no need for relations ontology to be importing agents ontology. It seems a bit backwards.
- Suggest move identifies(isIdentifiedBy) properties to the relations ontology. Many things that are not agents have identifiers. Then the agents ontology can import the relations ontology, like most other ontologies do.
- Suggest change name of rel:hasUniqueIdentifier to rel:hasUniqueString to avoid confusion with the class, Identifier.
- Suggest move fibo-fnd-qt-qtu:isDerivedFrom to relations ontology so it can be used for other things, like deriving information products from accounts.
Properties with too narrow domain and/or range
...
- Consider subproperty rel:characterizes. This causes many odd things to be inferred to be subclass of Reference. These include Funds, SecuritiesTransaction, RegistrationScheme, AccountSpecificServiceAgreement, SystemOfUnits, AccountingTransactionEvent and Catalog. A Catalog contains things that refer to products, but it does not itself refer to anything, it IS something.
- Consider subproperty rel:appliesTo. Many thing that are not references can apply to other things. A rule or law applies to specific circumstances. This infers every Rule and Law into the class Reference. It infers a SystemOfUnits to be a subclass of Reference. This has to be wrong. Other inferred subclasses of Reference: Funds, SecuritiesTransaction, RegistrationScheme, AccountSpecificServiceAgreement, AccountingTransactionEvent
- Every Classifier is inferred to be a Reference. So the classifier for mortgage purpose has instances say, home improvement, home purchase and refinance. That means these instances are "concept(s) that refer or stand in for anothere concept. What concept does a Classifier stand in for, other than the trivial sense in which every thing in owl is stands in for an concept in the world being modelled.
- A PublicRecord of say a bankruptcy, is inferred to be a Reference if I want to say that PublicRecord refers to an account, (which is does!).
Proposed solution: just remove the domain for refersTo, and from all other properties that have indeterminately broad potential usage.
...
isMemberOf should be general, now there is need to create a isGenericMemberOf.
UPDATE: this may have been fixed now.
Suggested Changes to class and property hierarchies
Changes to class hierarchy
Changes to property hierarchy
Check for date properties that should be a subproperty of fd:hasDate. For example:
- ctr:hasEffectiveDate,
- doc:hasDateOfIssuance
- doc:hasExpirationDate (maybe via fd:hasEndDate)
Make corp:hasDateOfIncorporation a subproperty of (a new property called hasCreationDate which is a subproperty of) fd:hasStartDate
Recommended Additions
Chunks of ontology
- for representing communication, which includes request, reponse, from/to and content of the communication. MU has some clear ideas abou this to be shared at a future date.
- ordering products is a special kind of request., link with FND products and services.
Classes
MarketCategory:
Definition: Specifies the market domain in which a product is offered. This is a superclass of LoanMarketCategory which is: specifies the market domain in which the loan product is offered.
RiskAssessment
A subclass of oc:Occurrence that means the event of determining the risk of something. For loans, we have a subclass called CreditRiskAssessment, which entails among other things, getting a credit report.
InformationProduct
For things like credit reports. A Product that is informational in nature, rather than physical.
PostalAddress
There needs to be a way to spell out details of an address, city, street etc, ideally beyond just a string. Cities and zip codes are real things.
Properties
identifies:
should be functional (or isIdentifiedBy inverse functional).
conformsTo:
To be in alignment or agreement or obeying some kind of specification, e.g. terms in a master agreement. Also policies, conditions, guidelines, a recipe.
hasCreationDate (make it a subproperty of hasStartDate)
For reports, contracts, and many other things.
asOfDate a subproperty of hasDate
Used for credit reports. Not necessarily the same as creation date, which could be later.
ALSO: ctr:effectiveDate should probably be a subproperty of asOfDate, since it means effective "as of" a given date.
onBehalfOf
Relates a party to the party for whom the are doing something. E.g a point of contact is acting as such on behalf of a company. It might be this is quite general for FND, or one might want it in BE?
datatype property for version indicator
...