Re: [Data Cubes] unit of measure with multiple measures

Hi Thomas,

On 20/07/12 12:32, Thomas Bandholtz wrote:
> Ok, Dave,
>
> I think I understand now.
> If I have a multiple measure observation with different UoMs I have to
> split it so that each obeservation has only one UoM for all its
> measures, right?

Like I say, there is nothing to stop you attaching the UoM to the 
MeasureProperty itself.

While that's not listed as an explicit qb:Attachable there's nothing to 
prevent you doing that.

> Somehow I dislike this. F.e. we have observations of chemical exposure
> including number of probands (count), arithmetic mean (ng/g dw) and
> standard deviation (ng/g dw).
>
> So I need to describe this in two separate qb:Observation instances, one
> with number of probands and UoM "count", and one with arithmetic mean
> and standard deviation, both with UoM "ng/g dw", right?

That is fine too but it seems to me you have several reasonable options 
which are probably all preferable to that one:

(1) Attach the UoM to the MeasureProperty using 
sdmx-attribute:unitMeasure. This is not blocked by the Data Cube 
specification though it might be something the working group should 
review and clarify since that is more than simple abbreviation.

(2) Attach the UoM to the MeasureProperty using your own annotation 
property, so as to be absolutely clear on what it means in your usage.

(3) Define a record class to hold all the different values which make up 
one of your observation points. Represent the UoM for those values using 
whichever UoM machinery you are planning to adopt. Then have the Data 
Cube be a single-measure cube whose measure comprises instances of that 
record class. This is a design pattern we used for the weather forecast 
data and it fits with the style of ISO TC211 Observations & Measurements.

(4) Use the measure-dimension layout (which is more normal in the SDMX 
world) so that each observation has a single measure and so can be 
annotated with UoM directly.

Dave

> This somehow tears the real obeservation into tatters for the sake of a
> in-my-eyes strange data model.
> Why not describe each single measure as a pair of number and UoM?
> Is there a really serious reason?
>
> Best,
> Thomas
>
> Am 19.07.2012 10:15, schrieb Dave Reynolds:
>> Hi Thomas,
>>
>> On 18/07/12 17:30, Thomas Bandholtz wrote:
>>> Hi,
>>>
>>> i am dealing with multiple measures and i want to give them
>>> individual uoms.
>>> http://www.w3.org/TR/vocab-data-cube/ is a little bit vague about this.
>>> I read: "Specifically in this example we can use the predefined
>>> sdmx-attribute:unitMeasure which in turn corresponds to the COG concept
>>> of UNIT_MEASURE."
>>>
>>> and later:
>>>
>>> "Attributes can also be attached directly to the qb:MeasureProperty
>>> itself (e.g. to indicate the unit of measure for that measure) "
>>
>> Indeed you can attach sdmx-attribute:unitMeasure to the
>> qb:MeasureProperty (if you declare that as the attachment level) or to
>> the observation (if you use the measure dimension approach to
>> multi-measure cubes).
>>
>>> I want to provide a qb:codeList with a set of uoms, but the schema says
>>> i can do this only with a qb:DimensionProperty, why?
>>
>> No, it's the other way round.
>>
>> The schema requires qb:DimensionProperty to be coded (and that's one
>> of the restrictions under review in GLD) but it is doesn't prevent
>> other uses of CodedProperty.
>>
>> qb:ComponentProperty > qb:CodedProperty > qb:DimensionProperty
>>                       > qb:AttributeProperty
>>                       > qb:MeasureProperty
>>
>> There's no disjointness assertions between qb:CodedProperty and the
>> others. Something can't be both a qb:DimensionPropety and  a
>> qb:AttributeProperty but it can be both a qb:CodedProperty and
>> qb:AttributeProperty.
>>
>> So if you have a qb:AttributeProperty you want to want to use to
>> declare the UoM and you want to declare those as skos:Concepts then
>> you can indeed use qb:codeList to associate the skos:ConceptScheme for
>> the UoMs with the qb:AttributeProperty.
>>
>> However, for declaring units of measure you might want to consider
>> using an existing vocabulary. In particular we've found QUDT [1][2]
>> very useful and adds more value than a simple concept scheme.
>>
>> Dave
>>
>> [1] http://www.qudt.org/
>> [2] http://www.linkedmodel.org/catalog/qudt/1.1/index.html
>>
>>
>>
>>
>
>

Received on Friday, 20 July 2012 12:34:31 UTC