...
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?
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.
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.
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.