hierarchy support

[mberg]

DHIS2 has implemented hierarchy's within FRED this way.

Do we want to follow this format?

This would require specification of the level and parent along with the hierarchy block.

Within the block we'd probably want to agree upon use of id, level, name. Should URL be supported or implementation specific?

level: 4,
parent: "hRZOIgQ0O1m",
hierarchy: [
{
    id: "H1KlN4QIauv",
    level: 1,
    name: "National",
    url: "http://apps.dhis2.org/dev/api/organisationUnitLevels/H1KlN4QIauv"
},
{
    id: "wjP19dkFeIk",
    level: 2,
    name: "District",
    url: "http://apps.dhis2.org/dev/api/organisationUnitLevels/wjP19dkFeIk"
},
{
    id: "tTUf91fCytl",
    level: 3,
    name: "Chiefdom",
    url: "http://apps.dhis2.org/dev/api/organisationUnitLevels/tTUf91fCytl"
},
{
    id: "m9lBJogzE95",
    level: 4,
    name: "PHU",
    url: "http://apps.dhis2.org/dev/api/organisationUnitLevels/m9lBJogzE95"
}
]

[mortenoh]

One thing that should be mentioned here, is that this information is today repeated for EVERY facility, which sucks. But the spec only has the properties block as a place to put this kind of data.

Would be helpful to have a similar block that will apply to the entire collection of facilities.

[edjez]

Resolved to postpone from 1.1/current release

[ctford]

@mortenoh, another way to do this would be to define a separate hierarchy resource. I feel like that would be semantically clearer rather than having to have individual facilities reference a common properties block.

[bobjolliffe]

On hierarchy there are two reasonable approaches:

One is to support a link type property which I need to search back through github, but was one of my earliest proposals in FRED. The reason for proposing such a property (which takes a url as a value) was mostly to support references to arbitrary external resources related to the facility, for example a resource in another registry (provider, services or what have you). That same property type could be used, abused or misused (depending how you see it) to represent arbitrary relations between facilities (or facilities and other things such as administrative zones) if an implementation so chose to do. Personally I would leave it at that. I don't believe the way we (dhis2) have it currently with the tree of identified nodes is the proper long term solution, though it is legitimate within the terms of the spec and a stopgap solution. Having a link property type allows implementations to be as creative as the web allows them to be, which is ok by me. (Advance warning: following recent and ongoing experience in Rwanda, I am girding my loins for a renewed assault on the mandatory uuid which continues to be an irritating and frankly fairly useless property. But more on that later.)

The other valid approach to hierarchy is to understand it as an aspect of metadata about the facilities within the registry rather than any sort of property of the facility itself. This is the essence of what Chris has proposed. I think it gets us (sort of) into the general territory of how we describe/represent facility registry metadata which we are some distance from resolving and maybe means pushing this can further down the road.

I propose we just support a link type. Implementations can provide links to supervisory facilities, administrative districts or whatever they want really if that is important. Applications can choose to assemble these into trees, graphs or what have you if it is useful to do so for display or other purposes.

[ctford]

If we provide a link type, does it make sense to have a few pre-defined link relations? Maybe that's a bit much to specify up-front, but I could imagine rel="administrative_zone" or similar as a standard way of using the links.

One question @bobjolliffe - if we went the link direction, how would you imagine DHIS2's API working? At the moment, the API renders e.g. Kampala district as a "facility". Would you see these dummy facilities still existing, or would they be replaced by separate resources?

[litlfred]

Hi Chris,

I think Bob is on vacation at the moment. I have asked a related question on the DHIS2 users group: https://lists.launchpad.net/dhis2-users/msg02779.html and there was discussion of this issue with reference to the FRED API there.

Cheers, -carl

On Aug 21, 2013, at 8:15 AM, Chris Ford notifications@github.com wrote:

If we provide a link type, does it make sense to have a few pre-defined link relations? Maybe that's a bit much to specify up-front, but I could imagine rel="administrative_zone" or similar as a standard way of using the links.

One question @bobjolliffe - if we went the link direction, how would you imagine DHIS2's API working? At the moment, the API renders e.g. Kampala district as a "facility". Would you see these dummy facilities still existing, or would they be replaced by separate resources?

— Reply to this email directly or view it on GitHub.