ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] How many objects needed for employment?

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Christopher Spottiswoode" <cms@xxxxxxxxxxxxx>
Date: Sat, 22 Mar 2008 18:48:05 +0200
Message-id: <050501c88c3c$89c6e960$0100a8c0@Dev>
Matthew, many thanks for your detailed reply below.  (And please excuse the liberty I am taking in posting this to the list too, which I do for its relevance to MACK.  I do so even though without your attached jpg if any other readers need a fuller grasp of your proposed alternative setups I must ask them to imagine your Venn diagrams from your narratives.)
 
Ah, yes, I apologize:  I should have followed-through with your double-employment use-case in other posts from you on the same matter, in which you are an Employee of both Shell and Leeds, each during different and possibly-overlapping time intervals.
 
But there is at least one further possibility in addition to those you offer below, and it profitably uses the subtype relationship and has no need for any notion of Role:
 
You can perfectly logically be one Employee but with possibly multiple simultaneous Employments (or "Jobs" or "Salaries"), each with its own start and stop times so the "4D" requirements you mention are met.  The Employee type (as distinct from Person with its possibly much more numerous instances serving different recorded purposes) might have attributes such as, say, qualifications or time schedule for HRM purposes, total salary and PAYE for personal income tax purposes, and total deductible health insurance and pension contributions with statutory limits per person.  The relationship between Person and Employee would still be subtype for its automatic OO-inheritance and consistency-assurance advantages, but, say, "Earns" between Employee and "Salary", or "HasJob" between Employee and "Employment", either of which can be 1-to-n.  And any one of multiple Employers or Departments would relate directly to its own time-relevant zero or one of your multiple Employments, though also, automatically navigated via there, to the single and unique Employee for scheduling or tax calculation purposes.
 
Conceptions along such lines seem to me simpler, more natural and yet more powerful than what you have in mind.
 
Then there would also be no danger of any difference of opinion as to whether an entity is a type-instantiation or in a mere role-assignment.  (There is no danger of difference of opinion as to what is subtype and what basetype, as identity and restriction apply and can be verified in live data or even heuristically discovered in it.)
 
All the above is easily understood by any database designer.  But more crucially in MACK as I have already indicated, subtyping is a very dynamic, context-sensitive and critically useful affair:  while there should be no fixed silos in our globalizing and otherwise dynamic and integrating world, there are still different departmental or operational emphases, which might easily lead to one use's typing being confused with another use's role-assignments, or vice versa in another context.  Even in the present example, a Payroll department and application could historically have Employee as a Type but another department now wants to relate it to its own Person Type - temporarily even! - for internal marketing purposes, say, but it would not seem useful to regard the Employee Type as in a Role merely because the relationship is temporary.  On the contrary, to relate or identify Employees with historically-separate Persons it is useful to test the data for subtyping, as noted in my previous paragraph above.
 
Or is there some other significance of your use of Role which I am not seeing?
 
If not, it does seem better to dispense with Role where subtype can usefully apply.
 
Such considerations are of course yet further aspects of the central notion of relativity in MACK.  That is, they are further to the key role of time dimensions which, by the way, seems to me a lot more than your notion of "4D".
 
But you will see all that in much detail in the coming instalments of my "MACK basics" series of posts to this forum!
 
Meanwhile, I much appreciate your detailed trouble in addressing my concern.
 
Christopher
 
----- Original Message -----
Sent: Saturday, March 22, 2008 1:54 PM
Subject: How many objects needed for employment?

Dear Christopher,

Not the change in thread name.

> Matthew,
>
> Sorry to resume with one of your messages from far back in this
> thread.  But this matter did not clear up subsequently, in my
> mind at least, and it still bothers me.
>
> On 19 March you were answering PatC:
> >> "Employee" is also a subtype of Person,
> >
> > MW: Now there you go and spoil it. If employee is a subtype of
> > person, it means that each instance of employee is a separate
> > instance of person, i.e. there are two of me. There is a
> > relationship between employee and person of course, but you
> > need to let go of the popular myth that it is
> > subtype/supertype.
>
> I must confess to subscribing to that "myth"!  And certainly, as
> you say, it is popular, being a classic or textbook example of
> OO's inheritance.
>
> I am sure that there must other ways of interrelating Employee
> and Person (even assuming that by Person we mean HumanBeing),
> but I cannot for the life of me see how the subtype relationship
> should imply your second sentence above, which I extract and
> quote again:
>
> > If employee is a subtype of person, it means that each
> > instance of employee is a separate instance of person, i.e.
> > there are two of me.

MW: See the attached .jpg.

MW: The diagrams show Venn diagrams that illustrate the problem.
One elipse inside another represents subtype/supertype of course,
and the hexagon represents an instance of the class.

