Re: Data Cube ED

Hello,

Below are some corrections and comments on the Data Cube Vocabulary
Editor's Draft 13:

   - If you wish to make comments regarding this document, please send them
   to public-gld-wg@w3.org - when I sent here the mail got blocked. The
   document should say public-gld-comments@w3.org
   - The subscribe link requires a password, I see no way to subscribe to
   updates to public-gld-wg.
   - dimensions that define what the observation applies to (e.g. time,
   area, population) -> dimensions that define what the observation applies
   to (e.g. time, area, gender)... <- population is not a dimension, it is
   a measure
   - suggestion: what has been measured (e.g. economic activity) -> what
   has been measured (e.g. economic activity, population)
   - We can think of the statistical data set as multi-dimensional space
   -> We can think of the statistical data set as a multi-dimensional
   space...
   - time period (averages over three year timespans?) <- which is it,
   single years or two year timespans? this should be cleaned up, and the
   "2004-6" notation should be explicitly explained - does it mean 2004-2006
   or something else?
   - region, sex -> region and sex
   - a specification for the structure of this datasets we need -> a
   specification for the structure of this dataset we need
   - (ususally using one of the sub properties qb:dimension, qb:measure or
   qb:attribute. -> (ususally using one of the sub properties qb:dimension,
   qb:measure or qb:attribute).
   - However, it is also permissible to attach attributes at other levels
   of the structure such as the overall data set <- I'm wondering, what is the
   full set of possible levels at which attributes can be attached? does it
   include slices? I suggest it be more concrete and say: "However, it is also
   permissible to attach attributes at the slice or data set level."
   - In the SDMX information model then each observation can... -> In the
   SDMX information model, each observation can...
   - Similarly in Business Intelligence applications and OLAP then a single
   "cell" in the data cube will typically represent multiple facts about a
   single transaction. <- OLTP deals with transactions, OLAP deals with
   aggregations, not transactions. I think "transaction" is not the right word
   here, but I'm not sure what is. From the definition of OLAP cell
here<http://altaplana.com/olap/glossary.html#CELL>,
   it seems the term "cell" refers to both the address of the cell, and the
   thing that "contains" the measure values. I suggest it be rephrased
   "Similarly in Business Intelligence applications and OLAP, a single
   "cell" in the data cube will typically contain values for multiple
   measures."
   - The data cube vocabulary permits either representation approach to be
   used though they cannot be mixed within the same data set. <- So this means
   that any tooling developed for combining data sets together into larger
   data sets must handle both forms, and transform its output into one form or
   the other?
   - If it is desired, these redundancy can be reduced -> If it is desired,
   this redundancy can be reduced
   - codes drawn from some for of code list -> codes drawn from some code
   list
   - In the Data Cube vocabulary such coded are represented -> In the Data
   Cube vocabulary such codes are represented
   - (dcterms:date) <- has black left paren and orange right paren
   - record such a classification of an whole data set -> record such a
   classification of a whole data set
   - (data flows, reporting taxonomies, maintainers, provision agreements.
   -> (data flows, reporting taxonomies, maintainers, provision agreements).
   - Property: qb:slice ( qb:DataSet -> qb:Observation ) -> based on this
   triple which appears in the examples "eg:dataset-le2 qb:slice eg:slice2",
   shouldn't this be Property: qb:slice ( qb:DataSet -> qb:Slice ) ?

Best regards,
Curran Kelleher