Happy New Year to All, While I have been enthusiastically following the conversations here of latte, I have been quiet and very focused on my wife's and my move from Cedar Rapids, Iowa USA to Broomfield, Colorado which is very near the brilliant computational linguists and #UIMA researchers at the Colorado Computational Pharmacology research center in Aurora at the U. of Colorado (http://compbio.ucdenver.edu/). For what it is worth, Robert's insights about the time/place sensitivity to data values makes great sense from a long-time Smalltalk/OOP modeler's perspective. The expressive/extensible context-sensitivity of this aspect of the model is a strength of the CRM as a foundation for specific use. My concern is that efforts to go too fine-grained in the base model will turn off or confuse potential users who need to see their models as non-conflicting extension of the base model rather than as a non-compatible alternative to parts of it.Happy-Healthy Vibes,Jim _____________________________ From: Robert Sanderson <[email protected]> Sent: Friday, January 6, 2017 5:18 PM Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency To: <[email protected]>, martin <[email protected]> Cc: David Newbury <[email protected]>
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] Thanks! Rob On 1/6/17, 6:06 AM, "Crm-sig on behalf of martin" <[email protected] on behalf of [email protected]> wrote: On 4/1/2017 1:01 πμ, 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. 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. _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
