[Crm-sig] 6.2.2's MonetaryAmount and Currency

martin martin at ics.forth.gr
Fri Jan 6 16:06:42 EET 2017


Dear Robert,

Thank you very much for your message! Let me first comment your initial 
mail.

As a general remark to all other valuable contributions to this issue 
however: We should not loose focus: the CRM intends only to describe 
important facts for cultural-historical and scientific inquiries across 
integrated knowledge networks. If we want to describe any detail, we are 
free to put it in P2 notes or to make our own extensions. For instance, 
I'd argue that details of dimensions of museum objects are irrelevant to 
global queries. Would anybody research for all objects that could be 
3.25 mm long, without any prior, substantial reduction of the search 
space? Without a strict scope limitation, we will end up modelling all 
sciences and businesses of the world.

CRM compatibility does not prohibit any local extension of topics 
outside its scope. Since CRM SIG acts as standardization body, it cannot 
be proactive to needs. It can only react after some established 
practices need harmonization.

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.

The fact that units of length are mathematically convertible, and that 
observable dimensions are fuzzy, does not create a generalization of 
market-based "conversions" of monetary amounts between currencies, which 
are not based on a numerical approximation of a "true quantity". Rather, 
one could only change units between US cents and US dollars, between UK 
pounds, shillings and pence, but that would not be useful, once the 
currency has a standardized base unit (which, for instance, metric 
systems do not have).
> 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”.
Exactly!
>   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?
We do not. As any Dimension, the monetary value of a transaction is 
defined with respect to the relevant event. The purchase agreement 
defines the time of validity. The CRM is not intended as a stock market 
system. Queries to a knowledge network including conditions of real 
market values inferred from past agreements is a reasoning form that is 
to my understanding out of scope for the CRM. The question for the CRM 
is only how to interface with such systems. This requires an unambiguous 
definition of facts registered within CRM. This is given by binding the 
amount to the terms of the respective agreement or the nominal values of 
monetary tokens.
>
> 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.
I would argue that this does not solve the problem. Specifying USD, and 
a numerical value such as 125, 457,(which may appear in interest rates), 
is to my understanding unambiguous, with repect to the time of agreement 
or issuing of a monetary token, obligation etc. One can regard that all 
numerical values identify themselves, regardless if they have ever be 
mentioned, such as 
12354357646764675578900976.9987765443000000066655777755678990987664568443367

In case a fixed conversion has been applied, such as in France 
converting 100 Old Franc into 1 New Franc per definition, I think we 
should regard the currency to be changed.
>
> 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.
>
> {
>    "@id": "http://data.getty.edu/museum/Purchase/1",
>    "@type": "crm:E96_Purchase",
>    // …
>    "crm:P9_consists_of": {
>      "@id": "http://data.getty.edu/museum/Payment/2",
>      "@type": "pi:Payment",
>      "pi:paid_amount": {
>        "@id": "http://data.getty.edu/museum/MonetaryAmount/3",
>        "@type": "crm:E97_Monetary_Amount",
>        "rdf:value": 100
>      },
>      "pi:paid_to": {
>        "@id": "http://data.getty.edu/museum/Person/seller",
>        "@type": "crm:E21_Person"
>      },
>      "pi:paid_from": {
>        "@id": "http://data.getty.edu/museum/Person/buyer",
>        "@type": "crm:E21_Person"
>      }
>    }
> }
>
> This also lets us record, for example, if multiple currencies were used in the transaction (e.g. the price listed was in dollars, but the sale occurred in France and the currency exchanged was francs)
>
> Thoughts on these issues would be greatly appreciated.
I think this is a very good idea!

  CRM-SIG had decided in Oxford to create a business model as a separate 
unit, however volunteers for that did not become active. We had looked 
at an ontology for bronze age business transaction, for instance. The 
most general idea being, that payments are a special case of 
compensating obligations. I regard David Graeber's "Debt, the first 5000 
years" as a good comprehensive source about the anthropological aspects 
of money and obligation.

A first analysis revealed a surprising complexity of when, by what and 
by whom compensations are regarded to be satisfied, which actors are 
directly and indirectly involved, which are the combinations of facts 
causing obligations and satisfying obligations. The only clear picture 
we could safely standardize was this simple purchase, without entering 
payment complexity.

I would recommend all partners of this mailing list to experiment with 
extensions such as the above proposed, gather experience and then 
discuss again further.

A Happy New Year to all of you!

Martin
>
> Many thanks, and a happy new year to all!
>
> Rob Sanderson
> Semantic Architect
> J. Paul Getty Trust
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig


-- 

--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at ics.forth.gr |
                                                              |
                Center for Cultural Informatics               |
                Information Systems Laboratory                |
                 Institute of Computer Science                |
    Foundation for Research and Technology - Hellas (FORTH)   |
                                                              |
                N.Plastira 100, Vassilika Vouton,             |
                 GR70013 Heraklion,Crete,Greece               |
                                                              |
              Web-site: http://www.ics.forth.gr/isl           |
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20170106/19474e94/attachment-0001.html>


More information about the Crm-sig mailing list