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

Re: AW: ISSUE-30 (CubeRel): Declaring relations between cubes [Data Cube Vocabulary]

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Thu, 17 Jan 2013 14:50:51 +0000
Message-ID: <50F80FCB.5030202@gmail.com>
To: public-gld-wg@w3.org
P.S.  I'm not sure what this means for your use cases document.

To me the definitive record of the issues we are considering is the 
issues list. We may chose to address any of those issues in a number of 
ways including saying they are invalid, out of scope or should be 
postponed. They don't represent promises :)


On 17/01/13 14:47, Dave Reynolds wrote:
> Hi Benedikt,
> I would need to study QB4OLAP property before commenting in detail on that.
> However, this issue was deliberately framed as about *declaring* the
> relationship between cubes. Such a declarative statement would be
> different from a procedural description of a set of transformations
> which have actually taken place - which is what I understand Cogs to be
> about.
> As a high level observation, the working group has very limited time and
> capacity left so we should focus on getting a sufficient version of the
> core of QB agreed. My recommendation on Issue-30 is, in fact, that we
> should postpone to a future iteration. There is a genuine requirement
> here, and QB4OLAP looks good, but I'm not sure we have sufficient
> experience with it and sufficiently working group bandwidth to properly
> address this area, this time around.
> Dave
> On 11/01/13 13:27, Benedikt Kaempgen wrote:
>> Hi,
>> Regarding this issue, I would like to point to the suggestion of [1].
>> Here, the component specification of a measure can define an
>> aggregation function that should be used when aggregating measures to
>> a higher level.
>> A vocabulary that may be used for data transformations to statistical
>> data is Cogs [2].
>> Again, I have added a recommendation to [3]: "There should be a
>> recommended way of declaring relations between cubes"
>> Best,
>> Benedikt
>> [1] QB4OLAP: a Vocabulary for Business Intelligence over the Semantic
>> Web.
>> <http://publishing-multidimensional-data.googlecode.com/git/index.html>
>> [2] Cogs. ETL Provenance Vocabulary.
>> <https://sites.google.com/site/cogsvocab/>
>> [3]
>> <http://www.w3.org/2011/gld/wiki/Data_Cube_Vocabulary/Use_Cases#There_should_be_a_recommended_way_of_declaring_relations_between_cubes>
>> ________________________________________
>> Von: Government Linked Data Working Group Issue Tracker
>> [sysbot+tracker@w3.org]
>> Gesendet: Freitag, 17. Februar 2012 17:03
>> An: public-gld-wg@w3.org
>> Betreff: ISSUE-30 (CubeRel): Declaring relations between cubes [Data
>> Cube Vocabulary]
>> ISSUE-30 (CubeRel): Declaring relations between cubes [Data Cube
>> Vocabulary]
>> http://www.w3.org/2011/gld/track/issues/30
>> Raised by: Dave Reynolds
>> On product: Data Cube Vocabulary
>> In some situations statistical data sets are used to derive further
>> datasets. Should Data Cube be able to explicitly convey these
>> relationships?
>> A simple specific use case is that the Welsh Assembly government
>> publishes a variety of population datasets broken down in different
>> ways. For many uses then population broken down by some category (e.g.
>> ethnicity) is expressed as a percentage. Separate datasets give the
>> actual counts per category and aggregate counts.  In such cases it is
>> common to talk about the denominator (often DENOM) which is the
>> aggregate count against which the percentages can be interpreted.
>> Should Data Cube support explicit declaration of such relationships
>> either between separated qb:DataSets or between measures with a single
>> qb:DataSet (e.g. ex:populationCount and ex:populationPercent)?
>> If so should that be scoped to simple, common relationships like DENOM
>> or allow expression of arbitrary mathematical relations?
>> Note that there has been some work towards this within the SDMX
>> community as indicated here:
>> http://groups.google.com/group/publishing-statistical-data/msg/b3fd023d8c33561d
Received on Thursday, 17 January 2013 14:51:24 UTC

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