W3C home > Mailing lists > Public > public-gld-wg@w3.org > March 2013

Re: [QB] Last Call document draft

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Thu, 07 Mar 2013 22:36:43 +0000
Message-ID: <5139167B.1000506@gmail.com>
To: public-gld-wg@w3.org
Hi Sarven,

Thanks for the comments, very helpful.

Responses in line.

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

Fixed, that hangover has been missed for some time!

> * Is 6.2 missing sdmx-metadata?

Yes but that's deliberate. We don't have MetadataProperty in QB, that 
remains part of the SDMX-RDF extension and the sdmx-metadata translation 
(and use) is based on that. So I think it best to leave that out of this 

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

Not sure I follow how this is different from normal skos usage.

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

qb:Hierarchy *is* qb:HierarchicalCodeList, Richard suggested the name 

In terms of SDMX relation then remember that QB is still SDMX 2.0, 
changing that to 2.1 has been postponed. It may be that some of what you 
are describing is part of 2.1.

In 2.0 then simple hierarchies are already covered by skos:ConceptScheme.

SMDX 2.0 has, in addition those, a notion of "Hierarchical Code Scheme" 
(SMDX 2.0, Information Model, section 8, p.96) which describes the key 
features of those as being:

1. A child code can have more than one parent.

2. There can be more than one code that has no parent (i.e. more than 
one “root node”).

3. There may be many hierarchies (or “views”) defined, in terms of the
associations between the codes. Each hierarchy serves a particular 
purpose in the reporting, analysis, or dissemination of data

qb:HierarchicalCodeList supports all of those. Of course, SKOS already 
supports the first two, what qb:HierarchicalCodeList adds in this case 
is the ability to have different hierarchies laid over the same code set 
by using different qb:parentChildProperties. True it doesn't use 
associations for that but simple properties are so much easier to handle 
in RDF and the aim was to provide something simple to cover the  common 
use cases.

SDMX Hierarchical Code Scheme does go further in allowing for 
level-based hierarchies. This is really useful but since there is 
already the xkos work on representing levels in hierarchies then it did 
not seem right to duplicate that. Especially at this late stage :) 
After all, that builds on skos:Collection and now that we allow 
skos:Collections then connections to xkos become easier.

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

Yes, that could be clearer :) I've improved it based on your suggestion.

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

Leave for future extensions :)

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

Indeed. Once you have URIs you can annotate to your heart's content 
anyway using existing vocabularies.

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

I think the current union range for qb:codeList allows enough 
flexibility on that for now.

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

Some of that was in SDMX-RDF and so could be added in extensions, not 
part of core qb, at least on this round.

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

Actually QB allows literal values and always has, there's been no change 
there. First line of what is now section 8.1 says:

"The values for dimensions within a data set must be unambiguously 
defined. They may be typed values (e.g. xsd:dateTime for time instances) 
or codes ...". The integrity rules just demand that there is an 
rdfs:range declared and that *if* there is a code list the values fall 
within that code list.

We do use the UK reference.data.gov.uk URIs in the examples - which then 
enable you to talk about government years v. calendar years etc. But 
there's nothing in the spec that *forces* you to use URIs for timepoints.

Thanks again for the comments.

Received on Thursday, 7 March 2013 22:37:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:06 UTC