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