dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> Dear DHIS2 devs,
> While considering the email sent to the users list this morning (which
> is a problem I have come up against several time) I wanted to
> experiment with the possible re-use of category options across
> categories. With a bit of SQL applied to the database, I was able to
> "reuse" a category option between two separate categories. One age
> group
>  was defined as  0-4, >5  and the other as 0-4,5-10, 11-15. Note the
> re-use of the "0-4" category option between two seperate categories.
> These two separate age categories were applied to a category
> combination, and then applied to a dataset. I was able to enter data
> for a test organisation unit and time period.
>
> This leads me to beleive there is nothing wrong with the model, which
> would not allow re-use of category options between categories, but
> rather, it seems to be design issue which
> 1) is not properly enforced because the restriction of a category
> option to a single category seems to be rather easily evaded
> or 2) should be relaxed/improved to allow the re-use of category
> options between categories.

1.  Don't have time to look at your sample, but I believe you.
2.  The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE.  Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}.  But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name).  So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :-(

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC.  This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all.  As you say the model rather easily
allows this retreat.  But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

>
> Attached is the sample database (Postgres backup) which I created
> during this experiment. Not sure by any means that everything works,
> but it would be interesting to get comments on this issue, which has
> been raised several times.
>
> Best regards,
> Jason
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>