[Crm-sig] 6.2.2's MonetaryAmount and Currency

Richard Light richard at light.demon.co.uk
Wed Jan 4 17:22:59 EET 2017


Yes, this all makes perfect sense, and I am happy with it as a system. 
I would just point out that the version of the 6.2.2 draft which is
provided on the [old] web site isn't the one you quote below, but is an
older version, still with the number 6.2.2.  It is:


and is dated July 2015.  So maybe the minor version number should be
incremented each time there is a substantive change (such as the
addition of four new classes).  It would also help if the list on the
Official Release page made it clear which versions are Official or
Published, and which are In Progress or Under Revision.  At present they
all say "New version" (or "New draft version" for the RDFS encodings).

Now that I have read the proposed new sections, I have the following

 1. I wonder whether providing E96 Purchase as a subclass of Acquisition
    is too limiting a solution.  It only applies to one particular
    circumstance.  Rob's alternative suggestion of a generic E?? Payment
    class would allow the recording of other activities involving
    payment (such as saleroom purchases), and it could be linked to E8
    Acquisition via a P??? involved_payment property.
 2. Another reason for having an E?? Payment class is that it offers the
    opportunity to record complexities as regards who pays, and who is
    paid, what amount - there won't always be a simple sum involved
    (e.g. items acquired with help from granting bodies, contributions
    from Friends, etc.).
 3. The strategy for E97 Monetary Amount is different from the strategy
    for its superclass E54 Dimension.   In fact, I see that the
    definition of E54 Dimension has changed (as noted on pp139-141)
    although it is unaltered in the main text on pp26-27 - or at least
    the examples there are unchanged.  So the current approach is to
    record a description of the dimension as the value of E54 Dimension,
    and then have subordinate P90 has_value E60 Number and P91 has_unit
    E58 Measurement Unit properties to record its value and units. 
    Adopting the same approach for E97 Monetary Amount, the value would
    be e.g. 'purchase price of object 1980.345', and it would have a P90
    has_value property to record the amount, and P91 has_unit to record
    the currency.  I don't see the need for P180 has_currency (although
    it could be declared as a subproperty of P90 has_unit), and I
    certainly don't see the need for a separate P181 has_amount.  Just
    use P90!
 4. Another point about E54 Dimension in general (including currency
    amounts) that is not tackled by the current draft is the recording
    of multi-unit dimensions.  If you want to say that a length is 3 ft
    6 inches, how do you express that?  You can't just have two P90s and
    two P91s, since you have no way of expressing which value goes with
    which unit. (You certainly won't by the time you come to express
    this in RDF.)  This wasn't an issue with the earlier treatment of
    E54 Dimension, but it is now that value and unit are explicitly

Best wishes,


On 2017-01-04 1:07 PM, Chryssoula Bekiari wrote:
> Dear Richard
> About the releases of the text of CIDOC CRM, I would like to note
> that, in the the 36th meeting, taken place in August in Crete, it is
> proposed and accepted to separate publications into categories:
> Official, Published and Current and to add the 'editorial status' in
> the each cidoc crm text. 
> If the Type of Document is Official or Published then the editorial
> status is closed. This means that this document is no longer under
> editorial revision. It is no longer subject to change and its contents
> will remain stable.
> If the Type of Document is Current then the editorial status is open.
> This is an un revised and as yet incomplete community version of the
> CIDOC CRM. It is the currently edited version of the CIDOC CRM text
> and represents a working version of the CIDOC CRM and should not be
> used for implementation, reference or other official purposes. The
> function of this document is as a reference resource for developers of
> the CIDOC CRM standard to discuss on-going, proposed but not yet
> accepted changes to the model. The contents of this document are not
> stable and are subject to change. In this case, we distinguish two
> types of editorial status, the following:
> "In Progress": This current  version of CIDOC CRM contains open issues
> that are actively being worked on. The document may therefore change
> at any time since it is being updating according with the last CIDOC
> CRM SIG meeting discussions and their conclusions. This copy of the
> standard should be used only for the purpose of following present
> modelling discussions on the CIDOC CRM SIG meeting. This document is
> not meant to support implementations, referencing or other official
> activities.  
> "Under Revision". This  current version of the CIDOC CRM standard
> contains open issues that have been declared and specified and which
> are scheduled to be addressed in an upcoming meeting of the CIDOC CRM
> SIG. The document may change relative to decisions taken at the next
> CIDOC CRM SIG meeting. This copy of the standard should be used only
> for the purpose of following present modelling discussions on the
> CIDOC CRM SIG list and meetings. It represents a step before a
> potential stable release of the standard. This document is not meant
> to support implementations, referencing or other official activities.
> (see also
> http://www.cidoc-crm.org/sites/default/files/minutes_Heraklio_1_8_2016%28v5%29.pdf.)
> Thus the latest 'current' version of CIDOC CRM 6.2.2 is on the site
> with editorial status 'Under Revision since 2/12/2016'
> http://www.cidoc-crm.org/sites/default/files/CIDOC%20CRM%206.2.2%28current%20since%202-12-2016%29%28site%29.pdf
> and it contains the E96 Purchase.
> This version does not contain yet the latest changes made in the
> Berlin meeting. New current version will be uploaded until January 15.
> Any comments or recommendations for this process are welcome
> with my best wishes for a happy and productive  2017
> Chryssoula
> On 4/1/2017 10:23 πμ, Richard Light wrote:
>> 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
>>> Crm-sig at ics.forth.gr
>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>> -- 
>> *Richard Light*
>> _______________________________________________
>> Crm-sig mailing list
>> Crm-sig at ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> -- 
> ----------------------------------------------------------------------
> Chryssoula Bekiari
> Research and Development Engineer
> Center for Cultural Informatics / Information Systems Laboratory
> Institute of Computer Science
> Foundation for Research and Technology - Hellas (FORTH)
> N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece
> Phone: +30 2810 391631, Fax: +30 2810 391638, Skype: xrysmp
> E-mail: bekiari at ics.forth.gr
> Web-site: http://www.ics.forth.gr/isl/index_main.php?l=e&c=231
> --------------------------------------------------------------------------------

*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20170104/6d662cab/attachment-0001.html>

More information about the Crm-sig mailing list