Re: categorization of information/priority

------
SUMMARY:  

Many exciting experiments are possible with this
ontology, as Gavin's ambitions for Sahana suggest.

Gavin's use cases for software compliant with the
ontology can be extended into other cases that might
increase response efficiency, identify response gaps,
identify experts with skills relevant to a current
crisis, assess plan applicability, prevent corruption,
identify prejudicial or nepotistic resource
allocations, and inspire software research.  These
goals may inspire support for the ontology.

A list of patterns and anti-patterns is suggested at
all levels from governance problems to UIs and URIs. 
Clever use of URIs that mimic that of social software
like Wikipedia, adoption of user interface patterns
from commercial services like Facebook, maps of the
situation and response and plan coordinated as in a
project or resource management system, are mentioned.

Another benefit of such a sophisticated approach is
greater transparency and giving the impression of
greater scrutiny or supervision on persons in the
supply and decision chains, which may condition people
to behave better and ultimately alter long term habits
that disadvantage victims.  This deals with some of
Paola's concerns and human rights and social goals.

-------


Gavin's is absolutely the right approach, but take it
further.  Think about all the users of all instances
of the software sharing all public information about
their responses or roles or skills, perhaps to make
themselves available in situations where a similar
profile of person is required.  Just-in-time disaster
expert recruiting.  When the field personnel need to
focus on gathering data and doing work, people further
away can take some data analysis and supply chain
tasks over.  Not that people far away should do that
in general, but, for some tasks, they're more
objective, and they are also closer to the origin of
the supplies, donations and sometimes the expertise
(as in a pandemic).

Also think about pattern recognition on how the actual
response matches the plan, or how the response maps
onto the situation, or how the plan could or should
change to deal with either based on information that
is held in the software, data or the configuration.

--- Gavin Treadgold <gt@kestrel.co.nz> wrote:
> Sure, perhaps the best practical way of improving
> this is to merge  
> the collaborative document development process with
> an ontology so  
> that all elements or a plan are marked up as the
> plan is written and modified.
> ...Wouldn't it be fantastic if the simple act  
> of editing the plan dynamically modified the actual
> group within the  
> messaging module as soon as the change is submitted
> (and approved if required). 

Yes, that's exactly how it should work.  Until any
such approval occurs, messages are sent "pending"
approval and held in a queue, so none are missed.

I've done things like this before, like specifying a
way to update email lists of political candidates and
associated web services so that when someone's added
to the category, or removed, pages and links change.

Tikiwiki incorporates gACL lists and so I thought
could be useful in this regard.  However its lack of
social software features (nowhere near as good as
mediawiki) made it impractical for what amounts to a
social networking application.  I suggested once to
Sahana that it simply adopt the mediawiki URLs and
conventions for user identification, in anticipation
of having similar social features embedded in it some
day.  So you'd have URLs like:
 
http://sahana.biggestdisasterever.tm/User:Gavin_Treadgold

and this would be Gavin's sahana profile as it relates
to that particular disasters.

Following strict naming conventions for URLs is always
important.  Done perfectly, you'd end up with URIs not
URLs, so that the above would remain as a persistent
and reliable record of what Gavin did in that
disaster.

This would in turn make it easy to find past users and
experts who intervened in similar events or recognized
similar patterns.

Another alternative is an OpenID compatible approach.

> And a link is created automatically next
> to the list in  
> the plan that takes the user directly to the form to
> send out an  alert using the messaging module.

Or checkmarks beside everyone who should receive it,
defaulting to those in roles that say they should in
general receive that type of message.  Facebook does
this quite well, you should look at its messaging
interface.

The interaction between plans and software and data
could go further than you suggest, Gavin:

>e.g.  building up  
> default software users in Sahana based upon the
> response structure,  
> and role descriptions. Customising a Sahana server

