[Crm-sig] 6.2.2's MonetaryAmount and Currency

Dominic Oldman doint at oldman.me.uk
Sat Jan 7 22:45:59 EET 2017


Happy new year!

Just preparing to go back to work next week and saw this thread.

>From my quick reading of the emails it is of course possible to place a
time span on any event/activity such as a measurement event and connect
that to a dimension that has a P2_has_type (height, width, US inch, US inch
(pre-1959), Swedish inch, etc and a P90 value and P91 unit.

Our own mapping uses P2_has_type to provide the type of dimension of an E54
and then uses a vocabulary (E55) provided by qudt http://www.qudt.org/ (or
local vocab for more specialized dimension types not available in qudt). We
also use qudt for unit but again you can add your own historic ones - e.g.

On a more general data integration point I was interested in Rob's email
about the pre-1959 inch and looked it up. I assume that Rob has the data
that provides a date of each measurement activity, and that all inch's are
US and that those actors who did the original measuring adhered to the
different inches at the exact time of change in 1959. I know that in
Britain we might have been less than quick at changing to new fancy EU
measurements and distributing new rulers! and in any event changing
measurements is usually transitional (the Swedish inch was transitioned
between 1855 and 1863 - quite an efficient eight years). It seems that more
generally in history the inch has been less than a standard. If the purpose
is to query or construct triples that provide consistent metric
conversions, for example, then the more diverse the integrated data (our
primary aim is to integrated diverse data) the more complex it becomes. On
wiki media (and wikipedia) they have the following image.
https://en.wikipedia.org/wiki/Inch#/media/File:Inch_converter.jpg. I cite
http://themetricmaven.com/ from which I have derived the information for
this email and which is devoted to US metric system and its history. The
site author has also published a book called

"The Dimensions of the Cosmos: Tales from 16 Metric Worlds" (by Randy
Bancroft) described as follows,

"Originally, our world was described using a plethora of provincial ad hoc
measurement units only of everyday dimensions. The US inch was initially
defined as the length of three barleycorn placed end-to-end, and is the
current basis of US shoe sizes. The invention of the microscope and
telescope in the 17th century revealed unimagined new macroscopic and
microscopic worlds. The Dimensions of the Cosmos takes the reader on a tour
of these hidden worlds with the only measurement system designed to
intuitively describe them, the modern metric system."

>From the wiki media image the metric maven site reproduces the following
table. It should also be noted that the Swedish inch also changed in the
later part of the 19th century and please note the large variation
particularly for the Russian inch.



   - Hamburgh – Inch divided into 8 parts. 1 inch ≈ 23.2 mm
   - Austrian – Inch divided into 8 parts. 1 inch ≈ 25.8 mm
   - Itallian – Inch divided into 8 parts. 1 inch ≈ 28.3 mm
   - Bremen – Inch divided into 10 parts. 1 inch ≈ 23.7 mm
   - Swedish – Inch divided into 12 parts. 1 inch ≈ 24.3 mm
   - Turkish – Inch divided into 12 parts. 1 inch ≈ 31.3 mm
   - Bavarian – Inch divided into 12 parts. 1 inch ≈ 24.0 mm
   - Spanish – Inch divided into 12 parts. 1 inch ≈ 23.0 mm
   - Portuguese – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
   - Moscow – Inch divided into 12 parts. 1 inch ≈ 27.7 mm
   - Russian – Inch divided into 8 parts. 1 inch ≈ 44.1 mm
   - Amsterdam – Inch divided into 12 parts. 1 inch ≈ 23.5 mm
   - Rhynland – Inch divided into 12 parts. 1 inch ≈ 26.1 mm
   - French – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
   - Fr. Metre – Centimetres divided into millimetres
   - English – Inch divided into 32 parts. 1 inch ≈ 25.3 mm

I will pass this on to our own documentation section for their comment.

Although obviously important from an institutional documentation point of
view, I agree with Martin in that when you are exploring integrated
datasets you probably don't want to rely on dimension values as the main
exploration mode and we are instead looking at how best to display
dimensions as facets once the result set is reduced to a more useful graph
using more global categories. The interfaces that FORTH and BM are
currently working on do precisely this and we are both at a stage trying to
understand what relationships work best at the more macro level and what
information is better left at a facet or micro (record) level. For my own
part this data is often (whatever the dataset) affected by varying
standards and inconsistent validation over time, and so attempting to
provide faceted dimension ranges (which might be useful to users at another
level of exploration) becomes difficult, but at the moment, given current
feedback probably makes this marginal work at the moment. However, I do
hope to be able to provide CRM-SIG with some practice information at some
point.

