2010/11/18 Bob Jolliffe <bobjolli...@gmail.com> > Can someone define what exactly is an onChange period type? Its a > term I have heard referred to a lot but I must confess I don't know if > I properly understand what it means. Do we simply mean an arbitrary > period of time (without frequency) ie. it has start and end date only, > but no inherent frequency characteristic? So start date would equal > the end date of the previous OnChange period for the same series of > datavalues. Or is it an instant ie. an observation captured at a > moment in time with no inherent interval implied? So > startdate=enddate? > > One case I recall hearing onChange periods being discussed was regard > staffing data in the context of data import from iHRIS. The number of > doctors might change infrequently so we might capture number of > doctors only when there is a change, rather than capturing the same > numbers each month. Either way it raises an interesting problem. I > think we define the aggregation "operator" (sum, average etc) per data > element. But it seems to me, looking at this particular example, that > you would actually want to aggregate differently depending on which > axis (time and space) that you were aggregating along. So for example > if I have datavalues for "number of doctors" which I collect on a > monthly report, it makes sense to sum across the spatial axis and > average across the time axis > > clinicA clinicB DistrictTotal > Jan 5 7 12 > Feb 5 6 11 > Mar 5 5 10 > > Quarter 5 6 11 > > Maybe there are other such cases where the aggregation operator would > differ across different axes. So there are maybe two ways to > rationalise this: one is to not capture the data monthly, but rather > "onChange". This does have an implication for things like monthly > data collection instruments, because I suspect frequently there will > be a requirement to capture such data routinely. The other is for the > dataelement to capture the change rather than the cumulative count - > like we would do with "new malaria cases" for example. In this case > we'd capture "new doctors". In that case we could sum across both > axes and get a sensible result, but one which would only be useful > with a sort of opening balance for the dataelement. So it is not so > much the period type which is onChange but the dataValue type. The > datavalue either reflects what has happened within that period or what > the cumulative status is at the end of that period. > > This is maybe confusing two related issues, but the other approach > which comes to mind is to have two aggregation operators for the data > element - the time aggregation operator and the space aggregation > operator. This might lead a simple way out of the contradictions and > complications above. For many, perhaps most, these would both be > "sum". But for others, like the above, we would "sum" over space and > "average" over time. I am sure there might be other examples where > the reverse is true. > > I am also sure these are all well known and well solved problems, so > apologies if I am being ignorant. > > Cheers > Bob > > Philosophical aside: Frederick Engels in Anti-Durhring, defines time > as that quantity required in order for things to change. I always > like that definition :-) >
Quick comment: Currently the aggregation operator property applies to the time axis only, space axis is always sum.
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
