[Crm-sig] ISSUE MonetaryAmount Identity

Richard Light richard at light.demon.co.uk
Fri Jan 6 19:33:38 EET 2017


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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20170106/b07add7b/attachment.html>


More information about the Crm-sig mailing list