Re: EIIF draft needs unified person,

Craig/paola,

I'm coming to this thread late, but given Paola's recent email did
want to add my thoughts to the discussion of a "unified person"
concept.


I I agree with Craig's initial suggestion that "There should be only
one "person" object".

He proposed handling using "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'  and provided 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."

My initial thought is that  we can leverage the healthcare (HC) model
of person and patient the situation is like that of a "person" as a
"patient" receiving various types of  care over periods of time.  We
want an integrated medical record in the HC case and in our emergency
we want a corresponding emergence record for the person in the
emergency.  Now analagously different emergency systems may have a
person registered with them, so in the case of the displaced doctor
there may be an existing system that identifies her or him by some ID.
 As a victim there would be another ID and so on.  To integrate all of
these we need to map these role IDs into a master person ID.  So we
would create this person ID as the way of integrating disparate
records.

Does this create extraneous person objects?  I hope not, but it does
allow records from the past to be used and other records to be built
when we don't know the complete identity of a person and integrated
when identity is established.

Regards,

Gary Berg-Cross
Regards,

Gary Berg-Cross

On Tue, Dec 2, 2008 at 5:48 AM,  <paola.dimaio@gmail.com> wrote:
> 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
> *********************************************
>
>

Received on Tuesday, 2 December 2008 17:47:23 UTC