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

Dave,

I can live with the general approach. Comments inline.

On 28 Feb 2013, at 11:30, Dave Reynolds wrote:
> PROPOSAL.  Proposed approach is a vocabulary extension:
> 
> 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 understand that this is no longer part of the proposal, but instead qb:codeList is generalized to allow Hierarchies in the range? That would seem better to me.

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

Ok. Maybe call it qb:HierarchicalCodeList? That might draw attention to the similarities between the two kinds of hierachies -- the flexible qb:Hierarch(y|icalCodeList), and the more specific skos:ConceptScheme. (Not a strong opinion.)

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

I don't quite see how this can work. If I know that each parent is the disjoint union of its children, I still don't know how to aggregate values. If the observations measure life expectancy, I need to average. If the observations measure population count, I need to sum. In other cases, I may have to take the minimum or maximum. It seems to me that this class only addresses one particular use case and is not a general solution to the problem of aggregating up the hierarchy.

I propose to drop qb:AggregatableHierarchy. It can be easily defined in a use case specific extension.

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

Fine. (Is there a general assumption that the members of a hierarchy still must be skos:Concepts? I think we don't need to make that assumption. Not making the assumption may avoid some confusion and may be less controversial. In that case, the range would simply be rdfs:Resource I think.)

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

One of these is redundant. I'd do away with broadeningProperty, rename narrowingProperty to something like parentChildProperty (seems more intuitive to me), and point out the design pattern of asserting

  ex:myHierarchy qb:parentChildProperty [ owl:inverseOf ex:parent ].

This minimises the number of vocabulary terms, and isn't really any more difficult to query for.

I presume the well-formedness rule for hierarchies are something like:

1. If a dimension has a hierarchy as code list, then values of that dimension in observations must be reachable from one of the roots in zero or more hops along the parentChildProperty, except if the parentChildProperty is a blank node.

2. If the parentChildProperty has an inverse property P, then any dimension value must be reachable from one of the roots in zero or more inverse hops along P.

Best,
Richard



> 
> Dave
> 
> [1] http://www.w3.org/2011/gld/track/issues/31
> 
> [2] http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf p.39
> 
> [3] https://groups.google.com/forum/#!topic/publishing-statistical-data/3I1-Ix1Hk14/discussion
> 
> [4] I'm using skos:narrower as a shorthand for skos:narrower/skos:broader, no slight intended to skos:broader
> 
> [5] http://data.ordnancesurvey.co.uk/.html
> 
> [6] http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf p.96
> 
> [7] This is to match SDMX 2.0 [6] which also supports multiple roots.
>

Received on Sunday, 3 March 2013 20:43:46 UTC