...
Properties with too narrow domain and/or range
rel:refersTo property has too narrow domain (Reference)
the 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".
...
- 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.
...
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
...