随筆:「本を読んで2」

by ご近所のきよきよ



 時計の電池が切れて、久しぶりに街に出ました。日が射していて気持ちよい日でした。ついでだったので本屋さんに行きました。気に入った本があって、買ってしまいました。それは、

でした。

 帰ってきて一気に読んでしまいました。分かりやすい良い本です。セマンティックWebはデータ処理の技術で、Webアプリケーションのデータタイプの整合性を保持するのに使うサポート機能であるとのことでした。整合性を設立するためにオントロジーを用いるという。

 オントロジーを中心に考えればそうなのかなと気がついたのですが、セマンティックWebって、インターネットを高度なデータベースとして利用できるようにしようというのが本来の目的ではなかったでしょうか。文章検索の拡張として文章に明示された情報だけでなく、推論で意味を捕らえて、情報を作り込んで検索できるような、そういうこともできることが重要なのではないでしょうか。そういうのは当面は目指さないということでしょうか。


 でも、オントロジーを中心にしたWebアプリケーションも商機は大いにありますね。データベースサイトから情報を持ってくるとき、使っている記号を自システム用に変換しないといけませんが、その記号とか意味の変換をしてくれるサービスサイトがあると良いとは思いませんか。サービスサイトが持っているオントロジーを使うのであれば、サービスサイトを通して、データベースサイトをアクセスするだけでいいわけです。自分が用意したオントロジーを使いたい場合には、オントロジーをサービスサイトに登録して、そこを通してデータベースサイトをアクセスする。

 検索はプログラムからだけでなく、人手でSPARQLなどのコマンドを発しても良い。そんな方式ですね。問い合わせが自然言語でできるように、自然言語からSPARQLに変換するプログラムを作っていってもいい。これはサービスサイトが頑張ってやってもいい。


 なんにせよ、文章認識は当面セマンティックWebのフォーカスをはずれるので、香澄を開発する時間は十分にあるということですね。ところで、ついでに思い出したのですが、「管理データーはオリジナルデータが生成されるときに限定して作ることを許す」原則は大切ですね。人はものごとを何でも管理したいもののようです。しかし、工程管理を報告するためにのみ手作業で線表を作るなどはもってのほか。日々の作業員の作業進捗報告データのみが手作業であるべきです。あとは計算機がやってくれる。グループウェアの機能もそういう方向に持って行ってほしい。作業員の日々の報告データを集計して、他システムにデータを公開していく、グループウェアが手作業入力データの源泉という位置づけですね。管理データ作成に工数かけるなという原則です。

 オントロジー作成もこのグループウェア的発想発展、成長できるようなものになっていないと、挫折するでしょう。管理に工数がかかりすぎるということで。その工数は、主に生成時よりも改変時に発生するのです。

 昔、調度管理プログラムというのを紹介されたことがあります。机とかいす、パソコンなどの会社内の備品を管理しようというソフトウェアですね。「管理が好き」な人がつくった製品だとは想像がつきます。でも、「これ売れないな」というのもすぐに想像ができました。椅子を買ったときにこのプログラムに登録するのはいいとして、椅子をほかの課とか、工場へ移管したら、その都度思い出して、このプログラムに登録変更をしなくてはなりません。たぶんそんなこと、地球上のだれもできない作業だと思います。

 で、机にバーコードをつけて、年に1度棚卸しの時、バーコードを読む作業をして、あとは計算機の調停に任せるという方式にすれば、この調度管理プログラムは生きてくるでしょうね、というのは今思いついたところです。オントロジーもセマンティックWebも運用に知恵を働かせるべき対象だということです。


 

 ついでに、また思い出しました。プログラムは作ることよりもメンテナンスに難しい問題があるということです。ここを誤解している人が多い。プログラムを組むのが面倒だという思いこみ。実はプログラムを作るのは本を読める人ならだれでもできるのです。苦痛でもない。実際ずぶの素人からAccessのデータベースアクセスプログラムを作った御仁を何人もしっています。

 それと平行して、社内ツールを何度も使わせられた苦い経験があります。手続きにはこのソフトで入力しないといけないという。プログラム完成テストしかり、外注費要求しかり、バグ報告しかり。だが、そのソフトたちが簡単に動いた試しがない。使い方も難しいというか、マニュアルにない情報があって、それは開発者に聞かないといけない。紙で手書きで書類作った方がどれだけ工数がかからないことか。

 こういう社内ツールはマニュアル不備とか仕様不備も多くて困りものなのですが、さらに長い期間の内に、動作環境が変化することから問題が発生します。ネットワークが変更になったとか、パソコンが古くなって、新しいのに移行して、マシン名が変わったなんてことは茶飯事です。そうゆうことがあるとまともに動かなくなる。さらに、新しい環境に移行するとき、今までのツールが落ちてしまって、使えなくなるということもあります。そんなとき、古い作業マニュアルみて、そのソフトを探しても見つからない、動かないということになります。マニュアルの整合性の問題という、深刻な問題に直面します。

 オントロジーもどうメンテナンスしていくか、していくべきか、メンテナンスソフトが必要になるでしょうね。それはグループウェアなのでしょうか。




 それと、フリーソフトで音声認識システムを作れるということで、次の本を注文で取り寄せました。

これも分かりやすくてためになる良い本でした。で、一つ考えたことがあります。探索候補数の爆発です。音声認識を途中で刈り込みしないで順次パターンを時系列で解析していくと、曖昧性の分岐が組み合わせ論的に増加して物理的に対処不可能になるという。でも、これって、解析パスを細かく分断しておき、その分断点から解析を順次平行に行っていくと組み合わせ爆発を押さえられるのです。

 まず組み合わせを行わないといけない部分を小さく押さえて、代わりに解析開始点をふやしていくと、分断点で整合性の評価をしていくことができますので、全体での組み合わせを刈り込むことができるというわけです。こうゆう技術ってどうでしょう。未夢も結構この点を工夫して、組み合わせとなることをさけています。データを木構造に組み合わせるのをさけて、複数選択肢を持ったノードの時系列として管理して、その中にデフォルト選択のパスを通して処理が進展するようにしています。デフォルト値の選択はまだ完全でなく、苦労していますが、これからの研究テーマとして(評価系)楽しみな分野となっています。

 もう少し、具体的に説明しましょう。音声認識では例がありませんから、日本語処理で考えてみます。

(例文)

  1. 花子は祐二が好きだ。
  2. 祐二は花子にバラを贈った。

 (1)は「花子は祐二のことをすき」と「祐二は花子のことがすき」という2つの選択肢があるので、(1)(2)と文章が続くと曖昧性が組み合わせで増えていくことになります。しかし、(2)を(1)と独立に平行して解析すれば、祐二が花子に好意を持っていることが推論できますから、(1)の曖昧性は(2)の情報から捨て去ることができるわけです。




 今回は久しぶりに読んだ本から発想したことを述べてきました。寒さもあと1ヶ月。頑張りましょう。



 

おわり