[b-free 880] 実身の名前について、他。3

Hideaki Suzuki (H1Suzuki@Bridgew.edu)
Wed, 29 Oct 97 04:29:50 -0500

ども。Aki です。

[b-free 807] Night さん

|TAD 註釈レコードが容易に使えるようになっても、実身の名前をつけるという
|ことはなくならないわけだし、実身をつくるときに短い名前をつけてから註釈
|をつけるということをするより、実身名に長い名前をつけるだけで済ますとい
|うのは自然だと思いますけど。

矛盾してない?
実身名に長い名前を付けるような時に、実身名を最初に付けることをめんどくさがる
かなぁ。ホントに? 何でも良いのに?

むしろ、実身の複写にしろ何にしろ、実身を制作する度に実身名を決めなきゃいけな
いのだから、ぱっぱと決めて、あとで、「長い実身名」といった大量の情報は、じっ
くり文書編集でも図形編集でもつかって、書けばいいと思うのだけど? その方が、
入力しやすそうだし。

取りあえず実身を作っておいてから長い実身名をかく。となったら、注釈機能も、別
に面倒さは変わらないはず。

# 大量の情報はすぐに保存は、95のお陰で習慣になりました。
# 3 action 1 save の時代に逆戻りとはね。とほほ。^^;

「実身名は実身を作る度に決めなくちゃいけない」という所が大切な点ね。

[b-free 808] Night さん

|> 実身仮身マネージャとかで、OSで支援しないの?
|> 結構、一般的に使われるんじゃないの?
|>
|> # 他に、色々と注釈レコードを扱う App があっても良いけど。
|
|とゆーか、一般的に使われることを望むならば、マネージャを変更して、公開
|すればいいわけですね。

そうですね。:)

|# もちろん、Hideaki Suzuki さんがマネージャを作るのもいいと思いますし。

うひゃぁ。早く卒業して日本に帰ろうと思ってはいますが、、、。
取りあえず、学生時代は、どのくらい取り組めるか知れない。
しかも、大変そうな実身仮身マネージャでしょ? 
# まあ、みんな大変か。 ^^;;;
ただひとつ、僕は、はなはだ、任せてもらうような「信用に足りる男ではない」と言
っておきましょう。<おいおい。

99年の夏くらいから集中的に半年から一年くらい時間取れると思いますがそれじゃ
あ、全然遅いですよね? でも、OS を作るなんてすっごく、興味はあるんですけどね
ぇ。いろいろ、経験&勉強になりそう。
ということで、今できることは、ML への参加と、自分の技能の向上くらいですのであ
しからず。という結論に達しました。(^_^;

|でもまぁ、使いやすいユーザインタフェースというのは、試行錯誤が必要なわ
|けで、マネージャに組み込むと、使いやすさが損われるような気もします。

??
「基本文書編集」はシステムが提供する編集用 App だ。
とかいうのと同類じゃない? 注釈機能は、 OS が使用を支援するけど、それ以上は
App でやって下さい。ってかんじ。

[b-free 809] 塩澤さん

|「直結」じゃないんですか? それ、ややこしいですよ。
|X→Y→Zという経路が欲しいとして、
|XからYに至るのに経路が複数ある可能性もあるわけ。
|直結じゃないとしたら、10*10*10でもなくなる。
|計算量的には「1レベルごとに何倍」というの(指数関数)は、
|10倍でなくて2倍になっても大変なことにかわりないですよ。

うーむ。
絞り込み検索みたいな物かな。
では、少し新しい Algorithm を。

***********
まず、X,Y,Z のそれぞれと同じ名前の実身名を探す。(get_lnk の改良版見たいのが
あるといいね)。
X,Y,Z それぞれに a,b,c 個の実身が発見されたとする。
で、X→Y, Y→Z という参照関係がある一定の道の長さ以内にあるか調べる。
同じ Y について両方あれば、X→Y→Z と繋がった。
***********

これで実身名の文字列による照合を最小に押さえて、整数(実身ID)で道が繋がっ
ているかどうかを調べられるようには成るけど、、、。
でも、まだ、大変かなぁ。

|高速に行なうためには、OSレベルで補助が必要かもしれない。

期待大。;-)
実身名によって、get_lnk みたいに直に link を file-system から取り出せる API
と、指示された長さの道以下で、ある実身から到達可能な実身集合と指定した実身集
合の積を教えてくれる API があると良いのだけど。これを、ファイルマネージャで支
援してくれれば、実身仮身マネージャに僕の言った「道検索」を入れても、大分、楽
ができそう。

|人間は階層的に情報をしまっているものなのです。

いくつもの木構造が互いに重なっているような情景でしょうか?

|ところが、リンクには階層を表すものだけでなく、
|いろいろな目的のものがあるので、(たとえば、
|「場」の理論で、コーヒー飲んで一服したいからといって、
|論文のなかに、コーヒーの仮身を置いちゃったりすると)、
|話がややこしくなります。

ははは。^^;
論文は階層のためにリンクを使いがちだけど、コーヒーは違いますものね。

# ちなみに、コーヒーを「開く」と、色々な豆への仮身が並べて
# あって、きっとダブルクリックすると、コーヒーが運ばれてくる
# に違いない。未来の社会では。と、現実感を出してみる。^^;

でも、場というのは、ウインドウを開くことのみで移動するわけではないと思います
。むしろ、ウインドウ間を移動する事が、場を移動するのです。だから、コーヒーを
論文の中に置かなくとも(そんなことをしたら「論文」という場が変質してしまう)
コーヒーというウインドウを開いておけばよい。もしくは、コーヒーに到達できるウ
インドウを開けばよい。で、どんどんウインドウを開いていって(いくつかの場を通
り過ぎていって)コーヒーに到達する。それが自然ですよね。

ウインドウをいくつか開くことによって、同時に開いているウインドウ間にリンクが
貼られたようになると言うのは面白いと思います。で、そういった状態を即座に作る
ために、あらかじめ、同時に作業しそうな仮身を集めて、一つの新しい実身(場)を
形成するというのも、ネットワークならではですね。

# 95で shortcut (もろ仮身のパクリだが)を採用したのも
# 木構造だけでは不自由だという事だと理解しています。

「直ぐに必要な物を集めて、新しい環境をつくる。」というのは、実身仮身ネットワ
ークのキャッチフレーズにならないかなぁ。

  B-free なら
   自分の好む仕事場をコンピュータの中に
    <直>作れます。

とか。
なんか、センスがたんないか。^^;;;;

|> 革命的な使い方に挑戦して、ネットワークを最大限使ってみよう!
|> 僕もまだ、革命には至ってないけどさ。
|
|私の個人的な研究テーマになるけれども、
|ツリーって簡単に描画できるけど(上から下へ)、
|ネットワークって、方向性がないから描画が難しいんですよね。
|まず、ツリーと同じくらい人間に分かりやすい
|図や模型が作れるくらいでないと。

なんか、「地球儀を平面に歪みなく書き写せ」って聞こえる。^^;
でも、その複雑さが決まり切った使い方を越える可能性を与えてくれるようで。なん
か、個人的に期待しています。:)