日時：2005年 6月30日(木) 18:30 から
場所：東京大学 大学院情報理工学系研究科創造情報学専攻（秋葉原拠点） 秋葉原ダイビル13階
アクセスはJR秋葉原駅電気街北口から目の前徒歩40秒でダイビルです. 迷うこ とは不可能だと思われます. そのほか, 地下鉄日比谷線秋葉原駅 (4分くらい), 同銀座線末広町駅徒歩5分, 都営新宿線岩本町駅徒歩6分, 2005年9月からつく ばエクスプレス秋葉原駅徒歩3分などとても便利です. 以下のページを参照して ください. 13Fまでエレベータで上れば, そこで迷ったらノーベル賞. だいたいその時間は 開放しておきますが, 閉まっていたら黒いインターホンを押してください. 〒101-0021 東京都千代田区外神田1-18-13 秋葉原ダイビル13F http://www.daibiru.co.jp/tokyo/akihabara/ http://www.i.u-tokyo.ac.jp/ci/ci.htm
話者：
松田一孝 （東京大学）
（共同研究者：大川徳之，野村芳明，森田直幸）
話題：
双方向変換を利用したファイルマネージャ
概要：
ショートカットなどのファイルに対する別名は，複数の場所で同一の ファイルを扱えるという利点がある．しかし一方で，別名を削除 しただけではファイル本体は削除されず，また別名を残したままファイル 本体を削除すると宙吊り参照となってしまうなど，特にコンピュータ 初心者にとってはわかりづらいものとなっている． データベースの世界では，実体であるデータに対してその見せかけで あるビューを設定し，その上でデータの編集を行う研究が行なわれて きた．近年のXMLの興隆から，木上の「双方向変換手法」と呼ばれる 特定のビュー変換言語を用い，編集の反映の際に 元データの情報も使用する手法の適用の研究も 行われるようになってきている． 本ファイルマネージャは，双方向変換手法を利用すること により，こうした別名を含めたファイルへの参照を抽象化して 対称的に扱うことができる．たとえば，双方向変換でファイル 参照を複製することにより，2つのファイル参照を同期することができる． さらに別名だけでなく，ソートなどのさまざまなディクレトリ木の 見せ方に関する機能をも双方向変換手法を利用することにより統一的 に扱うことができる．
出席者：33人
今村昌之，岩崎英哉，大日向大地，多田好克，滝田 裕，原 大輔，藤田昌平， 前澤直洋，間瀬哲也，丸山一貴，明神智之（電通大），小林弘明（元電通大）， 伊知地宏（ラムダ数教研），並木美太郎（農工大），村山慎也（富士重工業）， 安田絹子（SFC研究所），須崎有康，八木豊志樹（産総研），山口文彦（東京理科大）， 森岡靖太（東芝），福井眞吾（NEC），須賀 淳（芝浦工大），永松礼夫（神奈川大）， 荒川博志，王 浩，大川徳之，竹内郁雄，田中哲朗，塚本純一，松崎公紀，森田直幸， 横山大作，筧 一彦（東京大）
皆様どうもコメントありがとうございました． Q. 複数箇所で編集が起きるとどうなるか. A. 現在は，そのような場合を考えてはいませんが， マージできるものはマージすることになります． Q. 同時に編集が起きることが必要となるようなものに対しては対応ができない, ということですね. A. 現在においては，その通りです． 将来的には，分散システムなどを参考に， 解消できるものは解消を行うつもりです． Q. Wikiのような共有物で個人ごとのviewを作って, というような研究はあるか. A. 双方向変換については，私の知るかぎりありません． 双方向変換を含む分野であるView Updatingについては私のサーベイ不足でよく わかりません． ただDUPを用いることで，そのような複数のviewを抽象化することができます． Q. 効率は良いのか. A. 現在では，木のサイズ×変換の大きさ^2程度の時間オーダ がかかります．あまり効率が良いとは言えず今後の課題と させていただきます． Q. 様々な変換が基本的な変換の組合せで表現できるという証明はあるのか. A. ありません． 一般に変換の表現力を挙げるとビューがあまり編集できなくなります． Q. DUPとTOCの例とが繋がらないのだけれど... A. 説明が下手で申し訳ありませんでした． TOCの見出しは，本文の見出しと同じものであり， それらは複製(DUP)の関係にあります． Q. 「file directoryを使った神経衰弱」のように見える... Q. 新たにDUPのフォルダを作るのは手間が多くないか. Q. むしろshortcutよりも難しくなってしまっているのではないか... Q. propertyやannotationをつけて管理する方が楽に思えるのだが... A. 現在のものはベースとなる理論の応用のプロトタイプにすぎないものです． インタフェースはまだまだ議論の余地があるでしょう． Q. 他の言語での実装は? A. もう少し理論的な整理を行ったあとで考えます． Q. 消去はどうなるのか. 見えなくてもdisk spaceを必要としている, という ことになるのか. Q. Hideはどのような操作(変換)か. A. Hideはプロジェクションのようなものです． 「見え方」は複数定義されうるので， 現在の「見え方」で見えていなくてもファイルは存在しつづける ことになります． ファイルの消去はHideは異なるもので，実際のファイルを削除します． Q. 名前の変更は編集としてのみ可能か. A. 現在は実装していませんが，変換でも行えます． つまりファイル毎にその「見え方」特有の名前を付けることができます． Q. loopを作ることは可能か. 可能な場合, その状態での編集を行なうとどう なるか. そしてそのようなことをしても制約は保たれるか. A. 難しい問題であり，現在でもなおよくわかっていません． Q. 束(lattice)のようなものが作れたりするか. Q. /a/bと/b/aとが同じ実体を指す, というようなことは可能か. A. DUPによる同期により， DAGと等価な木構造が作成可能です． Q. 木構造を引きずり続ける理由は? 利用者からすると必ずしもその必要はない ような気がする... Q. 木構造の変換で嬉しいことは何か. Q. 木構造に皮をかぶせて再度木構造にしているように見える. バージョン管理 くらいまでしてほしい. A. 現在木構造を利用している理由は3つあります． 1) 木構造以上に複雑なデータの操作がよくわかっていないこと 2) 現在でもDAGのような構造は作成できること 3) 木構造は適度に複雑であること 木構造以外のデータも将来的には扱うことを目指しています． Q. 類似の「スマートフォルダ」でのDelの扱いは「消す」なのか「隠す」なのか. Q. MacOS XでのMac OS 9のファイルの扱い(同じファイル名があったりするらしい), というのとの関連はあるか. A. 私はMacを所有していないのでMacユーザの方に聞いてみようと思います． Q. ハードリンクそのものとはどう違うのか. A. 直接的な違いはDUPは木の任意のノードをDUPできるということです． また，変換はリンク作成の課程を構造化したものと捉えることができます． そのため， 1) 他の変換と相性がよく 2) 変換を切りかえることで様々な同期構造を実現できる(未実装) ことができるようになります． Q. 「ショートカットでのエラーメッセージが出てくるのがおかしい」というので あれば, 単にそのエラーメッセージが出てこないように隠せば良いだけでは. A. 「出てくる」のがおかしいのではなく 「出さなければならない状況」がおかしいと考えています． Q. 単にDUPだけあれば良いのか? A. 良くわかりません． DUPは，同期構造をあらわすものとして導入されましたが， 現在DUPがある場合の理論的取り扱いについてもよくわかっていない状況です． Q. "Real tree"と"virtual tree", "name space"(multics)について調べてみると 良いのではないか. A. 余裕があれば参考にしてみます． Q. IFを含むような例はあるか. A. たとえば，検索やフィルタリングなどがあります． Q. SQLでviewが実現する程度のものではないのか. A. 双方向変換は同じ分野の研究の構成的なアプローチです． ですので基本的に同じことの実現を目指しています． 今回双方向変換を用いたのは，構成的という性質から， view of view が簡単に作成できることため， 変換を追加していく「梅林」に都合がよかったためです． Q. 分野特定(domain specific)のアプリケーションとしては良いが, 「名前と パスだけ」というのが大切な世界だったりする一般的なファイルシステムに 対して今回の方法を適用するのは本当に成功するか. A. 正直なところ，よくわかりません． Q. 変換による表示を使うことで, 「所属研究室名」と「学年」といった本来直行して いる概念について希望に沿った表示を作れる, という説明があったが, 親子関係の 逆転はどうつくれるか. また, 学生データで年度変更の際に「M1」を「M2」にする だけで全て反映されるのか. A. 語弊がありましたが，双方向変換の能力的には作成できるということであり， 現在の基本として提供している変換の組み合わせでは簡単ではないでしょう． 後者に関しては， もともとの構造が，学年の下に所属研究室という構造になっているなど， 依存関係がなく冗長性がない場合そうなります． Q. 「もう 1回M1を」という学生がいた時はどうすれば良いか. A. うまく変換を記述することができれば，M1というディレクトリを 作成し，そこにその学生を移動することで対応できると思います． Q. Gmailのような検索を用いた振り分けとの比較は. A. 同じことができます． Q. ファイルのダウンロードを行ないファイル名を付け替える例を挙げていたが, ファイル名の付け替えを行なわない方が嬉しい時はどうなる? A. 質問の意図がよくわかりませんが，付け替える必要がない場合は 付け替えなければ何も問題はないのではないでしょうか？ Q. 下のレイヤと表示部分との変換, と考えると面白いのではないか. A. ご意見どうもありがとうございます．