[Crm-sig] ISSUE MonetaryAmount Identity

martin martin at ics.forth.gr
Sat Jan 7 19:25:24 EET 2017


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 at 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: martin at 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           |
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20170107/fa9ec4dc/attachment-0001.html>


More information about the Crm-sig mailing list