[Crm-sig] 6.2.2's MonetaryAmount and Currency
RSanderson at getty.edu
Sat Jan 7 02:12:18 EET 2017
Thank you, Martin!
I think the explicit addition that the value is the face value, not the market value, would make the usage clearer. Perhaps even adding that the time associated with an activity with which the Monetary Amount is associated should be used for comparison, if that degree of accuracy is important and historical market values are available?
And, if I understand you on the topic of Dimensions, the intent is the same? That a Dimension with a value of 3, and a Unit of inches, is the equivalent notion of the face value of the observed length, however it happens to be extremely stable as to the “buying power” of that particular unit … however per Simon’s informative email, before 1959 the imperial and US inch currencies were very fractionally different from what we call an inch today and using the date and location of observation (if known) would be important for Very Large numbers of inches.
If I had two measurements of:
_:big a E54_Dimension ;
P90_has_value 2000000 ;
P91_has_unit <uri-for-inches> .
And one was associated with a Measurement performed in 1950 in France, the other in 1970, the two quantities are actually off by one.
The interpretation of the combination of the value and unit seems dependent on the date of the activity that established it, and thus is the scope note correct that the quantity the instance of Dimension describes is independent from the observed approximation? Or am I just misunderstanding the intent of scope note? :)
To look at it another way, for the activity of assessing the value of an object, would you say that’s an E16 Measurement, that P39 measured the object, and P40 observed dimension of the Monetary Amount?
(perhaps also with a P2_has_type of aat:300054622, “appraising”)
[More about the identity question in the other thread]
On 1/6/17, 6:06 AM, "Crm-sig on behalf of martin" <crm-sig-bounces at ics.forth.gr on behalf of martin at ics.forth.gr> wrote:
On 4/1/2017 1:01 πμ, Robert Sanderson wrote:
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.
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?
This was the intention!
We thought that the phrasing of the scope note " This class comprises quantities of monetary possessions or obligations in terms of their nominal value with respect to a particular currency. " is unambiguous in this respect. If the term "nominal value", is regarded not clear enough, I suggest to add a remark such as " the nominal value is in contrast to the market value of a monetary amount with respect to other goods or currencies, which is not intended to be represented by this class". Any market value would need another reference to a particular exchange market system, wouldn't it?
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.
I agree and disagree! Firstly, defining monetary amounts as Dimensions is a preliminary solution. A monetary amount is declarative or nominal, and not a question of observation. It is naturally exact. Therefore we had arguments in CRM-SIG that monetary amounts are not Dimensions, but other kinds of quantifiable entities. In order to be more robust against future reconsiderations, we defined all properties of Monetary Amount to be subproperties of properties of Dimension. Any change of generalization will affect general queries, but not encoded instances.
More information about the Crm-sig