Issue 327: Monetary Amount Identity

posted by Ritchard Light on 4/1/2017On 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.

posted by Richard Light on 4/1/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:

http://cidoc-crm.org/docs/cidoc_crm_version_6.2.2%20(WorkingDoc).pdf

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 comments:

    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.
    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.).
    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!
    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 modelled.

posted by Simon Spero on 4/1/2017

On Jan 3, 2017 6:06 PM, "Robert Sanderson" <RSanderson@getty.edu> 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.

The value of $1 (USD) is $1 (USD).  The purchasing power may vary over time, but nominal value remains the same.

If you have an account holding 2000 Brazilian Reals, this may have been worth $1000 (USD)  in 2014, but only be worth $500 (USD) in 2016; the value in Reals is unchanged.

When redenomination of a currency occurs, a new ISO 4217 code is assigned.

     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”. 

Strangely enough, the length of an inch has changed in the past.

"In 1959, the International yard and pound agreement defined the international yard as 0.9144 metres, and the imperial and US yards were redefined accordingly.

This resulted in the internationally accepted length of the imperial and US customary inch being exactly 25.4 millimetres. The international inch is 1.7 millionths of an inch longer than the old imperial inch, and 2 millionths of an inch shorter than the old US inch." (Wikipedia: Inch) 

posted by Martin on 6/1/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.
 

posted by Martin on 6/1/2017

Backing Stephen's comment, the idea is to implement E60 Number in an RDF/OWL type environment by an open series of data types specializing RDF literal, as is current practice  for time, GeoSPARQL, etc. The type of a Dimension could be bound to the use of certain data types. In general, Dimension should be specialized into subclasses for more complex forms of data. This should not be part of the core CRM, and is encoding specific,
RDBMS environments would need other guidelines.

Posted by Martin on 6/1/2017

Dear Simon,

Just a few details to add:

On 4/1/2017 10:52 μμ, Simon Spero wrote:
> On Jan 3, 2017 6:06 PM, "Robert Sanderson" <RSanderson@getty.edu> 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.
>
>
> The value of $1 (USD) is $1 (USD).  The purchasing power may vary over time, but nominal value remains the same.
Absolutely!
>
>  If you have an account holding 2000 Brazilian Reals, this may have been worth $1000 (USD)  in 2014, but only be worth $500 (USD) in 2016; the value in Reals is unchanged.
Actually, conversion rates may change in seconds, once they are traded.
>
> When redenomination of a currency occurs, a new ISO 4217 code is assigned.
That solves an ambiguity!
>
>      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”. 
>
>
> Strangely enough, the length of an inch has changed in the past.
>
> "In 1959, the International yard and pound agreement defined the international yard as 0.9144 metres, and the imperial and US yards were redefined accordingly.
>
> This resulted in the internationally accepted length of the imperial and US customary inch being exactly 25.4 millimetres. The international inch is 1.7 millionths of an inch longer than the old imperial inch, and 2 millionths of an inch shorter than the old US inch." (Wikipedia: Inch)
Great! Once we have a date for any Dimension association, even that does not cause any ambiguity.

I'd like to add, that all physics units are redefined relative to their empirical base definition as precision of instruments increase. This pertains also to absolute time.

posted by Richard Light on 6/1/2017

I think Rob's point is that there could be a URL to represent the concept of 'the sum of $100'.  You would use this same URL each time you wanted to express that concept, not 'a new instance for any new agreement'.  The URL would be an instance of E97 Monetary Amount, and so would have currency and amount specified within it, using an appropriate RDF encoding.

Anyway, that's implementation-specific stuff.  At the abstract level (i.e. the level at which the normative CRM is expressed), I wonder if it is helpful to have separate and independent 'value' and 'unit' properties for an E54 Dimension.  (This argument applies equally to E97 Monetary Amount, since it is a subclass of E54.)  It seems intuitively obvious to me that E60 Number should have its units bundled up within it, i.e. P91 should be a property of E60, not of E54.  It's all very well wanting to indicate that you can carry out arithmetic operations on instances of E60 Number, but if you treat them as dimensionless and add $300 to 14ft, the results are clearly meaningless.  Also, as noted previously this model doesn't allow you to specify a value made up of a number of components (ft and inches; dollars and cents).

I've just checked E47 Spatial Coordinates, which involve a rather different kind of combination to achieve a result, and I see that no attempt is made to analyse them down to this level.  An equivalent approach would involve specifying properties and classes which allow you to specify say latitude and longitude, and to specify the value of each, either as a single real number or as 'degrees, minutes and seconds': another example of a complex Dimension.

I'm puzzled as to what one is expected to actually record now for E54 Dimension.  The examples include 'the height of silver cup 232'.  Is this information to be simply inferred from the context, or is this the literal text that you are meant to record?  Either way, I'm concerned that useful information ('height') is either lurking within a text string or is lost completely, depending on which approach is intended.  Most working museum documentation systems will support 'Dimension measured' (e.g. height), 'value' (e.g. 23) and 'units' (e.g. 'mm') (with the latter two fields being repeatable as a pair).  How does the current proposal support such an approach?

