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 [1] 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 [2], 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 monetary amount. > 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. Best wishes, Richard [1] http://old.cidoc-crm.org/official_release_cidoc.html [2] http://new.cidoc-crm.org/get-last-official-release [2] http://ceur-ws.org/Vol-665/CorrendoEtAl_COLD2010.pdf > > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- *Richard Light*
