WiLiKi:TreeModel
WiLiKi:WishListの次の書き込みに端を発する議論。
- anon (2003/06/05 07:22:08 PDT): ページ間の親子/兄弟関係を表示する機能が欲しいです.
Wikiのページ群の見せかた
- Shiro (2003/06/05 17:55:17 PDT): Wikiのページ群は自由な有向ネットワークを作るので、
親子/兄弟という関係はそもそも無いです。情報を整理するには、
今のところ名前付けを工夫して$$indexマクロを使うしかないです。
機能を追加するとしたら、ページ属性にページ関係を持たせておいて、
マクロでナビゲーションリンクを表示する、というような方向になるかと。
- anon (2003/06/05 22:37:22 PDT): ページ間の関係がフラットなのは分かっています.問題は,ページを整理しようと考えたときにツリーしか思い浮かばなかった私の発想の貧困さですね.イメージはRWiki:mapでした.
- shelarcy (2003/06/05 23:13:26 PDT): 昔のハイパーテクストシステムの話を聞くとブラウザ兼エディタレベルでグラフ構造をサポートしていたというのが非常にうらやましく思えますが、Wiki上のみならともかく、Web全体でやろうとすると、どこにデータを蓄えて引き出すかが最大の難問。(という話をVidさんところでリファラーとトラックバックに関する考察が繰り広げられていたときのネタにしようと思っていたのですが……)
- Shiro (2003/06/06 01:27:08 PDT): なるほど>RWiki:map。
実際、データ設計の方から見ると自由なネットワークは柔軟性があって良いのですが、
「何でもあり」にしてしまうと人間の方がついていけない、ということは良く
ありますね。メンタルモデルにうまくマップできない、というか。
階層型ファイルシステムが、数々の制限にもかかわらず根強く残っているのは、
互換性や効率の問題以外に、ユーザの意識もあると思います。
以前、完全ネットワーク型のOODBにしようとしてうまくいかなかった経験があるので。
ネットワーク構造と人間の認識
- Makoto (2003/06/06 01:51:25 PDT): 余談ですけど、Ruby本か何かでRubyが多重継承を採用しなかったのは、ネットワーク型のクラス構成は人間の頭で追いかけるには複雑過ぎるから、と書いてあったと思います。Rubyは単一継承とMix-inを採用し、クラス階層はツリー型になるようにしたと。それと同じようなことですかね? 人間が直感的に把握できる形態というか。
- Shiro (2003/06/06 02:09:17 PDT): 似たようなことかもしれません。
CLOSでも、基本のクラス構成はツリーにしておいて、必要に応じてmixinクラスを
使うというスタイルが良いとされています。運用で無秩序を回避しているわけですな。
- 戯 2003/06/06 09:00:53 PDT RWiki:mapみたいなのはアルゴリズムはどうしてるんでしょね?というか何れにせよ恣意的に1つのアルゴリズムを選ばざるを得ないっすよね。ならば、ちょっとヒイてしまいます。ほげデータ構造のパラドックスとか言ってみるテスト。そろそろツリーは嫌だな。
- rubyのmix-inは(単なる)Treeとは違いますよね。Moduleのincludeは、Classに対してModuleをCopyOnWrite(?)してるわけで。C++だってClass継承を例えば「循環」させることは出来ないんだし。
- というか、継承は元々Tree+α構造が出発点で、WikiはNetworkが出発点だと思う。Wikiを議論する際にOOP継承を引き合いに出すと、おかしな話になる予感。もともとNetwork構造を捨てたいという意図をもって議論するなら話は別だけど。
- Tikiには名前空間なる概念がありますね。WikiNameを"/"で区切れる。実質的にはC++の"."に近い概念。これならWriterが明示的に階層を仕込みたい時以外は、階層の「解釈」は読者の自由に委ねられる。
- 結局は、解釈の恣意性を喜ぶか嫌うかの問題に帰着しそうな予感。
- ちなみに俺はNetwork構造のヘッドレス(?)感覚が好きです。まさに「辞書の中を彷徨う」感覚で、しかも興が乗ったらWriteも出来るという幸せ!! -戯
- 型クラスや C++ の Template は同じカテゴリーに属することを示し、ステレオタイプからの違いを記述するので、プロトタイプ論という認知のアプローチに近いという風に言っていいでしょうか? C++ では policy のイディオムがこの好例だと思います。 - shelarcy
- Shiro: 多重継承はDirected Acyclic Graph(DAG)。それだと複雑すぎるからと制限をきつくしたのがTree。木構造vsネットワーク構造という文脈ではDAGもNetworkに含まれるんじゃないかな。Wikiはacyclicでさえない、Directed Graphですね。
- shelarcy (2003/06/06 10:27:31 PDT): Tree で考える方がやりやすいというのは、社会的に Tree で考える事が染み渡っているためと、同じように染み渡っている古典的カテゴリー論による論理が Tree モデルだとすっきり扱えるに過ぎないからだと思いますが……
- Tree モデルの最大の欠点は人あるいはコミュニティのレベルで認識の差が大きくなってしまうこと。
- 理想的には関連、異見など個々のコンテンツの対応関係がある程度便利に示せるといい。もっとも、これでも主観が入ることは避けられませんが……
- Network 構造は Graphical に利用できてこそ強みを発揮できるはずです。先に挙げた昔のハイパーテクストシステムでは確かグラフのノードが編集できたはず…… 関連:WikiWikiWeb:VisualizeTheWiki
- (2003/06/09 19:29:53 PDT): 忘れてました。これも関連として示さないとまずいですね。LeafWiki、HashedWiki - shelarcy
- (2003/06/09 21:23:01 PDT): ページをパラグラフのTreeとして見せるStickyWikiやTumikiというのもあります。--SHIMADA
ネットワークの見せかた
- Shiro (2003/06/06 21:53:21 PDT): 「Network構造はGraphicalに利用できてこそ」というのは
そうなんですが、scalableに作るのは難しい。
フラットなグラフエディタだとノード数が数千とかになると把握できないですし。
Treeの強みは、要らない枝を畳んでおけることですね。
- shelarcy (2003/06/07 03:33:00 PDT): Network の関係を明らかにする場合、「ノード間リンクの密な集まり(クラスター)と、リンクの密集している所(ハブ)と、クラスター間のリンク」が分かるので、それらを押さえてあとはできるだけ短い段階でカットするというアプローチで、ある程度すっきり見せることができると思います。問題はクラスターそのものが非常に巨大になったときですが……
- (2003/06/07 14:48:08 PDT) 補足: ハブとクラスターのアプローチでよく参照される文書と相互関係の深い文書が図示できるわけですが、これをそのまま使うか、何らかの方法で関係性の重みづけを行い、それを示すかということは考えてもいいと思います。
- 例えば、軽い参照なら1、リンク先を読んでおいて欲しいなら2、文書に関わっている人の多数が重要度が高いと考えるなら3、という具合に。もちろん、変更可能にしておく必要があります。
- 戯 2003/06/07 09:05:38 PDT Wikiって元々、Graphを畳み(?)まくって、あるNODEからしか見えないようにしたものが、各頁ですよね。
- 全部をいっぺんに広げて見ようってのはしばしば無謀ですが、ある頁の近傍を表示するってのは欲しいかも。
- でもそれって、頁内に他の頁への参照(WikiName)が書かれているという従来からある状況と、なんら変わらないなあ。
- すぐ隣を表示するだけじゃなく、nホップ隣までを表示するみたいな仕組みがあると、どうだろうか?
- 戯 2003/06/07 22:32:48 PDT Treeに変換しなければいいのかも。頁間のリンク関係だけを一括getする手段が有ればいいのかも。
ただし手元にそれを解析&表示&NavigateするToolが別途必要そうですが。それって無限次元の中をWalkThruする(ことでGraphを「見せる」)Toolになるのかな?
Wikiページ間の関係
- 戯 2003/06/07 09:05:38 PDT お馴染みWikiNameはNODE自体の名を参照する為の仕組みですが、一方で、Objectのメンバ変数と同じように、あるNODEから見ての他のNODEの「相対的立場」を記述するWikiName(と呼んで良いかどうか疑問だが)を設ける、ってのはどうだろう?
- 節じゃなく枝の名を書くわけね。当然、同じ名が同じ意味になる事が保証されるのは、同一の頁からその枝が伸びてる場合に限る。
- ある頁と、その頁「への反論」頁とか、その頁「の後日談」頁とか。
- 指された頁が、その指され名とは別に、自前の名前をも持っていてもいい、かも。
- Graphと言われて思い出したんです。そういや「Graph計算ソフト」はどうしたんだ?>俺(ぉ
- で、(全ての)頁は、別のどの頁から何という枝名で参照されてるか?を知る手段が要るだろうなあ。
- shelarcy: あまり色々とできすぎるのも考えもの。そうした関係性に対する考えはどうやっても一致しませんし……「後日談」は wiki なのだから直接書いてしまえばいいような気がします。同様、異見、対立などの2〜4ぐらいのシンプルな関係に絞るべきだと思います。
- 戯 2003/06/07 22:41:05 PDT 某OODBシステムが、Objectの間のRelationをもObject(Class)として自作出来る系でして、これが痛快。関連の仕方をばんばん分類できるのは快感です。EndUserが直接Objectを触れるシステムです。Relationもね。何と何が何繋がりで繋がってるのかをばんばんNavigate&編集出来る。つまり分類可能な繋がりというMeta仕組みを持っているわけ。そんな世界を既に経験してると、半端に数通りの選択肢が有るだけの系は…。いっそ分けないほうがいいなぁと思う。
- shelarcy (2003/06/08 02:19:31 PDT): それをやるのが RDF や XTM(XML Topic Maps) などで文書の外側にメタデータを付与する Semantic Web だったと思うんですけど……。
- (2003/06/10 05:18:39 PDT) 補足: あんまり細かくしすぎると、どうしても個人向けのものになってしまいます。Semantic Web の構想は、個人個人にとって見える Web の姿が違ったものになってしまう可能性があるという問題点を孕んでしまっています。
グラフ表現は遅いUIの代用?
- 戯 2003/06/07 09:05:38 PDT 大昔に大学の先生(俺が受講してた人じゃないが:てか俺は情報系じゃないんで)に「計算機のUIに一番大事なのは速度です」と言われたもんだった(笑)けど、webという媒体の遅さが人にストレスを与えているのかも。
- ClickしてWikiName間を飛び回る時のPage表示が劇的に高速だったら、紙の本を手にしてるのと同じ(しかも頁数という概念が無限次元に拡張されてる(笑)という便利さ)くらいの楽さで、人は接せられるのかも。
- 現状でそれが無理だから、mapという代替物を欲しくなるのかも。
- 参照回数が更新頻度よりも十分大きいなら、静的な頁も生成するといいのでは。
(今の実装だと毎回DBにアクセスして、文法解析してるんですよね?) Y.Hana
- 戯 2003/06/07 22:32:48 PDT あっと。通信の遅さの問題も有りますんで。AirH"とか(藁)。鯖処理がBottleNeckとは限らないです。
- shelarcy (2003/06/08 15:17:30 PDT):あたりまえのことですが、ページの大きさが問題になることもありますが、かといってあまりに小分けにされすぎると(クリック数が増えるのもあって)文書を一貫して読もうとするときの障壁になる、という問題も忘れてはいけません。
- shelarcy (2003/06/07 21:05:43 PDT): そんなことを言う人には富豪的プログラミングで反撃。
- 参照の速度を増やすよりも、どうやって目的の情報にたどり着くかを最適化した方が、早く目的の情報に辿り着く事ができると思います。
- ユーザビリティが悪い為に時間が無駄になるという問題は、Jakob Nielsen博士のAlertboxで時折触れられています。
- 戯 2003/06/07 22:32:48 PDT 目的の情報がどこに有るのかを直接探す(導く)のは、Wikiそのものの仕事では「ない」んじゃないかとも思っています。
何処に何あるか判らないからWebは駄目だと考える前にGoogleで検索しろよ、みたいな。
- shelarcy (2003/06/08 02:18:41 PDT): サーバーの関係で古い名前を参照していて、いつまでも Google で検索に一切引っかからないサイトも……という話は置いておくとして、人の認識はそんなに直接的なものではありません。むしろ文書間のつながりから何を調べなければならないか思い出す事もあります。
- ツールの側でやる方が良い事は分かっています。ただ、現実にはツールが広まってくれないと利用可能にならないわけで、その間を凌ぐのには必要だとも思います。だから、関係性の部分で作りこみすぎるなとも言っているんですが……
Last modified : 2003/09/03 06:48:04 UTC