「TMの会」 プログラム このウインドウを閉じる
/ 2009年 4月15日 / 

 

 「モデ 家」 の アトリビュート・リスト (「契約」 に関する アトリビュート) を検討しました。

 
 ● VE の読みかた

 VE の読みかたを確認しました。

 (1) VE は、派生もとの entity に戻すことのできる性質である。したがって、entity の
   アトリビュート・リスト 作成と同じ手続きで VE の アトリビュート・リスト を作成する。

  (1)-1 VE の アトリビュート と、派生もとの entity に帰属している アトリビュート の
      あいだで制約・束縛を確認する。
      { v1, e1, ・・・, en }.

  (1)-2 entity から派生している VE のあいだで、それぞれの アトリビュート 間の
      制約・束縛を確認する。
      { v1, v2, ・・・, vn }.

  (1)-3 VE の アトリビュート と、派生もとの entity に関与している他の entity に
      帰属している アトリビュート のあいだで制約・束縛を確認する。
      { v1, r1, ・・・, rn }.

 (2) このときに、VE 間の 「関係」 を 再度 確認する。
   というのは、VE どうしが、もし、家族的類似性の強い性質であれば、それらの VE に
   対して クラス を適用して、クラス の状態で実装することがあるので。

 → 板書写真 (1)

 
 ● VE 間の家族的類似性

 VE のあいだで家族的類似性の強い性質を クラス 概念として定立できるかどうかを確認する。
 たとえば、VE 「CD royalties (版権、印税)」 を検討するときに、VE 「royalties 」 との 「関係」 を確認する。すなわち、「royalties 」 という クラス 概念のなかで、ふたつの VE を統括できるかどうかを確認する。ユーザ (モデ さん) に確認したら、ふたつの概念は、それぞれ べつの概念であることが明らかになった──この確認 (「CD royalties 」 と 「royalties 」 との 「関係」) は、TMD を作成するときに すでに一度 実施したが、アトリビュート・リスト を作成するときに、かならず、再度、確認すること [ というのは、アトリビュート・リスト を作成して アトリビュート の制約・束縛が明らかになったときに、entity 間の 「関係」 が変わる場合があるので ]。

 ちなみに、現 「構成 (TMD)」 は、「書名」 entity を 「紙形式の現物」 としているが、もし、「書名」 entity を 「コンテンツ」 とした場合には、「royalties 」 と 「CD royalties 」 は ひとつの クラス 概念のなかで扱うことができるかもしれないことを協議しました。

 → 板書写真 (2)

 
 ● アドバンスト 料、入金回数、入金時期および通貨の関係

 (1) アドバンスト 料と入金回数とのあいだの制約・束縛を確認しました。
   「回数」 (一般化すれば、「数」) という性質では、かならず、以下の点を確認すること。

  (1)-1 下限 「最小値」 は存在するのか。
      もし、最小値が 「1」 のとき、「1」 を明記するのか (「1」 は null か)。
      すなわち、「1」 は、対象になるのかどうか。

  (1)-2 上限 「最大値」 は存在するのか。

  この確認は、数学的には、「閉区間」 「閉区間」 (あるいは、下界・上界) の確認です。

 (2) 入金回数と入金時期とのあいだでは、「時期」 に付帯する制約・束縛を確認すること。
   一般化して言えば、「区間」 の定めかたの確認です。

  (2)-1 具体的な日付を記述するのか (「変数」 か)。
      したがって、つねに、一定の間隔 (級数的) であるとはかぎらない。たとえば、
      ( 4月末、5月末、7月末、・・・ ).

  (2)-2 「間隔」 (たとえば、「1ヶ月ごと」 とか) を記述するのか (「定数・係数」 か)。
      したがって、もし、「間隔 (interval )」 が記述されれば、或る値 (たとえば、
      契約日など) を起点にして、入金日は、等間隔の線形 (forcast propagation
      となる。
      ( 4月末、5月末、6月末、・・・ ).

 (3) 「通貨」 は、派生もとの entity に対して 「1 対 1」 の関係として記述されているが、
    以下の諸点を確認すること。

  (3)-1 多貨幣での入金はあり得るか。
      たとえば、いちぶが円で、いちぶが ドル とか。

  (3)-2 言語と貨幣には、「(意味論的な) 1 対 1」 の対応関係があるのか。
      逆に言えば、「英語」 と 「円」 の対応関係はあるか。

  (3)-3 貨幣が 「円」 以外のときには、「換算」 を考えなければならないか。

  さらに、「貨幣」 を検討する際に、 VE 「territory 」 とのあいだに 「関係」 があるかどうか
  を確認しなければならない。

 → 板書写真 (3)

 
 ● クラス 概念の使いかた

 クラス 概念は、とても便利な──「実用的な」──概念です。「概念」 と言ったように、クラス は、「実質的な対象」 ではないのですが、セット を ひとつの クラス として考えれば、クラス は 「構成」 の妥当性を問うには極めて強力な手段です。私 (佐藤正美) は、「セット を特殊な クラス である」 というふうに考えています [ 拙著 「いざない」 第 4章 97ページ-99ページ 参照 ]。すなわち、或る クラス が他の クラス の構成員であれば、セット と考えて良い、と思います。

 TM は、自然言語で記述された 「情報」 に対して形式的構造を与える ツール なので、「F-真」 を重視して セット 概念を起点にしていますが、「構成」 を検討するときには、「つねに」 クラス 概念を援用しています──ただし、「現時点では」、クラス の性質を記述しないことにしていますが。言い換えれば、「構成」 を検討するときに、クラス を使うということです。関数 f (x) を 「性質 P (x)」 として翻訳したときに、「性質」 を さらに クラス として翻訳すれば──すなわち、クラス を 「性質」 と似た種類であると考えれば──「構成」 を検討するときに非常に役立つので、(セットとクラスに関して、数学的な厳密性を少々犠牲にしても、) セット と クラス を併用するほうが便利 (「実用的) だと思います。

 f (x) を ブラックボックス として考えれば、自然言語で記述された 「情報」 を input にしたとき、「情報」 には 「値 (言い換えれば、いくつかの集合を構成できる元 [ メンバー ]) が存在するので、セット を前提にした 「構成」 を作ることができます。その 「構成」 が ブラックボックス なのだから、ブラックボックス のなかで 「構成」 を検討するときに クラス 概念を使っても齟齬はないでしょう。すなわち、クラス は、セット を元とすることができると考えてもいいでしょうね。そうすれば、クラス に関して 「性質」 を考えるという面倒な手続きを省いて 「構成」 を検討することができるでしょう。

 そして、セット を元にして クラス を作ったときに、かならず、「昇ったら降りる」 こと (集合と、その メンバーという単位) を思い起こしてください。すなわち、クラス を作ったら、逆に、クラス を セット に読み替えればいい、ということ [ セット と サブセット という関係に翻訳すればいい、ということ ]。そうすれば、サブセット の構成要件を適用して、「構成」 の妥当性を調べることができるでしょう。

 → 板書写真 (4)

 
 ● 「意味」 と 「文脈」

 語の 「意味」 は、「文脈」 のなかで付与されます。言い換えれば、「文脈」 を離れた 「意味」 はない、ということ。この考えかたは、数学的な モデル でもそうです。たとえば、f (x, y) という関数において、x および y は 「変項」 なので──その関数を 「関係 R (x, y)」 と翻訳して、「存在」 するということは 「変項」 になり得ることというふうに考えれば、指示対象は変動するので──「解釈」 から独立して (対象を) 「指示」 できる訳がない。言い換えれば、「指示」 は、それぞれの 「解釈」 を免れる訳ではない、ということ。少なくとも、「現実的事態を対象にした形式的構成」 では、「いかなる形式的構成であれ自然言語で翻訳できない構成は言語ではない」 という考えかたです。そして、TM では、その 「解釈」 に対して 「F-真」 という 「真」 概念を使っています。

 したがって、個々の語のみを対象にして 「意味」 を問うことはできないでしょう──たとえ、その語が実地の事業過程のなかで なんらかの 「意味」 を付与されているとしても、「すべての」 語を対象にして それぞれの語の 「意味」 を システム・エンジニア が把握できる訳がない。そのために──事業過程に直接に関与していない システム・エンジニア が、語の 「意味」 を 「正確に」 把握するために──、それぞれの語に対して文法を適用して 「構成」 を作って、「構成」 のなかで 語の 「意味」 を確認するのです。

 TMD は、語の 「意味」 を 「或る程度」 理解して、語に対して論理法則を適用して作られますが、その 「構成」 は、あくまで 「暫定的な構成 (tentative modeling)」 にすぎない。語の 「意味」 を 「正確に」 把握するには、アトリビュート・リスト を作成しなければならない。したがって、アトリビュート・リスト の作成過程で、TMD が変更されることも起こります。「東京都 IT 迷惑条例 (20禁)」 を破っているような構成では、語の 「意味」 を正確に把握していないと思って宜しい──なぜなら、「文脈」 を示した構成になっていないのだから。

 「構成 (文脈)」 を離れて、語の 「意味」 を深読みしないように注意していてください。この点については、拙著 「いざない」 212 ページ を参照してください。

 → 板書写真 (5)

 
[ 追伸 ]

 4月15日の 「TMの会」 では言及しなかったのですが、モデル では、どうも、以下の 2つの考えかたが 「『解釈』 および 『(順序の) 構成』」 に関して黒子的役割を演じているように思われます。

 (1) レーヴェンハイム・スコーレム の下降定理
 (2) ツォルン の補題

 「レーヴェンハイム・スコーレム の下降定理」 については、拙著 「いざない」 211ページ・212ページ を読んでみてください。なお、「ツォルン の補題」 については、私の ホームページ 「反 コンピュータ 的断章」 の 2009年 5月23日付け エッセー で アップロード します。

 

ページのトップ
 
  このウインドウを閉じる