organize around the victim [was] Re: Requirement for 3W interop standard (new proposed schema attached)

Agreed with Paola on all points, but I caution that compromising the right answer with the wrong answer usually yields an even worse monstrous hybrid non-answer with both sets of problems.  Accordingly I'd suggest following the organize-around-the-victim principle even more strictly than Paola says or suggests in her proposal.

--- On Sat, 8/9/08, paola.dimaio@gmail.com <paola.dimaio@gmail.com> wrote:
> , WHO should be the person affected by the event, as that
> is the center of the universe when some emergency occurr, not the
> ORGANISATIONs who  delivers the service

Clearly, absolutely, indisputably, obviously, unquestionably correct.

The database has effectively no single key if the victim/client isn't the core organizing principle of any hierarchy.

Business has learned this lesson over and over and over again - any and all approaches which organize any data whatsoever in forms convenient to the institutional/internal structure fail miserably and totally to meet the demands of the customer.  Usually the entire organization has to be dismantled and large numbers of people fired and moved into different jobs to undo the damage this kind of bad organization of data reliably creates.

Read the book "Parkinson's Law" in full if you doubt a single word of that.

> Please explain to me where is it stated that the person
> affected by
> the event, should not be even mentioned in the 3w (thats
> the main flaw in my view)

Not only is it a "main flaw", it makes the "work" worthless.  A serious database developer would have to discard such a schema as a basis for extensions, if only because it doesn't really allow for cross-institution cooperation without modifying basic data organization.  Not acceptable.

> a model that does not include the person affect by the
> event is lacking something critical, imho

That's being polite.
 
> however, that aside, 
> the whole 3w thing can be read in different ways.
> 
> The view you take below is organizationa centric, that is,
> the center
> of the model is the organizational structure - thats what
> is causing a
> lot of inefficiencies in the service information flow,
> cause the whole
> process seems determined by the role of the organisation

Not only does it cause "inefficiencies", it causes failures of need and mission definition, of boundary conditions, of after the fact followup and accountability.  A "service information flow" is always organized in terms of the value chain delivered to the client/customer/victim/recipient who's the whole rationale for the service.  Any exceptions to that invariably make niches or eddies which become safe nesting spots for institutional parasites who do what's convenient for the organization not the recipient.

That said, an organization does need to direct specific people to be in specific places at specific times with specific materials and trained or briefed to expect specific conditions.  Since there is no chance at all that machines could calculate all of this for rapidly changing conditions based on uncertain data, the best we can hope for is accurate capture of instructions and reports from those who are already in the field.  When someone in this situation makes a request, actually recording it in the database accurately is critical.  Who ends up bringing the blood plasma or radio battery recharger is not only less critical, making assumptions that effectively prevent anyone else nearby from discovering the need or filling it can be disastrous.  The ideal is to just record the needs accurately and rapidly, and let whoever is able to fulfil them, fulfil them.  That fulfilment organization may require its own internal logic and logistics and records, but,
 best to let several approaches compete on this.

So the database of needs and the internal data specific to the assistance organization intersect only as a set of requests and offers, like a market.

So Paola's approach seems much more valid:

>  lets try this instead (just as exercise)
> 
> WHAT = 1) EVENT (type,  (WHERE),  other variables )
>               2) RESOURCEoffered (required to
> alleviate.mitigate the effect of the event)
>               3) RESOURCEneeded

But has to be applied consistently:

> WHERE= Location of EVENT
>                 Location of RELIEF ENTITY
>                 Location of RESOURCEo/RESOURCEn

Shouldn't this be, then, "Location of VICTIM/CLIENT/RECIPIENT"?  The "RELIEF ENTITY" is in many places, wherever its agents and supporters and paid local helpers are.  For instance, in a jeep rolling along a dirt road four kilometers from the place and moving away.  Since many cell phones now have GPS built in, it would be wise to assume dynamic GPS data on any vehicle, even any person who might represent a relief effort bottleneck.  Given that the aid resources are now more mobile by far than the victims, why record the more dynamic data while letting the static data be diffused into many places?  Just seems wrong.  Applications can calculate in real time which aid worker might be best equipped to get to a given victim for instance, without ever recording all their locations in some big database, just by querying the nearest ones in a spiral pattern around the victim.
 
> WHO 1 =  Person affected by EVENT (WHERE, other variables)
> WHO 2 =  RELIEF ENTITY (type (PERSON OR ORGANISATION),
> stucture, WHERE
> location, RESOURCEO,RESOURCEN, contact, other info)

"WHO 2" just seems worthless as a core data field.  Unless there's also who3, who4, who5, etc. for the neighbours, the legal civil authority, the church group whose missionaries are pitching in, the local army, each of the NGOs, etc.  Thinking of all these as competing to help may not be bad either.

> I am sure the above could be improved further

Mostly by making it more internally consistent with the principle of always organizing data around the victim/recipient/client.
 
> In principle, you could map any use of the 3w schema as
> made by ocha
> for example, onto this generic schema, which is designed to
> represent
> the whole EM supply chain and not just part of it, - this

It helps to think of it ias a value chain not just a supply chain.  The supply-sided EM approach misses a lot of victims.  ;-)  Though it does distribute a lot of donations.

> means that
> OCHA does not have to change its internal structure to work
> with such
> a schema, which is designed to serve multiple purposes
> without
> carrying the bias and limitations of any particular structure

Absolutely correct.  Assuming anything about organization structure or "location" necessarily imposes administrative burden on anyone who wants to cooperate with the overall data exchange system.

If the interop standard does not even *allow* for totally decentralized citizen-run approaches to evolve, rather like old pre-Internet networking protocols did not allow for totally distributed managemente, it'll just fail.

It would be nice if the first effort didn't fail, though it usually does, due to totally wrong assumptions by organizations and institutions that it'll be other entities like themselves that will be using the system the most.

Craig Hubley

Received on Saturday, 9 August 2008 20:59:44 UTC