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

Re: ISSUE-59 (FC-HierarchicalCodeList): Last Call comment. Frank Cotton on qb:HierarchicalCodeList [Data Cube Vocabulary]

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Wed, 10 Apr 2013 14:43:48 +0100
Message-ID: <51656C94.1040003@gmail.com>
To: public-gld-wg@w3.org
On 10/04/13 13:49, Government Linked Data Working Group Issue Tracker wrote:
> ISSUE-59 (FC-HierarchicalCodeList): Last Call comment. Frank Cotton on qb:HierarchicalCodeList [Data Cube Vocabulary]
> http://www.w3.org/2011/gld/track/issues/59
> Raised by: Dave Reynolds
> On product: Data Cube Vocabulary
> Last Call comment from Frank Cotton: http://lists.w3.org/Archives/Public/public-gld-comments/2013Apr/0061.html
> [[[
> 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.
> ]]]

I propose that we push back in this case.

We failed to mark this item "At Risk" (arguably an oversight) so 
withdrawing it would mean another Last Call which would probably mean 
not getting to CR before we close.

We had one comment [1] specifically endorsing this feature so removing 
it would also risk Last Call comments the other way round.

Possible sketch response text:

Thank you for your comments on qb:HierarchicalCodeList, we understand 
your hesitation.

This was added in response to feedback from groups who have tried to use 
Data Cube and found a requirement for something of this nature in order 
to be able to use existing geographic or admin-geographic hierarchies as 
dimensional values. See for example Last Comment [i] endorsing this feature.

We're not sure that adding this option necessarily fuels confusion 
between skos:broader and say admingeo:containedBy. One could equally 
argue that having to create a parallel skos hierarchy in which quite 
different notions like geographic containment and administrative 
containment are all translated to skos:broader would itself fuel such 

In any case, in the reported use cases minting a parallel skos hierarchy 
is not practical. In technical terms it is possible but there is a 
challenge for how to keep it up to date as the primary geographic 
hierarchy is changed (in the absence of standardized change notification 
for linked data resources). In social/political terms it is much harder. 
There is a strong preference to use officially supported identifiers for 
administrative areas when publishing information pertaining to those areas.

Our preference would be to retain the qb:HierarchicalCodeList in Data 
Cube at this time since it gives users who have expressed this 
requirement a usable option. We would qualify the text to clarify that 
this construct should not be in cases where a suitable SKOS concept 
scheme exists or could could reasonably be created.

Would this be acceptable to you?

Your suggestion of ad hoc W3C, or other, group work to develop best 
practice in this area is a good one. Such a group could include in their 
advice recommendations on when and how qb:HierarchicalCodeList is best 
used. Which may include recommendations that it should be deprecated in 
favour of a broader solution when one is available.



One other thought is whether we can add something similar to "At risk" 
statements between LC and CR?  I.e. could we now mark it this section as 
"May be deprecated, seeking further feedback from implementers"? Is 
there such a notion?


Received on Wednesday, 10 April 2013 13:44:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:38 UTC