qb:componentAttachment to qb:MeasureProperty

[Vladimir Alexiev]

Hi! I have a question about attaching attributes (eg UOM) to measures.

I've researched it and I think I got the answer but would like to confirm.

- http://www.w3.org/TR/vocab-data-cube/#reference-compspec

  "qb:componentAttachment: might be an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty"

- http://www.w3.org/TR/vocab-data-cube/#h4_dsd-mm-obs

  "Attributes can also be attached directly to the qb:MeasureProperty itself (e.g. to indicate the unit of measure for that measure)"

No example is provided, and 

it's a bit unclear whether the attribute should be attached to a measure property, or class qb:MeasureProperty, or both (as suggested below).

Dave Reynolds gave an example n Jul 2012:

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:Number . # not unit:Count

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

Looking at the normalization/flatten rules in the spec:

- http://www.w3.org/TR/vocab-data-cube/#normalize-algorithm

  Phase 2: shows only attachment to qb:DataSet or qb:Slice. 

- The third rule "Dimension values on slices" shows that for a qb:DimensionProperty it doesn't matter whether "qb:componentAttachment qb:Slice" is declared or not: as soon as the value is put in the Slice, it will be transferred to the Observation. In other words qb:componentAttachment is not useful for dimension components.

There is no rule that would transfer from a MeasureProperty to Observation.

Looking at the "unofficial" rules:

- https://code.google.com/p/publishing-statistical-data/source/browse/trunk/src/main/resources/flatten.ru

The fourth *commented-out* rule  transfers from MeasureProperty to Observation, if:

- AttributeProperty is attached to a MeasureProperty, 

- the attribute is declared "qb:componentAttachment qb:MeasureProperty", 

- the measure is used for the Observation

The shape of this rule matches Dave's example

  # Measure property attachments
  INSERT {
      ?obs  ?comp ?value
  } WHERE {
      ?spec  qb:componentProperty ?comp ;
             qb:componentAttachment qb:MeasureProperty .
      ?dataset qb:structure [qb:component ?spec] .
      ?comp    a qb:AttributeProperty .
      ?measure a qb:MeasureProperty;
               ?comp ?value .
      ?obs     qb:dataSet ?dataset;
               ?measure [] .
  }

So to use this style, should I just add this rule to Normalization?

BTW, I got a perl script that converts flatten.ru to OWLIM PIE rules, if someone needs it.

In another example Dave uses qudt:unit rather than sdmx-attribute:unitMeasure. 

I'd like this since I'd prefer not to bring the SDMX machinery into the game.

What would be the downside, that qudt:unit will become qb:AttributeProperty and thus I shouldn't use it for any other purpose?

Cheers! Vladimir

[Dave Reynolds]

Hi Vladimir,

You've dug into this pretty thoroughly! Yes, the state on attachment to
MeasureDimensions is confused and not made adequately clear in the spec.

If I recall correctly there were some reservations about supporting this
attachment level (e.g. the comments on global impact mentioned in the
spec). In the end it was left in the vocabulary so that publishers are
free to express it but a conforming processor is not required to
interpret it and the push down rules for it are not included in the
official rules.

Which is not an entirely comfortable state but that's where it is.

So if you want to guarantee inter-operation with all tools you should
probably avoid it.

If you are working within some eco-system of tools/publishers/consumers
who mutually agree to use it then go ahead.

Further comments in-line ...

On 20/01/15 13:16, Vladimir Alexiev wrote:
> Hi! I have a question about attaching attributes (eg UOM) to measures.
>
> I've researched it and I think I got the answer but would like to confirm.
>
> - http://www.w3.org/TR/vocab-data-cube/#reference-compspec
> "qb:componentAttachment: might be an qb:DataSet, qb:Slice or
> qb:Observation, or a qb:MeasureProperty"
> - http://www.w3.org/TR/vocab-data-cube/#h4_dsd-mm-obs
> "Attributes can also be attached directly to the qb:MeasureProperty
> itself (e.g. to indicate the unit of measure for that measure)"
>
> No example is provided, and
> it's a bit unclear whether the attribute should be attached to a measure
> property, or class qb:MeasureProperty, or both (as suggested below).

To the property.

> Dave Reynolds gave an example n Jul 2012:
> |
> 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:Number.# not unit:Count

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

That's not attaching to "both". The first block declares the level at
which the sdmx-attribute:unitMeasure attribute is going to be attached
as being to things of type qb:MeasureProperty and the next two blocks
then do the attachment to the specific two measures. There's no
attachment to the class qb:MeasureProperty itself.

Yes. As I say, since it is not in the published spec then you can't rely
on other processors to include this but if you want to implement it
yourself then that's the one to use.

> BTW, I got a perl script that converts flatten.ru to OWLIM PIE rules, if
> someone needs it.
>
> In another example Dave uses qudt:unit rather than
> sdmx-attribute:unitMeasure.
> I'd like this since I'd prefer not to bring the SDMX machinery into the
> game.
> What would be the downside, that qudt:unit will become
> qb:AttributeProperty and thus I shouldn't use it for any other purpose?

Well it does imply that qudt:unit is a (member of the class)
qb:AttributeProperty but that is not harmful and doesn't change or
conflict with the semanics of qudt:unit and doesn't stop you using it
elsewhere.

Dave

[Vladimir Alexiev]

Hi Dave, thanks for the clarifications!

> eg:myDSD  a qb:DataStructureDefinition;

>       qb:component [qb:attribute sdmx-attribute:unitMeasure;
>                     qb:componentAttachment qb:MeasureProperty].
>
> eg:measure1 a qb:MeasureProperty;
>       sdmx-attribute:unitMeasure  unit:Percent.

That's not attaching to "both".

Yes, I should have said "related to both", since the relation mechanism is different:

• "qb:componentAttachment qb:MeasureProperty" says to expect the attribute to be attached to a qb:MeasureProperty
  
• Which measure property gets which attribute value is specified by a plain triple (the last triple above)

> use qudt:unit rather than sdmx-attribute:unitMeasure.

> qudt:unit will become qb:AttributeProperty and thus I shouldn't use it for any other purpose?

but that is not harmful and doesn't change or conflict with the semanics of qudt:unit and doesn't stop you using it elsewhere.

I mean that I can't use it as Dimension or Measure in any cube expressed in the same ontology (set of DSDs).

Not that I can think of a useful example of using "qudt:unit" as a Dimension (let alone Measure!).

Cheers!