subject:"\[Crm\-sig\] 6.2.2's MonetaryAmount and Currency"

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-07 Thread Dominic Oldman

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 expl

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-07 Thread martin


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

Of course.

Richard


--

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



___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig


--
*Richard Light*


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig



--

--
 Dr. Martin Doerr  |  Vox:+30(2810)391625|
 Research Director |  Fax:+30(2810)391638|

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-07 Thread Jim Salmons

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,Jim
_
From: Robert Sanderson 
Sent: Friday, January 6, 2017 5:18 PM
Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency
To:  , martin 
Cc: David Newbury 



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 200 ;
  P91_has_unit  .

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]

Thanks!

Rob

On 1/6/17, 6:06 AM, "Crm-sig on behalf of martin"  wrote:

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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-07 Thread Robert Sanderson



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 200 ;
  P91_has_unit  .

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]

Thanks!

Rob

On 1/6/17, 6:06 AM, "Crm-sig on behalf of martin"  wrote:

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.

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-06 Thread Richard Light


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.

Richard

> -- 
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>Center for Cultural Informatics   |
>Information Systems Laboratory|
> Institute of Computer Science|
>Foundation for Research and Technology - Hellas (FORTH)   |
>  |
>N.Plastira 100, Vassilika Vouton, |
> GR70013 Heraklion,Crete,Greece   |
>  |
>  Web-site: http://www.ics.forth.gr/isl   |
> --
>
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

-- 
*Richard Light*

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-06 Thread martin


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" > 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.9144metres, 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.


Best,

Martin


Simon



___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig



--

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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-06 Thread martin

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.

Martin

On 5/1/2017 4:57 πμ, Stephen Stead wrote:

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

Stephen Stead
Tel +44 20 8668 3075
Mob +44 7802 755 013
E-mail ste...@paveprime.com
LinkedIn Profile http://uk.linkedin.com/in/steads

-Original Message-
From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Robert 
Sanderson
Sent: 04 January 2017 18:39
To: Richard Light ; crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency


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  .

_:p2 a Purchase ;
   transferred_ownership_of _:object2 ;
   sale_price  .

_:p3 a Purchase ;
   transferred_ownership_of _:object3 ;
   sale_price  .

 a MonetaryAmount ;
   value 100 ;
   currency  .


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  ], [
   a Dimension ;
   value 6 ;
   unit  ] .

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.



Rob

On 1/4/17, 12:23 AM, "Crm-sig on behalf of Richard Light" 
 wrote:
 On 2017-01-03 11:01 PM, Robert Sanderson 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.  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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-06 Thread martin


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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-05 Thread Stephen Stead

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

Stephen Stead
Tel +44 20 8668 3075 
Mob +44 7802 755 013
E-mail ste...@paveprime.com
LinkedIn Profile http://uk.linkedin.com/in/steads

-Original Message-
From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Robert 
Sanderson
Sent: 04 January 2017 18:39
To: Richard Light ; crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency


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  .

_:p2 a Purchase ;
  transferred_ownership_of _:object2 ;
  sale_price  .

_:p3 a Purchase ;
  transferred_ownership_of _:object3 ;
  sale_price  .

 a MonetaryAmount ;
  value 100 ;
  currency  .


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  ], [
  a Dimension ;
  value 6 ;
  unit  ] .

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. 



Rob

On 1/4/17, 12:23 AM, "Crm-sig on behalf of Richard Light" 
 wrote:   
On 2017-01-03 11:01 PM, Robert Sanderson 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.  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 anal

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Simon Spero

On Jan 3, 2017 6:06 PM, "Robert Sanderson" 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,
<#m_-9186408886729773087_m_-239957202859173186_m_-2910843439945447373_m_-5890627998445079603_cite_note-FR59-5442-21>
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)

Simon

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Robert Sanderson



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  .

_:p2 a Purchase ;
  transferred_ownership_of _:object2 ;
  sale_price  .

_:p3 a Purchase ;
  transferred_ownership_of _:object3 ;
  sale_price  .

 a MonetaryAmount ;
  value 100 ;
  currency  .


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  ], [
  a Dimension ;
  value 6 ;
  unit  ] .

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. 



Rob

On 1/4/17, 12:23 AM, "Crm-sig on behalf of Richard Light" 
 wrote:   
On 2017-01-03 11:01 PM, Robert Sanderson 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.  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 occurre

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Richard Light

Chryssoula,

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:

 1. 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.
 2. 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.).
 3. 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!
 4. 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.

Best wishes,

Richard

On 2017-01-04 1:07 PM, Chryssoula Bekiari wrote:
> 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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Chryssoula Bekiari

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,

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Richard Light


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

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
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

-- 
*Richard Light*

[Crm-sig] 6.2.2's MonetaryAmount and Currency

2017-01-04 Thread Robert Sanderson



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

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

[Crm-sig] 6.2.2's MonetaryAmount and Currency

15 matches

Site Navigation

Mail list logo

Footer information