[om-list] Roles, symbols, and proxies as first class objects

[Mark Butler]

Hello everybody,

I have discovered that treating roles, symbols, and proxies for other 
objects as first class objects in their own right solves serious data 
representation problems in object relational form. I have tried to avoid 
multiplying entities as much as possible, but this is a distinction that 
is hard to avoid in a general purpose model, even though it is not at 
all obvious that this should be so.

For example, let's say that I have the expression "every tenant", as in 
the constraint "every tenant must be a student".  That is a constraint 
that is perfectly valid long before I bind 'tenant' to an actual 
individual.  So how can I make propositions about a symbol that has not 
been bound?  One solution is to promote the symbol to a first class 
object, a proxy for some arbitrary number of as yet undetermined objects.

This works in the past situations involving incomplete knowledge as well 
- Take the two propositions:

  "General Washington had a white horse"
  "Jonathan Edwards had a white horse"

How in the world are we to determine a priori that we are not talking 
about the _same_ horse?  Or in other words how are we ever to assume 
that two objects in a system are not already aliases or proxies for each 
other?  If we have to handle that prospect anyway, keeping multiple 
proxy or role objects that we identify with the same core object seems 
no great leap.

For example, one might say:

"The captain ordered the men to abandon ship" and
"The captain was John Smith, of Newport, Rhode Island."

We might go on for pages relating this proxy object ("the captain") to 
this or that, and only entangle his proper identity ("John Smith of 
Newport, RI") every once in a while.  This is great for mapping to 
natural language, and for conflict resolution.  If I discover someday 
that the captain was the John Smith from Roanoke, Virginia instead of 
the one from Rhode Island, I only need snip and replace one link rather 
than redoing every relationship in the whole history.  This seems to me 
to be quite an advantage, one that maps quite well to how disciplined 
thinkers actually track partial and uncertain evidence without drowning 
in unwarranted skepticism or stubbornly fixating on preliminary 
judgments before all the facts are in.

This pattern shows up in traditional data modelling all the time - for 
example lets say I have an entity named PARTY (a legal party that is) 
and he/she/they can enter into business relationships with my business.  
I might generally consider them either a CUSTOMER, a VENDOR.  In actual 
practice, however there will be some parties that will be my customer 
more than once, and some that will be both a customer and a vendor.  
Traditionally the fact that these different accounts actually correspond 
to the same legal entity has been neglected, because the PARTY table 
isn't implemented in most systems.

In more modern systems this relationship is more explicit (if sometimes 
broken) - In Quickbooks, for example an entity can either be a customer 
or a vendor, but not both, a classic example of how not to apply single 
inheritance.  The only way out of the real world complexities of 
multiple inheritance is to create proxy objects for the core entity, in 
this case a customer proxy and a vendor proxy for a core legal party object.

Consider the following questions:

Is ABC a customer of ours?   Yes
Is ABC a vendor of ours?  Yes.
Is a customer a vendor ?   No
How can that be?  ABC is a customer and a vendor, but a customer is not 
a vendor?

In  data modelling syntax we might say that the proxy objects are like 
singleton base classes in a multiple inheritance scheme:

ABC can be treated as a customer
ABC can be treated as a vendor
But ABC treated as a customer is not the same as ABC treated as a vendor.

Or in C++ style syntax:

(Customer)ABC is a valid cast
(Vendor)ABC is a valid cast
But (Customer)ABC != (Vendor)ABC

Another example: people who wear multiple hats:

The district court judge (John Wells) decreed that the case should be 
dismissed

Now what is important here - the person (John Wells) or the judge (John 
Wells ex officio).  I would say the latter, and furthermore that the 
distinction is critical.  Without his office, Mr. Wells is of no 
consequence in the matter.  The relationship must be made to the judge 
object, not to John Wells directly.  If we try to do all the latter we 
end up having to add tagging information after the fact anyway to 
clarify in what role or by what authority Mr. Wells acted in the case.  
It seems much simpler to just make this explicit by using a proxy object 
instead.

This principle can be correctly extended to a reference attribute of any 
class, by promoting the attribute to a first class object that acts as a 
proxy for the referenced object, but with special properties (timing, 
duration, authority, status, etc.) all its own.  In that sense I can 
say, for example, that "John was a good person, but a horrible tenant".

Comments?

   - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://six.pairlist.net/pipermail/om-list/attachments/20031208/99ba3a7d/attachment.html