ISSUE-33: Collections of observations and well-formedness of slices

Hello,

Thanks for this answer, Dave.

The consumption of abbreviated data (slices) probably is not an issue per
se, but rather something to keep in mind regarding ISSUE-33: Collections of
observations and well-formedness of slices.

I hope you do not mind if, by this email, I attach your answer to issue-33.

Best,

Benedikt


-----Original Message-----
From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com] 
Sent: Wednesday, February 22, 2012 6:49 PM
To: Benedikt Kämpgen
Cc: richard@cyganiak.de
Subject: Re: Data Cube Vocabulary - Possible issue?

On 22/02/12 16:42, Benedikt Kämpgen wrote:
> Hello Dave, Richard,
>
> When preparing the use case document, I came upon the following COINS 
> issue of QB:
>
> For brevity reasons and to avoid repetition, it is useful to have 
> abbreviation mechanisms such as assigning overall valid properties of 
> observations at the dataset or slice level, and become implicitly part 
> of each observation. For instance, in the case of COINS, all of the 
> values are in thousands of pounds sterling. However, one of the use 
> cases for the linked data version of COINS is to allow others to link 
> to individual observations, which suggests that these observations 
> should be standalone and self-contained – and should therefore have 
> explicit multipliers and units on each observation. One suggestion is 
> to author data without the duplication, but have the data publication 
> tools "flatten" the compact representation into standalone observations
during the publication process.
>
> Do you think we should add it as an GLD QB issue?

Not sure.

We do need both flattened and abbreviated forms. The current doc does point
out that flattened is preferred and that tool chains might (statically or
dynamically) generated flattened views of abbreviated data.

When we published COINS we had no tool chain for dynamic flattening (indeed
still don't) and needed to cater to users without specialist client code for
access QBs, hence the choice of flattened.

What would the issue be about?

Possibilities are:
   (1) Clarify documentation around use of flattened/abbreviate forms and
what client tools would need to do to consumer abbreviated cubes.

   (2) Consider some vocabulary extension to simplify testing whether a cube
is flattened. At the moment you have to go from Observation to DataSet to
DSD to each Component and test it's abbreviation level.
Richard I remember us discussing something like qb:FlattenedDataSet at one
point but can't recall the details of the discussion.


BTW there is some hint of this in issue 29 [1].

Dave

[1] https://www.w3.org/2011/gld/track/issues/29

Received on Wednesday, 21 March 2012 13:05:26 UTC