W3C home > Mailing lists > Public > public-gld-wg@w3.org > March 2013

Re: AW: [QB] ISSUE-34 proposed resolution

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Fri, 01 Mar 2013 11:54:35 +0000
Message-ID: <513096FB.4060603@gmail.com>
To: Benedikt Kaempgen <kaempgen@fzi.de>
CC: Government Linked Data Working Group <public-gld-wg@w3.org>
OK. I can see that as a use case.

In that case I withdraw the suggestion to deprecate qb:subSlice.

I will try to see if I can make the well formedness checks work even in 
the presence of subslices. Had hoped to avoid that complication. Sigh.


On 28/02/13 17:03, Benedikt Kaempgen wrote:
> Hi,
> I see a possible use case of qb:subSlice:
> In OLAP systems one often tries to materialise parts of the entire data cube to optimise query processing. This materialisation can be done along a "data cube lattice" of views on the data cube. See attached a figure of such a possible lattice. Assuming the node on the very bottom of the figure is the original dataset (with date, customer... as dimensions). Then, the nodes connected to this base node are "slices", aggregating the original dataset on a certain dimension (i.e., slicing this dimension to an ALL value). Every node reachable from these slices further up are "sub-slices" that further slice dimensions.
> In this sense, the relationship qb:slice or qb:subSlice between dataset, slice, and subslice would mean something like "derived from via slicing a dimension". This may be helpful in applications to quickly find the ideal slice for answering a query.
> I would be in favour of keeping the option of representing such a use case.
> There are at least two options:
> 1) Remove qb:subSlice and allow qb:slice both on qb:DataSet and qb:Slice.
> 2) Leave qb:subSlice.
> Best,
> Benedikt
> ________________________________________
> Von: Dave Reynolds [dave.e.reynolds@gmail.com]
> Gesendet: Mittwoch, 27. Februar 2013 15:52
> An: Government Linked Data Working Group
> Betreff: [QB] ISSUE-34 proposed resolution
> As it says in the ISSUE description ...
> """
> The Data Cube slice mechanism allows hierarchical organization of slices
> though the use of qb:subSlice.
> However, it is not possible to distinguish between different levels of
> sub-slice when defining attachment levels, which in terms makes
> abbreviated formats for such cubes under-defined.
> """
> While it would be possible to fix the issues the subslice mechanism is
> not part of SDMX and I've not seen its use in "in the wild" Data Cubes,
> perhaps because of the lack of clarity.
> Proposal: remove qb:subSlice (leaving it in the ontology but marked as
> deprecated and removing mention of it from specification document).
> Dave
Received on Friday, 1 March 2013 11:55:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:06 UTC