Re: [Crm-sig] ISSUE MonetaryAmount Identity
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. Best, Martin On 18/1/2017 6:53 μμ, Robert Sanderson wrote: 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. Rob On 1/18/17, 8:45 AM, "Simon Spero" wrote: 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? Simon -- -- 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 (FO
Re: [Crm-sig] ISSUE MonetaryAmount Identity
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. Rob On 1/18/17, 8:45 AM, "Simon Spero" wrote: 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? Simon
Re: [Crm-sig] ISSUE MonetaryAmount Identity
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? Simon
Re: [Crm-sig] ISSUE MonetaryAmount Identity
On 1/7/17, 9:25 AM, "Crm-sig on behalf of martin" wrote:
On 6/1/2017 7:33 μμ, Richard Light wrote:
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.
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?
If the identity of the Monetary Amount can be reused, then there the article
should instead refer to the Activity that had the sales price of the Monetary
Amount.
[snip]
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.
If height [in the default orientation] is the type of the Dimension instance,
then it is a particular usage of that combination of value and unit. This
would mean, by inheritance from the superclass, that you would have to have
different instances for each different “use” of the face value “100 USD”.
At which point, you could just as easily treat it as a dimension completely
with a type for “sales price”, “starting price”, “estimated hammer price”, and
so forth, rather than needing a specific relationship.
Rob
Re: [Crm-sig] ISSUE MonetaryAmount Identity
Richard,
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.
best,
Martin
Best wishes,
Richard
On 2017-01-06 2:36 PM, martin wrote:
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.
--
*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] ISSUE MonetaryAmount Identity
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'. 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?
Best wishes,
Richard
On 2017-01-06 2:36 PM, martin wrote:
>> 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.
--
*Richard Light*
[Crm-sig] ISSUE MonetaryAmount Identity
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. Best, Martin 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]
