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

Craig

thanks for the comments below
I wanted to say something about your point n1 below, but was busy, apologies
for late reply

Our diagram so far does not represent a database schema

>From the database modeling point of view, following the relational model,
you are right, there should be only one ind of person, and contactperson,
and affected person
are more likely attribute/states of person.
is this what you mean?

however, in the diagram that we are working on below, person is not an
entity
(this is not a database model) but more like  a role, as such there can be
many kinds of persons, because they are all roles

I see the diagram as we are producing would have to be heavily normalized
before becoming a database schema

do I understand this right?

thanks

PDM

On Sun, Nov 23, 2008 at 1:33 AM, C H <craighubleyca@yahoo.com> wrote:

>
> 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.
>
>
>
>
>


-- 
Paola Di Maio
School of IT
MFU.ac.th
*********************************************