Hi Matt
Thanks for these clarifying remarks.
We have gone round many circles in this discussion and I would suggest that people do read your remarks carefully.
There are some salient points:
-
we have foreseen the situation that there can be any number of identifiers associated with a health facility. So we have a provision for multiple identifiers. These can include Ministry (or other agency) assigned codes, machine generated random numbers, identifiers peculiar to particular software systems etc. This is not an concocted or fanciful requirement. It reflects what we find in practice.
-
we have constructed urls such as “/facilities/{id}.json” which imply that we have to nominate an identifier.
-
we have created an element precisely for this purpose. And mandated no other requirements of the id other than it be fit for this purpose.
The subsequent discussion has largely ignored what is in the spec and has instead fetishised this field in isolation into something that it was not ever intended to be.
We have conceded (albeit a bit reluctantly) that facilities should have a RFC4122 uuid.
That could be in the identifiers block as I had indicated previously. (I know Ed has never liked the identifiers block 
). If we are indeed to concede that the uuid is mandatory, then it could even be in a toplevel element. Though, as again I have alluded to in previous mail, it can be very important to know who has minted this uuid (with which authority). Software representations of health facilities differ from physical disk drives in this respect.
Chris has mentioned in previous mail that “the UUIDs are managed by and for the benefit of the systems that hold the facilities, and the government can administer its own set of identifiers”. This illusion of separating the system from the system owner is again a sort of fetishism (in the Marxist sense of fetishism of commodities rather than a psycho-sexual diversion). Nethope, Thoughtworks, the Univ of Oslo and the Democratic People’s Republic of Korea might all run systems maintaining health facility uuids on health facilities in that country. And unless they have collaborated from the start, all those uuids will (probably, though I understand the probability is high) be different. Resolving identity is almost always a bit more complex than solving a mathematical puzzle.
Anyway, my point is not to dwell on the mystical properties of uuids. But to simply point out that the the field has a purpose quite distinct from that of the . And whereas we can be quite prescriptive about the way uuids are generated, there is not really much justification for doing the same for .
Matt, all of your proposals below have some merit, though they are more complex than just having . To extend further, I think something like:
/facilities/{agency}/{context}/{identifier}.json
could be particularly useful but perhaps more complicated than we need right now. v2?
Bob
···
On 10 February 2013 11:20, Matt Berg notifications@github.com wrote:
Sorry for the delay in responding to this issue.
As I mentioned earlier, if we use a UID as the ID then we will probably
need to modify the way our current API is specified if we don’t want the
full uid to show up in the rest end points.
Currently, we have:
/facilities/{id}.json
What we could propose is:
/facilities/{identifier}.json
Where the identifier has to match up with one of the id’s in the
identifiers block.
“identifiers”: [ { “agency”: “MOH”, “context”: “DHIS”, “id”: “123” }, {
“agency”: “UNICEF”, “context”: “mtrac”, “id”: “53adf” } ],
So in this case either 123 or *53adf *would work. Alternatively, we
could specify one of the identifier types to be the one used in the url.
If we allow support for both, we have to state that there can’t be any
id collisions between the different ID schemes (might be tricky).
Another option would be to do something like:
/facilities/{context}/{identifier}.json
We still would need to decide how the URL would be represented.
What’s nice about this is we could in theory also support the following
where id = uuid if we thought this format would be easier for
those programmatically It might make sense to limit the number of end
points.
/facilities/{id}.json
Thoughts? Does this address everyone’s concerns?
Thanks,
Matt
—
Reply to this email directly or view it on GitHub…