ウィンドウズのファイルはフォルダーで区切られていて、favoriteという名前のフォルダーがそのままIEのお気に入りになっています。なので、お気に入りはフォルダごとに整理することになると思います。

　皆さんも、ジャンルごとにフォルダを作り、お気に入りを振り分けていると思います。この構成は名前の衝突が起こり得ないので、ファイルの管理には最適なのでしょう。

　しかし、お気に入りの管理にもそれがそのまま当てはまるのでしょうか。例えばあるお気に入りが複数のジャンルに当てはまるとします。そうすると、検索性を良くする為には、その複数のフォルダに同じ内容のお気に入りを作ることになります。僕はそれに強い違和感を感じます。無駄が多いと思いませんか？もう一度お気に入りを整理しようとしても、同じ内容のお気に入りがいくつもあって煩雑です。

　僕は以前から、漠然とではありますが、この違和感を解消して形にしたいと考えています。ちょっと考えを整理してみようと思います。以下、お気に入りを”.URLファイル”と書きます。

【案.1】

URLとタイトルをリストに列挙する。そこにタグを付けて検索に利用する。一つのURLとタイトルの組み合わせには複数のタグを付けられることにする。

・問題点

IEのお気に入りとの互換性が無い。効果的な相互変換も難しい。ツリー構造の、目的の.URLファイルを段階的に絞り込んでいけるという長所がない。いや、AND検索で絞り込んでいける。それでも案.2のようなUIも併用する必要があるかも。

【案.2】

.URLファイルの中身がINI形式であることを利用して、既存の.URLファイルにタグを埋め込む。これをツリー形式で画面に出力して検索に利用する。フォルダに対応したノードを作り、フォルダ内のフォルダや.URLファイルを子ノードとして追加していくのは通常のお気に入りと同じ。.URLファイル内にタグが見付かると、そのタグと同名のノードの子ノードとして追加する。同名のノードが無ければ新たにタグ名のノードを作り、その子として追加していく。

・問題点

INI形式に従ってタグを付加しようとすると、タグは一つ、または決まった個数以下の数しか付けられない。既存の.URLファイルを加工するのは精神衛生上良くない。実際に出力されたツリーはかえって複雑にならないか。実際にツリーを生成しようとすると無限ループになったりして。あ、フォルダ名とタグ名に優先順位を付ければループにはならないか。実際に保存されている状態とツリーとして出力されている様子が違うと、かえって管理がしにくくならないか。直感的でない。全ての.URLファイルの内容を読み込まないとならないのでツリーの生成に時間がかかるかも。

【案.3】

INI形式の制限を取り除くために、中身をXMLにしたお気に入りの形式をでっち上げる。

・問題点

案.2と殆ど同じ。

【案.4】

そんなこと気にしているのは僕だけだろうから、諦めて忘れる。

・問題点

無し。

なんかとんでもなく難しい悩みを作ってしまった気がします。