On 1/7/17, 9:25 AM, "Crm-sig on behalf of martin" <crm-sig-boun...@ics.forth.gr
on behalf of mar...@ics.forth.gr> 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 “1000000 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