Go a step further:  track the exceptions and unchecked
boxes so you know how accurate the defaults were or
how updated the plan was.  There must be some metrics
to determine how "real" the plan is by comparing it to
what actually happens, once things are so
instrumented.

> could be as quick  
> and easy as importing your plan! Of course, the
> obvious thing to do  
> would be to create a module that combines all this
> so that any  
> realtime changes in the plan are reflected in the
> Sahana server hosting it.

Now imagine the actual configuration and data of that
server affecting the plan itself.  So for instance if
a group of users are added who are local religious
leaders managing various relief shelters out of their
churches or mosques or temples, the commonality in
their titles or the names of the institutions could be
recognized and questions asked of the planners or the
managers.  

  74% of the shelters have "mosque" in their name.   
  44% of the new users added since the disaster have
  the title "imam" [or whatever applies locally].
  The plan makes no reference to religious authorities
  or institutions.  Should this not be updated now?

A fairly simple concept lattice could recognize that
the titles or names are associated with Islam and that
Islam is a religion and possibly generate this kind of
pattern query automatically.  Anyone could type in a
one-liner response to this kind of message, it needn't
go on anyone's priority list.  But it may help reveal
problems such as a lack of secular/religious trust or
one well-organized group dominating the relief process
and diverting resources preferentially to their own.

A much simpler example of the same thing is geographic
location patterns:

  80% of the new users added since the disaster live
  in the bounds of the urban area least affected by
  the earthquake.  94% of the messages issued regard
  events in those areas.  75% of the population lives
  outside the urban area and is unaffected by these
  events.  Should there be some rural outreach effort?

A rather simple program can do this, if it has a list
of anti-patterns to recognize (like ignoring the rural
area) and knows that the response to that is a "rural
outreach" (even though the program has no idea what
that is, it's a link to something that a human reads).

Comparing plans with results after the fact, using the
data as evidence, is an expert task of course.  These
kinds of pattern recognitions don't replace the expert
review of the plan.  But they can minimize harms maybe
by coaxing people in a position to take specific
action
to prevent anti-patterns from developing, or even just
to discuss the possibility of them developing.  Or, to
convince them that Big Brother is watching, and so
they
better not steal anything or try to misdirect any
help.

(admittedly this last effect can be counter-productive
but it's a reality among local officials in many
places)

> This is the sort of integration that will really wow
> emergency managers, 

I'd rather wow the most vulnerable and disadvantaged
people and the most under-appreciated responders who
get there first.

In the Kashmir earthquake, I'd want to wow the Scouts
of Pakistan, maybe by having their response effort be
logged the same way as every other, and its extreme
cost effectiveness and timeliness cited to motivate a
few quick calls to get such organizations involved as
soon as the disaster strikes.  In turn, the Scouts can
wow the people in remote mountain villages no one else
could reach.

Another example might be a disaster in a place where a
caste system dominates or where past conflicts have
left one group in authority and another group at their
mercy.  Heuristics to detect 'inefficient' allocation
of resources (which may be prejudicial or corrupt) are
pretty standard in any resource or project management
software.  If the temptation to draw conclusions too
early can be curtailed, and it can be, constructive
ways to prevent or mediate these problems can arise.

The more this kind of reminder and notification and
invitation can be automated, the better.  There's no
risk involved since it's humans making the decision to
use the information or not or approve specific users
or outreaches.

If the ontology exists at all, and sample data from
real disasters is made available (in some
privacy-obfuscated form), some truly brilliant and
creative minds will want to use it to test reasoning
approaches.

It's not inconceivable to get people like freebase.com
or AI researchers involved in tackling the worst of
the worst problems, the ones that cost many many
lives.

All it takes is data that accurately describes what is
going on.  Admittedly this is hard to get and maintain
but once you've got it, you create a culture of
keeping it up to date and accurate and relevant, and
that in turn can lead to a culture of transparency.

Craig Hubley


      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

Received on Tuesday, 19 June 2007 22:05:08 UTC