Uniqueness of Orgunit names - once again

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,
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

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