Re: AW: [QB] Last Call document draft

Thanks Benedikt,

I have addressed your editorial issues. Here's responses on the others:

 > * 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?)

A dimension may specify its values using rdfs:range in order to be able 
to use instances of some class as the codes. For example, see the use of 
time intervals from the UK reference time service in the running 
example. This is not a change to the spec, it has been like that all the 
time  and we haven't changed that phrasing.

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

Sorry, not sure I follow what you are saying here.

For both approaches to multiple measures then all measures are required. 
IC-17 says that for Measure dimension cubes, just as IC-14 says it for 
multi-measure observations. So that's not an advantage of one approach 
or the other.

Whereas the section you quote is one reason to use the Measure dimension 
approach instead of multi-measures.

Due you mean we should point out explicitly that all measures are 
required, whichever approach you use? Or are you saying that measures 
should be optional in one approach or the other?

 > * 7.5.2: "SMDX-in-RDF extension vocabulary" (reference is missing)

I've rephrased that line instead. I want to avoid getting into the 
status of the SDMX-in-RDF extension!

 > * 11: No mentioning of DCAT?

Ah, good point. Of course that section was originally written before 
DCAT. I'm not sufficiently familiar with DCAT to suggest what to put 
here. DCAT seems like it would be more used to describe a catalogue 
entry that would reference a Data Cube rather than a Data Cube itself.

Richard - if you feel there is a useful reference to DCAT to be made 
here I'm happy for you to make that change and will trust your judgement 
on it.

 > * 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?)

Yes. If there is explicit markup the query will find it and check that 
it is being applied to an attribute. If there is no explicit markup then 
there is no error to find and the query will not find one. After all if 
there is no declaration then it is only attributes that trigger that 
default behaviour.

 > * 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?)

Originally we wanted to leave the range rather open to allow for other 
attachment levels in the future. Especially when/if it came to resolving 
issue with subslices, but also possibly for SDMX 2.1. It seems 
reasonable to leave it like that at this stage since the integrity 
constraints make the relevant usage reasonably clear.

Changes checked in and updated pubrules-compliant static.html generated.

Cheers,
Dave


On 07/03/13 17:19, Benedikt Kaempgen wrote:
> 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 18:52:11 UTC