Posted by Robert Sanderson on 7/1/2017

Thank you, Martin!

I think the explicit addition that the value is the face value, not the market value, would make the usage clearer. Perhaps even adding that the time associated with an activity with which the Monetary Amount is associated should be used for comparison, if that degree of accuracy is important and historical market values are available? 

And, if I understand you on the topic of Dimensions, the intent is the same? That a Dimension with a value of 3, and a Unit of inches, is the equivalent notion of the face value of the observed length, however it happens to be extremely stable as to the “buying power” of that particular unit … however per Simon’s informative email, before 1959 the imperial and US inch currencies were very fractionally different from what we call an inch today and using the date and location of observation (if known) would be important for Very Large numbers of inches.

If I had two measurements of:

_:big a E54_Dimension ;
  P90_has_value 2000000 ;
  P91_has_unit <uri-for-inches> .

And one was associated with a Measurement performed in 1950 in France, the other in 1970, the two quantities are actually off by one.
The interpretation of the combination of the value and unit seems dependent on the date of the activity that established it, and thus is the scope note correct that the quantity the instance of Dimension describes is independent from the observed approximation?  Or am I just misunderstanding the intent of scope note?

To look at it another way, for the activity of assessing the value of an object, would you say that’s an E16 Measurement, that P39 measured the object, and P40 observed dimension of the Monetary Amount?
(perhaps also with a P2_has_type of aat:300054622, “appraising”) 

[More about the identity question in the other thread]

posted by Martin on 7/1/2017

Dear Richard,

On 6/1/2017 7:57 μμ, Richard Light wrote:
>
> On 2017-01-06 2:06 PM, martin wrote:
>> Dear Robert,
>>
>> Thank you very much for your message! Let me first comment your initial mail.
> Martin,
>
> This reply of yours has only just popped into my in-box, so my previous reply was written before I had read it.
>
>> 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.
> I don't see how this argument applies to measurement of museum objects, given what is already in the CRM.  We have E16 Measurement, which is an attribute assignment activity, with properties P39 measured specifying the thing measured, and P40 observed dimension giving the result of the measurement activity.  This is an E54 Dimension: the very thing we are discussing.  The examples in the scope notes include the length of museum objects.  If measuring museum objects is 'out of scope', what are these classes and properties doing in the CRM?
I never said that measuring is out of scope. I said that reasoning about precise dimension values is out of scope. Applications that do have the problem would first filter out certain contextual parameters, then verify the quality of the available data, and then feed the numerical data into a specialized system doing further processing.
>
> Also, while I agree that it is unlikely that anyone would search for all objects that are exactly a certain length, they might very well be interested in objects that have dimensions which are less than or greater than a certain value.
That might be the case. If it is, your proposal to split a length value into feet and inches is exactly the opposite to do. Then, we normalize to a common standard, i.e., e metric interval. The applications I know of is packaging for exhibitions etc. This is a local problem in the museum. Packaging dimensions require a specific method, e.g., using a box with adjustable walls.

But, asking the audience: Who has a real use case for this scenario? This is not to question your argument, it is a serious question.
>
>
>> 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.
> Measuring objects is a core part of museum documentation.  There is a wealth of existing 'established practice' to support this.
Of course. Not only measuring lentghs, but a large variety of analytical methods. This is a domain of CRMSci.
For instance, spectral analysis of colorants. But you would query for "egyptian blue", and then question the measurement data. You would not query for spectral values. Therefore, spectral values need not be accessible to SPRQL queries, only obviously connected to the object and the analysis events. Please conservators to correct me!

Best,

Martin

posted by Dominic on 7/1/2017

Happy new year!

Just preparing to go back to work next week and saw this thread.

