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

Hi Dave,

took some time to clarify the requirements of the database model.
Here is my note about this:

One further useful extension is supporting multiple measures per
observation. However, the specification notes “that one limitation of
the multi-measure approach is that it is not possible to attach an
attribute to a single observed value”. This forbids adding a specific
unit of measure to each of the given measures.

Dave Reynolds (Co-author of Data Cubes) has proposed a work-around which
is “not something explicitly sanctioned by the spec” (Reynolds, Dave,
2012). In this proposal the uom is assigned to each measure property in
the structure definition, not to the individual measure, so it will be
the same wherever this measure property is used.

Structure definition:
eg:measure1 a qb:MeasureProperty;
sdmx-attribute:unitMeasure unit:Percent .

eg:measure2 a qb:MeasureProperty;
sdmx-attribute:unitMeasure unit:Count .

Observation record:
eg:observation1 a qb:Observation;
eg:measure1 55;
eg:measure2 1333 .

In the current native UPB data model however this is not the case. E.g.
one measure is the contamination of a certain specimen with a certain
substance. The specimen may be solid and measured in kilogram, or liquid
and measured in litre. This would require defining distinct measures for
liquid and solid specimens. This has to be clarified with the domain
experts. If such a distinction should be avoided we can only provide one
measure per observation record, which would considerably increase the
data volume and processing complexity. Another solution might be
attaching multiple individual uom definitions to each observation record
but this seems to be out of scope of the standard.

Did I understand you right?

Best regards,
Thomas


Am 20.07.2012 15:18, schrieb Dave Reynolds:
> On 20/07/12 13:52, Thomas Bandholtz wrote:
>> Oh Dave,
>>
>> Am 20.07.2012 14:33, schrieb Dave Reynolds:
>>> 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.
>>
>> To my understanding this wouldn't make any difference. The range of
>> qb:componentAttachment is rdfs:Class, I would need multiple UoM
>> components, each of them attached to a different *instance* of
>> qb:MeasureProperty.
>
> The range of qb:componentAttachment isn't relevant here.
> qb:componentAttachment is how you describe the level at which an
> attribute is being attached. That's not how you attach the attribute
> itself.
>
> So you would have something like:
>
> eg:myDSD a qb:DataStructureDefinition;
> qb:component [qb:measure eg:measure1 ];
> qb:component [qb:measure eg:measure2 ];
> qb:component [qb:attribute sdmx-attribute:unitMeasure;
> qb:componentAttachment qb:MeasureProperty;]
> .
>
> eg:measure1 a qb:MeasureProperty;
> sdmx-attribute:unitMeasure unit:Percent .
>
> eg:measure2 a qb:MeasureProperty;
> sdmx-attribute:unitMeasure unit:Count .
>
> eg:observation1 a qb:Observation;
> eg:measure1 55;
> eg:measure2 1333;
> .
>
> [All the above manually typed quickly, no guarantees of correctness.]
>
>> It's like describing life expectancy and hat size in a single
>> qb:Observation instance, each of them with a distinct UoM ;-)
>
> Quite :)
>
> If the above isn't satisfying (and it's not something explicitly
> sanctioned by the spec so is questionable) then use QUDT as I
> mentioned before - the domain of qudt:unit is open:
>
> eg:myDSD a qb:DataStructureDefinition;
> qb:component [qb:measure eg:measure1 ];
> qb:component [qb:measure eg:measure2 ];
> .
>
> eg:measure1 a qb:MeasureProperty;
> qudt:unit unit:Percent .
>
> eg:measure2 a qb:MeasureProperty;
> qudt:unit unit:Count .
>
> Dave
>
>
>
>
>


-- 
Thomas Bandholtz
Principal Consultant

innoQ Deutschland GmbH
Krischerstr. 100, 
D-40789 Monheim am Rhein, Germany
http://www.innoq.com
thomas.bandholtz@innoq.com
+49 178 4049387

http://innoq.com/de/themen/linked-data (German)
https://github.com/innoq/iqvoc/wiki/Linked-Data (English)

Received on Friday, 10 August 2012 09:59:28 UTC