jstcki
commented
6 years ago @ktk,
Following up on the idea I posted on Slack, and to align it more with the terminology of the RDF Data Cube Vocabulary.
I think the solution might be to have multiple slices per dataset. Slices, as defined in the Data Cube Vocabulary, are groups of observations, used "to fix all but one (or a small subset) of the dimensions and be able to refer to all observations with those dimension values as a single entity". As I understand it, the Data Cube Slice aligns pretty well with what we've named "Facet" (or even a combination of dimensions).
Slice Shapes
Note: this is primarily about the Shape of Slices. Accordingly, all the metadata described below must be available on the Shape endpoints of a dataset. The Shape would contain all Slices of a dataset, so the frontend can decide which chart configuration and controls to render (and which Slice Data to query).
Option A: "Open" Slices
One option could be to keep the Slice definition open. That means a slice would group all observations which share the same dimensions but can have different dimension values. In addition, RAUM would be a kind-of-fixed dimension but not on the individual value but on groups of values (i.e. Stadt, Kreise, Quartiere etc). For example:
- slices:
- SEX + Kreise
- contains dimensions:
- SEX
- Kreise
- facets:
- M + Kreis 1
- F + Kreis 1
- M + Kreis 2
- F + Kreis 2
- ...
- SEX + HEL + Kreise
- contains dimensions:
- SEX
- HEL
- Kreise
- facets:
- M + Schweiz + Kreis 1
- F + Schweiz + Kreis 1
- ...
As seen here, the "Open" Slices would still need to be described with Facets or possible (= existing!) combinations of dimension values.
Option B: "Fixed" Slices
The other possible option could be Slices where all dimension values are fixed (except time). These slices would be equivalent with our "Facets". For example:
- slices:
- M + Kreis 1
- M + Schweiz + Kreis 1
- F + Kreis 1
- F + Schweiz + Kreis 1
- ...
This would be the simpler and less structured approach, but still contain all necessary information for the frontend to construct charts (I think!).
Bonus: In addition to Slices with fixed RAUM and open TIME dimensions, we maybe could also have fixed TIME and open RAUM dimensions alongside them (maybe on different URIs?), useful to create maps … just a thought.
Currently this is my preferred option because it's simpler and more information-rich than what we originally proposed (because value/time domains on a Facet level).
Common Slice properties
Both variants of slices need to specify a few properties per Slice for them to be useful and usable:
- value domain (min, max)
- time domain (from, to)
- title (generated from the dimensions, e.g. "Ausländer und Ausländerinnen im Kreis 2")
- the list of dimensions that are contained in the Slice (and the dimension values if fixed)
Slice Data/Observations
Based on the information about the Shape of the Slices of a Dataset, the frontend should be able to fetch the data of one or more Slices. Ideally, the endpoint which returns Observations can be parameterized with one or more Slices which would be equivalent of an OR query. For example http://stat.stadt-zuerich.ch/api/dataset/BEV001/data?slice=S1&sliceS2 would return observations in both Slices S1 and S2. (This is important, so we don't need to do multiple fetches per graphic)
Final Notes
- A good dataset to test this is BEV001, since it contains obervations with different dimension combinations, i.e. it has multiple slices as per the definition above (e.g. BEV032 is not a good dataset to test this, since it only contains one slice anyway!)
- @lucguillemot I'm currently not 100% sure if we really need the additional grouping described in Option A from the API, I think Option B where 1 Slice = 1 Facet would be sufficient to group slices in meaningful ways.
l00mi
ktk
sszscm
MauroBaster
cf. https://sszvis-components.netlify.com/#/api-specs
Shape API
The metadata of a dataset should be sufficient to decide on all the possible ways this dataset can be visualized, including controls like dropdown-menus to change on the fly the data subsets, the possibility or not to switch from a map view to a chart view, if a time series is present, if several small line charts are preferable to a single line chart with many lines (unreadable), if the option to use a bar chart should be available or not, if bars should be grouped or stacked, etc.
See the prototype of the front-end app to get a hint on the user experience that flows from the data structure: https://projects.invisionapp.com/d/main#/console/13100338/273973736/preview
Here is a list of missing metadata:
_:b0Raumvalues should be grouped by type of geographical entity. For instanceKreis = Kreis 1orQuartier = Hönggand notraum = Seebach. This will be used to decide which base map to use, and also to group by consistent geographical levels.idand aname, for instance “Bevölkerungbestand nach Religion, Heimatland und Stadtkreise”Slices
raumshould be one of the geographical entities (Kreise, Stadtquartier, Stadt, Statistische Zonen, Wahlkreise, Historische Stadt, Historische Kreise, etc. )Error 503here: http://stat.stadt-zuerich.ch/api/dataset/BEV001/slice