教師は人間のサブクラスではない？

この本読んだんだけど今年有数のヒットだった。

オントロジー工学 (知の科学)

長年の疑問が、オントロジー工学なる学問の世界ではとっくに解決されていることを知った。
例えばこんな問いと、その答えが書いてある。

1. 「〜のインスタンスである」と「〜の部分である」と「〜のメンバーである」の違いは何か？
2. 「〜の部分である」と「is-a」の違いは何か？
3. 「〜の部分である」という関係には、推移律が成立するものとしないものがある。何が違うのか？

3は、例えば以下のA,Bの「部分である」の違いを明らかにせよ、ということ。面白い問題だと思う。
A. ピストンはエンジンの部分である。エンジンは車の部分である。ピストンは車の部分である。
B. 指はA教授の部分である。A教授は教授会の部分である。が、指は教授会の部分ではない。

「部分である」に推移率が成立しないケースがある、というのはけっこう大問題で、全社目標を個人目標に分解して与えたりするけどそれって大丈夫なのとか、MECEとか言ってツリー構造の絵描いたりするけどあれもやばいんじゃないのとか、いろいろ不安になる。後でゆっくり考えてみます。

ところで、オントロジーの世界では「人間」クラスのサブクラスに「教師」クラスを置くことは認められないのだそうだ。
理由はこうだ。

例えば「教師」を例にとれば、

Xさん instance-of 教師
教師 is-a 人間

のような表現がなされるのが普通であるが、Xさんが教師を辞めたとすると、退職ということの意味は表現方式が現実を
正しく反映していると考える立場からはインスタンスの消滅に対応する. しかし、この組織化では、教師インスタンスは
人間のインスタンスでもあるため、退職によって教師インスタンスが消滅することになり、それは人間インスタンスの
消滅、すなわち死亡を意味することになる。
このことから上のモデル化は現実世界を正しくモデル化していないことがわかる。

我々がプログラム書くときにこんなことを考えないで済むのは、ほとんどのインスタンスが処理のリクエスト単位で生成−消滅するからだ。
データベースにはオブジェクトではなく値と関係だけが保存されているので、処理要求ごとに好きなようにクラスの階層を組んで操作すればよい。
「人間」のサブクラスに「教師」があっても何も困ることはない。
逆に、インスタンスをそのまま出し入れするようなデータベースを使うなら、オントロジーを理解してクラス階層を構築しないと、後でめんどくさいことになるわけだ。
RDBの代替品がいろいろ出てきたけど、値と関係だけを保存し、かつSQLと同等にデータを操作できるプロダクトじゃないと使いこなせそうにない。