Separate "measures" lookup table at structure

[zeginis]

It would be usefull to have also information about the measure at the structure of the table format. These information include:

• The URI
• The label
• The unit of measure
• other??

We can also consider the support of multiple measures by the table format

[RickMoynihan]

Agreed. Where possible we tend to view measure's like other dimensions, and I'd intended to include them in the locked_dimensions / free_dimensions buckets, though if we're being pedantic we might want to then rename the keys something like locked_components & free_components. Or could put them under a measures key - any preferences on this @zeginis?

I've started another ticket #20 to discuss multiple measures. Will have a chat with people here at Swirrl to see what we might want to propose for that.

[zeginis]

I think it is better to have a separate measures key. This will give us also more flexibility also for the expression of multiple measures.

[RickMoynihan]

I'm not sure I agree we're thinking that measures are mostly just another dimension, and that we should make them look like that to API users by returning values not observations in cells.

We're thinking we're going to change the data format in the spec to support N-dimensional cases after all, and assume a kind of multi-column table representation. We're planning to write some of this up as part of #21 and #20.

Regarding multiple measures, we think a measure's value will be the cell object, but it'll probably link to the observations URI so measure-properties will appear as basically just another dimension in the headers (which will also change).

We think this will allow us to handle both styles of cube, i.e. ones where there are multiple measures on a single obs and ones where there are multiple observations for each measure.

Effectively we'll be exploding multiple-measure observations into the "free measure dimensions", abtracting across both cube representations.

[RickMoynihan]

I do agree though that it's also useful to treat measures differently in some circumstances, so would suggest that though we categorise them together under free_components and locked_components that we provide some type information on the objects that lets implementers display and handle them differently should they require.

Basically we're thinking that the API should try and abstract and hide the difference between these two different styles of cube - especially with regards to locking/freeing components.