N dimensional headers / multiple measures #24
Conversation
|
@zeginis Can you please take a look at what is written in this document and check you agree with it. It's primarily about adding support for multiple measures, N-dimensional data - but also covers sorting too. If you broadly agree with the bigger ideas, then I'll then merge it with the original table-format document. The example here is made up, but the plan is to integrate it with the real example from the original document, and also write it to use JSON-LD syntax etc... The bigger ideas to agree on are whether to adopt this approach for multiple-measures / and to switch to an N-dimensional view of the data. Smaller less important details are whether we use a nested array format for data vs Row major order etc... |
|
I agree that However, |
|
Hi @zeginis - Rick's example follows the approach we have taken with a lot of recent data cube data, including that for the Scottish Government, where we have a fairly generic measure (the qb:MeasureProperty) such as 'count' or 'ratio', then we use an attribute (linked to the observation using the sdmx:unitMeasure predicate) to say what the unit is. So if the value is (for example) 123, then we are saying that the value of the observation is a 'count' of 123 - and if you ask 'count of what?', the answer is 'births'. We have had many internal discussions on the best way to distribute the semantics between dimensions, measures and units so I appreciate alternative approaches are possible! But this is just to confirm that Rick's example is not a mistake, but is a conscious choice we made for modelling that data. |
|
Hi @BillSwirrl, in both cases (either use the 'births' as measure and the 'ration' as unit OR use the 'ratio' as measure and the 'births' as unit) I thinks it usefull the table format to model both the measure and the unit. I suggest we use some reserved words at the table format to distinguise measures and units |
Fixes #22 #20 #21.