Having measures as columns (#23) gives us the possibility of getting rid of the magic Value column (i.e. any column defined with no component type).
The examples below describe the distinction between how we might declare a cube using the multi-measure and measures-dimension approaches outlined in the RDF Data Cube specification. The use of a Value column only pertains to the measures-dimension approach. The choice, then, is whether to keep the Value or instead declare this in measures columns instead. Examples of the various observation declarations follow.
On the one hand, removing the Value column would be cleaner for machine-processing, as then the observation-csv is tidy - one row per observation, one column per component. This also removes the potential for confusion that has arisen around how the measure property is determined (i.e. currently the cell values in Measure Type needs to correspond to column titles of configurations for measure columns that themselves are never used as columns).
On the other hand, owing to the de-normalisation of the measure type dimension in cubes, without a Value column, you end up with a measure-columns <> Measure Type dependency and thus integrity problems (dependent updates between cells) and redundancy (all but 1 measure column will be empty in any given row). Having a Value column is definitely neater for human-readers, and potentially for machine-writers (no need to synchronise dependent updates).
If we do want to remove the Value column then we'd also need to think about backward compatibility, although we could use ons-table2qb to act as a compatibility layer (it would convert a Value column into measure columns before passing the results to table2qb).
Having measures as columns (#23) gives us the possibility of getting rid of the magic
Valuecolumn (i.e. any column defined with no component type).The examples below describe the distinction between how we might declare a cube using the multi-measure and measures-dimension approaches outlined in the RDF Data Cube specification. The use of a
Valuecolumn only pertains to the measures-dimension approach. The choice, then, is whether to keep theValueor instead declare this in measures columns instead. Examples of the various observation declarations follow.On the one hand, removing the
Valuecolumn would be cleaner for machine-processing, as then the observation-csv is tidy - one row per observation, one column per component. This also removes the potential for confusion that has arisen around how the measure property is determined (i.e. currently the cell values inMeasure Typeneeds to correspond to column titles of configurations for measure columns that themselves are never used as columns).On the other hand, owing to the de-normalisation of the measure type dimension in cubes, without a
Valuecolumn, you end up with a measure-columns <>Measure Typedependency and thus integrity problems (dependent updates between cells) and redundancy (all but 1 measure column will be empty in any given row). Having aValuecolumn is definitely neater for human-readers, and potentially for machine-writers (no need to synchronise dependent updates).If we do want to remove the
Valuecolumn then we'd also need to think about backward compatibility, although we could use ons-table2qb to act as a compatibility layer (it would convert aValuecolumn into measure columns before passing the results to table2qb).one measure
multi-measure approach
measure-dimension approach (with measure columns)
measure-dimension approach (with value columns)
many measures
multi-measure approach
measure-dimension approach (with measure columns)
measure-dimension approach (with value columns)