「ベーシックス」 （7月 1日付） で、「集合 オブジェクト」 と 「組 オブジェクト」 について、述べた （420ページ 参照）。「集合 オブジェクト」 と 「組 オブジェクト」 は、以下にように、定義できる。

　（1） S₁、S₂、・・・、S_nを オブジェクト （あるいは、セット の メンバー） とする。
　（2） オブジェクト の並びを論点にすれば、
　　　（S₁、S₂、・・・、S_n） は、「組 オブジェクト」 である。
　（3） オブジェクト の並びを論点にしないなら、
　　　｛S₁、S₂、・・・、S_n｝ は、「集合 オブジェクト」 である。

　「並び」 が論点になるかどうか、という点が、「集合 オブジェクト」 と 「組 オブジェクト」 の相違点である （「組 オブジェクト」 は、いくつかの集合値が、或る規則に従って、並べられた組である）。
　TM では、モノ を記述する概念として、以下の 2つを使っている。

　（1） Entity
　（2） 集合を値とする オブジェクト （集合 オブジェクト および組 オブジェクト）

　Entity と 「集合を値とする オブジェクト」 との相違点は、認知番号が付与されているかどうか、という点にある。つまり、「合意された認知番号」 を付与されている対象が、TM では、entity として考えられ、認知番号を付与されていない対象は、「みなし　entity」 か 「集合を値とする オブジェクト」 として考えられている。「みなし entity」 は、任意の entity のなかに、ほかの entity の性質として扱われ得る性質が混成されているときに、第一階の述語論理のなかで、認知される個体であるが、「集合を値とする オブジェクト」 は、高階の概念である。
　したがって、TM では、entity と オブジェクト （object） は、用語法が違う。

　さて、TM では、entity の並びを考慮する際、「時系列」 を並びの規準にしている。
　したがって、以下に示すように、1つの対照表のなかで、（R） の並びを 「組 オブジェクト」 として考えない。

　　　　｛部門 コード （R）、従業員番号 （R）｝.

　すなわち、（部門 コード、従業員番号） であっても、（従業員番号、部門 コード） であっても良い。
　ただし、（もし、対照表が、「event」 として認知されるのであれば──言い換えれば、対照表のなかに、日付が帰属するのであれば──、） 2つの対照表のあいだには──あるいは、1つの対照表と 1つの 「event」 のあいだには──「並び」 を考慮しなければならない。

　1つの対照表のなかで、（R） の 「並び」 を考慮したほうが良い例も、たしかに、ある。たとえば、「銀行口座」 がそうである。

　　　　｛銀行 コード （R）、支店 コード （R）、口座番号 （R）｝.

　もし、これらの （R） が、事実上、1つの 「口座番号」 として、意識されているのなら──言い換えれば、1つの コード が、3つの コード から構成されている、と意識しているのならば──、（R） のあいだには、並びが成立する。したがって、以下のように、組 オブジェクト として、記述するのが正しい。

　　　　（銀行 コード、支店 コード、口座番号）.

　ただし、TM は、（数学的な手法を使っている訳ではないが、数学的に言えば、） 第一階の述語を上限としている。そして、高階の概念は、すべて、まず、「関係」 を 「事態」 として認知することを原則としている。したがって、対照表は、あくまで、「事態」 として、まず、認知されるか──その性質として、日付が帰属するか──もし、「事態」 として認知されないのであれば、「構成表」 （真理値表） として扱うことを原則としている。

　その構成表が、「resource」 として、entity 的な役割を担うかどうか──言い換えれば、複数の （R） が、1つの認知番号に置換できるかどうか、（かつ、日付が帰属しないかどうか）──、という点は、TM の対象外としている。
　たとえば、対照表｛銀行 コード （R）、支店 コード （R）、口座番号 （R）｝ は、日付を付与すれば、「event」 （口座開設） として認知することもできるし、事実上、1つの 「口座番号」 を 3つの （R） が構成している 「resource」 として認知することもできる。

　TM では、「並び」 とは、原則として、時系列を規準にしている──ただし、例外として、「親子関係」 を示す再帰 （構成表） は、（関係の論理を グラフ の論理に読み替えて、） 個体のあいだに、並びを導入している。
　したがって、対照表のなかには──「構成」 を記述する対照表には──、「組 オブジェクト」 として記述できる構成もあるが、TM では、（それを 「組 オブジェクト」 として考えたとしても、） 記述上、「並び」 を記述していない。

　今読み返してみて、ひどく歯切れの悪い説明をしていますね （苦笑）。
　歯切れが悪くなった理由は、「対照表が 『組 オブジェクト』 になる」 例 （銀行口座の例）──言い換えれば、対照表が 「event」 的性質ではなくて「resource」 的性質となる例──の説明が下手くそだからでしょうね。そして、「組 オブジェクト」 であれ 「集合 オブジェクト」 であれ、オブジェクトは 「集合を値とする」 クラス であると説明している点が、歯切れの悪い説明になった根本の理由でしょうね。

　対照表を オブジェクト の観点で説明しないで、対照表は写像集合である、と言い切ったほうが わかりやすい。そして、その写像集合の性質として 「日付 （できごとの起こった日、取引日） を仮想したいのであれば、写像集合を一つの集合 （event） として考えればいい、というふうに説明するほうが わかりやすいでしょうね [ ZF の公理系を前提にして、「対の公理」 「和集合の公理」 および フレンケル の 「置換公理」 を使う、ということ）。

　Entity を セット （集合） に変換して、セット を整えてから クラス に変換するほうが──多値関数上の 「AND 関係 （one-header-many-details）」 を ファンクター として説明するほうが──手続きとして統一がとれているし、わかりやすい [ この場合でも、ZF の公理系と第一階の述語 ロジック を前提にすれば、多値関数の 「AND 関係」 を合成関数として考える （説明する） こともできるでしょう ]。TM は、手続き上、（多値関数の 「AND 関係」 を一価関数に変換する手続きを除けば、） セット 概念を使っているので、TM の関係文法において、対照表を説明するときに クラス 概念を事前に定義しないで導入するのは ルール 違反になるでしょう。したがって、対照表は、セット 概念の観点に立って、写像集合として説明したほうがいい。この写像集合において、或る性質 f (x) が考えられるなら──そして、TM では、「event」 と 「resource」 を類別する性質は 「日付」 なので──、「event」 を構成する 「日付」 が実存しているか、あるいは、そういう 「日付」 を仮想したいのであれば、写像集合を 「event」 として 「解釈」 すればいい、ということ。

　論点は、写像集合として構成された対照表に対して、性質 f (x) が考えられるかどうか、という点です。性質 f (x) を考えられるのであれば、「event」 として 「解釈」 すればいいし、そうでないなら、「resource」 としての性質が考えられるかどうかを検討すればいい。そのときの争点が、対照表を構成している 2つの集合において、「並び」 （順序、関係の対称性・非対称性） を配慮しなければならないかどうか、という点です。その点を本 エッセー では、「集合 オブジェクト」 （関係の対称性） と 「組 オブジェクト」 （関係の非対称性） を使って説明したのですが、いっぽうで、「階」 概念──あるいは、「集合を値とする」 という言いかた──を混入してしまったので、歯切れが悪くなった次第です。申し訳ない。