Re: [Data Cubes] Why this kind of Data Structure Definition

Am 15.08.2012 12:43, schrieb Dave Reynolds:
>> I have drafted some non-ordered solution which allows multiple different
>> UoM for multiple measures  on the dataset level.
>>
>> myDef:dataset a qb:Dataset ;
>>      myCubes:hasUoM
>>        [myCubes:property myDef:year; myCubes:uom x:years],
>>        [myCubes:property myDef:age; myCubes:uom x:years],
>>        [myCubes:property myDef:hatSize; myCubes:uom x:cm],
>>        [myCubes:property myDef:moneyInPocket; myCubes:uom x:euro];
>
> Not sure how this relates to the above conversation.

I thought about ordered lists as a way to attach different individual
UoM to multiple measure properties in a single dataset.
This is a way doing it without ordered lists.

>
> That seems to just express the UoM not a DSD.

Yes. Assume that myDef:dataset has a DSD. I want to add something.

>
> For the UoM for multi-measure cubes you could use an attribute on the
> ComponentProperties as I mentioned before.

I did not forget that. But I am looking for a more compact way so I can
provide multiple measures in a single dataset though they have different
UOM.
Secondly, the UOM may change per measure in my use case. That is why I
have to provide the UoMs per dataset  (may be even per observation) not
per measure property.

>
>> myDef:MixedObservation rdfs:subClassOf myCubes:Observation
>>     rdfs:domain :myDef:region, myDef:year , myDef:age, myDef:hatSize .
>>        myDef:moneyInPocket.
>
> Sorry, can't follow that at all.

Sure. Made a very silly mistake, sorry.

>
> Did you mean things like:
>     myDef:year    rdfs:domain myDef:MixedObservation .
>     myDef:age     rdfs:domain myDef:MixedObservation .
>     myDef:hatSize rdfs:domain myDef:MixedObservation .
> ?

Exactly. Thanks.

>
> If so then that kind of works but now you can't use myDef:year etc on
> another cube of a different shape. For many of our use cases we want
> to reuse dimension and measure properties across cubes.

I don't see the problem. If I publish such definitions under a distinct
namespace (MyDef:), anybody can reuse them just like DSDs.

>
> So to use this approach you would need OWL so as to make the
> association specific to the MixedObservation class. For example:
>
>   myDef:MixedObservation a owl:Class ;
>     rdfs:subClassOf qb:Observation ;
>     rdfs:subClassOf [
>       a owl:Restriction;
>       owl:onProperty myDef:year;
>       owl:cardinality 1 ;
>     ];
>     etc
>
> Perfectly fine your you to do that in addition to a DSD. But my
> previous remarks still stand as to why that's not a necessary or
> sufficient alternative to a DSD.

Like above. But this is not my main topic here.

>
>> Then proceed like in Data Cubes or Scovo.
>> :o1 a myDef:MixedObservation ;
>>      myCubes:dataset myDef:dataset ;
>>      myDef:region x:spain ;
>>      myDef:year 2011 ;
>>      myDef:age 50 ;
>>      myDef:hatSize 52 ;
>>      myDef:moneyInPocket 0.01 .
>>
>> I guess this again is not SDMX compliant.
>
> ?? Looks just like a Data Cube observation to me.

right, only difference is that myDef:dataset knows all the different UoM
and  to which measure property they belong

>
>> Basically I propose some very few extensions (prefixed with myCubes:)
>>
>> myCubes:UomOfProperty a owl:Class ;
>>      rdfs:domain myCubes:property ;
>>      rdfs:domain myCubes:uom .
>>
>> myCubes:property rdfs:range qb:ComponentProperty .
>> myCubes:uom rdfs:range qudt:Unit . # may be SDMX as well, this doesn't
>> matter here
>>
>> qb:Dataset rdfs:domain myCubes:hasUoM .
>
> Presumably you meant:
>   myCubes:hasUoM rdfs:domain qb:DataSet .

Sure - wonder how this happend so systematically ;-)

>
>> myCubes:hasUoM rdfs:range myCubes:UomOfProperty .
>
> Seems unnecessary to have an entire new structure just for declaring
> UoMs.
>
> If the attribute mechanism is proving cumbersome for you then the
> thing to consider would be to add a qb2:uom property to
> qb:ComponentSpecification so that you can define the UoM as part of
> the DSD:
>
> myDef:dataset a qb:DataSet ;
>     qb:structure [ a qb:DataStructureDefinition;
>       qb:component [qb:dimension myDef:year;    qb2:uom x:years] ;
>       qb:component [qb:dimension myDef:region;  qb2:uom x:place] ;
>       qb:component [qb:measure   myDef:hatSize; qb2:uom x:cm] ;
>        ...
>      ];
>
> Though I'm not yet convinced that is preferable to attaching the UOM
> directly to the component property.

So I would need a different DSD whenever a measure property switches UoM.
I thought it would better to handle this on the datset level than in the
DSD.

>
> Note that dimensions rarely have UoM, dimension values are typically
> coded as instances of some class or concept scheme and so the
> interpretation of their values is given by their rdfs:range.

Sure, I did not provide any UoM for regions in my example.

>
> Attaching UoM to non-coded measures by putting an attribute like
> sdmx-attribute:unitMeasure on the MeasureProperty seems simple and
> nicely symmetric with use of rdfs:range.
>
> Dave 

So, to focus this:

What do you think of attaching multiple UoM to multiple measures on the
dataset level, each by a pair of (measure property, UoM)?

Thanks for being so patient!

regards,
Thomas

-- 
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 Wednesday, 15 August 2012 11:22:46 UTC