Hello,
We really have to resolve the issue of unique orgunit names and
shortnames. I have 7000 orgunits, and it does not make sense to
pollute the name strings with random digits at the end or something
similar (another strategy is to use the parent name), just to make
them unique. I also don't know how to attach extra characters to just
the duplicates (i.e. not to the first one).
--
Cheers,
Knut Staring
Not sure why they should be unique. There are lots of places with the
same name (McDonalds, BP, etc) within a given administrative district.
They have other unique properties of course such as ownership,
address, telephone number, lat/long, etc, but this seems to be another
one of those strange restrictions in the data model/business logic
that keep hitting us in the face.
I would argue these restrictions should be a data integrity rule, but
should not be hard-coded into the system itself. If people want to
have duplicate orgunits names, as you do Knut, there may be valid
reasons for this. It seems like potentially bad practice within a
given orgunit level, but this could only be a myopic view of things
(see my McDonalds example above) Certainly mangling the names with
arbitrary (supposedly) random numbers is no better.
Regards,
Jason
On Wed, Aug 25, 2010 at 2:01 PM, Knut Staring <knutst@gmail.com> wrote:
Hello,
We really have to resolve the issue of unique orgunit names and
shortnames. I have 7000 orgunits, and it does not make sense to
pollute the name strings with random digits at the end or something
similar (another strategy is to use the parent name), just to make
them unique. I also don't know how to attach extra characters to just
the duplicates (i.e. not to the first one).--
Cheers,
Knut Staring_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025
OK I think we can remove the uniqueness constraint on orgunit names.
This is related to the discussion on meta-data object identifiers. If we create a “dedicated” identifier property on meta-data objects and separate it from the name we can remove uniqueness constraints on all attributes from a system perspective. In the case of orgunits it makes sense because the context can be retrieved from the hierarchy (parent). I am not sure if removing uniqueness constraints on data elements, indicators, datasets etc is sensible, wouldn’t it eg. be confusing to select from a list where multiple options has the same name?
Lars
On Wed, Aug 25, 2010 at 6:17 PM, Jason Pickering jason.p.pickering@gmail.com wrote:
Not sure why they should be unique. There are lots of places with the
same name (McDonalds, BP, etc) within a given administrative district.
They have other unique properties of course such as ownership,
address, telephone number, lat/long, etc, but this seems to be another
one of those strange restrictions in the data model/business logic
that keep hitting us in the face.
I would argue these restrictions should be a data integrity rule, but
should not be hard-coded into the system itself. If people want to
have duplicate orgunits names, as you do Knut, there may be valid
reasons for this. It seems like potentially bad practice within a
given orgunit level, but this could only be a myopic view of things
(see my McDonalds example above) Certainly mangling the names with
arbitrary (supposedly) random numbers is no better.
Regards,
Jason
On Wed, Aug 25, 2010 at 2:01 PM, Knut Staring knutst@gmail.com wrote:
Hello,
We really have to resolve the issue of unique orgunit names and
shortnames. I have 7000 orgunits, and it does not make sense to
pollute the name strings with random digits at the end or something
similar (another strategy is to use the parent name), just to make
them unique. I also don’t know how to attach extra characters to just
the duplicates (i.e. not to the first one).
–
Cheers,
Knut Staring
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
–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025
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
OK I think we can remove the uniqueness constraint on orgunit names.
Supposed to be “shortnames”.
2010/8/26 Lars Helge Øverland larshelge@gmail.com
This is related to the discussion on meta-data object identifiers. If we create a “dedicated” identifier property on meta-data objects and separate it from the name we can remove uniqueness constraints on all attributes from a system perspective. In the case of orgunits it makes sense because the context can be retrieved from the hierarchy (parent). I am not sure if removing uniqueness constraints on data elements, indicators, datasets etc is sensible, wouldn’t it eg. be confusing to select from a list where multiple options has the same name?
Lars
On Wed, Aug 25, 2010 at 6:17 PM, Jason Pickering jason.p.pickering@gmail.com wrote:
Not sure why they should be unique. There are lots of places with the
same name (McDonalds, BP, etc) within a given administrative district.
They have other unique properties of course such as ownership,
address, telephone number, lat/long, etc, but this seems to be another
one of those strange restrictions in the data model/business logic
that keep hitting us in the face.
I would argue these restrictions should be a data integrity rule, but
should not be hard-coded into the system itself. If people want to
have duplicate orgunits names, as you do Knut, there may be valid
reasons for this. It seems like potentially bad practice within a
given orgunit level, but this could only be a myopic view of things
(see my McDonalds example above) Certainly mangling the names with
arbitrary (supposedly) random numbers is no better.
Regards,
Jason
On Wed, Aug 25, 2010 at 2:01 PM, Knut Staring knutst@gmail.com wrote:
Hello,
We really have to resolve the issue of unique orgunit names and
shortnames. I have 7000 orgunits, and it does not make sense to
pollute the name strings with random digits at the end or something
similar (another strategy is to use the parent name), just to make
them unique. I also don’t know how to attach extra characters to just
the duplicates (i.e. not to the first one).
–
Cheers,
Knut Staring
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
–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025
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
OK I think we can remove the uniqueness constraint on orgunit names.
Supposed to be "shortnames".
Good. But what about the orgunit names, do they have to be unique for
technical reasons? If so, we should have an algorithm that adds on the
parent name (and grandparent, if required) in parentheses at the end,
instead of just rejecting the import file outright.
This is related to the discussion on meta-data object identifiers. If we
create a "dedicated" identifier property on meta-data objects and separate
it from the name we can remove uniqueness constraints on all attributes from
a system perspective. In the case of orgunits it makes sense because the
context can be retrieved from the hierarchy (parent). I am not sure if
removing uniqueness constraints on data elements, indicators, datasets etc
is sensible, wouldn't it eg. be confusing to select from a list where
multiple options has the same name?
I think it is fine to require uniqueness for these other entities -
diseases etc should probably have unique names.
Knut
2010/8/26 Lars Helge Øverland <larshelge@gmail.com>:
2010/8/26 Lars Helge Øverland <larshelge@gmail.com>
Lars
On Wed, Aug 25, 2010 at 6:17 PM, Jason Pickering >> <jason.p.pickering@gmail.com> wrote:
Not sure why they should be unique. There are lots of places with the
same name (McDonalds, BP, etc) within a given administrative district.
They have other unique properties of course such as ownership,
address, telephone number, lat/long, etc, but this seems to be another
one of those strange restrictions in the data model/business logic
that keep hitting us in the face.I would argue these restrictions should be a data integrity rule, but
should not be hard-coded into the system itself. If people want to
have duplicate orgunits names, as you do Knut, there may be valid
reasons for this. It seems like potentially bad practice within a
given orgunit level, but this could only be a myopic view of things
(see my McDonalds example above) Certainly mangling the names with
arbitrary (supposedly) random numbers is no better.Regards,
JasonOn Wed, Aug 25, 2010 at 2:01 PM, Knut Staring <knutst@gmail.com> wrote:
> Hello,
>
> We really have to resolve the issue of unique orgunit names and
> shortnames. I have 7000 orgunits, and it does not make sense to
> pollute the name strings with random digits at the end or something
> similar (another strategy is to use the parent name), just to make
> them unique. I also don't know how to attach extra characters to just
> the duplicates (i.e. not to the first one).
>
> --
> Cheers,
> Knut Staring
>
> _______________________________________________
> Mailing list: DHIS 2 developers in Launchpad
> Post to : dhis2-devs@lists.launchpad.net
> Unsubscribe : DHIS 2 developers in Launchpad
> More help : ListHelp - Launchpad Help
>--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
--
Cheers,
Knut Staring
OK I think we can remove the uniqueness constraint on orgunit names.
Supposed to be “shortnames”.
Good. But what about the orgunit names, do they have to be unique for
technical reasons? If so, we should have an algorithm that adds on the
parent name (and grandparent, if required) in parentheses at the end,
instead of just rejecting the import file outright.
OK we could maybe remove uniqueness constraint on names too. Any disadvantages here?
2010/8/26 Knut Staring knutst@gmail.com
2010/8/26 Lars Helge Øverland larshelge@gmail.com:
2010/8/26 Lars Helge Øverland larshelge@gmail.com
This is related to the discussion on meta-data object identifiers. If we
create a “dedicated” identifier property on meta-data objects and separate
it from the name we can remove uniqueness constraints on all attributes from
a system perspective. In the case of orgunits it makes sense because the
context can be retrieved from the hierarchy (parent). I am not sure if
removing uniqueness constraints on data elements, indicators, datasets etc
is sensible, wouldn’t it eg. be confusing to select from a list where
multiple options has the same name?
I think it is fine to require uniqueness for these other entities -
diseases etc should probably have unique names.
Knut
Lars
On Wed, Aug 25, 2010 at 6:17 PM, Jason Pickering > > >> jason.p.pickering@gmail.com wrote:
Not sure why they should be unique. There are lots of places with the
same name (McDonalds, BP, etc) within a given administrative district.
They have other unique properties of course such as ownership,
address, telephone number, lat/long, etc, but this seems to be another
one of those strange restrictions in the data model/business logic
that keep hitting us in the face.
I would argue these restrictions should be a data integrity rule, but
should not be hard-coded into the system itself. If people want to
have duplicate orgunits names, as you do Knut, there may be valid
reasons for this. It seems like potentially bad practice within a
given orgunit level, but this could only be a myopic view of things
(see my McDonalds example above) Certainly mangling the names with
arbitrary (supposedly) random numbers is no better.
Regards,
Jason
On Wed, Aug 25, 2010 at 2:01 PM, Knut Staring knutst@gmail.com wrote:
Hello,
We really have to resolve the issue of unique orgunit names and
shortnames. I have 7000 orgunits, and it does not make sense to
pollute the name strings with random digits at the end or something
similar (another strategy is to use the parent name), just to make
them unique. I also don’t know how to attach extra characters to just
the duplicates (i.e. not to the first one).
–
Cheers,
Knut Staring
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
–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025
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
–
Cheers,
Knut Staring
I have removed the uniqueness on organisation unit short names.
We can think about removing uniqueness on name too after we have implemented the identifier blueprint.
One challenge I came to think of is how we then match with “third party” data sources like gml, excel workbooks which will not have the DHIS specific identifier. Currently we match on name. Alternatives are to match on code (which is unique but not required in DHIS), or to add the DHIS identifier to the datasource.
Probably all good options, but likely we will need some flexibility to
match on different properties, and even combinations of properties.
For instance, there are two clinics in lusaka named "Pearl of Health".
Both in the same parent organisationunit, but with different physical
locations. So if you are faced with a situation like this, you might
need to match on parentid, name, and then lat/long, just as an
example.
Of course, having duplicate names is tricky within a district. It
would be easy for data entry personnel to make a mistake and enter
data for one clinic in another, especially if the data is being
entered from paper. I guess this is a separate process issue related
to a unique identifier, whatever that may be in the end. The approach
that we have taken with most surveys in the field is not a single
field, but a combination of fields that uniquely identify the
facility, such as Name, Address, and Lat/long. Perhaps a checksum of a
combination of fields might be a possibility to think about in terms
of assigning a computer-friendly ID.
Regards,
Jason
2010/8/27 Lars Helge Øverland <larshelge@gmail.com>:
I have removed the uniqueness on organisation unit short names.
We can think about removing uniqueness on name too after we have implemented
the identifier blueprint.
One challenge I came to think of is how we then match with "third party"
data sources like gml, excel workbooks which will not have the DHIS specific
identifier. Currently we match on name. Alternatives are to match on code
(which is unique but not required in DHIS), or to add the DHIS identifier to
the datasource.
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+17069260025