Re: EIIF draft needs unified person,

Paola and all,
just to introduce some OntoClean notion, consier that Person and Patient 
are concepts of two different types, since the former is 'rigid', the 
latter is not. For Person to be rigid means that Person(x)  implies 
necessarily Person(x). i.e. if I'm a Person in a context (possible world) 
I'm a Person in every context. Patient, of course, is different. Non-rigid 
concepts (also referred to as 'roles') are typically those expressing 
social roles (manager, employee, etc) and\or temporal phases (injuried, 
missing, etc). Rigid concepts can subsume non-rigid ones but not 
viceversa. Many ontologists (e.g. Guarino), however, would recommend a 
'multiplicative approach',  i.e. a) keep roles into a specific hierarchy 
(in fact, roles are usually modeled as 'abstract' whereas rigid concepts 
are mostly 'concrete'), thus b) have two different instances for rigid and 
non-rigid concepts respectively, and c) link the two instances with a 
suitable association. For practical reasons, you can adopt a 
'deflationarist' approach by setting Patient(x) -> Person(x), thus having 
one istance with two properties instead of two instances with one property 
each.  There are pros and cons in both approaches, that can be analyzed 
case by case.

Hope that helps ..

Cordiali Saluti, Best Regards,

Guido Vetere
Manager & Research Coordinator, IBM Center for Advanced Studies Rome
-----------------------
IBM Italia S.p.A.
via Sciangai 53, 00144 Rome, 
Italy
-----------------------
mail:     gvetere@it.ibm.com
phone: +39 06 59662137
mobile: +39 335 7454658





paola.dimaio@gmail.com 
Sent by: public-xg-eiif-request@w3.org
02/12/2008 18.59

To
"Gary Berg-Cross" <gbergcross@gmail.com>
cc
"C H" <craighubleyca@yahoo.com>, public-xg-eiif <public-xg-eiif@w3.org>
Subject
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
*********************************************



IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) 
Cap. Soc. euro 361.550.000
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società con Azionista Unico
Società soggetta all?attività di direzione e coordinamento di 
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)