Recommended Changes
ReFactoring Suggestions
- 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.
Properties with too narrow domain and/or range
rel:refersTo property has too narrow domain (Reference)
The property refersTo in the relations ontology has an overly narrow domain: Reference. Every Reference refersTo something, but a person or a document or a report can refer to something, and it is not true that individual persons, documents or reporets are examples of " a concept that refers to (or stands in for) another concept".
For loans, I have a class called PublicRecord for bankruptcies, tax liens, wage garnishments etc. These are legal documents that often refer to specific accounts. I want to use the refersTo property but this will generate an untrue inference. Given the dearth of disjoint axioms, this will probabaly not be caught by inference, but we don't want incorrect inferences, just the same. I doubt we need two refersTo properties, one specific to Referencee and one more general.
There are many other examples of problems.
- 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
Proposed solution: just remove the domain for refersTo, and all other properties that have indeterminately broad potential usage.
doc:hasExpirationDate has too narrow domain (Document)
It is currently not possible for an agreement to have an expiration date, because only Documents are allowed to have expiration dates
Proposed solution: just remove the domain for doc:hasExpirationDate
doc:hasDateOfIssuance has too narrow domain (Document)
It is currently not possible for anything to be issued unless it is a Document, thus the current ontology requires every financial instrument (which is currently a WrittenContract) to also be a Document. Is that desirable?
Proposed solution: just remove the domain for doc:hasDate
fd:hasCount has too narrow domain (RegularSchedule)
Data property: hasCount only applies to a RegularSchedule, but many things can be counted, e.g. the number of entries in a report, or number of members of a collection.
Proposed solution: just remove the domain for fd:hasCount
rel:uses has too narrow domain (AutonomousAgent)
The domain for uses is AutonomousAgent. Unlike the other examples, this one immediately seems reasonable and defensible from an intuitive and ontological perspective. Yet from a practical perspective, the domain is still too narrow. Outside of finance per se you can say an Argument uses a line of reasoning or that ontology uses a design pattern. This is convenient and useful (as it were), even though strictly, the agent creating the argument or the ontology is doing the direct using. In finance, there is a CreditScoring Occurrence whereby an algorithm is used to compute the credit score. Strictly the agent doing the work was using the model. But there is no reason to introduce an Agent here, that information is never tracked. I want to use the rel:uses property to link the credit scoring occurrence directly to the model. In English this is fine, it makes sense to say algorithm X was used by this Occurrence of coming up with a credit score. Lots of things might use something else, and it is hard to say what they all might be, so probably best to remove the domain. An alternate strategy is to try soemthing like Agent OR Occurrence (and anything else we can thyink of) and then if we run inference one day and find a problem we can keep extending the domain as needed. Not clear what the pros/cons are.
Proposed solution: just remove the domain for rel:uses
rel:isMemberOf has too narrow domain
isMemberOf should be general, now there is need to create a isGenericMemberOf.
UPDATE: this may have been fixed now.