作成中の知識整理用システムであるSpiderの構造について、書いていきたいと思います。

ドキュメント類はJavadocしかない状態なので、これがマニュアルに準じたものになればいいなあ、と思っています。たぶん、明日には、この目標を忘れているんでしょうけど。

Spiderシステムは次のモジュールから構成されます。

• Spider : システムの中核
• Network : 知識ネットワーク
• Concept : 知識ネットワークを構成するオブジェクト
  • Knowledge : 文字列を表すオブジェクト
  • Link : オブジェクトとオブジェクトを関連づけるオブジェクト

情報は、多数のKnowledgeと、それらを結びつけるLinkによって構成されます。これはひとつのネットワークを形作り、それがNetworkに対応します。ネットワークを束ねるのがSpiderです。

Networkはひとつのデータベースに対応することが予定されています。つまり、Spiderは複数のデータベースに散らばった情報を統合するものでもあるのです（もちろん単独のNetwork、すなわちデータベースしか使わないこともできます）。

なぜこのような構造になっているのかを説明します。

まず、人の知識というものが、どのように表現できるか、というところが出発点です。ただ情報が散在しているだけでしょうか。それとも、階層構造になっているのでしょうか。どちらでもありません。たしかに、情報は断片として記憶されています。しかし、それぞれの情報は単独で意味をなすものではなく、他の情報と関連して意味をなします（例えば、「蜘蛛は縦糸を歩く」という知識はそれ単体で有用なものではなく「蜘蛛の横糸は粘着性があり縦糸にはない」という知識と関連することで意味の通るものとなる）。だからといって、あらゆる情報がなんらかの情報に包含されるという関係があるわけでもありません（仮にあるとすれば最も上にある概念は何になる？）。このような思考を経てたどり着いたのが、知識と知識が関連しあい、そこに上下関係などは必ずしも観念されないという、ネットワーク構造です。

Spiderは複数のNetworkを束ねるという役割を果たします。これによって、複数のNetworkをあたかも一つの大きなNetworkであるかのように扱うことができるようになります。しかし、べつに複数のNetworkを作らなくても、すべての要素をひとつのNetworkとして作り上げてしまえば済むようにも思われます。おそらく、そちらのほうが動作効率としてもいいでしょう。

Spiderが考えているのは、動的なNetworkと静的なNetworkの存在です。たとえば、学校で使う教科書を挙げてみます。教科書に書かれた内容は、すべての学生にとって同じものです。しかし、各人の教科書への書き込みや、細かな内容の取扱いは別々です。日本史が苦手な人は、日本の年表に「要チェック」のラベル付けをするでしょう。一方で、得意な人は「チェック不要」のラベル付けをするかもしれません。日本の年表は「静的なNetwork」、個々人の評価は「動的なNetwork」なのです。実際の運用では、教科書のデータを書き込み不可なデータベースに配置し、個々人のデータは読み書き可能なデータベースに配置することになると思われます。Spiderは、そのような事態に対応できるようにするため、複数のNetworkを束ねます。いまのところ、複雑な構造をサポートできるようにする必要性が感じられないので、フラットに束ねることしか考えていません。必要が出てくれば、さらに複雑な束ね方を検討することも考えられます。

Spiderに登場するモジュールは、これだけです。これらを複雑に組み合わせれば、難解な知識も表現できるものと期待しています。