Monetary Amount Identity

posted by  Robert Sanderson  on 4/1/2017

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? 

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

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.

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.

Many thanks, and a happy new year to all!

Rob Sanderson
Semantic Architect
J. Paul Getty Trust

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 Chryssoula on 4/1/2017

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%….)

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%28curr… 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.

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 Robert Sanderson on 4/01/2017

Hi Richard,

I agree that the Currency should be constant unless the monetary system changes, regardless of the changing value.  However that’s not what is implied by Monetary_Amount being a subclass of Dimension, where the actual value is independent of the approximation.  For the subclass to be valid, the features of the parent class must be valid for the child class (All Persons are Actors, and all of the features of Actor are valid for Person).  Ergo, the proposed structure is invalid, or the scope notes for Dimension should be changed to say that 6 inches is the face value, not the independent absolute value.

Regarding the URI discussion, the URI would not be the value of the Monetary_Amount, just its identifier.
For example, if three artworks each sold for $100, the instance of Monetary_Amount referenced from each Purchase can be the same instance.  In short hand:

_:p1 a Purchase ;
  transferred_ownership_of _:object1 ;
  sale_price <uri-for-$100> .

_:p2 a Purchase ;
  transferred_ownership_of _:object2 ;
  sale_price <uri-for-$100> .

_:p3 a Purchase ;
  transferred_ownership_of _:object3 ;
  sale_price <uri-for-$100> .

<uri-for-$100> a MonetaryAmount ;
  value 100 ;
  currency <uri-for-dollars> .

And from your second email, I agree (per your point 3) that P181 is unnecessary if a Monetary_Amount is a Dimension. And an equivalent case of pounds, shillings and pence for your point 4 would be also important to take into account for currency.  Both could be solved by allowing sub-values of a larger whole:

_:total a Dimension ;
  consists_of [
      a Dimension ;
      value 3 ;
      unit <uri-for-feet> ], [
      a Dimension ;
      value 6 ;
      unit <uri-for-inches> ] .

The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm.  The approach taken by timespan with begin_of_the_begin and end_of_the_end might be appropriate to duplicate here, if recording the precision is important. 

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 Steve  on 5/1/2017

Not commenting on everything but
" The scopenotes for Dimension recommending intervals seem to be out of date – as value is explicitly a number, it’s impossible to say 3.9-4.1 cm.  "
The value is tied (via P90) to an instance of E60 Number not a number. E60 Number includes, explicitly, intervals.

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 Martin on 6/1/2017

Dear Robert, Richard

On 4/1/2017 8:39 μμ, Robert Sanderson wrote:
> Hi Richard,
>
> I agree that the Currency should be constant unless the monetary system changes, regardless of the changing value.  However that’s not what is implied by Monetary_Amount being a subclass of Dimension, where the actual value is independent of the approximation.  For the subclass to be valid, the features of the parent class must be valid for the child class (All Persons are Actors, and all of the features of Actor are valid for Person).  Ergo, the proposed structure is invalid, or the scope notes for Dimension should be changed to say that 6 inches is the face value, not the independent absolute value.
As I mentioned in my other message, if the type of the Dimension is "nominal value", there is no conflict. Further,
to my best knowledge there is no other absolute value to money, in particular once the gold standard has been abandoned.
>
> Regarding the URI discussion, the URI would not be the value of the Monetary_Amount, just its identifier.
> For example, if three artworks each sold for $100, the instance of Monetary_Amount referenced from each Purchase can be the same instance.
I think this is interesting and should be clarified! We can take the position that an agreed on amount, regardless being value-identical with another, is a new instance for any new agreement. I'd rather tend to this interpretation,
once "one meter" is not an instance of Dimension! This is an issue to be described in the scope note.

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 Richard on 6/1/2017

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?

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.

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

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 Jim Salmons on  7/1/2017

Happy New Year to All,

While I have been enthusiastically following the conversations here of latte, I have been quiet and very focused on my wife's and my move from Cedar Rapids, Iowa USA to Broomfield, Colorado which is very near the brilliant computational linguists and #UIMA researchers at the Colorado Computational Pharmacology research center in Aurora at the U. of Colorado (http://compbio.ucdenver.edu/). 

