dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 10 August 2011 10:28, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> I think what you are implying here is that category options should
> actually be derived from concepts.
>
> We would start off be defining a concept, such as "Age" with all
> possible category options.
>
> We could define multiple categories, with the concept of "Age" and the
> only available options would be from the "Age" concept.

Exactly.  Plus generic ones.  There are categoryoptions such as None,
Unknown etc which will likely be required across concepts.  And in the
pivot table views you make use of the concept rather than the category
as column heading - in which case all your age categories fold
together so you can compare under 1's regardless of which category
they derive from.

I had originally thought that categoryoptions don't need a concept -
they would simply derive that from the category they are assigned to.
But in retrospect, it is actually much simpler to also associate the
categoryoptions with a concept so they will have a natural affinity
with the correct categories.

>
> Totally agree with that "0-4" should not appear in both an "Age" and a
> "Gender" concept. This seems to make no sense what so sever. But 0-4
> appearing in multiple categories does seem to make a lot of sense.
>
> Regards,
> Jason
>
>
> On Wed, Aug 10, 2011 at 10:13 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>> 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
>>>
>>>
>>
>