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 ofhttp://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
[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
--
----------------------------------------------------------------------
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: [email protected]
Web-site: http://www.ics.forth.gr/isl/index_main.php?l=e&c=231
--------------------------------------------------------------------------------
