EIIF draft needs unified person, rigorous when/where, criteria towards common ontology, use of phases

My quick comments on the draft, to be followed up later, as there's no teleconference now until January.

1. person

There should be only one "person" object and attributes of persons should be attributes of that object, that is, the impact /affect of a disaster can be a different type of object  "emergency_affect' (or in the very sad unreadable non-English idiom W3 uses, emergencyAffect).  A list of those can be attached to a person, with the potential to model several different emergencies and affects, or the status of a person as both affected and assisting without a multiplicity of objects.  Proliferating entities is a bad idea at the best of times.  Certainly having to destroy an object and create another one when a person changes status, or moves from being potentially to really affected, adds a lot of potential for error.

Consider also the example of a doctor displaced by a flood, who is assisting in a hospital in an evacuation camp.  This person is affected by the flood, potentially affected by any epidemic that spreads in wake of the flood, and assisting with the medical activities that help prevent that epidemic or treat its victims.  There's a long list of emergencies at various phases (per the model) that this person is involved in, and ways they're involved.  Imagine now also that some of their family members are missing.  You can start to see how truly bad an idea it is to be creating a new variant of the person object for each affect, and to try to manage them without one way to attach all these attributes to a unique person object.  There are privacy reasons to avoid combining data but this can be dealt with by making attributes encodable in such a way that one can only check existence of an affect in a given context, and only if that exists would the data be
 decoded/retrieved.

2. when and where

 The OWL-time recommendations already mentioned http://www.w3.org/TR/owl-time/
are competent enough to use for this application, in my opinion.  They call a TimeSpan an "Interval" and one that is relative (unfixed in time with a moving starting point) a "Duration" and even have specialized concepts like "DeliveryDuration" which are useful out of the box.  Unlike incompetent time libraries this one actually has understood that dates and years and such cannot exist without a specified time zone (an amazingly common error that destroys the integrity of any time library that so much as permits dates to be specified w/o zones).

Accordingly this terminology should be the default.  The "trajectory" is also absolutely necessary and I'm glad to see it, because it allows some degree of interception of resources in flight, optimization of deliveries and so on.  But I think the word is "itinerary" in most libraries, a "trajectory" sort of implies the actual path taken not an intended path.  The way I see this working in practice is that GPS reports update the actual location and then some subsystem can calculate the expected times of arrival, reschedule rendezvous, etc. to really minimize waiting and update the expected times to travel specific routes (due to new potholes, snipers, etc.).

3. towards common ontology

This section isn't of much use without a list of questions that can be asked of ontologies that are being considered for convergence.  For instance, we can ask "is it easy to map this interoperability framework onto [this other ontology] or is it really necessary to converge semantics and align the terminology exactly with it?"

I would argue, for instance, that you must align date/time/place terminology with other libraries and cannot "map" them because the possible semantic errors are vast in number and no value is added by the mapping.  Also it has to happen in potentially thousands of places in the code.

However, it seems inevitable that medical records of a person would be mapped onto the EIIF definition of a person, if only because privacy concerns forbid the EIIF users having all the medical records of everyone in the same database or forcing a standard encryption method on every medical service provider.

I would like to see this section evolve into a list of related ontologies and a one-line description of how well or how deeply each could or should converge/change or provide precedents for EIIF to copy more exactly in future releases.

4. phases

Defining the phases is a real contribution but the text seems to present the concept a bit too monolithically.

It needs to be clearer, perhaps with an example, that several overlapping emergencies (like a flood and subsequent water shortage or epidemic) often occur - and that the phase diagram is more useful to calculate the kinds of transactions that will tend to overload the systems at particular times.  Allowing resources to be staged.  For instance, if you know medical services will be needed particularly badly in the immediate wake of an earthquake, but that floods tend to have a longer and more profound effect on health due to bacterial contamination of water supplies, you may be able to schedule the types of medical supplies and personnel more readily.  It should be possible to build a model of what emergefncies, major and minor, tend to co-occur and follow on one another, e.g. total power blackout tends to lead to looting opportunities and armed conflicts, in any particular place and keep updating that model based on actual experience in similar cultural
 settings.

The word "resilience" belongs in there more prominently, perhaps as a function of response effectiveness in all the phases.  One might say, for instance, that resilience is calculated by multiplying the effectiveness across all phases, however weighted, and accordingly that you can't achieve resilience by neglecting any phase - are better off shoring up weak points rather than trying to become "best in the world" at some more visible phase.

Received on Saturday, 22 November 2008 18:34:07 UTC