[Crm-sig] 6.2.2's MonetaryAmount and Currency
richard at light.demon.co.uk
Wed Jan 4 10:23:15 EET 2017
On 2017-01-03 11:01 PM, Robert Sanderson wrote:
> Dear all,
> At the Getty, we are currently remodeling our Provenance Index data into Linked Open Data. As you might expect, there is a lot of historical payment information related to the transfer of ownership of objects. We were very happy to see that 6.2.2 adds in some of the foundational modeling for supporting this information. The scope notes in the current draft are a little unclear for Monetary_Amount and Currency, however.
The version of 6.2.2 on the old web site  doesn't include P96
Purchase, so I can't comment on this in detail. (In fact, the .doc
version of the current release is actually headed 6.2.1. Still, this is
better than the 'new' site , where the current release that is
offered is 5.0.4 from December 2011. I think some updating is required.)
> We are assuming that the Amount the face value of the money (e.g. $100 USD is always the amount 100 of the currency USD) regardless of the actual _value_ of that amount. If this is correct, then could the scope notes confirm this?
> All currency amounts have an absolute value that changes constantly due to inflation and markets, and there’s no way to associate a date with the amount instance to capture this. This seems somewhat in conflict with being a subclass of Dimension, which is “the true quantity, independent from its numerical approximation, e.g. in inches or in cm.” – in other words the absolute value, independent of the unit, which is in this case the currency.
Assuming that E96 Purchase is a subclass of E7 Activity, it will have
the opportunity to record an associated date. I think you are
over-thinking what it is feasible to record here: if a specified price
was paid for an object on a specified date, surely that's all you need
to record - in fact it's all you can record. It is for others to make
their own deductions as to the 'real' value (in some sense) of that
> As a thought experiment, if the unit of an “inch” were to change definition to be exactly 2.5 centimeters, then I believe from the description of Dimension, that the lengths would remain the same in absolute value, and we would need a new unit for “new inches”. This is not practical for currency, as we would need new units constantly … which is also forbidden by the scope notes of currency: “One monetary system has only one currency”. So how are we to deal with comparisons over time?
I think that the only case where we should be making this sort of
distinction is where the currency itself changes its 'semantics': for
example the revaluation of the French franc in 1960.
> And in either case, it would be correct to have all uses of $100 USD refer to the exact same resource… there need only be one Monetary_Amount that has a particular value and currency … $100 is $100, regardless. The practical implication is that Monetary_Amount URIs could be constructed algorithmically along the lines of http://example.org/Monetary_Amount/dollars/100. This doesn’t seem to be affected by face value vs actual value, but confirmation would be appreciated.
Again I can't comment on what the 'official' line on this might be, but
there are analogies here for other measurement-like entities, such as
dates [e.g. 3]. While there may be advantages to 'quantizing' dates
(given the inherent uncertainty in deciding when an event/activity
happened, and the possibility it opens up of matching on the 'same'
date) I think there is less of a case for doing this to monetary
amounts. If they are recorded as a numerical value, it is
straightforward to add them up, and to make comparisons ('find all
transactions with a value greater than $10,000'), etc. With a URL for
the amount, you lose this ability.
> Secondly, and this is likely out of scope for the CRM at this stage, we have a requirement to model where the money comes from and goes to. For example, there are many occurrences of dealers owning only a part share of an expensive artwork, and the payment being divided according to that share amongst the owning dealers. For this we need more than just a Monetary_Amount associated with a Purchase, and have been using a new subclass of Activity a “Payment” with properties mirroring transfer of ownership: paid_amount, paid_to and paid_from.
I agree that this would be generally useful. Another element of this
Payment activity would be a description of the good or benefit that is
transferred in return for the payment.
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Crm-sig