Re: EIIF draft needs unified person

----- "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)

Received on Wednesday, 3 December 2008 09:58:43 UTC