dhis2-devs team mailing list archive

[Murod Latifov <mlatifov@xxxxxxxxx>]

Hi Ime,

Yes, there is better way of doing this. Matching by name instead of id is
unacceptable. We should give unique id across implementation despite naming
conventions. Single data element can have more than one alias. We cannot
live with just two names, there could be more. Moreover alternative name is
not solution for i18n too. I call again for metadata refinement, which
sovles most of issues brought to audience with "alternative name" removal.
Also, though slitely out of this discussions, I see patterns of use, which
are used in most of metadata objects are being repeated, we should avoid
them.

 regards,
murod

On Thu, Apr 28, 2011 at 1:22 PM, Ime Asangansi <asangansi@xxxxxxxxx> wrote:

> Interesting...
> My experience is that the same data element can be called different things
> by different installations e.g. in different states or projects - for
> example, "Malaria cases in children under five" and "Malaria - under five",
> etc. Sometimes the range of synonyms becomes so large between databases that
> importing for cross-database analysis becomes so difficult and a tiring
> process.
> At other times there are just two synonyms. In this case having an
> "alternative name" or "old name" seems to be useful.
>
> This "match-making" process during import is one requirement for an
> "alternative name" or "old name" or whatever it wants to be called...but
> perhaps there is a better way of solving this?
>
> Ime
>
> --- On Thu, 4/28/11, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>
> > From: Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> > Subject: Re: [Dhis2-devs] Alternative names
> > To: "Hieu Dang Duy" <hieu.hispvietnam@xxxxxxxxx>
> > Cc: "Ola Hodne Titlestad" <olati@xxxxxxxxxx>, "DHIS 2 developers" <
> dhis2-devs@xxxxxxxxxxxxxxxxxxx>
> > Date: Thursday, April 28, 2011, 12:18 PM
> > On 28 April 2011 10:09, Hieu Dang Duy
> > <hieu.hispvietnam@xxxxxxxxx>
> > wrote:
> > > Hi,
> > >
> > > We have to be careful in misunderstanding of the
> > meaning of alternative
> > > name. The I18n translation functionality which is only
> > the support one for
> > > Multilingual. But in this case alternative name which
> > could understand that
> > > a another name of a specified object. One data
> > element, ie. it could be
> > > having many other alternative name. I'm not familiar
> > with the health words.
> > >
> > > But for example in Chemical field, if you say CH3-OH
> > so everyone would know
> > > that is Methanol or Metilic alcohol.
> > >
> > > Just a small comment.
> >
> > Fair point.  AlternativeName does invite the user to
> > use it like this
> > in the absence of any other guideline.
> >
> > In general many things do have many names (I am Bob, my
> > passport says
> > Robert and the University of Oslo has me as Bo).  What
> > is important on
> > the output side is to know the context in which a
> > particular name is
> > appropriate.  In the I18n case, the context is
> > determined by locale
> > which seems to me to be the right way of determining which
> > alternative
> > name to use (assuming, as Ola says, that it works).
> >
> > I am not sure if there is really a requirement for
> > supporting other
> > sorts of naming contexts - I haven't seen one, but there
> > might be.
> > For example different programs might have different names
> > for the same
> > indicator.  Facilities are perhaps an interesting case
> > because they do
> > occasionally get renamed so you might have current name and
> > old name.
> > Which is not a very serious problem when we don't use the
> > name as the
> > primary identifier.
> >
> > It would be easy enough to have a table for alternative
> > names of any
> > and all identifiable objects.  In fact it might even
> > be a good idea.
> > What would be more complicated is to decide the context in
> > which to
> > use which name.  The simplest approach would be to not
> > try and be too
> > artificailly intelligent about it and provide the report
> > designer with
> > the set of alternative names to pick from if he/she so
> > chose.
> >
> > But without a clear requirement there's no need to make our
> > lives
> > complicated.  So to go back to my original question,
> > do we have an
> > existing use case (outside of I18n) where people are using
> > alternativename differently?  eg synonymns for
> > methanol.  My guess is
> > that this is more a requirement in clinical systems than in
> > aggregate
> > reporting of datelements and indicators.  Except
> > perhaps facilities
> > ...
> >
> > Cheers
> > Bob
> >
> > >
> > > On Thu, Apr 28, 2011 at 1:37 PM, Ola Hodne Titlestad
> > <olati@xxxxxxxxxx>
> > > wrote:
> > >>
> > >> Not 100% sure, but I think Alternative Name is
> > used to store the English
> > >> translations of the Swahili data elements in the
> > Tanzanian databases, as an
> > >> ad-hoc i18n approach. This can of course be
> > replaced by a using the i18n
> > >> functionality (given that it works properly, and
> > that it is also possible to
> > >> show lists/reports etc. showing both languages).
> > >>
> > >> Ola
> > >> --------
> > >> ----------------------------------
> > >> Ola Hodne Titlestad (Mr)
> > >> HISP
> > >> Department of Informatics
> > >> University of Oslo
> > >>
> > >> Mobile: +47 48069736
> > >> Home address: Vetlandsvn. 95B, 0685 Oslo, Norway.
> > Googlemaps link
> > >>
> > >>
> > >> On 27 April 2011 17:04, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> > wrote:
> > >>>
> > >>> On 27 April 2011 15:24, Jason Pickering <jason.p.pickering@xxxxxxxxx
> >
> > >>> wrote:
> > >>> > +1 from me as well, assuming that we can
> > migrate the existing
> > >>> > alternative names to whatever object
> > replaces it.
> > >>>
> > >>> To what extent to we have existing alternative
> > names?
> > >>>
> > >>> >Also, if you can
> > >>> > look into how  we can match on these
> > names during import, similar to
> > >>> > DHIS 1.4, this would be very useful in
> > hetereogeneous, data
> > >>> > warehousing situations where multiple
> > data bases feed DHIS2, but which
> > >>> > may have slightly different names of the
> > same data element.
> > >>> >
> > >>> >
> > >>> >
> > >>> > On 4/27/11, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> > wrote:
> > >>> >> 2011/4/27 Saptarshi Purkayastha
> > <sunbiz@xxxxxxxxx>:
> > >>> >>> I would actually suggest that
> > multiple alternative names to be added
> > >>> >>> for a
> > >>> >>> dataelement or indicator.
> > >>> >>> It would be similar to the
> > representing synonyms for a data element
> > >>> >>> or
> > >>> >>> indicator.
> > >>> >>
> > >>> >> Saptarshi I think I agree with you in
> > principle.  And probably the
> > >>> >> best way to work towards this is to
> > start by removing the hard coded
> > >>> >> alternative name property. So +1 from
> > me to the proposal.
> > >>> >>
> > >>> >>>
> > >>> >>> ---
> > >>> >>> Regards,
> > >>> >>> Saptarshi PURKAYASTHA
> > >>> >>>
> > >>> >>> My Tech Blog:  http://sunnytalkstech.blogspot.com
> > >>> >>> You Live by CHOICE, Not by
> > CHANCE
> > >>> >>>
> > >>> >>>
> > >>> >>> 2011/4/27 Lars Helge Øverland
> > <larshelge@xxxxxxxxx>
> > >>> >>>>
> > >>> >>>> Hi all, we are currently
> > investigating the core domain model in
> > >>> >>>> order to
> > >>> >>>> see how we can make the
> > entities have a consistent set of
> > >>> >>>> properties.
> > >>> >>>> In that regard we are
> > proposing to remove the alternative name
> > >>> >>>> property
> > >>> >>>> of
> > >>> >>>> data element and indicator
> > entities. It seems this property is a
> > >>> >>>> ad-hoc
> > >>> >>>>
> > legacy internationalization effort and not really useful.
> > Would it
> > >>> >>>> be
> > >>> >>>> okay
> > >>> >>>> to remove it?
> > >>> >>>>
> > >>> >>>>
> > >>> >>>> regards, 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
> > >>> >>>>
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > _______________________________________________
> > >>> >>> 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
> > >>> >>
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Jason P. Pickering
> > >>> > email: jason.p.pickering@xxxxxxxxx
> > >>> > tel:+260974901293
> > >>> >
> > >>>
> > >>>
> > _______________________________________________
> > >>> 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
> > >>
> > >
> > >
> > >
> > > --
> > > Good health !
> > >
> > >
> >
> > _______________________________________________
> > 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
>