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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
