Re: EIIF draft needs unified person,

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

yes

well, sort of

person ID is only one, is it? (name/surname/dob/passportnumber/gender)
but can have many roles/attributes which are variable



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


they may be useful when there are partial records available

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



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