AW: [QB] Last Call document draft

Hi,

Impressive work. I have one larger comment and a list of smaller comments to the new QB spec version. 

Larger feedback:

==10.2 Hierarchical code lists==
* For OLAP on QB [1], I use hierarchy levels of increasing detail as first class citizens in the data, e.g., to give them a name such as "Product Brand". Therefore, I am using XKOS for representing hierarchy levels (xkos:ClassificationLevel, subclass of skos:Collection) [2]. 
* Here, I would still use skos:narrower to define relationships between skos:Concepts. 
* However, I would connect those concepts via skos:member to separate xkos:ClassificationLevels, each having a xkos:depth, and would then connect those xkos:ClassificationLevels via skos:inScheme to the code list.
* Also, I would not declare skos:topConcept but rather define the top concepts via an upmost level (depth 0 or 1). 
* I want to make sure that I still comply with the vocabulary and do "not use terms from other vocabularies instead of ones defined in this vocabulary that could reasonably be used".
* Thus, my question: Can publishers still reuse XKOS together with QB? I think, we should allow and clarify this. For instance, this could mean to allow that skos:Collections are connected to a code list instead of using skos:hasTopConcept.

[1] <http://code.google.com/p/olap4ld/>
[2] <https://github.com/linked-statistics/xkos>

Minor feedback:

* 2.1: "using the the W3C" (double the)
* 5.2: Maybe call this section "Introducing slices" or similar to distinguish it from Section 9
* 7.1: "In particular, is sometimes" (should be "it is sometimes")
* 7.1: "To cater for this a component can also be optionally annotated with a qb:codeList to indicate a set of skos:Concepts which may be used as codes." (do we allow to have non-coded DimensionProperties?)
* 7.2: "has developed, and maintains, RDF encodings of these guidelines" (rephrase: "has developed that maintains RDF encodings of these guidelines")
* 7.3: Explicitly mention prefix "interval" and "admingeo" in prose before having it used in the turtle (interval:Interval and admingeo:UnitaryAuthority). Have a reference to the data.gov.uk reference time service.
* 7.4: "every observation then the specification should set ." (incomplete sentence, should finish with "qb:coponentRequired", probably)
* 7.4: "The qb:componentRequired> declaration" (the ">" is not needed)
* 7.4: "It can also be useful in the publication chain to enable synthesis of appropriate URIs for observations." (unclear, you mean qb:order as a kind of code for a dimension?)
* 7.5.1: "Note that one limitation of the multi-measure approach is that it is not possible to attach an attribute to a single observed value." (Is there not also the following limitation: Since measures defined in data structure definitions are always "required", all multiple measures need to be set in every observation. If IC-17 does say otherwise, we should explain it here.)
* 7.5.2: "SMDX-in-RDF extension vocabulary" (reference is missing)
* 7.5.2: "which subsumes each of the individual measures, those individual measures are used directly." (difficult to understand, please rephrase)
* 9: Section structure could be better balanced, here. How about having "8.2 Slices and general groups of observations" instead of "9. Slices"? 
* 10.1: "Explicitly declaring the code list using qb:codeList is not mandatory" (What exactly does that mean? Using qb:codeList is not mandatory in general or in case an rdfs:range is set? Put differently, can we give a ranking of how to best model coded values: 1) Use qb:codeList and rdfs:range 2) Use qb:codeList 3) use rdfs:range?)
* 10.2: "code lists lists should" (double lists)
* 10.3: "or then they form a complete cover of the parent concept" (should be "when they")
* 10.3: "The Data Cube vocabulary supports this situation through the qb:HierarchicalCodeList class. An instance of qb:HierarchicalCodeList defines a set of root concepts in the hierarchy (qb:hierarchyRoot) and a parent-to-child relationship (qb:parentChildProperty)." (Do I understand correctly, that qb:HierarchicalCodeList is the non-SKOS pendant to skos:ConceptScheme, qb:hierarchyRoot to skos:hasTopConcept and the property defined by qb:parentChildProperty to skos:narrower. If so, I think we should clarify that. Also, I think, we should back up "parent-to-child relationship" with a reference of what it means.
* 10.3 - example 16: "qb:hierarchy Root" (should be qb:hierarchyRoot)
* 11: No mentioning of DCAT?
* 11.1: "where eg:Wales is a skos:Concept drawn" (eg:Wales not found in example 18)
* 12: "For illustration see example 4 in which" (link to example 4 does not work)
* IC-6: "The only components of a qb:DataStructureDefinition that may be marked as optional, using qb:componentRequired are attributes. " (Since in 7.4 we say "In the absence of such a declaration an attribute is assumed to be optional.", will this test work?)
* 14.7: "might an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty" (1) verb "be" is missing 2) Why is this union not formalised in the range?)
* 14.7: "component is a attribute." ("an attribute")
* 14.6: "Defines/indicates" (editorial comment: We sometimes start with an upper case letter, sometimes with a lower case letter. Should be consistent)

Best,

Benedikt

________________________________________
Von: Dave Reynolds [dave.e.reynolds@gmail.com]
Gesendet: Dienstag, 5. März 2013 15:28
An: Government Linked Data Working Group
Betreff: [QB] Last Call document draft

I've released what I hope is a reasonable initial candidate for the Last
Call WD for the Data Cube vocabulary. This is preparation for the vote
on Thursday.

https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html

I'll send a separate note around on where we are with the various
issues. However, I think this draft resolves each of the issues in the
way discussed in the separate email threads.

Richard please check this. Feel free to fix minor problems or ask me to.
Major problems should probably be raised on the list.

Benedikt - thanks for volunteering to do a review check. Please let us
know of any problems that you spot.

The most substantial change from the last WD is the section on criteria
for well-formed Data Cubes (ISSUE-29 [1]). The criteria discussions have
been on the list. The SPARQL queries which are provided (to back up the
narrative descriptions of the criteria) have all been checked on at
least some positive and negative examples. The code for this is in the
same repository where the vocabulary source sits [2].

I have one more task before putting down the edit token, which is to
find a way to have a "Contributors" section to list Jeni, rather than
leave here in the Acknowledgements.

Dave

[1] http://www.w3.org/2011/gld/track/issues/29

[2] https://code.google.com/p/publishing-statistical-data/

Received on Thursday, 7 March 2013 17:20:05 UTC