Hi, Search for onchange in this page: http://208.76.222.114/confluence/display/DHIS1/DHIS+1.4 <http://208.76.222.114/confluence/display/DHIS1/DHIS+1.4> ---------------------------------- Ola Hodne Titlestad (Mr) HISP Department of Informatics University of Oslo
Mobile: +47 48069736 Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link<http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=Vetlandsvn.+95B,+0685+Oslo,+Norway> 2010/11/18 Lars Helge Øverland <larshe...@gmail.com> > > > 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 > >
_______________________________________________ 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
