dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olati@xxxxxxxxxx>]

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.

Ola
-------


On 16 February 2011 11:57, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> On 16 February 2011 07:37, Abyot Gizaw <abyota@xxxxxxxxx> wrote:
> >
> >
> > 2011/2/15 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> >>
> >> On 15 February 2011 14:09, Lars Helge Øverland <larshelge@xxxxxxxxx>
> >> wrote:
> >> >
> >> >
> >> > On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset <storset@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> >> >> Unsubscribe : https://launchpad.net/~dhis2-devs
> >> >> More help   : https://help.launchpad.net/ListHelp
> >> >
> >> >
> >>
> >> _______________________________________________
> >> 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
> >
> >
>
> _______________________________________________
> 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
>