考察：「知識ベース」

　

　軽薄短小な使い勝手の良いITシステムを実現するには知識ベースなものとなるでしょう。知識とは処理エンジン、処理手順データ、データそのものという固まりで考えるべきで、オブジェクト指向で捉えることが肝心です。そして、使い勝手の良さ、直感的に使えるもの、勉強しないでも使えることが命になります。どんなレベルの人でも作れ、使えるものでないと何時か重厚長大なシステムと化してしまいますから。

　

１．知識ベースシステムの構造

　知識ベースシステムはどんな風に作るべきか考えてみたいと思います。下図のようになるでしょうか。

　

　知識ベースフレームワークはパソコンみたいに汎用的で、入出力さえ設定すれば、どんな作業もこなすものというイメージです。そこに知識オブジェクトが格納されるわけです。パソコンにインストールするプログラムみたいなものですね。同じようにヘルプデータとか、制御データとかを知識オブジェクトはもって、実際にはメソッドを通じて知識ベースフレームワークとやりとりしていくのです。

　

　コマンドは基本的に、パターンマッチングとマッチングしたときに実行するアクションとして表現できるでしょう。エキスパートシステムですね。無論、手順になってもいい。パターンマッチングを基本とした簡略言語になっているべきです。

　ここで重要なことは、知識ベースがなんでも自分で実行すべきものと捉えるものでないことです。他のソフトウェア/システムに処理を依頼する制御文とかプログラム、時には使用上の注意（README.TXT)なんかを生成するだけのこともあってしかるべきです。

　コマンドのコーディングは基本的なものから、コーディングのパターンを記号として定義して、それの組み合わせでも知識としてのコードを作れることも使いやすさの視点から望ましいことです。

　

　知識ベースからダウンロードして個人的な知識ベースをつくったり、アップロードして共有化したりできることも重要でしょう。自分が求めている知識ベースがあるかどうかの検索機能も充実していて欲しいところです。

　操作はテキスト入力インターフェースとグラフィカルインターフェースの両方が必要になるはず。メソッドやコマンドデータなどを定義するのもコードを入力した方が簡単にできる人とグラフィカルな操作でないと駄目という人がいるはず。実際に操作させる中でコマンドを自動収集するというウィザード機能も欲しいですね。

　

　

２．パターン

　知識の基本はパターンでしょう。なんでもかでもパターンを作り、それを後から利用できるのが知識というものです。パターンは知識の枠組みを設定するし、動作・操作を分解して知識とする手がかりともなります。言葉の単語は一つのトークンですが、その意味するところはパターンでしょう。全てはパターンなのです。

　パターンは入れ子構造をしていますし、また組み合わさって上位のパターンにもなります。この入れ子構造の把握は大切です。部分のマッチングから全体のパターンを連想することは推論において重要な役割を演じます。

　

　たとえば、文章から知識を抜き出しデータベース化することを考えてみましょう。

（例文）「私はカモメ」

これを分かち書きして品詞を同定するのは簡単な処理です。

（分かち書き文）<ND>私</ND><XX>は</XX><ND>カモメ</ND>

　ここから意味を取り出します。パターンを使うのですね。

（パターン）ND(*)_XX(は)_ND(*)_## 　　→　　ND(#1#).IS_A.ND(#2#)

「第一の名詞は第二の名詞のことです」という意味

　

データベース化は次のエントリーを与えることになるのでしょうか。

　

　文章の厳密な意味解析をする必要のない場合には、自然言語処理としてパターン切り出しを主眼においた意味解析で事足りる感じがします。そんな厳密な解析を必要とはしないでしょうから。曖昧性を沢山持っていても良い。多分、表層な格解析ぐらいが求められるレベルかもと感じるわけです。曖昧性のバックアップは単語のプライミング機構を充実させることと考えます。次世代テキスト検索技術の主流はこんなパターン解析になるかもしれませんね。私は本格的な曖昧性解析をする自然言語処理を目指していますけれども。

　で、どうなんでしょう自然言語解析ではJavaとかのオブジェクトとして文書解析結果が得られるわけで、わざわざXMLテキストに落としてXMLデータベースに保存するというのもなんですね。処理時間からいうとオブジェクト指向データベースが欲しいかなとは思うのです。でも、WordとかExcelなどのビジネス文書はXMLデータベースで管理することになれば、自然言語解析後の文書もXMLデータベースで管理した方が有利かなとも思えたり。