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

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

From: Richard Cyganiak <richard@cyganiak.de>
Date: Sat, 2 Mar 2013 18:49:36 +0000
Cc: Government Linked Data Working Group <public-gld-wg@w3.org>
Message-Id: <62FE5152-28BF-40AB-A131-CB7750FCA94C@cyganiak.de>
To: Benedikt Kaempgen <kaempgen@fzi.de>, Dave Reynolds <dave.e.reynolds@gmail.com>
The way attachment levels for slices are defined has changed quite a bit in SDMX 2.1. So, qb:subSlice is something that is not in SDMX, makes the specification of well-formedness constraints more complex, and would likely be impacted by a change in alignment from SDMX 2.0 to SDMX 2.1. In the interest of shipping a reasonable first version of Data Cube, I agree with Dave that dropping qb:subSlice is the best course of action.

The use case you mention is perfectly reasonable, but it can be addressed by a property in an extension namespace, and can be easily re-added in a future version.

Best,
Richard


On 28 Feb 2013, at 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
> 
> <cube_lattice_ssb.png>
Received on Saturday, 2 March 2013 18:50:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:38 UTC