- From: <paola.dimaio@gmail.com>
- Date: Sat, 9 Aug 2008 22:12:51 -0400
- To: "C H" <craighubleyca@yahoo.com>
- Cc: "Paul Currion" <paul@currion.net>, public-xg-eiif <public-xg-eiif@w3.org>
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