Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

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

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
  • live links to CRM & BMX classes
  • 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)


  • 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
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.