dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Yes Abyot!  I found myself backtracking a bit in your direction in my mail
of 9 Nov, reporting back from sdmx connectathon:

"2.  There was an interesting revelation for me (somehow I had not
understood it completely before) around the way SDMX HD deals with the issue
of selecting valid dimensionOptions for a dimension.  It bears some
resemblance to both what Abyot had originally implemented
(categoryoptionsfor a particular category selected from a super set of
all available
categoryoptions) and the subsequent refinements discussed on the Zooks mail
thread.  What is proposed in SDMX HD is that dimensionOptions should
implement a concept.  For each concept there is a list of all possible code
values.  Particular dimensions would implement a subset of dimensionOptions
selected from that list.  For example:

codelist representing the AGE concept:
{<1, >1, 0 to 5, 0 to 16, >16, <40, .... } etc

A particular dimension, eg STI_AGE_GROUP might then contain the subset:
{0-16, >16}

This is an interesting twist on what we do and does seem to have some
merit.  It addresses Abyot's concern that we might want to reuse category
options as well as my concern that we shouldn't mix apples with oranges.  I
think we are all a bit fatigued looking at datamodel refinements (I'm sure
particulalrly Lars!) but this is something we might want to consider.  So
far as supporting SDMX HD we will at a minimum probably have to implement a
concept field to the categor/categoryoption (and Group/GroupSet) objects.
The constraint to apply would be that categories of a particular
conceptshould contain
categoryoptions of the same concept. "

This hybrid approach seems to capture the best aspects of both ways of
looking at category options.  Obviously people were a bit fatigued because
this didn't elicit any response :-)  For the moment I am hoping that we can
get away with just relaxing the uniqueness constraint.

Regards
Bob

2009/12/11 Abyot Gizaw <abyota@xxxxxxxxx>

> Sorry, for picking the famous old discussion :(
>
> This is exactly what I have been arguing for. Category option is more than
> a label - for me it is a unit of analysis and we need to reuse it !
>
> It is a mistake to constrain our unit of analysis with only one category.
> In Ola's case, even more stupid we are going to have "15-49  Years" twice
> and no guarantee we might even end up with 100's of the same "label" or same
> unit of analysis.
>
> On Fri, Dec 11, 2009 at 3:36 PM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:
>
>> Hi,
>>
>> I know there might have been some discussion on this in the past, but in
>> stead of browsing through all my mails, a quick question:
>>
>> No that a category option only can exist within one category why do we
>> need the unique name constraint on catoptions?
>> Within one category we should have unique names for its option, but why
>> across categories?
>>
>> This constraint is making it more difficult to come up with good and
>> consistent names for category options, e.g I have two categories
>> VCCT_age and PMTCT_age and they share some of the age groups, and now I
>> need to name age differently (e.g. '15-49 y' and '15-49 years') in the two,
>> which is stupid I think.
>>
>> Can we get rid of this constraint?
>>
>> Ola
>> -------
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> More help   : https://help.launchpad.net/ListHelp
>
>