Which is born out by the ontology in the casting to RDF, in that the range is rdfs:Literal, not xsd:integer. Good catch, thank you!
So, it would be valid to say, for example: _:red a E54_Dimension ; P90_has_value “red” ; P91_has_unit <uri-for-css-color-values> . And thus the observation that “Red Square” in MOMA is red could be a Measurement of that Dimension? The concern, of course, is that some implementations will use “16” (the string) and others 16 (the integer), which are not comparable. To which the obvious answer is, I fully realize: Don’t do that then. Rob On 1/4/17, 6:57 PM, "Stephen Stead" <[email protected]> wrote: Not commenting on everything but " The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. " The value is tied (via P90) to an instance of E60 Number not a number. E60 Number includes, explicitly, intervals. Rgds SdS Stephen Stead Tel +44 20 8668 3075 Mob +44 7802 755 013 E-mail [email protected] LinkedIn Profile http://uk.linkedin.com/in/steads -----Original Message----- From: Crm-sig [mailto:[email protected]] On Behalf Of Robert Sanderson Sent: 04 January 2017 18:39 To: Richard Light <[email protected]>; [email protected] Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency Hi Richard, I agree that the Currency should be constant unless the monetary system changes, regardless of the changing value. However that’s not what is implied by Monetary_Amount being a subclass of Dimension, where the actual value is independent of the approximation. For the subclass to be valid, the features of the parent class must be valid for the child class (All Persons are Actors, and all of the features of Actor are valid for Person). Ergo, the proposed structure is invalid, or the scope notes for Dimension should be changed to say that 6 inches is the face value, not the independent absolute value. Regarding the URI discussion, the URI would not be the value of the Monetary_Amount, just its identifier. For example, if three artworks each sold for $100, the instance of Monetary_Amount referenced from each Purchase can be the same instance. In short hand: _:p1 a Purchase ; transferred_ownership_of _:object1 ; sale_price <uri-for-$100> . _:p2 a Purchase ; transferred_ownership_of _:object2 ; sale_price <uri-for-$100> . _:p3 a Purchase ; transferred_ownership_of _:object3 ; sale_price <uri-for-$100> . <uri-for-$100> a MonetaryAmount ; value 100 ; currency <uri-for-dollars> . And from your second email, I agree (per your point 3) that P181 is unnecessary if a Monetary_Amount is a Dimension. And an equivalent case of pounds, shillings and pence for your point 4 would be also important to take into account for currency. Both could be solved by allowing sub-values of a larger whole: _:total a Dimension ; consists_of [ a Dimension ; value 3 ; unit <uri-for-feet> ], [ a Dimension ; value 6 ; unit <uri-for-inches> ] . The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm. The approach taken by timespan with begin_of_the_begin and end_of_the_end might be appropriate to duplicate here, if recording the precision is important. Rob On 1/4/17, 12:23 AM, "Crm-sig on behalf of Richard Light" <[email protected] on behalf of [email protected]> wrote: On 2017-01-03 11:01 PM, Robert Sanderson wrote: 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 <http://old.cidoc-crm.org/official_release_cidoc.html> [2] http://new.cidoc-crm.org/get-last-official-release <http://new.cidoc-crm.org/get-last-official-release> [2] http://ceur-ws.org/Vol-665/CorrendoEtAl_COLD2010.pdf <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 _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
