search

lcnetdev / bibframe-ontology

Repository for versions of BIBFRAME ontology.
http://www.loc.gov/bibframe/
49 stars 7 forks source link

Deprecate the bf:dimensions datatype property, and advocate for the use of the ARM Measurement Ontology #39

Closed sfolsom closed 3 years ago

sfolsom commented 6 years ago

Justification: The ARM Measurement Ontology (https://ld4p.github.io/arm/measurement/ontology/0.1/measurement.html), though a relatively simple model, provides greater machine actionable expressivity over the current bf:dimensions. In current MARC cataloging practice dimensions are recorded in one single subfield (300 $c) even if the content standard or domain specific cataloging practice direct the cataloger to record the measurements in much more detail. BIBFRAME has carried this forward by defining the datatype property bf:dimensions. However, there are number of domain specific ontologies (such as QUDT, VRA RDF and CIDOC CRM) that do provide more granularity and in 2015 a discussion paper was submitted to the Committee on Cataloging: Description & Access to expand RDA instructions in this area. This ARM Measurement Ontology provisions for pairing measurements and their units in such a way that sizes, durations, etc. can be computed and compared.

By deprecating bf:dimensions and using the ARM Measurement Ontology, the BIBFRAME community would have a single expressive pattern to describe measurements with BIBFRAME implementations.

Note: For more information on the recommended implementation of the ARM Measurement Ontology (including the reuse of QUDT terms), see: https://github.com/LD4P/arm/blob/master/modeling_recommendations/measurements.md

[This recommendation was made on behalf of the LD4P Art & Rare Materials BIBFRAME Ontology Extension (https://github.com/LD4P/arm).]

klngwll commented 6 years ago

I think the idea to split up value and unit is a great one that could bring alot of value, for example in facets. However given the nature of the existing data in the MARC21 300#c field it would require work in splitting values and matching units. Therefore it would make sense to also have something of a note-like Class for Dimensions (again advocating for subClassed Note types) which could support content which is either not analyzed or failed to split and match.

From what I can see LC is already thinking in these lines with 300#b and 300#e.

If dimensions were an ObjectProperty it could also support more complex descriptions and less scattering of information.

sfolsom commented 6 years ago

Legacy data is a valid concern; we too had considered a note type. Instead, in the model we proposed... we leaned toward using an rdfs:label off of a arm:MeasurementGroup or a arm:Measurement for storing strings like those found in 300 $c. The thought was that if we wanted entities specifically for measurements, we should try to attach the human readable labels to those entities, rather than a separate Note entity.

kefo commented 3 years ago

Did not deprecate the property, but did add a note advertising the ARM Ontology as an alternative. This is a conservative decision. Time may suggest it be revisited.

https://id.loc.gov/ontologies/bibframe.html#p_dimensions