[QB-UCR] Review comments

I'm sorry about this Benedikt but having finally cleared some time to 
look at the document I don't think it is ready to go.

# 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.

2. Some requirements here are not requirements for the data cube 
vocabulary but for associated tools/services which have not been 
considered as part of our work. They should either not be here or they 
need to be pulled out separately (specifically 4.8 and 4.9).

3. In some of the use cases it's not clear how the use case motivates 
the requirement associated with it.

4. A number of the diagrams appear to have been copy from other 
publications. This may be a copyright violation. Publication can not 
proceed until this at least is resolved.

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.

6. Some of the "use cases" represent actual deployed systems. For those 
then it may be appropriate to highlight "Lessons" or "Insights" rather 
than just focus on unmet requirements.

# Detailed/minor comments (ordered and numbered by section)

## 1

o The first paragraph needs to be clarified to make the nature of the 
requirements clearer (high level comment #1).

## 1.1

o Second bullet. s/"dimensions", e.g., the specific phenomenon "weight"/ 
"dimensions", the specific phenomenon e.g. "weight"/  (otherwise it 
sounds like the measure is an example of a dimension)

o Figure. Not sure I see the value of this figure. Not all observations 
are made by a person. Aggregate statistics are not observations in this 
sense.

## 3.1

o The figure here (it would help if the figures were numbered) seems to 
be a direct copy of that in reference [SMDX 2.1]. I'm not sure what the 
W3C processes would be for obtaining and registering clearance for such 
reproduction but suggest that we simply not go there. Either drop the 
diagram or do a new one.  The flows in the current diagram are confusing 
anyway.

## 3.2

o The requirement listed is not a requirement of this use case. COINS 
works fine based on slices. I would be inclined to label this as "No 
additional requirements beyond Data Cube". I would instead add a 
subsection about "Lessons" and for COINS the lessen is that data cube 
can be successfully used for publishing financial data, not just statistics.

## 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.

o It is not clear from the write up why the first requirement emerges 
from this use case. Why does this data need non-SKOS hierarchies?

## 3.4

o In the Turtle example the URIs need "<" replacing by "&lt;" so they 
show up. The sdmx prefix probably should be defined, though maybe the 
claim that this is "pseduo-turtle" is sufficient to duck that.

## 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).

o If you do add "Lessons" sections for some of the examples then the 
lesson here is that "Data Cube can be successfully use for observation 
and measurement data, as well as statistical data".

## 3.6

o Trivial s/have to/have too/

o Qcrumb.com is not explained or linked to, and I couldn't find any 
useful information via Google.

o The first requirement seems to be about publishing advice or tooling 
requirements, not a requirement on the vocabulary design.

## 3.7

o Is copyright OK on that diagram? Seems possible in that case.

## 3.8

o Is copyright OK on those diagrams? Seems possible in that case.

o Not quite clear how that requirement flows from the use case, but can 
believe it does.

## 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.

## 3.11

o The requirement is reasonable but it is not a requirement on Data Cube 
vocabulary.

## 4

o Suggest separating this section into requirements on the Data Cube 
vocabulary update and other associated requirements (4.8, 4.9, maybe 
DSPL one from 3.9).

## 4.1

o This requirement is confusing. It is not a requirement of the GLD work 
to build upon SMDX, Data Cube was already built upon SDMX. If we list 
that they would would need to list all the other requirements that 
pre-GLD Data Cube had to meet.
   I understand you to be saying there is a putative requirement to 
update to SDMX 2.1 if there are specific use cases that demand it. If so 
then should be made clearer in the title and drop the link to COINS - 
there is no motivation to use SDMX 2.1 from the COINS use case.


Dave

Received on Thursday, 23 May 2013 13:15:30 UTC