dhis2-devs team mailing list archive

[Murod Latifov <mlatifov@xxxxxxxxx>]

Hi Bob,

Regarding multidimentionality of Data Elements I have a suggestion. This
double identifier for DE should be removed at all. For me each instance of
DE/Categoryoption combination is a real Data Element. So I suggest to
generate another set of unique ids based on DE/Categoryoption combination.
So lets call current DEs categories and categoryoptions as options. Each
relation of them would be DE with its unique id. In datavalue table we than
will have three keys: DE, Period, OrgUnit (categoryoptioncomboid would be
missing). This will eliminate lots of issues, like one presented here. This
could be neatly brought into play with full backward compatibility i guess.

Another suggestion is that we have almost the same type of objects in
metadata representation. These also could be unified into one the same way
as java containers. These objects are groups and sets of groups in DE,
Indicator, OrgUnits, etc. If we create a container whos sole purpose is to
group elements of some type of object, we could achieve this. I know this is
out of scope of this discussion, but as we are talking on generalization, I
thought would be good to mention here.

Cheers,
murod

2011/9/19 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> 2011/9/19 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> > Hi Bob,
> >
> > thanks for the well-written document, I think it is very sensible and
> > clearly describes the direction where we want to move. Agree fully on
> > the points on separation of meta- and data, idscheme, and period
> > representation.
> >
> > My only comment is about the representation of dimensions by
> > "exploding" our category model onto optional attributes. This is good
> > when dealing with third-party systems but do represent an overhead
> > when communicating between dhis systems (including mobile).
>
> Good question.  My sense is that the categoryoption combo is an
> internal representation of dimensionality within dhis which should not
> *necessarily* be exposed to 3rd parties.  I think this also can and
> does include mobile use cases.  In fact Jo has been been on my case to
> implement the dimensions particularly with a mobile use case in mind.
>
> Having said that, there is also nothing which prevents an
> application-specific datavalueset from using a catoptcombo attribute,
> and we can certainly support that internally.  The web-api currently
> does this for example.
>
> I'm currently thinking about how best to export the structural
> metadata (codelists and the like) required to compose datavalue
> messages.  I need to have a bit of discussion about how the data
> dictionary is envisaged, but it seems that one should be able to
> browse the datadictionary and export relevant codelists from that.
> And/or pull them from web-api.  It could well be that it makes sense
> to export a dimensionset codelist along the lines of (shooting from
> the hip):
>
> <dxf:dimensionsets>
>   <dxf:dimensionset id="345" SEX="M" AGE="under5" />
>   <dxf:dimensionset id="346" SEX="F" AGE="under5" />
>   <dxf:dimensionset id="347" SEX="M" AGE="5andOver" />
>   <dxf:dimensionset id="348" SEX="F" AGE="5andOver" />
> </dxf:dimensionset>
>
> Which might allow an abbreviated form of datavalue along the lines of:
>
> <dxf:dataValue datelement="45" orgunit="42" "period="201001/P2M"
> dimensionset="345" value="56" />
>
> (Note the funny period - that's Jan/Feb 2010).  I think this explicit
> approach would be more grokkable by external systems (including our
> own tightly coupled ones) than transmitting the entire lattice of
> categoryoptioncombo links,, and would be quite familiar with xslt
> programmers familair with the attributeset construct in xslt .
>
> Of course the downside being that is yet another codelist to transmit
> and perhaps something else to model on the other side.  That seems to
> be the eternal compromise.  What you gain on the swings you lose on
> the roundabouts :-)
>
> >I thought
> > SDMX-HD was our format for communicating with third-party sources - if
> > dxf becomes "third-party friendly" then where does that leave SDMX?
>
> That could well turn out to be an interesting question given the
> rumblings within WHO :-)
>
> But having a close mapping from (the useful parts of) sdmx to dxf is
> very convenient, and in the process makes our dxf representation of
> datavalues more sensible I think.
>
> Bob
>
> >
> > Lars
> >
>
> _______________________________________________
> 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
>