On this point we have made our beta exploration system public to get some
feedback when we visit colleagues at www.researchspace.org/home/public (or
a link to it is here) and we will be working with FORTH to understand the
optimal set of fundamental categories and relationships for different
purposes and situations to further refine the beta before formal release.
This type of system is very different from keyword searching because
instead of masking data issues by simple indexing keywords and prioritizing
recall, it actually and deliberately exposes data issues writ large. This
is necessary if we are to collaborate on identifying and enriching key
data. In many cases, what I see as really important categories of
information and context for wider audiences (including researchers) are
missing from traditional catalog data using standards not designed for open
world engagement and research. I'm not saying that there isn't a research
or engagement question, (particularly given Randy's book), for which the
minutiae of measurement related to cultural heritage collections wouldn't
be valid or interesting (and I don't know the level of precision needed for
provenance assessments which is something more internal), but I suspect
from the emails that we currently have some good coverage in CIDOC CRM
linked to its open world purpose, particularly now with CRMSci - and as
Martin says, we can easily specialize locally if we want to reflect local
documentation issues. These discussions are good for provoking practical
use cases for future CRM -SIG meetings and modeling issues - and on that
note once I have a copy of Randy's book, I may have much much more to
say.....

;-)

Cheers and best for the new year,

Dominic




orcid.org/0000-0002-5539-3126

On Sat, Jan 7, 2017 at 5:02 PM, martin <martin at ics.forth.gr> wrote:

> Dear Richard,
>
> On 6/1/2017 7:57 μμ, Richard Light wrote:
>
>
> On 2017-01-06 2:06 PM, martin wrote:
>
> Dear Robert,
>
> Thank you very much for your message! Let me first comment your initial
> mail.
>
> Martin,
>
> This reply of yours has only just popped into my in-box, so my previous
> reply was written before I had read it.
>
> As a general remark to all other valuable contributions to this issue
> however: We should not loose focus: the CRM intends only to describe
> important facts for cultural-historical and scientific inquiries across
> integrated knowledge networks. If we want to describe any detail, we are
> free to put it in P2 notes or to make our own extensions. For instance, I'd
> argue that details of dimensions of museum objects are irrelevant to global
> queries. Would anybody research for all objects that could be 3.25 mm long,
> without any prior, substantial reduction of the search space? Without a
> strict scope limitation, we will end up modelling all sciences and
> businesses of the world.
>
> I don't see how this argument applies to measurement of museum objects,
> given what is already in the CRM.  We have *E16 Measurement*, which is an
> attribute assignment activity, with properties *P39 measured *specifying
> the thing measured, and *P40 observed dimension *giving the result of the
> measurement activity.  This is an *E54 Dimension*: the very thing we are
> discussing.  The examples in the scope notes include the length of museum
> objects.  If measuring museum objects is 'out of scope', what are these
> classes and properties doing in the CRM?
>
> I never said that measuring is out of scope. I said that reasoning about
> precise dimension values is out of scope. Applications that do have the
> problem would first filter out certain contextual parameters, then verify
> the quality of the available data, and then feed the numerical data into a
> specialized system doing further processing.
>
>
> Also, while I agree that it is unlikely that anyone would search for all
> objects that are exactly a certain length, they might very well be
> interested in objects that have dimensions which are less than or greater
> than a certain value.
>
> That might be the case. If it is, your proposal to split a length value
> into feet and inches is exactly the opposite to do. Then, we normalize to a
> common standard, i.e., e metric interval. The applications I know of is
> packaging for exhibitions etc. This is a local problem in the museum.
> Packaging dimensions require a specific method, e.g., using a box with
> adjustable walls.
>
> But, asking the audience: *Who has a real use case for this scenario? *This
> is not to question your argument, it is a serious question.
>
>
>
> CRM compatibility does not prohibit any local extension of topics outside
> its scope. Since CRM SIG acts as standardization body, it cannot be
> proactive to needs. It can only react after some established practices need
> harmonization.
>
> Measuring objects is a core part of museum documentation.  There is a
> wealth of existing 'established practice' to support this.
>
> Of course. Not only measuring lentghs, but a large variety of analytical
> methods. This is a domain of CRMSci.
> For instance, spectral analysis of colorants. But you would query for
> "egyptian blue", and then question the measurement data. You would not
> query for spectral values. Therefore, spectral values need not be
> accessible to SPRQL queries, only obviously connected to the object and the
> analysis events. Please conservators to correct me!
>
> Best,
>
> Martin
>
> Of course.
>
> Richard
>
> --
>
> --------------------------------------------------------------
>  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           |
> --------------------------------------------------------------
>
>
>
>
> _______________________________________________
> Crm-sig mailing listCrm-sig at ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
> --
> *Richard Light*
>
>
> _______________________________________________
> Crm-sig mailing listCrm-sig at ics.forth.grhttp://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           |
> --------------------------------------------------------------
>
>
>
> _______________________________________________
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20170107/198eb5fb/attachment-0001.html>


More information about the Crm-sig mailing list