From my quick reading of the emails it is of course possible to place a time span on any event/activity such as a measurement event and connect that to a dimension that has a P2_has_type (height, width, US inch, US inch (pre-1959), Swedish inch, etc and a P90 value and P91 unit.

Our own mapping uses P2_has_type to provide the type of dimension of an E54 and then uses a vocabulary (E55) provided by qudt http://www.qudt.org/ (or local vocab for more specialized dimension types not available in qudt). We also use qudt for unit but again you can add your own historic ones - e.g.

On a more general data integration point I was interested in Rob's email about the pre-1959 inch and looked it up. I assume that Rob has the data that provides a date of each measurement activity, and that all inch's are US and that those actors who did the original measuring adhered to the different inches at the exact time of change in 1959. I know that in Britain we might have been less than quick at changing to new fancy EU measurements and distributing new rulers! and in any event changing measurements is usually transitional (the Swedish inch was transitioned between 1855 and 1863 - quite an efficient eight years). It seems that more generally in history the inch has been less than a standard. If the purpose is to query or construct triples that provide consistent metric conversions, for example, then the more diverse the integrated data (our primary aim is to integrated diverse data) the more complex it becomes. On wiki media (and wikipedia) they have the following image. https://en.wikipedia.org/wiki/Inch#/media/File:Inch_converter.jpg. I cite http://themetricmaven.com/ from which I have derived the information for this email and which is devoted to US metric system and its history. The site author has also published a book called

"The Dimensions of the Cosmos: Tales from 16 Metric Worlds" (by Randy Bancroft) described as follows,

"Originally, our world was described using a plethora of provincial ad hoc measurement units only of everyday dimensions. The US inch was initially defined as the length of three barleycorn placed end-to-end, and is the current basis of US shoe sizes. The invention of the microscope and telescope in the 17th century revealed unimagined new macroscopic and microscopic worlds. The Dimensions of the Cosmos takes the reader on a tour of these hidden worlds with the only measurement system designed to intuitively describe them, the modern metric system."
 
From the wiki media image the metric maven site reproduces the following table. It should also be noted that the Swedish inch also changed in the later part of the 19th century and please note the large variation particularly for the Russian inch.

    Hamburgh – Inch divided into 8 parts. 1 inch ≈ 23.2 mm
    Austrian – Inch divided into 8 parts. 1 inch ≈ 25.8 mm
    Itallian – Inch divided into 8 parts. 1 inch ≈ 28.3 mm
    Bremen – Inch divided into 10 parts. 1 inch ≈ 23.7 mm
    Swedish – Inch divided into 12 parts. 1 inch ≈ 24.3 mm
    Turkish – Inch divided into 12 parts. 1 inch ≈ 31.3 mm
    Bavarian – Inch divided into 12 parts. 1 inch ≈ 24.0 mm
    Spanish – Inch divided into 12 parts. 1 inch ≈ 23.0 mm
    Portuguese – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
    Moscow – Inch divided into 12 parts. 1 inch ≈ 27.7 mm
    Russian – Inch divided into 8 parts. 1 inch ≈ 44.1 mm
    Amsterdam – Inch divided into 12 parts. 1 inch ≈ 23.5 mm
    Rhynland – Inch divided into 12 parts. 1 inch ≈ 26.1 mm
    French – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
    Fr. Metre – Centimetres divided into millimetres
    English – Inch divided into 32 parts. 1 inch ≈ 25.3 mm

I will pass this on to our own documentation section for their comment.

Although obviously important from an institutional documentation point of view, I agree with Martin in that when you are exploring integrated datasets you probably don't want to rely on dimension values as the main exploration mode and we are instead looking at how best to display dimensions as facets once the result set is reduced to a more useful graph using more global categories. The interfaces that FORTH and BM are currently working on do precisely this and we are both at a stage trying to understand what relationships work best at the more macro level and what information is better left at a facet or micro (record) level. For my own part this data is often (whatever the dataset) affected by varying standards and inconsistent validation over time, and so attempting to provide faceted dimension ranges (which might be useful to users at another level of exploration) becomes difficult, but at the moment, given current feedback probably makes this marginal work at the moment. However, I do hope to be able to provide CRM-SIG with some practice information at some point.

On this point we have made our beta exploration system public to get some feedback when we visit colleagues at www.researchspace.org/home/public (or a link to it is here) and we will be working with FORTH to understand the optimal set of fundamental categories and relationships for different purposes and situations to further refine the beta before formal release. This type of system is very different from keyword searching because instead of masking data issues by simple indexing keywords and prioritizing recall, it actually and deliberately exposes data issues writ large. This is necessary if we are to collaborate on identifying and enriching key data. In many cases, what I see as really important categories of information and context for wider audiences (including researchers) are missing from traditional catalog data using standards not designed for open world engagement and research. I'm not saying that there isn't a research or engagement question, (particularly given Randy's book), for which the minutiae of measurement related to cultural heritage collections wouldn't be valid or interesting (and I don't know the level of precision needed for provenance assessments which is something more internal), but I suspect from the emails that we currently have some good coverage in CIDOC CRM linked to its open world purpose, particularly now with CRMSci - and as Martin says, we can easily specialize locally if we want to reflect local documentation issues. These discussions are good for provoking practical use cases for future CRM -SIG meetings and modeling issues - and on that note once I have a copy of Randy's book, I may have much much more to say..... 

;-) 

posted by Robert Sanderson on 18/1/2017

Hi Simon,

I agree with you completely   40 yards is a length, 5.28 seconds is a duration, 1 million USD is a value.  In which case, there need only be ever one URI that is the identity for the length “40 yards” or the value “1 million USD”. However, if you say that 40 yards is actually a height in some instances, and a width in others, now it is specific to a particular orientation of a particular object and you need different identities for each Dimension / Monetary Amount.

Hence, given Martin’s statement that height is a p2_has_type addition to a Dimension, I could equivalently have Types of Starting Price, Hammer Price, Estimated Price, Paid Amount and so on in the Auction use case.  Making those Monetary Amounts tied exclusively to the Auction.  And hence my assertion that this is not “just” an implementation detail, but an ontological design choice.