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@gmail.com wrote:
On 16 February 2011 07:37, Abyot Gizaw abyota@gmail.com wrote:
2011/2/15 Bob Jolliffe bobjolliffe@gmail.com
On 15 February 2011 14:09, Lars Helge Øverland larshelge@gmail.com > > >> wrote:
On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset storset@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