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

AW: [QB] ISSUE-30 Proposed resolution

From: Benedikt Kaempgen <kaempgen@fzi.de>
Date: Thu, 28 Feb 2013 16:41:08 +0000
To: Dave Reynolds <dave.e.reynolds@gmail.com>, "Government Linked Data Working Group" <public-gld-wg@w3.org>
Message-ID: <0D7BFFD7C415144DA75C3D49C46AC21512AB2FF7@ex-ms-1a.fzi.de>
Hi,

agree.

I am reusing QB4OLAP with QB when I need to represent aggregation functions such as SUM, AVG. However, I see that aggregation functions do not necessarily need to be served by QB.

It would be good, though, if QB clarifies that it does not intend to describe how aggregated numbers have been derived.

Best,

Benedikt


________________________________________
Von: Dave Reynolds [dave.e.reynolds@gmail.com]
Gesendet: Mittwoch, 27. Februar 2013 17:15
An: Government Linked Data Working Group
Betreff: [QB] ISSUE-30 Proposed resolution

A number of groups have reported use cases where they wish to more
flexibly relate measures in one cube to measures in another cube or in
the same cube at a different aggregation level.

Examples included:
   - cubes of metrics which derive from combinations of more primitive
metrics (as occur in local government performance reporting)
   - relating population category statistics (expressed as percentage of
population) to corresponding total population counts
   - aggregation functions for OLAP cubes as expressed in, for example,
QB4OLDAP [1]
   - when aggregating measures at defined levels in a geographic
hierarchy [2] (a special case of the OLAP one)

This ISSUE is currently marked as RAISED but not OPEN.

There is some overlap here with ISSUE-31 which I'll raise on a separate
thread.

I would love to address this issue but there is significant work
involved here. As Arofan pointed out on that same thread [2] there has
been substantial work in the SDMX community on this. So addressing this
issue well is not simply a matter of agreeing a technically good
solution for Data Cube but would require coordination to ensure the
solution is compatible with the technical direction of SDMX. Given our
new timescale this is simply not possible.

Since this would extend but not change the existing design it could be
addressed by a future iteration of the spec.

Proposal: Mark the issue as "Postponed".

Dave

[1] Lorena Etcheverry, Alejandro A. Vaisman
http://publishing-multidimensional-data.googlecode.com/git/index.html

[While I'm here I'd like to apologize to Lorena and Alejandro for not
having followed up on this interesting work. This has been due to lack
of time to invest in this area, not lack of interest.]

[2]
https://groups.google.com/d/topic/publishing-statistical-data/3I1-Ix1Hk14/discussion
Received on Thursday, 28 February 2013 16:41:38 UTC

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