W3C home > Mailing lists > Public > public-gld-comments@w3.org > May 2013

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

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Thu, 09 May 2013 14:22:18 +0100
Message-ID: <518BA30A.2000302@gmail.com>
To: Cotton Franck <franck.cotton@insee.fr>
CC: "public-gld-comments@w3.org" <public-gld-comments@w3.org>, Guillaume Duffes <guillaume.duffes@gmail.com>
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 Thursday, 9 May 2013 13:23:15 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:23:16 UTC