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