OS Viewer: Hierarchies not working?

[skarampatakis]

@larjohn In this dataset if you choose a hierarchy for the treemap view, and click on a rectangle it seems that nothing happens. For that specific case I know that the bottom level of the the hierarchy (economic classification) is defined as dimension value on the dataset.

Shouldn't the Viewer initialize the graph with the higher levels? So we can eventually drilldown the dataset in the deepest detail available.

[skarampatakis]

Any update?

[larjohn]

I need some more time. Please be patient.

[pwalsh]

@larjohn let us know if this is somewhat that the OKI team can help with.

[larjohn]

@skarampatakis is this information somehow explicitly available in the RDF or it should be inferred looking at the values?

[skarampatakis]

Yes, all information is available through the definition of the Concept Scheme, each codelist item belongs to.

[larjohn]

Cool, this is not implemented yet. Give me a couple of days and it will be there.

[larjohn]

@skarampatakis can you give an example (SPARQL preferred) that connects any two of those dimensions here:

http://data.openbudgets.eu/page/dataset/budget-thessaloniki-revenue-2011/slice/248

For your convenience, here is the model of the dataset:

[skarampatakis]

I am not sure that I have understand what you request. Could you please explain more? What I originally requested was to presesnt values as aggregations of the parents in the hierarchy, if it is available of course. For instance, in the greek case, this is applicable on the obeu-dimension:economicClassification, which represent a hierarchy.

On the dataset you have defined only the lowest level leaf. Let say kae:6421. But this is a leaf node in the hierarchy. So it goes like kae:6 -> kae:64 -> kae:642 -> kae:6421, where the arrow means skos:narrower and kae:6 is a top concept of the Concept scheme.

So if you know what is the longest path (the level of detail) you can produce aggregated view of the datasets with a well defined level of detail, along a dimension. And you could also provide drilldowns.

So please explain a bit better of what you want, so I can give you a more detailed answer.

[larjohn]

In order for this to work, at a Babbage-compatible API, the levels of the hierarchy should be mapped to specific dimensions. Then these dimensions are groupped into a single hierarchy.

For our example, additional columns should be artificially created in the original table (or in the pipeline) and then also created in the dsd and the dataset.

[skarampatakis]

As this seems to be application specific, couldn't you just create these extra columns on Rudolf layer?

try a query like this

prefix gr-dimension: <http://data.openbudgets.eu/ontology/dsd/greek-municipalities/dimension/> 
prefix obeu-budgetphase: <http://data.openbudgets.eu/resource/codelist/budget-phase/> 
prefix obeu-measure: <http://data.openbudgets.eu/ontology/dsd/measure/>
prefix obeu-dimension: <http://data.openbudgets.eu/ontology/dsd/dimension/>
prefix qb: <http://purl.org/linked-data/cube#>

select ?notation2 (group_concat(distinct ?notation;separator="||") as ?hierarchies) (SUM(?amount) AS ?sum)
where
{
?dataset  obeu-dimension:fiscalYear ?year .
?dataset  obeu-dimension:organization ?organization .
?dataset qb:slice ?slice .
?slice qb:observation ?observation .
?slice gr-dimension:economicClassification ?classification .

?classification skos:broader+ ?topConcept .
?classification skos:notation ?notation2 .

?topConcept skos:prefLabel ?label .
?topConcept skos:notation ?notation.
?observation gr-dimension:budgetPhase ?phase. 
?observation obeu-measure:amount ?amount .

VALUES ?phase {obeu-budgetphase:revised}
VALUES ?organization { <http://el.dbpedia.org/resource/Δήμος_Αθηναίων>}
VALUES ?year {<http://reference.data.gov.uk/id/year/2005>}
}
group by ?notation2
order by ?notation2

then you could just explode the hierarchies column and get your virtual columns.

Or perhaps there could be a better query but I think we can and should do this at the application logic and leave data as is.

Annotating datasets with extra dimensions would produce excess triples, which is not always efficient, since these kind of info can always be retrieved by simple SPARQL queries.

[larjohn]

This could be done, but it is a major refactoring for the existing query builder so it might be left as a top priority after the deliverable due on the end of this month.