Definition of dimension values

[zeginis]

At the structure of the table are defined the "all_dimension_values".

In my opinion we need the dimension values only for the free dimensions. Why do we need the dimension values of the locked dimensions?

In the case we include only the values of the free dimensions then they could be merged with the headings. This means that the headings contain values like:

"headings": {"refArea": {"S12000005": {"@id": "http://statistics.gov.scot/id/statistical-geography/S12000005", "label":"Clackmannanshire"}, "S12000042": {"@id": "http://statistics.gov.scot/id/statistical-geography/S12000042", "label":"Dundee City"},....}

[RickMoynihan]

Hi @zeginis good questions... keep em coming :-)

The reason to provide dimension values for locked dimensions is so you can generate an interface like this during a drill down, where the application guides you into always ending at a valid slice table.

There is definitely some overlap in purpose between headings and free_dimensions, however the information in headings is really there to express the sort order for the headers, as defined in the RDF by something like ui:sortPriority.

Basically HashMaps or Objects in Javascript and other languages are usually un-ordered by default, therefore it's necessary to use Arrays to guarantee an ordering independent of any implementation.

[zeginis]

Hi @RickMoynihan,

• In my opinion we don't need to embed all the information at the table format. The interface can get the dimension values for the locked dimensions using other API calls i.e. GET /dimension-values

• You are right the headings should be ordered. Posibly we could use the following syntax that uses arrays for the order: "headings": {"refArea": [ {"S12000005": {"@id": "http://statistics.gov.scot/id/statistical-geography/S12000005","label": "Clackmannanshire"}}, {"S12000042": {"@id": "http://statistics.gov.scot/id/statistical-geography/S12000042","label": "Dundee City" }},...], "refPeriod": [ {"1999": {"@id":"http://reference.data.gov.uk/id/year/1999", "label":"1999"}}, {"2000": {"@id":"http://reference.data.gov.uk/id/year/2000", "label":"2000"}}, ...] }

• Another thing that we should have in mind is that the headings of the table may be different than ALL the dimension values of the cube due to sparce data. For example for a specific slice the year 1999 that exists at the complete cube may be missing due to missing data. ALL dimension values could also be different than headings due to pagination (e.g. the specific page may not contain all the values for a dimension)

[RickMoynihan]

Yes, we might well push the dimension-values data out onto a different API route.

Regarding syntax for headings, that is another alternative and one I did consider. Largely this stuff is down to personal preference with no clear reason to prefer one to the other. My reasoning for preferring just listing the keys was that I think it made the intention more obvious, and you can just lookup the definitions elsewhere. This does partly depend on API services generating good unique keys for the maps, from URI slugs etc...

Another reason to prefer listing just the keys though is that you can save some duplication, if we're also listing dimension-values (either under a separate object or route).

I agree that dimension values might not all be included due to pagination. We're assuming that the API will however return you the complete set of values for one axis (i.e. we're only planning to paginate in one dimension).

We were also thinking the other day that we should completely remove blank "rows" from the paginated axis so we can roll-up tables preventing people from having to page through hundreds of blank pages before finding the actual data at the bottom.