研究ノート

メイルがスケジュール管理のためにつかわれていることは，よく知られている． Outlook などにはそれを支援するための機能がくみこまれている． しかし，このような機能は十分ではないし，標準化されていないのでメイラーをかえるとつかいつづけることができなくなる． メイル・ワークフローにおいては，より強固な基盤を確立する必要がある．

ひとりのひとが，すくなくともひとつの組織のメイルと個人のメイルとを管理する． 複数の組織に同時に属しているひともいて，そういうひとの数は今後さらに増加するとかんがえられる． 個人のメイルも 1 人だけの組織あるいは家族という組織へのメイルとかんがえれば，いずれも組織への多重帰属の問題だととらえることができる． こういう多重帰属がある状況のもとでメイル・システムやメイル・ワークフローがどうあるべきか，検討しておく必要がある．

ワークフロー・システムは集中型の構成のほうが容易に実現することができる． しかし，メイル・ワークフローはメイル・サーバとメイル・クライアントとのあいだにはいるプロキシによって実現されるため，分散型の構成をとることが必須である． データベースだけはプロキシから分離して集中型の構成にすることも可能だが，プロキシが分散型である以上はその利点がいかせる構成にすることが適当だとかんがえられる．

ひとつのメイル・ワークフローにかかわるメンバー (ひと) のメイル環境は完全にはあわせられないとかんがえるべきである． これは，メイル・クライアントについても，サーバやプロキシについても，いえることである． メイル・ワークフローはこうしたヘテロジニアスな環境のもとでも，ただしく動作しなければならない．

メイル・ワークフローにおいては宛先アドレスによって機能が指定される． このアドレスは機能だけでなく，その機能が存在する (仮想的な) 場所もあわせて指定しているとかんがえられる． すなわち，そのアドレスのドメイン部において指定された場所において，その機能が実現されるべきである． この原則を無視すると，アドレスと機能との対応がくずれて混乱がおこる可能性がある．

Wikitecture の各項目はつぎの要素をふくんでいるべきである: 名称，設計者，施工者，所在地，建設年，構造，建築面積，建物の写真・動画，説明等，掲示板． これらのうち説明等，掲示板，リンクをのぞくと言語によらず共通の項目にする (つまり，ひとつの言語で入力すれば他の言語に自動的に翻訳されるようにする) ことができるとかんがえられる．

項目やその要素の登録・更新の方法として，つぎのような方法を用意する必要がある．

Wikitecture におけるブラウズ機能として，つぎのようなものがかんがえられる．

Wikitecture の検索機能として，キーワード検索，地図検索，年代 (竣工年) 検索などがかんがえられる．

Wikitecture の項目からは広告や商品へのリンクをたどることができ，またそれらに関する画像がみられるようにするべきである． ただし，露骨な商業主義は wiki への悪影響があるとかんがえられるので，Wikitecture サイトじたいが商業サイトになるのはさけるべきであろう．

TownWiki (Wikitecture) はつぎのようなメタファでとらえることができる．

ベースとするべき Wiki ソフトウェアの調査をおこなっている． 調査の進展とともにこの項目の内容を更新する予定である．

TownWiki (Wikitecture) は，おおきくわければモノとコトとで構成される．

• 建築やそれに関連する店やグッズはモノであり，
• 建築に関するイベントはコトである．

モノとコトに対してはことなる表現や属性 (スキーマ) があたえられるべきである．

建築だけがもつ属性をデータ・スキーマにとりいれると，建築以外のものを表現するのが困難になって汎用性がうしなわれる． しかし，もともとの Wiki のようにいっさいの属性をとりいれないと，特徴がうしなわれる． 特定の属性に依存する検索機能は実現できなくなる． したがって，データ・スキーマの設計が TownWiki / Wikitecture のおおわくをきめる． しかも，いったんスキーマをきめてシステムを構築すると，あとからそれを変更するのは容易でない．

TownWiki は

• PC だけでなく
• 携帯からと
• テレビからも

また，携帯に対応するのはモバイル対応という意味もある． 実在のまちの情報をとりこんだ TownWiki はフィールド・アクセスによって，さらにいきる．

建築や店舗にかぎらず，動物やヒトもふくめたモノにはある期間のあいだ存在する． したがって，モノには通常，存在を開始した年と存在が終了する年とがある． ヒトであれば生年と没年である．

女性には地図が不得意なひとがおおいという． そのため，とくにナビゲーションの際にはつぎのような選択肢がかんがえられる．

TownWiki の各項目がふくむべき項目つまり名称，設計者，施工者，所在地，建設年，構造，建築面積，建物の写真・動画，説明等，掲示板，リンクのなかで，最後の 3 つ以外は自動翻訳が比較的容易であり，自然だとかんがえられる． したがって，TownWiki を多言語化し，これらの項目は各言語 / 各地域に共通にする，つまりいずれかひとつの言語で入力されたら他の言語に自動的に翻訳するようにすることがかんがえられる．

Amazon にはリストマニアという機能がある． それと同様な建築などのリストをつくる機能をいれるとよい． カテゴリーにわけることはできても，それだけでは建築をたばねる機能は十分でないからである．

PukiWiki のプラグイン機能を使用することによって，およそ要求仕様をみたすことができるとかんがえられる．