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
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
