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
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
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
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
Meanwhile, I much appreciate your detailed trouble
in addressing my concern.
----- Original Message -----
Sent: Saturday, March 22, 2008 1:54 PM
Subject: How many objects needed for
Not the change in thread name.
> 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
> > 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
> I am sure that there must other ways of
> and Person (even assuming that by Person we mean
> but I cannot for the life of me see how the subtype
> should imply your second sentence above, which I extract
> 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
MW: The diagrams show Venn diagrams that illustrate the
One elipse inside another represents subtype/supertype of
and the hexagon represents an instance of the class.
if you insist on employee being a subtype of person, you
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.
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?
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
MW: If you insist on employee as a subtype of person you have
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
a person. Now I have three objects, and emp1 and emp2 are
of Shell emp and Leeds emp respectively, which are subtypes of
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
> always is) an instance of many types, with or without a
> relationship between any pair of them. As is often said,
> type is merely a predicate." And some predicates can
MW: Indeed they can, but only when they
> And of course polymorphism and the Liskov Substitution
> apply, in recognition of the singular nature of the entity
> the multiple IsA relationship. And a search on Employee
> 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
these are different.
Reference Data Architecture and Standards Manager
Petroleum Company Limited
Registered in England and Wales
Registered office: Shell Centre, London SE1 7NA, United
Tel: +44 20 7934 4490 Mobile: +44 7796 336538
> At least in MACK, dynamic subtyping
> is even
happening literally all the time, as change is the irreducible
of time and every new predicate is always a candidate
> for triggering
further state changes, so no new subtyping = no
> change = no perceptible
> Furthermore, all the above is timeless in the sense of
> criterion which I have already approvingly quoted (in my
> 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
- 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
> Furthermore, as such, that setup well satisfies
> intelligibility criterion that PatH drew to our attention
> 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
> > 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
> But that's enough from me on the subject.
Please, Matthew, let
> me (and - I don't doubt -others) have the benefit
> perspective here?