Re: [QB-UCR] Review comments

I too have been looking at the document today in an effort to have 
something to say this afternoon. Dave has gone into a lot of detail here 
and he knows the vocabulary/domain well. My comments as more or less an 
outsider are that:

- it appears to be very UK focussed;
- it's out of date;
- it needs tidying up by a native speaker (this is emphatically not a 
criticism, just a reality that writing a formal document in any language 
is hard, doing it in a second language is impossible).


1. the extensive and detailed comments that Dave has made, and my 
relatively superficial look at the doc;
2. the approval of QB to go to CR and the evidence that we'll be 
gathering for it to exit CR;
3. the amount of work required in the available time...

... is the amount of effort required to publish this justified? That's 
mostly a question for Benedikt and Richard but something we should 
probably consider on the call shortly.


On 23/05/2013 14:14, Dave Reynolds wrote:
> 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 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


Phil Archer
W3C eGovernment
+44 (0)7887 767755

Received on Thursday, 23 May 2013 13:26:43 UTC