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

Craig
thanks a lot for understanding and expanding the ideas

I think this group's work can be useful opportunity also to try and
iron out some old  creases in the system, such as making sure we know
where is the center of our universe, an old quest for humanity.

The ideas in the mail were thrown together on the fly, so thanks for
checking their consistency Just a few more comments on your points

 > Accordingly I'd suggest following the organize-around-the-victim
principle even more >strictly than Paola says or suggests in her
proposal.

Thanks for that. The ides is that
 1) the metamodel  is so generalised, that  anyone interested in the
efficiency of the supply/value chain can work strictly around the
victim, but if an organisation main mission has limited focus on
itself, it can use only the relevant portions of the schema that
reflect their own internal organisation and motives, without limiting
the universal schema and preventing others to follow a different
operational model

This means that an organisation could rearrange their view as
WHO2/WHAT3/WHERE3
 if that is the way the like to look at the world
while another could be
WHO1/WHAT1/WHERE4
that would supporte a more accurate/flexibe model of reality that does
not depend on the single institutional view of an organisation

2) that the metamodel can be extended ad hoc, assuming there is
something missing, an organisation could add elements, and suggest
expansion




>> a model that does not include the person affect by the
>> event is lacking something critical, imho
>
> That's being polite.

I would like to be 'full of grace' too, but thats a longer shot.

>
>> 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.
>
>
> 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.
>
>
I think we may have to compile a list of deisred functionality/systems goals.
 I cannot understand what is the functinality of an internal schema
like OCHA, other than represent its own internal workings for interna
purposes (I cannot see any function being carried out in that schema
but maybe I should study it more)

0) provide an accurate information map of the incident (WHAT, WHERE,
WHO) that can be viewed by all agents
1) matching  demand with supply
2) support communication (internal, external
3) support resouce allocation and planning
4)?

>>
>> 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"?

Sure sure, I forgot - LOCATION OF PERSON AFFECTED BY EVENT/BENEFICIARY
presumably overlap the LOCATION OF EVENT, with more granularity -
gotta think about how to specify that - Beneficiary could be a
dependend entity of EVENT

NOTE: PERSON AFFECTED BY EVENT changes state to BENEFICIARY upon
receipt of RESOURCEo
>
>> 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 was thinking: RELIEF ENTITY (type: organization, local , neighbor, friend, )

so all the relief providers would be listed as different types of relief entity



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

ok - value chain is a bit of an eufemism, but thats a choice
supply chain indends to be  borrowed in this case from logistics, not marketing
>
>>
Thanks for understanding and explaining further the outline of the approach
I am sure we can work on refinement-validation using case studies, and
have the respective members of this list see if something like this
would accommodate for OCHA and Sahana own internal schemas too.

-- 
Paola Di Maio
School of IT
www.mfu.ac.th
*********************************************

Received on Sunday, 10 August 2008 02:13:26 UTC