Re: [QB] ISSUE-31 (Aggregation hierarchies) Discussion and proposal

Hi Sarven,

On 01/03/13 09:18, Sarven Capadisli wrote:
> Hi Dave, thanks for putting this together.

Thanks for commenting.

> On 02/28/2013 12:30 PM, Dave Reynolds wrote:
>> ISSUE 31 [1] concerns support for hierarchies other than SKOS. I know
>> this one is controversial ...
>>
>> In Data Cube as it stands then a cube component (qb:ComponentProperty,
>> especially a dimension) can be coded using codes from a
>> skos:ConceptScheme. This roughly corresponds to the SDMX notion of a
>> Concept Scheme [2] where codes are arranged in a parent/child hierarchy.
>> The normal skos:narrower/skos:broader relationships are used to express
>> such parent/child relationships.
>>
>> Often in statistical publishing values will be given for different
>> levels in such a concept scheme - e.g. the population statistics for the
>> UK as a whole as well as those for each region. Though the value for the
>> parent may not simply be the sum of those for its children.
>>
>> Especially when dealing with geographic hierarchies some limitations of
>> the current approach that have come up in practice, e.g. see [3].
>>
>> There are 3 problems here and a non-problem.
>>
>> The non-problem is that it is perfectly reasonable to create a
>> skos:Concept to represent an geographic region and to use
>> skos:narrower[4] to represent a relevant containment hierarchy. That's
>> not why ISSUE-31 is on the list.
>>
>> The problems are:
>>
>> (a) Publishers would like to reuse existing geographic hierarchies
>> already published as linked data (e.g. [5]) but where that data uses
>> different predicates to represent the hierarchy than skos:narrower.
>>
>> (b) The same geographic regions can participate in multiple hierarchies.
>> As well as spatial containment there is also administrative containment.
>> We can only use skos:narrower for one of these.
>>
>> (c) In cases like [3] people also wish to state when the child concepts
>> are disjoint so that aggregation might be possible (so long as the
>> measures themselves can be aggregated), or more strongly that the parent
>> concepts are a disjoint union of the child concepts.
>>
>> It is possible to work around (a) by publishing your own skos:narrower
>> assertions about the existing published linked data. However, that is
>> problematic to keep up to date, may conflict with someone who wants to
>> use skos:narrower in a different sense over the same concepts (see b)
>> and can be socially/politically problematic.
>>
>> Problems like (b) are handled in SDMX through the use of hierarchical
>> code schemes [6] which can be used to create multiple different
>> generalized hierarchies over the same code list.
>>
>> PROPOSAL.  Proposed approach is a vocabulary extension:
>
> I for one would welcome these type of extensions because they are much
> clear than re-purposing or fitting the requirements into existing
> relations out there.
>
> I will first mention how I tried to deal with SDMX-ML to RDF/XML mapping
> by using SKOS and XKOS. To simplify:
>
> #An SDMX structure:HierarchicalCodelist
> :foo
>    a skos:Collection ;
>    skos:member :bar ;
>
> #An SDMX structure:Hierarchy
> :bar a skos:Collection, xkos:ClassificationLevel ;
>    skos:member :baz .
>
> #Hierarchy for the SDMX structure:Codes
> :baz
>    a skos:Concept ;
>    xkos:hasPart :bbq .
>
> :bbq
>    a skos:Concept ;
>    xkos:isPartOf :baz .
>
> I'm not completely sure if that's accurate but it seems close enough.
> But, it took me awhile to get my mind wrapped around it, in order to
> reuse what's out there. It is probably insufficient and would probably
> create undesirable relations - to be reviewed. So, again, I welcome the
> proposal.

I don't know enough about xkos to say if that's accurate but looks 
intuitively reasonable to me.

> Some comments on the following.
>
>> qb:hierarchy (domain: qb:CodedProperty, range: qb:Hierarchy)
>>     Indicates a specification of the hierarchy used for coding this
>> property (typically a DimensionProperty). Where a skos:ConceptScheme
>> exists with appropriate broader/narrower relations then that should be
>> used and should be specified using qb:codeList. The qb:hierarchy
>> declaration is only need for situations where a suitable
>> skos:ConceptScheme is not available.
>
> I don't think I fully understand this. Is this supposed to handle
> situations in absence of @codelist in <structure:Dimension>?

Yes, the proposal is to allow either qb:hierarchy or qb:codeList or both.

> Aside: my first impression of qb:hierarchy was for
> domain:HierarchicalCodelist, range:Hierarchy

That would be another approach. Define a generalized notion of code list 
and make that the range of qb:codeList. Then the hierarchy specification 
would be one form of generalized code list alongside skos:ConceptScheme 
and skos:Collection.

In some ways that might be better but I wanted to avoid having this 
small addition being seen as a skos extension and keep it as specific to 
Data Cube.

>> qb:Hierarchy (owl:Class)
>>     Specifies a hierarchy which can be used for coding. The same
>> concepts may be members of multiple hierarchies provided that different
>> qb:[narrowing/broadening]Property values are using for each hierarchy.
>
> Clear.

Good.

>> qb:AggregatableHierarchy (sub class of: qb:Hierarchy)
>>      Indicates a hierarchy in which each parent concept is a disjoint
>> union of its child concepts. So that measures such as simple counts
>> *may* be aggregated up the hierarchy.
>
> Would you mind elaborating on this or point at what it corresponds to in
> SDMX Structure 2.0/1?

As far as I'm aware this isn't in SDMX 2.0, I don't know about 2.1, 
Richard is looking that.

Does my explanation to Benedikt [1] in response to his question on xkos 
help?

>> qb:hierarchyRoot (domain: qb:Hierarchy, range: skos:Concept)
>>     Specifies a root of the hierarchy. A hierarchy may have multiple
>> roots but must have at least one.[7]
>>
>> qb:narrowingProperty (domain: qb:Hierarchy, range: rdf:Property)
>>     Specifies a property which relates a parent concept in the hierarchy
>> to a child concept. One of qb:narrowingProperty or qb:broadeningProperty
>> must be given but it is not necessary to have both. Note that a child
>> may have more than one parent.
>>
>> qb:broadeningProperty (domain: qb:Hierarchy, range: rdf:Property)
>>     Specifies a property which relates a child concept in the hierarchy
>> to a parent concept. One of qb:narrowingProperty or
>> qb:broadeningProperty must be given but it is not necessary to have
>> both. Note that a child may have more than one parent.
>
> Clear.

Great, thanks for the feedback.

Dave

[1] http://lists.w3.org/Archives/Public/public-gld-wg/2013Feb/0113.html

Received on Friday, 1 March 2013 13:40:18 UTC