search

RDFBones / FrAgeEst

An extension for RDFBones-O, implementing the generation, processing and documentation of cranial data for the purpose of age estimation as practised in Biological Anthropology at Freiburg University.
0 stars 2 forks source link

Define age ranges properly #9

Open zarquon42b opened 7 years ago

zarquon42b commented 7 years ago

Find a more suitable way of defining age ranges. Using a string might be not the best solution, as there is no way to validate the entry.

MasterChief13 commented 7 years ago

What about the following solution: we treat age ranges as categorical data and define a subclass of categorical label for each suture section. For example, for SutureSpecificAgeRange.CoronalSuture1 we define LabelForAgeRange.CoronalSuture1 which has three instances 'C1: <45', 'C1: 45-54' and 'C1: >54'. Then when can say that SutureSpecificAgeRange.C1 has exactly one LabelForAgeRange.C1. Thus, the researcher must choose exactly one of the three labels, i.e. age ranges. Is that "valid" enough?

cuboideum commented 7 years ago

The OBI development team is currently changing the OBI data model. As this process is not yet completed, it is not entirely clear how the final model will work. Still, our definition of value ranges should try to respect the new approach as much as possible. The current release notes (version 2017-02-22) contain the following known issues:

In the course of preparing OBI Core we have made significant changes to many of OBI's upper-level terms. However we have not yet had time to revise all the children of the changed nodes. In particular, many of the descendants of "measurement data item" have not yet been revised to use the new "value specification" approach.

The value specification approach is outlined in a paper entitled OBI Data Prototype, dating 16 August 2013. To what degree implementation into the OBI will follow this outline is not known.

The following exploration of the value specification approach is based on the current OBI version (2017-02-22).

rdfbones-o_datainobi_valuespecification

The basic idea of the value specification approach is that various data items might be attached to the same measurement datum, e.g. if an estimate and a true value are compared in an investigation. Therefore, values are linked to a value specification, not to the measurement datum. Instances of several value specifications can be linked to the same instance of a measurement datum.

Measurement data are are linked to the quality they assess via the 'is quality measurement of' property. This makes sense if, for example, the lengths of various features on a specimen are to be taken. Note that qualities encompass organismal qualities like biological sex. So, 'age at death' would also be a quality to be estimated.

rdfbones-o_datainobi_categoricalmeasurementdatum

With categorical measurement data, the individual labels (formerly known as categorical labels) are direct instances of the categorical value specification. These are referenced by the various measurement data.

As becomes clear from the example for scalar measurement values in the 'OBI Data Prototype' paper (cf. below), measurement data are quality measurements of instances of class 'quality' that represent this quality in a specific individual.

rdfbones-o_datainobi_scalarmeasurementdatum

Scalar value specifications are a composite of a measurement value and a measurement unit, as was formerly the case for the scalar measurement datum itself. The graph above is based on an example from the 'OBI data prototype' paper, where a mouse named Mickey is weighed and found to have a mass of 20 grams, and the 'mass value specification' class employed here is also the only one currently implemented into the OBI. The instance of class 'mass value specification' used in the example is called '20g specification'. This makes sense if a value for the collection of mice for use in an investigation is set, but not so much if the weights of several mice in an investigation is to be assessed. Note that for the set datum, a value range would make more sense than a precise value.

My suggestion for resolving this issue:

In order to introduce value ranges to the concept, a new child class of 'value specification' needs to be introduced: 'value range specification'. This would prescribe a measurement unit label and two data properties, 'has lower boundary' and 'has upper boundary'. I would prefer this solution over a categorical measurement datum, as the boundaries can be queried separately and used in calculations.

Alternatively, the boundaries could be individual value specifications, to the benefit of even more flexible queries and calculations. However, this approach would also considerably increase graph complexity.

cuboideum commented 7 years ago

I have opened a separate issue in the RDFBones-O repository for implementation into the core ontology.