Re: [QB] Last Call document draft

On 03/05/2013 03:28 PM, Dave Reynolds wrote:
> 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/
>

Wow, just got a chance to see this email. This is excellent!

Some comments where some of it may be for future discussion:

* In Example 15, should eg:sex a sdmx:DimensionProperty, 
sdmx:CodedProperty; be eg:sex a qb:DimensionProperty, qb:CodedProperty; 
? AFAIK, the intended classes are defined by QB.

* Is 6.2 missing sdmx-metadata?

* 6.4 has a typo "qb:componentRequired>"

* It may be that it is late to mention this, but the discussion on 
qb:parentChildProperty reminded me of SDMX's parentCode property "to 
describe simple hierarchies within a single codelist, by referenceing 
the id value of another code in the same codelist". So:

codeA hasParent codeB

I currently treat this encounter with xkos:isPartOf. Perhaps that's 
sufficient, but I wonder if we should handle this case separately.

This line of thinking is closer to what I've mentioned in separate email 
regarding how I handle hierarchical codelists and hierarchies. At least 
my interpretation. It is also inline with Benedikt's view as he mention 
in his reply.

Is qb:Hierarchy missing in action? Because I see 
qb:HierarchicalCodeList, but that's somehow given to something like 
eg:GBgeoHierarchy. But, SDMX (if this matters) differentiates between a 
HierarhicalCodeList (a collection of hierarchies) and a Hierarchy (a 
collection of codes with a hierarchical relationship).

* I had to read the sentence in 7.2 three times (probably only me): "For 
example, in representing results from a collection of asynchronous 
monitoring processes it can be desirable to group together the set of 
most recent observations available from each process."

Would an example from "common" vocabulary and knowledge be simpler e.g., 
"For example, in representing results from weather conditions, it can be 
desirable to group together previous three days observations."

* SDMX has an attachment type on the Series level. I'm not entirely 
clear on this, but I think it would be sort of like using qb:Dimension 
for qb:componentAttachment. 12.7 says "Indicates the level at which the 
component property should be attached, this might be an qb:DataSet, 
qb:Slice or qb:Observation, or a qb:MeasureProperty." Do we need to 
cover this? In my own work, I'm actually lowering the attachment level 
to qb:Observation. You mentioned "to leave the range rather open to 
allow for other attachment levels in the future", so, that's okay for now.

* I guess Annotations (e.g., SDMX Annotations) can be discussed in the 
future? :)

* This might not concern the RDF Data Cube vocabulary but, SDMX-ML 
differentiates ConceptScheme from CodeList. Should there be 
sdmx:ConceptScheme?

* Should SDMX's TimeDimension be given any special treatment?

* In SDMX KeyFamilies (DSDs), it is possible to have a dimension 
component without specifying a codelist, but rather some literal 
indicating what to expect e.g., "Year", for the dimension value in an 
observation. This is different than the TimeDimension. As far as I 
understand, there is a slight conflict with QB's expectations i.e., a 
coded value using an URI. Even if the Concept and the ConceptScheme is 
provided for the dimension component, it is a bit awkward to create a 
URI like:

http://{authority}/concept/{version}/{conceptScheme}/{concept}/{year}

I'm raising this moreso for awareness in case it wasn't previously 
discussed. I'm not suggesting a particular proposal. I like the things 
on the QB end as they are :)

Cheers,

-Sarven

Received on Thursday, 7 March 2013 21:43:37 UTC