こんにちは，児玉＠(株)エクサです。
羽生田さん，
「[modeling-dojo:00357] 汎化とインスタンス関係の使い分け再論」のお返事させていただき
ます。
>そもそも児玉さんの出されたモデルは何度も改訂を重ねて
>非常に完成度の高いものになっておりあまり突っ込みようがないのですが，
>1点だけ私として気になったのは，「サービス」というクラスのクラス名です．
>
>(1)他のクラス(この場合は特にお預かり品)との関係を見れば間接的に
>あぁ，このクラスは，1回1回のサービスではなく，サービス型を表わしているク
>ラスなのだな，というのがわかります．（最初のメールでは，わざとボケをかま
>して，お預かり品---サービスの関連のサービス側の多重度が変ですよ，と突っ
>込んで勘違いしやすいクラス名であることを示唆してみたのですが．）
>ですから，やはりモデル読者のことを考えて，「サービス型」クラスないしは
>「サービス種」クラスという名前にすべきではないかと考えた次第です．
>長いメールのやり取りになってしまいましたが，今回言いたかったことは，この
>1点のみです．
なるほど，サービスの種類を表すから「サービス種」なり「サービス型」
といったクラス名にした方が，理解しやすかったのではないかということ
ですか。
私は，サービスを商品としてとらえました。たとえば，お店で，天丼を
頼みます。これは１つひとつの「もの」（現物）ではなく，商品の種類で
す。これを「商品種」とか「銘柄」と呼ぶべきかですが，私は，これらの
現物を扱うときには区別しますが，そうでないときには「商品」あるいは
「サービス」としておいていいのではないかと思っています。
というのは，お客さん，つまりモデルの所有者がそれを意識していない
からです。もちろん，意識すべきなのに意識していないときには指摘しま
すけどね。
現物を扱うというのは，天丼にシリアル番号を付けて管理するような状
況です。この天丼は何日の何時何分にできて，それは誰が作って，誰が食
べたかを管理するというような感じです。見込みで先作りしておいて，保
存期限を過ぎたら廃棄する必要がある場合かな。そんな天丼は，誰も食べ
たくないので，現物を管理しません。
エンターテインメント系の商品の現物はわかりやすいですね。日時，場
所などで識別されます。
で，サービスの現物は識別しにくいです。クリーニングの例だと何月何
日のお預かり品への洗浄の「実行」ということになり，それは事象として
認識されます。今回のモデルで言うと，「お預かり品」と「サービス」の
関連そのものということになります。ですから，この関連に属性を付けて
もいいですよね。タグはその１つの方法です。
ですから，この事象をサービスの現物と理解して「サービス」クラスを
設けて，これに対するパワータイプとして，現在の「サービス」を「サー
ビス型」にすることはいいでしょう。でも，本当にこの現物に属性を持た
せますか。
ということで，パワータイプは相対的な関係なのです。これでご理解い
ただけますでしょうか。実際，Fowlerは「型」としてロールにしています
よね。
だから，パワータイプかどうかよりも，知識レベルかどうかなんでしょ
うね。知識レベルのオブジェクトは，ルールや予定，予約の表現に参加し
ます。
>(2)2回目のメールでは，この主張を補強するために，「サービス」クラスのサブ
>クラスである「加工」クラスや「クリーニング」クラスのノートとしてこれらの
>インスタンスはそれぞれ「防水加工，防虫加工」，「ドライクリーニング，水洗
>いクリーニング」と書かれている点を問題にしました．ノートもモデルの構成要
>素と考えれば，やはり，本来，防水加工や防虫加工は加工クラスのサブクラスと
>考えるべきであり（言葉遣いの問題ですけどね），防水加工や防虫加工をインス
>タンスと位置づけるのであれば，今のモデルで「加工」クラスとしているものは
>「加工型」クラス，同様に「クリーニング」は「クリーニング型」クラスに変更
>すべきで，その結果，それらのスーパータイプの「サービス」クラスは「サービ
>ス型」クラスとした方が誤解が生じづらくわかりやすいですよね，と言いたかっ
>ただけです．
上で述べたように，サービスは商品であり，インスタンスとして「防水
加工」や「防虫加工」があると見ています。それはパワータイプであるか
どうかとは関係がありません。
ちなみに，商品はさまざまに組み合わされて，別の商品の扱いを受けま
す。たとえば，「麻婆豆腐」と「麻婆定食」のようにです。また，バージ
ョン管理もされます。
＃今回のお題で，最初，加工のオプションがあることで，このコンポジッ
＃ト構造も考えていました。
>最初のメールを出したときの意図は，以上の指摘を通じて，パワータイプという
>わかりづらい概念の説明も明らかになればよいな，と思っていたのでした．
>自然言語で「サービス」といった場合に，それば実体として何を指しているのか
>は結構微妙ですが，児玉さんは明らかにサービス種という意味で「サービス」ク
>ラスを使われているので，意味的にこのモデルはまったく間違っていません．
>というわけで，非常に簡単な，児玉さんにとってはたぶん当たり前のことで，単
>なる言葉遣いの違いだけなので，問題にされていなかったのだろうと思います．
はい，問題にしませんでした。
>次に，パワータイプについてです．
>(3)わたしはまず頭の中で
>・a1:このYシャツにドライクリーニングを実施する．
>・a2:このYシャツにクリーニングを実施する．
>・a3:このYシャツにサービスを実施する．
＜略＞
>の段階で，「クリーニング型」は元の「クリーニング」クラスよりもメタ階層が
>1段階上がったことになります．
ここでは，思考の順序が現物から始めたので，パワータイプが見え
たのでしょう。
>(4)以上のことを踏まえて，児玉さんのモデル中の「サービス」クラスは実はパ
>ワータイプに相当するのですよね，と最初のメールで質問したのでした．モデリ
>ング作業の結果として提示されている児玉さんのモデル中には，「サービス」ク
>ラスをパワータイプと考えた場合のベースクラスは含まれていません．ですから，
>厳密な意味では，児玉さんのいうように「サービス」クラスはパワータイプでは
>ない，といえるかとは思います．が，そのモデルに至る(3)で述べたようなプロ
>セスを想定すれば，個々のサービス実体を表わすクリーニングや加工をベースク
>ラスにとるパワータイプとしてクリーニング型や加工型が導入され，そのスーパー
>タイプとしてサービス型（これは児玉さんのモデルでは「サービス」クラス）を
>パワータイプと位置づけるのはごく自然なことなのではないかと考えたのです．
ここに来て，だんだん分かってきました。「サービス」は知識レベ
ルなのか，と聞かれればイエスと答えたはずです。「知識レベル」は
オブジェクトの性質のことを言っていますので。
パワータイプかと聞かれれば，ベースクラスがないので，そうでは
ないと答えます。
>(6)ただ一方で，インスタンスとタイプの区別はできるだけ人間の常識的な概念
>化階層にもとづいて定式化しておくべきではないでしょうか．
それも１つの方法でしょうが，私は分類学をやるつもりはありませ
ん。あまねく正しいオントロジーはあり得ない（あるかもしれないが
記述できない）ので，相対的にとらえたいです。実際，ドメインモデ
ルを層別化していくと，各層内で現物と知識が出てきます。
人間の知識自体がそうなっているのだと思います。人はUoDごとに
しかものが言えないと思います。
----
児玉公信
(株)エクサ SPBOMソリューションオーナー
兼 技術部
kiminobu-kodama@....jp kodamak@....org
児玉流メール道 家元