この問題を解決した一例としては、Mac OS X TigerのUTI(Uniform Type Identifiers)がある。 (Appleは、この識別機構を導入することで、仮想フォルダやメタ検索を実現している) http://ars2.sjc.cachefly.net/images/tiger/utitree.png(UTIの階層構造)
2. id3やらのタグつき音楽ファイルがごちゃごちゃに入っている実行可能ディレクトリ music について、 music にアクセスするとタグデータをもとにartists ディレクトリなどが動的にできていて、 (タグつきとはいえ)ごちゃごちゃに入れているだけで、どんなソフトからでも整理されたディレクトリとして利用できる。
3. ~/dirscript/find という実行可能ディレクトリを作っておいて、 ls ~/dirscript/find/*.jpg で、ホームディレクトリやサブフォルダ内の*.jpgを全て表示
TREE構造のファイル管理は限界 (スコア:2, 興味深い)
さて、次世代のファイルシステムはどのようになるのだろうか?
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
PicasaやGmailにはフォルダで分類するという概念はなくて、写真やスレッドにいくつもラベルを付けるだけ。ラベルで済まない部分は、強力な検索アルゴリズムでかたづけるわけです。ネット上のリソースも、デスクトップ上のデータも、すべて同じことがあてはまります。
分類下手な自分は、Treeに分類するというのがそもそも人間の本質に合ってなくて、アイテムにキーワードをいくつか付けて、そのセットで目的のアイテムを探せばいいというアイデアは昔から持ってました。で、Googleが具現化しちゃったわけですが。
Re:TREE構造のファイル管理は限界 (スコア:3, 興味深い)
tree形式の方がまぁどうにかなっていい、と思っているのですが。
ラベルを作った所で、ラベルの付け方が大まかすぎたら同じラベルのファイルたちが溢れることになりますし、
逆に細かすぎたらラベルが溢れて、ラベルのツリー構造orラベルのラベルが必要になって
結果的にtree形式と変わらなくなります。
人からファイルをもらうときにラベルの付け方が違ったときも厄介です。
それに比べてtree形式なら、ごちゃごちゃはするけど、もらったディレクトリをそのまま入れちゃえるので楽です。
ラベルとtreeの併用については反対しませんが、現段階ではラベルはtreeに変わる程のものではないかと。
1を聞いて0を知れ!
Re:TREE構造のファイル管理は限界 (スコア:1)
ファイル名がキーワードだと思えばいいでしょう。例えば「6月29日○○の議事録」ってファイルを作るとすれば、検索するときもそれをキーに探せばいいのです、たぶんね。ファイル名忘れても、参加していた人の名前とか、おおよその話題を検索システムに聞けば、それっぽいファイルをリストしてくれるはず。
あるいは「写真」フォルダとか「mp3」フォルダも「.jpg」とか「.mp3」で検索すればいいし。
超整理法(Re:TREE構造のファイル管理は限界) (スコア:1)
ということで、ディレクトリは切らずに全部一箇所に……というのは嘘で、OA系で使うファイルはほとんどがMicrosoft Officeのファイルなので、見つからないときはOutlookの履歴機能で探してます。
Re:TREE構造のファイル管理は限界 (スコア:0)
ファイル(やファイルへのショートカットやWebブックマーク)は、出来るだけフラットに管理してます。
そしてファイル名に「そのファイルの、自分にとってのキーワード」を、ファイル名の後ろに追記しておいてます。
あとで自分の心の中のキーワード候補を適当に入力してファイル名検索すると、大抵ヒットします。
あとショートカットやブックマーク(をファイルにばらしたもの)は、それ自体がファイルとして「日付」情報を持っていますが、これが重宝します。
というのは、自分がそれに触った日時で「ソート」できるので。
こ
Re:TREE構造のファイル管理は限界 (スコア:1)
検索の技術を応用できそうなものなのに。
Re:TREE構造のファイル管理は限界 (スコア:0)
>検索の技術を応用できそうなものなのに。
それをどう見せ、どう操作させるかって考えた時、通常のファイラー以上の物が考え付いていないだけでないかと。
理想を持って機能を詰め込むのは簡単ですが、ファイラーみたいに普段使いで邪魔にならずそれで居て便利に、ってなると難しいですよ。
今作っても精々が自社サービスを纏めたもんにしかならんのでしょうね。
Re:TREE構造のファイル管理は限界 (スコア:1)
ファンなので残念ですが、きっとマイナーなのでしょう
#Picasa,Gmail,iTuneよりも早く公開されていたと思いましたが。
Re:TREE構造のファイル管理は限界 (スコア:1)
Operaと一緒で便利なんだけど、結局の所おまけなのでしょうか。
Re:TREE構造のファイル管理は限界 (スコア:1, 興味深い)
#とてもまだmだ検索ベースで管理できる状態で思っているのでAC
Re:TREE構造のファイル管理は限界 (スコア:1, 興味深い)
データ(特にブログ)の激増に精度が追いつかないような。
ブログのアクセスログ見てると、見当違いなキーワードでやってきたり、肝心の(と思える)ページにたどり着けなかったらしい人結構いてるような気がする。
Re:TREE構造のファイル管理は限界 (スコア:1)
ちゃんと満足度が高いからgoogleのシェアが高いのか、
しょうがなくgoogleの人が多いのでシェアが高いのか。
ネイティブじゃないどころか、
辞書片手に文章解読が精一杯の私からすると、
その辺りを推し量り様がありません。
分かち書き有無の関係で、検索方法やスタンス自体が違う可能性もありますね。
=-=-= The Inelegance(無粋な人) =-=-=
Re:TREE構造のファイル管理は限界 (スコア:0)
「色んな話題のページをごたまぜに表示する」というHTMLに対して
馬鹿正直に検索インデックスを作ってるせいじゃないかと思います。
話題別(そういう設定が出来るBLOGエンジンは多いですよね)に表示してるページ「だけ」をインデックス対象にしてくれたら、解決するんじゃないかと思います。
あるいは1エントリづつのバラバラのページ(パーマリンク?)とかね。
TOPページとか日付順ページとかでは
METAタグのNOINDEXをつけておくといいんじゃないかな。
一方でNOFOLLOWはつけない。
つまり、そのページ自体はINDEX化しないでおいてもらい、そこからリン
Re:TREE構造のファイル管理は限界 (スコア:1)
Re:TREE構造のファイル管理は限界 (スコア:1)
確かにこういった感じの方が直感的で解りやすいですね。
#これが普及したらしたで、各タグの利用数を調べる
#スパイウェアも一緒に普及しそう
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
何時まで経ってもTREE構造から脱皮できないのでは?(拡張子やタイプ/クリエータコード、MIMEタイプの限界)
この問題を解決した一例としては、Mac OS X TigerのUTI(Uniform Type Identifiers)がある。
(Appleは、この識別機構を導入することで、仮想フォルダやメタ検索を実現している)
http://ars2.sjc.cachefly.net/images/tiger/utitree.png(UTIの階層構造)
・ユニークさ:全く新しいデータ分類機構であるUTIは、過去の過ちに拘束される
ことはない。個別のUTIはユニークであるように定義され、そのユニークさが
持続的に維持されるよう保障するシステムも備えている。
・表現力と可読性の高さ:UTIには文字列長の制限はなく、人間が読むことを想定
した平文記述も付随している(この記述は多言語ローカライズも可能である)。
・拡張性の高さ:UTIでは、管理団体(この場合はApple)の承認作業を受けると
受けないとに関わらず、新たなタイプを容易かつ安全に追加できる、十全に定義された
体系をサポートしている。
・分類上の正確さ:何らかのデータタイプ(たとえば「全ての画像」)を選択すれば、
ベンダ依存のUTIや臨時のUTIなども漏らさずに、そのデータタイプに属する対象
すべてをちゃんと捕捉できる。
・public.dataは、UTI木構造の最上位とか、唯一のルート階層とかでは全くなく、
他のUTIを継承しないUTIは、事実上すべてルートだとみなすことができる。
・個別のUTIの表現上の階層構造を、さまざまなUTI同士の実態的な階層構造から切り離している。
・UTIは複数の親UTIを多重継承することもできる。
・各UTIは他のUTIを「継承」あるいは「従属」できる。
Winでも、こういったシステムの「底辺部分」から、抜本的な改革が必要とされていて、
上辺だけ弄ったところで解決しない問題なのではないだろうか。
参照記事
http://arstechnica.com/reviews/os/macosx-10.4.ars/11
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
確かにTREE構造では対応しきれない物は多いけれど, かと言ってTREE構造に変わる汎用的な構造が無いってのが一番の問題でしょう.
例えば汎用性だけを取ってみれば, 最近のリレーショナルデータベースの様にフラットな表形式でのメタデータ管理ってのも有りだと思います. しかしユーザとしてはこれにどのような形でどんなメタデータを格納しなければならないか設計する必要が出てくるわけで, これが利用する上での大きな障害になることは明らかです. 要はエンドユーザにデータベースを設計させようってことですから.
となると, 最大公約数的には古来コンピュータとか関係なしに情報分類の構造として使われてきたTREE構造のみをエンドユーザ向けの標準的なファイルシステムとして提供する, って判断は, 間違っていないとは言えないまでも, 十分に納得はできるんですよね.
Re:TREE構造のファイル管理は限界 (スコア:1, おもしろおかしい)
#あまりにもネタなのでAC
Re:TREE構造のファイル管理は限界 (スコア:1)
Re:TREE構造のファイル管理は限界 (スコア:1)
「ラフォーレ構造」や「ウッズ構造」はダメですか。
というか、「Forest構造」ってアクチブディレクトリで聞いたような。
Re:TREE構造のファイル管理は限界 (スコア:1)
エクスプローラと、そのフォルダツリーによる情報管理はマジ限界です。
仕事のドキュメントとかナレッジとか、○○案件の設計資料としてカテゴライズしたい、でもWindowsServer2003の技術資料としてもカテゴライズしたい!
という要求に応えてくれるのがWinFS(メタタグ+仮想フォルダ)だと思っていたのですが…。
う~む残念。
他の人はこういうときどうしてるんだろう。マジでハードリンク?
で、結局LotusNotesを相変わらず使い続けている私。
だってカテゴリを複数付けられるんだもん。
-- sun burst.
Re:TREE構造のファイル管理は限界 (スコア:1)
ファイル検索で引っ張り出すことが増えました。
Windowsさんはある程度探してくれるので良いのですが。
リアルデスクトップは検索機能がついてないので少々困ってます。
「なんとかインチキできんのか?」
Re:TREE構造のファイル管理は限界 (スコア:0)
>仕事のドキュメントとかナレッジとか、○○案件の設計資料としてカテゴライズしたい、でもWindowsServer2003の技術資料としてもカテゴライズしたい!
>という要求に応えてくれるのがWinFS(メタタグ+仮想フォルダ)だと思っていたのですが…。
そして、誰もメタタグを付けないので、HDの中身がカオスに・・・・。頭のなかで、これはAカテゴリであり、Bカテゴリでもあると認識しても、わざわざメタタグを付ける手間を継続的にかけられるか?
Re:TREE構造のファイル管理は限界 (スコア:0)
その手間をなるべく軽くするために, メタタグの付いた仮想フルダを作ってその中にファイルを放り込むのでは?
Re:TREE構造のファイル管理は限界 (スコア:1)
ああ、「振り分け」をするから「フルダ」なんですね。
Re:TREE構造のファイル管理は限界 (スコア:1)
# 今年のオールスターはセリーグ4球団の監督がそろうのかな。
Re:TREE構造のファイル管理は限界 (スコア:0)
Mac OS XのSpotlightの機能の一つであるスマートフォルダは、これを実現したものです。
例えば2週間以内にアクセスしたことのあるファイルが入っているフォルダとか作れます。
ただ、自分でタグ付けするわけではないので、ゴミも入ってきてしまいます。検索キーの選び方で減らせますが。。
#マカーの独り言なのでAAC
Re:TREE構造のファイル管理は限界 (スコア:1)
ディレクトリをスクリプトか何かでプログラム可能、実行可能な形式にして、
ディレクトリへのアクセス=ディレクトリの実行とするとどうなるのかなぁ、と。
Windows系の話題としては例が不適切だったりしますが、例えば、
1. LinuxなどでのRPM管理のとき、
/usr/share/rpm という実行可能ディレクトリを作っておいて、
アクセス時に動的に
/usr/share/rpm/installed
/usr/share/rpm/available
などのディレクトリを作り出す。
それらのディレクトリも実行可能ディレクトリとなっていて、
アクセス時に生成したり、ネットからダウンロードしたりできる。
2. id3やらのタグつき音楽ファイルがごちゃごちゃに入っている実行可能ディレクトリ music について、
music にアクセスするとタグデータをもとにartists ディレクトリなどが動的にできていて、
(タグつきとはいえ)ごちゃごちゃに入れているだけで、どんなソフトからでも整理されたディレクトリとして利用できる。
3. ~/dirscript/find という実行可能ディレクトリを作っておいて、
ls ~/dirscript/find/*.jpg で、ホームディレクトリやサブフォルダ内の*.jpgを全て表示
こんな感じです。
1を聞いて0を知れ!
Re:TREE構造のファイル管理は限界 (スコア:2, 興味深い)
ディレクトリに「見せる」という点ではCGIはそのアイデアを一般的に使っています。もっともそれはHTTPで見えるだけであってローカルでマウントできるわけではないですけど。
Re:TREE構造のファイル管理は限界 (スコア:1)
Re:TREE構造のファイル管理は限界 (スコア:1)
早速 iTunes と組み合わせて実装してみようかと思ったけど、 OSX には FUSE が無いですね……
Re:TREE構造のファイル管理は限界 (スコア:1)
ただ、FUSEのRubyバインディングのような便利なライブラリが無いと実装はやっかいかもしれません。
WevDAVで仮想ファイルシステムを書く簡単なライブラリ無いですかね?
Re:TREE構造のファイル管理は限界 (スコア:1)
みんな一度はこういうこと考えたりするんですかねぇ。
1を聞いて0を知れ!
Re:TREE構造のファイル管理は限界 (スコア:0)
Re:TREE構造のファイル管理は限界 (スコア:0)
さて、次世代のブックマークシステムはどのようになるのだろうか?
# わたしの能力では、ファイル管理どころか
# ウェブ・ブラウザのブックマーク管理がすでに破綻しています。
# Firefox に Places が来たら整理しようと思ってたのだけど、
# 3.0 に持ち越されてしまいました。残念。