On 16 February 2011 11:41, Ola Hodne Titlestad <ol...@ifi.uio.no> wrote: > Hi, > One thing to have in mind here is that a data element can be captured in > multiple datasets (but still refer to the same value). > This has been a popular mechanism to help implementers work around the many > duplicating forms and still keep the database as clean and consistent as > possible. > In this scenario it would be difficult to know which form/dataset actually > collected the value I guess. > I know there have been some requests to add more properties to the values, > e.g. how they were captured, who is the owner etc. but it should be possible > to accommodate this and still keep the original primary keys / references > for data values (orgunit, period, data element, catoptioncombo). > If your grouping of values only concerns how data values are collected and > transferred and not how they are persisted, then it seems fine to me. This > is the role of the dataset in today's model.
No its not and that is the shortcoming. The dataset is a grouping of dataelements not datavalues. Hence there is no explicit relationship between datavalue and dataset. You can implicitly figure it out by "calculating" the dataset as a f(dataelement, orgunit) where periodType you calculate as f(periodid). But bearing in mind what you start off with above, even this might be considered a best effort. All of this is much more entangled than it needs to be but it has evolved that way and, as Lars says, it won't be changed in a hurry. Anyway, more later .. Bob > Ola > ------- > > On 16 February 2011 11:57, Bob Jolliffe <bobjolli...@gmail.com> wrote: >> >> On 16 February 2011 07:37, Abyot Gizaw <aby...@gmail.com> wrote: >> > >> > >> > 2011/2/15 Bob Jolliffe <bobjolli...@gmail.com> >> >> >> >> On 15 February 2011 14:09, Lars Helge Øverland <larshe...@gmail.com> >> >> wrote: >> >> > >> >> > >> >> > On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset <stor...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Den 15. feb. 2011 kl. 18.40 skrev Bob Jolliffe: >> >> >> >> >> >> > Simple validation seems to work ok. I get an "Aw, Snap! ..." when >> >> >> > posting twice with the same period but that is probably something >> >> >> > you >> >> >> > are not catching yet. >> >> >> >> >> >> Should work now. >> >> >> >> >> >> > I don't agree with this. >> >> >> >> >> >> I know :) I don't necessarily agree myself, but it is also a matter >> >> >> of >> >> >> what is practically possible.. (And it might make sense to have a >> >> >> simpler >> >> >> json-oriented web api vs. a more fullfledged xml format for heavy >> >> >> imp/exp. >> >> >> Are you coming to Oslo in March by any chance, then we can fight it >> >> >> out! ) >> >> >> >> >> > >> >> > Can you please explain why it is not practically possible to have dxf >> >> > as >> >> > the >> >> > root element? >> >> > I don't have anything against grouping datavalues in sets to make the >> >> > format >> >> > more compact. But, first, we currently don't have any real >> >> > requirements >> >> > or >> >> > use-case where we want to persist the "datavalueset". Second we >> >> > currently >> >> > have no support for it in the model. So whats the point of modeling >> >> > our >> >> > exchange format this way? >> >> >> >> Well partly because this structure models the way data is produced. >> >> In sets. Off a form or off an import. SDMX data for example also >> >> arrives in sets. While there is no support in the model it simply >> >> means that we can lose information regarding the set. It becomes >> >> important where you might want to rollback a set or identify where >> >> some particular has come from. Currently this is sort of implicitly >> >> keyed but there are benefits in making it explicit. For example you >> >> can't currently trace a datavalue back to whether it was entered >> >> through a dhis form, whether it arrived from one of Jo's 5000 phone's >> >> or whether it was imported from iHRIS (or whatever). You can populate >> >> the comment of all the datavalues but that's really expensive. >> >> >> >> There are also savings to be had on storage by inheriting atttributes >> >> like period and orrgunit from a dataset rather replicating in each >> >> datavalue. >> >> >> >> It's not a model change I would propose immediately (I think we have >> >> enough zooks to sort out) but surely it is hard to argue that its not >> >> the (proverbial) right thing to do. Meanwhile the way Jo has it in >> >> his xml looks fine to me. >> > >> > >> > Hmmm... I think if we are to with this datavalueset concept and take >> > away >> > orgunit&period from datavalue and leave it with the groupset - we will >> > be >> > hitting a big trouble! >> > >> > The flexibility we have right now - the way we define Indicators, design >> > reports,... - is down to the independence of the datavalue. Each and >> > every >> > piece of datavalue can stand by itself and make sense - allowing >> > monitoring >> > and evaluation people greater flexibility and harmonization. >> > >> > Again, with the datavalueset approach mentioned here, we will be against >> > the >> > minimum-dataset concept. For me the minimum dataset concept worked >> > because >> > users/healthprograms can share dataelement/datavalue. >> >> I doubt the trouble would be as big as you think. But you might be >> right and could be I'm missing something. But regarding just posting >> of data it makes no difference at all other than making the message >> more efficient. >> >> What is minimum-dataset concept? >> >> Bob >> >> BTW its not really to do with groupset. But I guess that was a typo. >> >> > >> > Abyot. >> > >> >> >> >> Cheers >> >> Bob >> >> >> >> > Yes we might need it sometime in the future but >> >> > then we should implement it when we need it. >> >> > I also find it weird that we really need to implement two parsers for >> >> > this. >> >> > More work and more code to maintain. >> >> > The uuids will go for a new Identifier property for version 2.2 and >> >> > make >> >> > things less verbose btw. >> >> > Lars >> >> > >> >> >> >> >> >> > Your use of DataValueSet here is very welcome - as you know I have >> >> >> > been advocating this for a while. Would be nice also to persist >> >> >> > it >> >> >> > to >> >> >> > provide audit (and simplify dtavalue store) but that is maybe too >> >> >> > much >> >> >> > for now. >> >> >> >> >> >> Yes, that would have to be the next topic. Let's see if anyone else >> >> >> take >> >> >> the bait :) >> >> >> >> >> >> Jo >> >> >> _______________________________________________ >> >> >> 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 >> > >> > >> >> _______________________________________________ >> 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
