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

Why is the class called TransactionEvent instead of Transaction? Is there such a thing as a transaction that cannot be said to have happened? Also, given 'event' has a special meaning in finance, if you are going to call this out, should it not be called TransactionOccurrence and be a subcalss of Occurrence, not OccurrenceKind (they do have dates)?

The FIBO FND team is planning to do some work here. But, whatever the name, what is intended by TransactionEvent (which could be transaction activity or transaction kind, as an alternative) is a general class of activities – such as the class of activities that involve exercising an option on some number of shares of stock. The actual occurrence of that transaction would be of type Occurrence, but would be associated with the transaction "activity" via the "exemplifies" property – the transaction activity is the generic thing, whereas the occurrence is an individual occurrence that involves time. This corresponds to the PSL model of activities and occurrences, fyi.

Recommended Changes

Incorrect subclass relationships.

pas:TransactionEvent is something that does in fact happen, e.g. withdrawing $100 from an ATM. There for it is NOT an OccurrenceKind, which is defined as a " type of event, which has a description". It does in fact have a Date, where OccurrenceKind specifically lacks a Date.

The actual withdrawl is an occurrence involving a transaction time and some monetary amount, where as the class of activities that are of type WithdrawlActivity is a subclass of OccurrenceKind following the PSL and DOLCE models. See http://www.nist.gov/el/msid/psl.cfm for more on PSL.

ReFactoring Suggestions

Classes with names that are too general

The definition of caa:Account narrowly pertains to "a contractual relationship between a buyer and a seller", but this exludes many important accounts in finance, not a bank accounts and investment accounts.

Proposed Solution: Two options.

Preferred: do not have a class that means what the current class means. Have a class called Account that means the more general case.
Other: create a second more general class, if for some reason it is important to have both versions.

There are ripple effects, for example for Loans I want an account transaction history, so I want to use AccountingTransactionEvent, but it is limited to a too narrow a sense of account.

Properties with too narrow domain and/or range

Recommended Addition

add hasName restriction to pas:Product
add hasStartDate restriction to pas:Product that means when the product becaem available, create new subproperty only if needed.

Browser not supported