そのため、NetworkとSpiderは、特定の条件（SearchOption）を指定して検索できるようなメソッドを提供します。SearchOptionは用途に応じたサブクラスを提供しており、NetworkやSpiderは、指定された検索条件が実装するインターフェイスを調べることによって検索方法を判別します。これにより、Networkが現実に使用するデータベースの機能を用いるなどすることができ、アクセスの効率化が期待されます。

もっとも、現段階ではどのような検索条件が必要になるか明確ではないので、今後、具体的なアプリケーションを構築していくうえで問題が発生すれば、この仕様は変更されるかもしれません。

当初は、それぞれのNetworkが使用するデータベースとの接続オブジェクト（Connection）にはアクセスできないようにし、Network経由で接続を閉じるようなこともできないようにしようと考えていました。Networkがデータベース接続をラッピングするような役割を果たしているからです。Networkから実装側にアクセスできてしまうと、間違って接続を切断してしまうことも生じるのではないか、という不安もありました。

しかし、そのような方針では、アプリケーション側でConnectionを管理しなければなりません。すると、SpiderはNetworkを管理し、アプリケーションはConnectionを管理し、それらが整合するように調整する必要があります。これは手間ですし、バグを作り込む要因になってしまうので、Networkから実装側にアクセスする手段を提供することにしました。

Networkはインターフェイスですから、インスタンスを生成するためには実装クラスのコンストラクタを使う必要があります。しかし、それではアプリケーションとクラスライブラリが実装レベルで結びつくことになってしまい、仕様変更に強い設計になりません。そこで、Networkを構築するための情報として、NetworkSourceというインターフェイスと、NetworkFactoryというファクトリクラスを導入することにしました。

NetworkSourceはSerializableを拡張しており、シリアライズで永続化（保存）できることを想定しています。NetworkSourceのファクトリクラスも作れば完全に実装クラスとの結びつきを切断できるのですが、現段階ではファクトリのインターフェイスが定まっていないので、保留してあります。Networkのストレージとなるデータベースによって初期化に用いるパラメータが変わってくるので（例えばSQLiteではファイル名のみ、MySQLなどではデータベースのURLとユーザー名など）、そう簡単にはインターフェイス化できないのではないかと思っています。

ドキュメント類は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に登場するモジュールは、これだけです。これらを複雑に組み合わせれば、難解な知識も表現できるものと期待しています。