- From: <paola.dimaio@gmail.com>
- Date: Tue, 12 Aug 2008 19:26:06 +0700
- To: "Paul Currion" <paul@currion.net>
- Cc: public-xg-eiif <public-xg-eiif@w3.org>
Paul > > People who want to design from the top down based on how they believe the > humanitarian community should be operating. Ah! or: people who want to design by imposing their limited views of how the humanitatarian community operates and how they think it should operate by looking only at one flaky example of their choice, which is not even representative of how the humanitarian community works > People who want to design from the bottom up based on how the humanitarian > community actually operates. Designing from the bottom up means: take into account all stakeholders, and not just the institutional ones, your are mixing things up deliberatelly? > Can you explain exactly what gives you this impression? As far as I can > tell, nobody has stated or implied that humanitarian responses are static. I have not yet see a schema of a process, nor even a discussion about it on this list. Response is represented as something that people cannot interact with, and frozen into a 'service directory' type. > A proposed schema should be complete, or it would result in incorrect > representation of the response cycle > A big -1 to trying to model the entire humanitarian response cycle, > especially when the domain representation on this group is so limited. Paul, by 'complete' I mean complete in the Tarskian sense, whereby correctness and adherence to reality depend on completeness and acuracy etc etc (I think we just come from different backgrounds and use different 'language') http://philosophy.berkeley.edu/events/detail/444 > What's wrong with taking manageable slices of the response, building models > based on actual experience and ensuring maximal flexibility and > interoperability? Sure, but that is not what is being done by taking a limited partial approach and saying 'thats how the humanitarian sector works' Bull. What is a managemenable slice of the response for the purpose of our exercise is yet to be decided. I dont remember ever having a discusssion >In complex environments, a single integrated model is going to be far more >brittle than a modular one, and people are going to be less likely to adopt it. Paul, it a model that fails to represent the intended reality 'in a complete sense' is not truthful then it is flawed, biased, wrong. Modularity is fine with me, provided the architecture of the module is sound, > > cheers > > Pdm > > > > paola.dimaio@gmail.com wrote: > Ok Chamindra I can understand that very practically oriented developers > find it hard to work with abstractions, its a part of the problem I can see > two possible ways forward 1. we develop two versions of the schema, and we > make sure that they are compatible, then you go ahead and work with your > preferred subset and leave others to implement differently 2. I work with > you to help you implement your preferred view of the schema from a more > complete and more abstract superset Would any of the above solutions work > for you? Do you see other possible ways that we can reconcile our different > views of how should the 3W schema be modelled? cheers PDM On Tue, Aug > 12, 2008 at 3:04 AM, Chamindra de Silva <chamindra@opensource.lk> wrote: > I understand that Paola and I am not trying to constrain the goals of > the group, but help ground every decision in reality by having many > incremental cycle of the model validate itself with the actual systems it is > going to be applied in (currently only OCHA 3W and Sahana). If we come up > with a very abstract model and vocabulary that makes it hard to implement in > Sahana or OCHA 3W I think we have defeated the purpose of helping to improve > the ground realities of efficient information exchange in the times of > a disaster. There can be many iterations and multiple versions of this > model, but at least lets have a quick win by making sure the first iteration > is of value in enabling two systems to work together. This does not mean you > stop thinking in a generic way when coming up with the model. On Tue, Aug > 12, 2008 at 12:21 PM, <paola.dimaio@gmail.com> wrote: > Chamindra the point that is that while it is fully legitimate for you as > Sahana developer to create a system in whatever way you chose to model, > it would be unfair that your personal choices as a developer constrain the > (potential) global scope of this workgroup, which in its small way is rather > ambitious:make a contribution to how EM information web based exchanged can > be made more meaningful, representative, and efficient. We can only achieve > that if we are innovative, critical and proactive in our modelling > approach. If we as a workgroup produce an integrated model, you will be > able to use it and apply according to your preference, including just > adopting a subset (part 1), without narrowing its overall > capability. PDM On Tue, Aug 12, 2008 at 12:46 AM, Chamindra de > Silva <chamindra@opensource.lk> wrote: > In Sahana we have these two as separate modules. 1) "Who is doing What > Where" is the traditional 3W application called the Organization > Registry. 2) "Who _needs_ What Where" is a bulletin board of people > requesting aid on behalf of a victim group in the field called the (Aid) > Request Management System. It also track pledges of aid. The prior operates > at a high level of services provided (e.g. medical, sanitation, food, water) > by a responder group across the affected area, whilst the later works with > units of aid needed specifically by a victim group (e.g. 100 Tents) I would > prefer we stick to the traditional sense of the 3W (i.e. option 1) to keep > things simple for now and to help us can quickly get through the full cycle > up to an interop standard recommendation. We can always improve that > standard and build it up incrementally from there, though > I completely understand that everything is very closely related. On Mon, > Aug 11, 2008 at 9:08 PM, Nigel Snoad <nigelsno@microsoft.com> wrote: > Paola, In the F2F in Washington DC we scoped the 3W/4W as described by > Gavin. I completely agree that there must be a "needs" layer that is > centered around the affected population (I detest the phrasing "victim" and > can't too strongly suggest we never use it except for law > enforcement/human rights contexts) as well as the current "response" layer. > Thankfully, finally, the humanitarian clusters are starting to talk about > this in their data models, and definitely affected populations must included > in the incubator's data model from the start. So – we have a semantic > confusion about how we should scope "who". One is organizational, and one is > affected populations. In the 3W context for historical reasons it's the > organization/group providing assistance/services (of course this usually > includes the affected population themselves, something usually ignored in > the UN context). Usefully - from a data perspective responding organizations > "need" assistance as well – goods, staff and services – to continue their > work, and they, like affected populations, provide capabilities. I like the > thought of a symmetric integrated model along these lines. So - I's no > news to all of us that the scope of a solution/application affects which > components of a data model are used. The 3W/4W focuses on "response". My > suggestion is that when discussing the 3W/4W use case we confine the "who" > to organization providing services, but in the data models that come out we > ensure that the who are subclassed/flagged into both a "needs" component > including affected groups and > organizations requiring/recieving support/supplies/services, and a > "response" component that includes capabilities and > activities/outcomes/assistance/services > provided. Nigel From: > public-xg-eiif-request@w3.org [mailto:public-xg-eiif-request@w3.org] On > Behalf Of paola.dimaio@gmail.com Sent: Sunday, August 10, 2008 8:38 AM To: > Gavin Treadgold Cc: public-xg-eiif Subject: Re: Requirement for 3W interop > standard (new proposed schema attached) Gavin My understanding is the > 3W is 'just' a directory application, hence the schema is designed around > providing directory services. May I ask what is that assumption based > on? Did we as a group discuss/agree on such a constraint? Is there any more > useful purpose for which we need a 3W metaset? Is the schema for a service > directory part of our mission ? assuming 'directory' is accetaptable > description for everybody, it should be designed to be flexible to > accommodate for all stakeholder requirements, so we definetely gotta > talk -- Paola Di Maio School of > IT www.mfu.ac.th ********************************************* > -- Paola Di Maio School of > IT www.mfu.ac.th ********************************************* > > > -- Paola Di Maio School of IT www.mfu.ac.th *********************************************
Received on Tuesday, 12 August 2008 12:26:47 UTC