dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 10 August 2011 12:54, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> Yes, this would seem to work. Not sure of the amount of work involved
> in it of course.
>
> Ola and I had a long chat this morning, with some of it devoted to
> this and he brought up the important issue of deletion/editing. It
> would seem that the rules should be such that category options cannot
> be deleted from a concept, if they belong to a category, just like
> now, it is now possible to delete category options from a given
> category.
>
> Ola also raised the point of a sort of _conceptstructure resource
> table, which would basically consist of a coalesced view of the
> current _categorystructure table, whereby all categories which belong
> to a particular concept, would appear in a single table, which I think
> would provide the view needed for the pivot table. See the attached
> screen shots for what might work in this regard, simply by coalescing
> the two "Age" categories together.

Yes this is what I have been saying.  At the point of analysis (the
pivot table dimensions) it is no longer of interest whether a figure
represents under ones captured in forms A, B or C in different
categories.  Just the age is under 1.

The same logic also applies quite simply to other dimensions ie. those
derived from groupsets.

Imagine you have a number of dataelements wchich have been
disaggregated (using Mcdonalds categoryoptions) as Male and Female
under a Gender or Sex concept.

And you also have a bundle of "traditional" 1.4 style dataelements
where the sex is implicit in the name (Malaria_cases_male,
Malaria_cases_female).  Then you would probably create a gender
groupset and group male and female dataelements this way.  But ... if
your gender groupset could also implementing the Gender concept, then
this data would also be lined up in the same column as the
disaggregations from the categoryoptions.  Whether the disaggregation
is done pre-hoc (mcdonalds) or post-hoc (groupsets) is not of interest
to one analyzing the pivot table.

Regards
Bob

> Regards,
> Jason
>
>
> On Wed, Aug 10, 2011 at 12:07 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>