I think Ola's example is a pretty typical one and certainly one that meets most of the requirements here.
>To me this rules out re-using the same dimensional attributes for data > entry and analysis - we must in any case have on set of dimensions for data > entry and one set of dimensions for analysis. Yes, I agree with this to some extent. I think that categories should be confined to data entry, which is a clearly a requirement, but not an absolute one. Non-multidimensional data elements could be employed for the same purpose it would seem. I would think they may need special methods like ordering on a screen, which points to more of an implementation of an object, than the object itself. Multidimensional data elements can be assigned cateogries for the purpose of data entry, which would not be able to be deleted, but could perhaps be added to, once data has been entered. I suppose categories could be deleted, with the data being deleted as well? Seems complicated, but maybe this has been considered during the original implementation. I agree , they should be able to be assigned additional DimensionOptions, after the fact. CategoriesOptions and DimensionOptions should be invisible to the end-user. Likewise, data elements that have not been assigned categories for the purpose of data entry, should be able to be assigned DimensionOptions at any point in time. Thus, CateogryOptions and DimensionOptions would be drawn from the same data source potentially, but used for different purposes. > > c) Ola's suggested solution supports this. It is powerful in the ability to > assign "raw" DataElements to Dimensions/GroupSets through > DimensionOptions/Groups, completely independent of which Categories the > DataElement was assigned to for data entry. The weakness is that it is based > on flat data elements, not Categorized data elements, which we must include > if we are to justify the Categorized data entry. I think there is clear justification, as Johan has pointed out. It makes life easier in some cases, but I see a potential problem when it comes around to changing a multidimensional data element which inevitably happens all the time. Disaggregation is changed from time to time, which will force implementers that have chosen to go down the multidimensional route, to create new data elements somehow, with different category options. But if you want to compare these longitudinally across the change in CateogryOptions, this could be done by assigning correct DimensionOptions if necessary, perhaps? > > This way we can assign dimensions as we like without loosing the fine > granularity of the captured categorized data. We can improve the report > table functionality in order to utilize this. This will be feasible with the > time and resource constraints we are operating with. It also alleviates the > challenge regarding Indicators and SDMX. Perhaps. I am not familiar yet with how SDMX implements indicators. However, it is clear from our experience with the OpenHealth prototype that not all data elements or indicators are intrinsically multidimensional. Some of the indicators from the UNGASS are devilishly complex, like the NCPI index. DHIS 2 gets around this problem with the use of formulas. Take the indicator "Couple year protection rate", which is defined in my system as [103.16] / 13 + [104.16] / 4 + [105.16] / 6 + [107.16] * 10 + [106.16] * 5 + [108.16] * 10 + [109.16] * 10...a lot of data elements divided/multiplied by certain factors. This would never be multidimensional and SDMX will have to transport this "indicator logic" with it. The main use of the DimensionOptions/CategoryOptions for me would be for ad-hoc analysis, OLAP cubes, and other "analysis" purposes. I guess SDMX would need to be able transport both multdimensional indicators (which are defined with multidimensional data elements or non-multidimensional data elements that have been assigned DimensionOptions), but these will not cover all indicators .Usually, indicators themselves are not going to be sliced and diced with PivotTables in the same way as data elements, which may be brought into a PivotTable in order to calculate an ad-hoc indicator. If we could utilize the DimensionOptions with indicators for this purpose, it might be very useful to calculate things like "Under 5 malaria mortality rate" as a slice of the indicator "Malaria mortality rate", but for some indicators (as illustrated above) this is not going to be possible. Best regards, Jason _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