For what it is worth, Robert's insights about the time/place sensitivity to data values makes great sense from a long-time Smalltalk/OOP modeler's perspective. The expressive/extensible context-sensitivity of this aspect of the model is a strength of the CRM as a foundation for specific use. My concern is that efforts to go too fine-grained in the base model will turn off or confuse potential users who need to see their models as  non-conflicting extension of the base model rather than as a non-compatible alternative to parts of it.

Happy-Healthy Vibes,

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 Martin on 7/1/2017

On 6/1/2017 7:33 μμ, Richard Light wrote:
>
> Martin,
>
> 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'.
Yes, I understood that. I said to my opinion this representation does not solve a relevant question. So, please tell me a research question, in which this representation makes the critical difference.
>
> 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).
The Dimension has a type which indicates, if adding up makes a sense or not. So, there is no such ambiguity that someone would add up dollars and feet. Anyway, adding values needs compatible dimension type, compatible mathematical space, and identical reference space. I think you argue outside of real life questions .
>
> 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.
We have discussed these issues. Current best practice is not to encode compound values by RDF properties for the constituents, but to use XML encoding of datatypes. An instance of E60 Number is one logical thing, and not the parts of a represenation of it. "12.56" is not 4 numbers and a letter, it is one thing. A vector in vector space is one thing, and not a 3-tuple. Therefore, the CRM as ontological standard stops there. In an implementation, continue with other standards in the datatype world.
>
> 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?
No, it is a human readable label standing for the URI. More precisely, it should even contain a date and a temperature, but silver cups do normally not shrink significantly.
>
> 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?
"Height" would be the P2_has_type of the Dimension instance. More precisely, "height in default position", because height does not make a sense without specifying how the object is placed. For comparision, "maximum linear extent" would be better, specifying the maximim distance between spots on the object.

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 Simon Spero 17/1/2017

>    It makes a difference *to the model* for the relationship between Linguistic Objects and Monetary Amounts.  For example, if the researchers for a particular sale conclude from a newspaper article that the final auction hammer price was $1M for the painting, is it that the Linguistic Object refers to the Monetary Amount as the generic face value of any old million dollars, or is it explicitly the million dollars that was the sale price?

I find it difficult to interpret the use of the term 'price' as referring to anything other than a dimensioned value, rather than a specific payment event involving the transfer of some specific assets.

It's analogous to a report stating that Tom Brady has a 40 yard dash time of 5.28 seconds, but Ben Roethlisberger has a 40 yard dash time of 4.75 seconds. Although, because these are the results of measurements, we can infer the existence of two specific intervals of time, and two specific patches of  ground, this is irrelevant to the report.

Also, suppose that instead of a hammer price of $1M, there had been a reserve price of $2M, and the highest bid was $1M. 
Then consider the counterfactual sentence "Had the reserve price not been $2M, the hammer price would have been $1M."...

Is it possible to compare the hypothetical hammer price to the reserve price? Does this require an implicit conversion between two radically different things?

In the original scenario, at the time that the hammer fell, the precise assets to be used to make the payment are not known. Suppose the buyer refuses to pay, and is sued for $1M plus interest  for the  breach of contract.  What do the various tokens  of  "$1M"  that would occur in the complaint refer to? On What is the interest calculated? 

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.

posted by Martin on 18/1/2017

Dear All,

In support of Robert:

Thomas Gruber in his paper foundational to ontology engineering "Toward Principles for the Design of Ontologies
Used for Knowledge Sharing" Revision: August 23, 1993 discusses this issue. We follow in a way his arguments, adding however the problem of a reality with fuzzy dimensions and limited capabilities of observation. Since we want to compare values with respect to a common reality, the exact mathematical magnitude is irrelevant for our
reasoning. I.e. , questions can be: Is this the same object?, Has this object changed? Would it fit into another one?  The answer to these questions can only be given if the dimension is that of the object at some time, and the value an approximation.

The monetary value on the other side, represents the agreed-on obligation of the receiver to the giver, created by the acquisition of the object, regardless being paid or not. As such, it is different from any other monetary amount, being by incident 100$ as well. If we extend the model in the future assigning such properties to the monetary amount, which then acquires a history of its own, another interpretation is incompatible. The identity of the abstract amount of being 100$, has to my understanding no reasonable use beyond being just what has been encoded.

The question in ontology engineering is not what sense we can give, but what are the minimal senses we need to answer reasonable questions in the discourse we target at.