View Source

{excerpt}BM extensions to CRM{excerpt}
Developed by Seme4 as part of BM data mapping to CRM

(i) [^D2 - Commentary on the mapping process- from BM to CIDOC-CRM.pdf]
Hugh Glaser, SotonU
- very informative description of the mapping, shows the complexity of museum data.
- detailed description of the developed CRM extension ontology (BMX).
- [^bm-extensions.ttl]: BMX ontology definition
- [http://crm.rkbexplorer.com]: live links to CRM & BMX classes
- [http://bm2.rkbexplorer.com]: live links to BM objects, but these are restricted
- instructive usage guide for the CRM. Mariana got some ideas re the Goteborg Museum mapping (part of MOLTO)
- instructive re proposal on Archaeological metadata (Totko Stoyanov)

Vladimir:
- CRM is a very rich ontology, but still not rich enough to capture collection data from different institutions
- BMX shows that extensions are needed
- the BM should drive towards unification and vigorously promote such extensions for CRM standardization, rather than relying on thesaurus mapping (mapping profiles) and co-reference, which make for more difficult reasoning
- BMX itself can be improved. Here are two examples from the very simple area of measurements (eg width, height):
-- Rather than using BM-specific URIs for units, it'd be better to map during conversion to ontologies that are more established in this area: NASA QUDT (Quantities, Units, and Dimensions) or OASIS UoM (Units of Measure)
-- CRM uses a single number (P90F.has_value) while BMX extends this to an interval (PX.min_value and PX.max_value). However, no connection is made between the interval and the single value. has_value should be computed during conversion, e.g. to be the average of min and max, or equal to min if max is undefined