Re: EIIF draft needs unified person

I wanted to comment further on this discussion of "EIIF draft needs
unified person", which I believe, has a few roots and implications.
Besides improving our group understanding I take a goal of this is to
improve our Framework document.  There are several areas where the
improvement might be made, just in regard to the topic of People or
the more general "Who".

This thread started off with Craig's suggestion that "There should be
only one "person object", but, as far as I remember, he didn't
illustrate  this idea within the secions of our Framework document.

So one place that a "person object is implied is the Conceptual
Framework Model of Figure 1.  We have "people" and "organizations"
concept boxes in the diagram (with some non-exclusive sub-types in
each – "pets" as "people"!!).  We have lines relating some of our
boxes with very uncertain semantic that do not even have a label.  And
we have a "Who" box all the way over on the right side with people in
it, but also "providers", "responders" etc. (which don't appear
elsewhere).  The "Who" box is "associated" with the "Incident" concept
box, but nothing else!  Why it isn't connected to Person is not
obvious to me.  Is it to others?

My point for this discussion is that we have been discussing some
semantics for "person" in our email, but not relating it back to
improvements in the EIIF Framework document.  I think that one reason
for this is that some of the conversation was aimed at developing
material for Section 4 on Common Ontology.  While we need lots of work
there we need to be sure that the earlier sections on Framework and
the Use Cases make use of our understanding of Who/Person, What, and
Where.

That is, we can't be vague in these sections and then dump ontologies
into the document at the end. So, as a concrete proposal to leverage
our improving understanding, we should be improving our Conceptual
Framework Model as we discuss these things.

 We should also improve the ERD we have in Figure 3 illustrating our
W3 coordination. I take this model as a logical sub-set model that is
based on our Conceptual Framework Model.  It does have entities for
"person" (not people) and "organizations", so it roughly aligns with a
part of the Conceptual Framework Model and we have started on some
attributes for these entities.  And, if I understand correctly, we
have an entity to store "contact details" for each of these.  But we
model "person" and "organizations" somewhat differently – we have an
attribute "type" for organizations but have sub-type entities
(contactPerson) for Person.  Where the idea of "victim" etc. went from
our  Conceptual Framework Model I'm not sure.

My point is that there are some very fundamental semantics and
ontological engineering to flesh out the Conceptual Model and get
agreement on the major entities and relations we need for the domain
before we get too deep into the finer details of ontology.  Guido
provided a top-level ontology we might connect our domain model to
after it is more mature.

Refining our Conceptual Domain model  is in the spirit of one of
Rebecca 's comment on the Framework document where noted a mention of
teams and observed:

    " A team could be made up of unaffiliatedPersons or contactPersons
or maybe is part of
   Organization? Is it necessary to have a branch off any of these to
capture 'team'? "

We might borrow some ideas from healthcare models that have used
ontologies (e.g. Open Galen) and employ the Actor concept with several
sub-types: Organization, Group and Person.
Actors are not Roles since they are "Rigid" as discussed by Guido (we
just put a "valid for time Period" value into the role), but each is a
sub-type of Party.  Party relations are used to associate types of
Actors so a Person has some relation to a Group or Organization.
Among the things this does is allow us to put "contact details" at a
higher level since all Actors have these, but since roles have them we
might associate them with the Party entity.

This is only a start on suggested improvements, and I hope that it is
useful.  One idea from  this approach is  to improve our Conceptual
Model and them making sure that any ERD for a Use Case aligns with
this and provides incremental improvements to the semantics we need.

Regards

Gary Berg-Cross, Ph.D.
gary.berg-cross@em-i.com or gbergcross@gmail.com
SOCoP Executive Secretary
Principal, EM&I  Semantic Technology
Potomac, MD    301-762-5441

On Wed, Dec 3, 2008 at 5:33 AM, Guido Vetere <gvetere@it.ibm.com> wrote:
>
> Paola,
> yes, the relationship is usually called rigid dependence: the existence of
> an individual (the instance of your role) necessarily implies the existence
> of another specific individual (the instance of person).
>
> In DL, you must introduce a specific association (role), e.g.
> existential_dependence, and set cardinality constraints as *..1.
>
>
> 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
>
> 03/12/2008 11.08
>
> To
> "Jay R. Ashworth" <jra@baylink.com>
> cc
> "public-xg-eiif eiif list" <public-xg-eiif@w3.org>
> Subject
> Re: EIIF draft needs unified person
>
>
>
>
> Thanks a lot Jay and Guido
>
> I understand and can relate to the rigid/non rigid description
>
> however one thing I dont see in the description below, is the mandatory
> relationship that must exist betweet patient and person, that is, a person
> can be a patient, but a patient must be a person (how do say that in DL?)
> so, the non rigid concept can only exist in relation to a rigid one
> is that so?
> PDM
>
>
>
>
> On Wed, Dec 3, 2008 at 4:30 AM, Jay R. Ashworth <jra@baylink.com> wrote:
>
> ----- "Guido Vetere" <gvetere@it.ibm.com> wrote:
>> 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.
>
> You're a database analyst, aren't you, Guido?  :-)
>
> G'day, all.  I came to this list from the US CAP context, and I've been
> following along until now; I'm not even an associate member of the working
> group, but I do have a couple things to contribute; hopefully you will find
> them comprehensible, rather than compost.
>
> On this issue, which amounts to object modeling, as far as I can see, I
> agree
> with Guido, and I would introduce as corroborating evidence a similar
> example
> from my application design and business analysis work over the last 20
> years.
>
> Accounting systems tend to over-specify their lists of Entities With Which
> Your
> Company Interacts.  They have Customer files, Vendor files, Employee
> files... and
> they fail almost completely to manage well the (fairly common) case where an
> employee is both a customer and a vendor to the company as well.
>
> In part, I think this is early generation design oversight, entrenched into
> the
> design space.  Partially, too, though, I think it might be because it's hard
> to
> decide on a reasonable name for the objects enumerated in that file... which
> speaks
> rather directly to your charter here, does it not?
>
> So, yes, do not embed status of an object into the place you choose to store
> that
> object.  Put all your contacts into one Contact file, possibly with
> recursive
> associations, and then use auxiliary relation files to categorize or apply
> status...
> since status changes, and you want history anyway.
>
> ==
>
> On another current point, about ISO 8601 timestamps...  I concur with the
> person who
> asserted that IETF RFCs are an *excellent* target for the degree of rigor to
> which
> a standard's quality and degree of detail should be held, and, on point, I
> think
> that as long as the standard specifies that ISO 8601 timestamps *which must
> include
> timezones* (since "timestamps" *always must include timezones*), that ought
> to
> satisfy.  No?
>
> Cheers,
> -- jr 'now, off to go read the actual draft :-)' a
> --
> Jay R. Ashworth                   Baylink
>  jra@baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates     http://baylink.pitas.com                     '87
> e24
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
> 1274
>
>            Those who cast the vote decide nothing.
>            Those who count the vote decide everything.
>              -- (Josef Stalin)
>
>
>
>
>
>
> --
> 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)

Received on Wednesday, 3 December 2008 15:04:46 UTC