Re: AW: [QB-UCR] Review comments

Hi Benedikt,

 >> # High level comments
>>
>> 1. The requirements identified here are primarily those for
>> additional
>> work within GLD and not for Data Cube itself. That needs to be made
>> clearer. At a minimum by improving the phrasing in the introduction.
>
> You are right. In fact, I think we are actually describing "Use Cases and Lessons for the Data Cube Vocabulary".
>
> I changed the title accordingly as well as the phrasing in the introduction:
>
>          "The
> 	document describes use cases that would benefit from using the vocabulary.
> 	In particular, the document identifies possible benefits and challenges in using
> 	such a vocabulary for representing statistics. Also, it derives lessons that
> 	can be used for future work on the vocabulary as well as for useful
> 	tools complementing the vocabulary."

Interesting, I had thought that the document was a mix of use cases with 
genuine requirements and case studies with lessons. A case study being a 
different thing from a use case. I wonder whether renaming the concrete 
case studies as such would help with this direction.

> Consequently, I also turned the requirements into lessons:
>
> * "4.1 Vocabulary should build upon the SDMX information model" changed to "There is a putative requirement to update to SDMX 2.1 if there are specific use cases that demand it" <= Lesson: SDMX 2.1 is out and extends vocabulary, The vocabulary so far builds upon Version 2.0, if specific use cases derived from Version 2.1 become available, working groups may consider extending the vocabulary upon Version 2.1. Add link to issue.
> * "4.2 Vocabulary should clarify the use of subsets of observations" changed to "Publishers may need more guidance in creating and managing slices or arbitrary groups of observations" <= In the end, usage is most important. So consumers also need to know what to do.
> * "4.3 Vocabulary should recommend a mechanism to support hierarchical code lists" changed to: "Publishers may need more guidance to decide which representation of hierarchies is most suitable for their use case"
> * "4.4 Vocabulary should define relationship to ISO19156 - Observations & Measurements" changed to: "Modelers using ISO19156 - Observations & Measurements may need clarification regarding the relationship to the data cube vocabulary"
> * "4.5 There should be a recommended mechanism to allow for publication of aggregates which cross multiple dimensions" changed to: "Publishers may need guidance in how to represent common analytical operations such as Slice, Dice, Rollup on data cubes"
> * "4.6 There should be a recommended way of declaring relations between cubes"  changed to: "Publishers may need guidance in making transparent the pre-processing of aggregate statistics"
> * "4.7 There should be criteria for well-formedness and assumptions consumers can make about published data"  changed to: "Publishers and consumers may need guidance in checking and making use of well-formedness of published data using data cube"
> * "4.8 There should be mechanisms and recommendations regarding publication and consumption of large amounts of statistical data" changed to: "Publishers and consumers may need more guidance in efficiently processing data using the data cube vocabulary"
> " "4.9 There should be a recommended way to communicate the availability of published statistical data to external parties and to allow automatic discovery of statistical data" changed to: "Publishers may need guidance in communicating the availability of published statistical data to external parties and to allow automatic discovery of statistical data"

Those do work better for me at least.

>> 3. In some of the use cases it's not clear how the use case motivates
>> the requirement associated with it.
>
> I now started to have the "lessons" directly explained in the "challenges" section of each use case, if that is ok.

Yes, that makes sense.

>> 5. Given the structure of the document it is not obvious that
>> ACTION-92
>> makes sense. Need to either add a new use case in which the O&M
>> relationship can then be illustrated (e.g. the MetOffice usage) or
>> revert to having the O&M discussion as a separate note or drop it.
>> I'm
>> inclined towards the first of these but will need to think more about
>> it.
>
>
> I renamed "Publisher Use Case: Publishing slices of data about UK Bathing Water Quality" to "Publisher Use Case: Publishing Observational Data Sets about UK Bathing Water Quality" to better fit the use case.
>
> We now have a lesson "Modelers using ISO19156 - Observations & Measurements may need clarification regarding the relationship to the data cube vocabulary" instead of the requirement. Would be great if your additions fit in here better.

OK I will attempt to write up a case study for the MetOffice example 
that would be better motivation and explanation of the ISO19156 issues 
than the Bathing Water on.

>> ## 3.3
>>
>> o This use case seems to be a mix of a specific application (Dutch
>> historical census) and a generic use case (publishing spreadsheets).
>> It
>> would be clearer if picked one or the other as the framing. I would
>> suggest the more concrete one.
>
> You are right, but for the Google Public Data Explorer it is similar. I think the more general Excel Spreadsheet use case for now makes sense as it is (although it surely can be improved).

I still think the bulk of that section is a case study of the census 
application rather than a generic use case on spreadsheet publishing.
However, I won't object to leaving as is.

>> ## 3.5
>>
>> o This example does not really motivate the first requirement
>> (relationship to O&M). This publisher does not use ISO19156 here and
>> does not care about the relationship. In fact this is not directly a
>> sensor network problem (the data is the result of lab-based analysis,
>> validation and classification before publication).
>
> Still I think we are publishing statistics about sensor data which may lead to the question of how other potential publishers of sensor data statistics may use the vocabulary. Since we have rephrased the requirements into lessons, the hopefully suits you better.

We are publishing data about thing which are measured, that is true. But 
as I say this particular publisher does not use ISO19156 and wouldn't 
regard this work as motivating that particular lesson.

If I manage to write a new section on the MetOffice case study then we 
can move the ISO19156 lesson to there instead.

>> ## 3.9
>>
>> o The requirement does not flow from the use case. It seems like the
>> requirement that would follow is "Develop a mapping between Data Cube
>> as
>> DSPL". That would be a reasonable requirement for the Data Cube
>> eco-system but not one for the vocabulary itself.
>>
>
> I could either describe that as a challenge (similar as for COINS and Water Bathing UCs) or as a lesson. Challenge for now would require less work.

OK.

Cheers,
Dave

Received on Tuesday, 28 May 2013 21:36:17 UTC