--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jstarkey@...>
wrote:

> Sorry if this is a repeat, but it's worth taking up in some detail.
>
> The semantic extension allow simple handling of classes of things that
> have some common attributes and other attributes that aren't so

common.

> The example I gave was a clothing merchant. All of his articles

have an

> SKU, a description, a unit price, type of material, etc. But shirts
> have collar size and sleeve length, pants have waist and inseam, shoes
> have size and width, etc. Sometimes he wants to handle the common
> attributes of all articles and sometimes he want to handle just

pants or

> just shirt, and want to see the attributes specific to those records.
>
> Postgres tried to handle with this with many tables and views to
> aggregate the records. I don't think that works well. A simpler
> implementation has a single base table. This requires that the lower
> layers of the data store understand the type hierarchy, but this

isn't a

> serious problem.
>
> I don't see any purpose to multiple inheritance in the semantic world.
> I'd go further and say that multiple inheritance is almost any

domain is

> one of mother nature's gentle ways of telling you that your application
> design is lousy. C++ has it, Java doesn't (uses interfaces instead),
> and Java is the better language for it. There are lots of other pieces
> of OO baggage that people want to hang off the semantic model that
> should be resisted.
>
> So, single parent, primary key must be defined in the base table, other
> indexes defined in the type hierarchy as needed, and no sex change
> operations. Simple, elegant, and to the point.

I think you're conflating semantics with physical implementation.
If your notion of inheritance is bound to structure extension
(C++, Java) or table extension, then you're stuck with the root
of the hierarchy establishing identity for everyone else.

But there's no absolute requirement to use that sort of
implementation. Both perl and Python represent objects
as dictionaries which removes the implicit linkage between
inheritance and identity.

So why not scrap inheritance altogether and work with
identities and properties of identities (values or
relationships to other identities)? As it happens,
I have a working example of such a system, freebase.com.

If you consider an interesting identity:

http://www.freebase.com/view/en/arnold_schwarzenegger

You notice that it (he) has half a dozen types. And
more can be added with nary a "create table"

The underlying database is identity based and represents
relations uniformly as links between identities. Compare
to relational systems, which, in spite of the name, do
not give all relations first-class status: some get
expressed in tables, others require joins.

I've written a brief description of the underlying database:

http://blog.freebase.com/2008/04/09/a-brief-tour-of-graphd/

Regards,

-Scott