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

On the "when and where" discussion, I would hazard that the correct term is 
"route". This term is well defined in both ISO, OGC, and OMA standards.

Regards

Carl

----- Original Message ----- 
From: "C H" <craighubleyca@yahoo.com>
To: "public-xg-eiif" <public-xg-eiif@w3.org>
Sent: Saturday, November 22, 2008 11:33 AM
Subject: 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 Monday, 24 November 2008 23:34:25 UTC