Re: EIIF draft needs unified person

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)