RE: [publishing-statistical-data] W3C Data Cube Last Call

Hi Dave

Thank you for taking my comments into consideration, I am fully satisfied with your answers.

Cheers
Franck 

-----Message d'origine-----
De : Dave Reynolds [mailto:dave.e.reynolds@gmail.com] 
Envoyé : jeudi 9 mai 2013 15:22
À : Cotton Franck
Cc : public-gld-comments@w3.org; Guillaume Duffes
Objet : Re: [publishing-statistical-data] W3C Data Cube Last Call

Hi Franck,

Thank you again for your comments on the Data Cube Last Call draft.

We previously responded to your primary comment but I wanted to follow up to confirm that we have also made the editorial corrections that you suggested. Details below. The current editor's draft is at [1].

Please can you let us know if you are satisfied with this response.


On 08/04/13 10:02, Cotton Franck wrote:

> *Figure *picturing the vocabulary should have at least a title. It 
> should also make appearent that qb:Slice is a sub-class of 
> qb:ObservationGroup.

Fixed  (though the WG is seeking to develop new diagrams for commonality across the specs).

> Vocabulary *index* : I don't think that qb:Attachable and 
> qb:ComponentSet are mentionned in the specification (except in the 
> vocabulary reference). For example, the end of the third bullet in 6.4 
> would be a good place to mention Attachable.

Added reference to qb:Attachable.

> *2.2* SDMX and related standards
>
>
> - First line: "organisations" -> "organizations" (sorry)

Fixed :)

> - It is said that Data Cube builds on SDMX 2.0. Could it be instead 
> related to version 2.1?

We had a tracked issue to consider moving the whole Data Cube Vocabulary to SDMX 2.1. However, given the deadlines, it was not  feasible to do this in the available time. The Working Group has voted to postpone this issue to a future revision.

> - [end of the section] "RDF versions of [the COG] terms are available
> separately": where?

There was some description of this in 6.2, have added further clarification both here and in 6.2.

> *5 *Data Cubes
>
>
> - It is redundant to mark all sub-sections as normative since the 
> whole section is marked so.

Quite so, it's a tooling problem. If we just mark the outer section the tool chain also puts a mark the first subsection, which conveys an impression that the remaining subsections are not normative. We opted for redundancy over possible confusion. At least until someone comes up with a tooling fix.

> - End of section 5.2: "sub classes", wouldn't you rather write 
> "subclass" or "sub-class"?

Fixed.

> *6* Creating DSDs
>
>
> - second bullet in introduction: UI construction is just one example, 
> so maybe it would be more appropriate to say something like 
> "...simplifies data consumption, for example for UI construction"

Fixed.


> - third bullet in introduction: SDMX data flow is a new notion not 
> introduced before, and it is explained in the next paragraph, so maybe 
> a reference to this paragraph should be made.

Done.

> - Penultimate paragraph of section 6.1: "... information can encoded...
> " -> "be" is missing.

Fixed.

> - Section 6.3, first paragraph: maybe "... sex of the population units"
> rather the "... sex of the population".

Fixed by dropping "of the population", since "population units" reads very oddly.

> - 6.3 Example. I don't see where it is expressed that the measure is a 
> means over the three-year period

This is indeed not expressed in machine readable form (though it can be expressed as a textual annotation using standard RDF machinery such as rdfs:comment). Extension vocabularies for this, which can complement and extend Data Cube, would be valuable future work.

> - 6.4, first bullet, remove closing chevron at the end of second 
> sentence.

Fixed.

> Also, in the Turtle example 4, I think that the bracket contents 
> should start with a space (same is true for example 11 in section 
> 7.2).

OK, done.

> - 6.5 (Handling multiple measures)
>
> . I find the expression a bit sloppy in this section. In particular, 
> third sentence of second paragraph is not clear to me.

Rewritten for clarity.

> . Third paragraph: "data cube" -> "Data Cube".

Fixed.

> . Fourth paragraph (just before 6.5.1): lots of "then" that don't help 
> to clarify.

Fixed.

> - 6.5.2 (Measure dimension). There is a mention of a "SDMX-in-RDF 
> extension vocabulary". I'm not sure of how this is linked to what is 
> described at the end of section 2.2 or in section 6.2. Where is this 
> extension defined or available?

DONE. Removed this reference. The original goal was to have an extension vocabulary which extends Data Cube to cover the whole of SDMX. However, currently no resources are available to develop this further.

> *7 *Expressing data sets
>
>
> - The definition of "Observations" talks about numbers. Observations 
> are not necessarily numbers, so I would replace the two occurrences of 
> "numbers" by "values".

Good point, fixed.

> - 7.1, Example 10. The example is described as an improved version of 
> Example 9, but as you say normalized datasets have advantages and 
> inconveniences, so maybe "shorter" would be a better adjective than 
> "improved".

Fixed.

> - 7.2
> . Second sentence. "This not intended" -> "is" is missing

Fixed.

> . Last paragraph before Example 11, first sentence. First "which" is 
> probably "with". There are a lot of "which" in this paragraph.

Fixed.

> - 8.2
> Two points on the third sentence ("Hierarchical code lists..."):
> . are you saying that skos:broader should not be used?

No but where used then preferably skos:narrower should also be provided to allow for uniform query.

> . maybe explicitely say that sub-properties of skos:narrower can be 
> used (for Richard: I'm thinking XKOS here)

Good suggestion, done.

> - 8.3
> . I'm not sure I understand the case in the third bullet (exhaustivity 
> and mutual exclusion). In XKOS, these notions are expressed at the 
> skos:ConceptScheme (or xkos:ClassificationLevel) level, so it's just a 
> qualifier of SKOS concept schemes. You don't really need "non-SKOS 
> hierarchies" here.

This was intended to highlight a limitation of SKOS as it exists (and which XKOS addresses). Have removed that bullet.

> . On the whole, I am very hesitant about the introduction of the 
> qb:HierarchicalCodeList class and associated properties. This raises 
> the more general problem of how to derive SKOS concept schemes from 
> sets of resources that have some kind of "real world" hierarchical 
> relations that are not hierarchies between codes in a code list, but 
> hierarchies in some specific sense between objects. The example of 
> geographic territories is a good one: here you have the territorial 
> inclusion relation that induces a broader/narrower relation between 
> associated items in a code list, but of course we do not want to make 
> a confusion between a region, for example, and an item in a code 
> scheme, nor between territorial inclusion and "broader concept". It 
> seems to me that the approach you describe fuels a bit the confusion.
>
> A different approach would be to explicitely generate a SKOS concept 
> scheme parallel to the "real world" hierarchy and to use a property 
> like foaf:focus to link the concepts to the things they represent (see 
> http://lists.w3.org/Archives/Public/public-esw-thes/2010Aug/0002.html).
>
> I think that this is a very general problem that should be addressed 
> in an ad hoc W3C or other group aimed at developing a recommanded 
> practice, rather than treated here and there in different fashions.

This one we discussed and resolved previously [2]. Do agree that there is room for development of best practice advice in this area in some suitable forum.

Best wishes,
Dave

[1] https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html
[2]
http://lists.w3.org/Archives/Public/public-gld-comments/2013Apr/0071.html

Received on Friday, 10 May 2013 08:12:35 UTC