MW: Now if you insist on employee being a subtype of person, you
have two possibilities. The one you are suggesting is shown first.
There is just one person, and they are instances of the classes
person, Shell emp, and Leeds emp, with Shell emp and Leeds emp
being subtypes of person.

MW: The problem here, is what salary do you give MRW? The Leeds one
or the Shell one? If you give him two salaries, how do you know
which one is the leeds one and which one is the Shell one? If they
start and finish as employees on different dates, how do you hold
that separate information?

MW: The second possibility is that you have two employees, a Shell
employee and a Leeds employee. The good thing about this is that
all the start and end dates, salary etc are nicely separated. The
problem now is that there are two of me.

MW: If you insist on employee as a subtype of person you have to
choose between these options.

MW: However, the third option takes a different approach. It says
that roles (or perhaps the playing of a role) are different from
a person. Now I have three objects, and emp1 and emp2 are instances
of Shell emp and Leeds emp respectively, which are subtypes of role,
and I have one person, MRW, who plays the roles.
>
> In my book (and certainly in MACK) in such subtyping there are
> not at all two separate instances (except perhaps in a RDBMS
> with a historical legacy of separate and uninterrelated
> relations for Employee and Person), but one instance of two
> types, just as any entity at all can be (and in MACK virtually
> always is) an instance of many types, with or without a subtype
> relationship between any pair of them.  As is often said, "A
> type is merely a predicate."  And some predicates can specialize
> others.

MW: Indeed they can, but only when they should.
>
> And of course polymorphism and the Liskov Substitution Principle
> apply, in recognition of the singular nature of the entity with
> the multiple IsA relationship.  And a search on Employee or
> Person would reveal just one result in respect of any one
> individual.  And the identity criteria for Person would apply to
> Employee too, even though Employee might have further criteria
> (as in "the Manager of Department X").

MW: OK so both the person and the employee have the same start date?
>
> I also find that "4D" has no bearing on the matter, even though
> the Employee status or predicate might only hold for a limited
> period of time. 

MW: If you were in any doubt, 4D is quite decisive. Under 4D an
object is its 4D extent. Clearly the 4D extent of the employee is
from the start of employment to the end of employment, whilst the
4D extent of the person is from their birth to death. Clearly
these are different.

Regards

Matthew West
Reference Data Architecture and Standards Manager
Shell International Petroleum Company Limited
Registered in England and Wales
Registered number: 621148
Registered office: Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Mobile: +44 7796 336538
Email:
matthew.west@xxxxxxxxx
http://www.shell.com
http://www.matthew-west.org.uk/

> At least in MACK, dynamic subtyping
> is even
> happening literally all the time, as change is the irreducible
> measure of time and every new predicate is always a candidate
> for triggering further state changes, so no new subtyping = no
> change = no perceptible time!
>
> Furthermore, all the above is timeless in the sense of PatH's
> criterion which I have already approvingly quoted (in my "2nd
> instalment" of Feb 21) in this way:
>
> > .Pat Hayes had earlier insisted (now at
> >
http://ontolog.cim3.net/forum/ontolog-forum/2008-01/msg00385.html)
> > that
> >
> >> The ideal ontology framework is one in which all
> >> contextual sensitivity has been _eliminated_ as far as
> >> possible.
>
> (There, of course, I regard time-dependence - or "lack of
> timelessness" - as part of PatH's "contextual sensitivity".)
>
> That whole perspective just seems to me so plain and simple and
> everyday (even though for this forum I describe it with the help
> of some fancy words!)..
>
> Furthermore, as such, that setup well satisfies the
> intelligibility criterion that PatH drew to our attention with
> this (also on March 19) in this thread:
>
> > There are formal inconsistencies, which can be detected by
> > logical machinery.  But there are also what one might call
> > mismatches, where a formal ontology, while internally
> > consistent, fails to conform to a human user's intuition so
> > strongly that it becomes incomprehensible to them. Typically
> > this is what gives rise to formally incompatible ontologies,
> > when they are separately developed by folk with these
> > divergent intuitions.
> >
> > Simply being internally consistent does not guarantee that an
> > ontology is intuitive or even comprehensible.
>
> PatH's comment was not directed specifically at the issue I
> raise here, but it certainly should apply to it, and I maintain
> that (in PatH's words) your view "fails to conform to a human
> user's intuition so strongly that it becomes incomprehensible
> to" me at least!
>
> (Or, PatH, am I misinterpreting you in those two quotes of your
> words above?)
>
> But that's enough from me on the subject.  Please, Matthew, let
> me (and - I don't doubt -others) have the benefit of your
> perspective here?
>
> Christopher
>
>
>

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ontolog-forum] How many objects needed for employment?, Christopher Spottiswoode <=