AW: AW: [QB] ISSUE-30 Proposed resolution

Dave, I agree.

Thanks

Benedikt
________________________________________
Von: Dave Reynolds [dave.e.reynolds@gmail.com]
Gesendet: Donnerstag, 28. Februar 2013 17:53
An: Benedikt Kaempgen
Cc: Government Linked Data Working Group
Betreff: Re: AW: [QB] ISSUE-30 Proposed resolution

Thanks Benedikt.

The clarification should say that describing aggregation is out of scope
of the currently specification but may be addressed by future extensions.

We should keep open the options for W3C to develop a future Data Cube
2.0 with this capability, or to develop a separate extension vocabulary
like QB4OLDAP.

Dave

On 28/02/13 16:41, Benedikt Kaempgen wrote:
> 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 Friday, 1 March 2013 10:26:26 UTC