トップ :: G 物理学 :: G06 計算;計数




【発明の名称】 ハイパーメディアの視覚化システム
【発明者】 【氏名】松下 温

【氏名】岡田 謙一

【氏名】相馬 隆宏

【氏名】西山 晴彦

【氏名】塩澤 秀和

【目的】
【構成】
【特許請求の範囲】
【請求項1】 情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中の特定ノードを持ち上げて3次元モデルとしたことを特徴とするハイパーメディアの視覚化システム。
【請求項2】 情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中の特定ノードを持ち上げて3次元モデルとし、前記持ち上げたノードを下げて他のノードを持ち上げる対話的な操作により、異なる視点から情報構造を俯瞰できるようにしたことを特徴とするハイパーメディアの視覚化システム。
【請求項3】 情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中から選定した特定ノードを持ち上げて3次元モデルとし、この3次元モデルを回転させたり、部分的に拡大して該特定ノードを俯瞰し、見易くすることを特徴としたハイパーメディアの視覚化システム。
【発明の詳細な説明】【0001】
【発明の属する技術分野】この発明は、各サイト毎に独立して管理されていた情報をリンクすると共に、該リンクされた有機的な情報ネットワークよりなるハイパーネットワークを、特定ノード毎に持ち上げて、3次元モデルとし、これを視覚化することを目的としたハイパーメディアの検索システムに関する。
【0002】
【従来の技術】従来知られているインターネット上のハイパーメディアシステム(Hypermedia system、以下WWWという)は、各サイト毎に独立して管理されていた情報を2次元的にリンクし、世界的規模の有機的な情報ネットワークを実現することに成功していた。
【0003】
【発明により解決すべき課題】前記情報ネットワークは、各ノードのリンクが錯綜する広大な情報空間となった為に、情報同士の関連性がつかめなくなる問題点を生じた。
【0004】例えばリンク中の特定ノードを拡大すると、該特定ノード以外の周辺ノードが不明となり、大局的情報構造の理解が難しくなる問題点があった。更に2次元的に展開した情報は視野及び認識が画一化し、視点を変えて異なる方向からの観察が困難になる為に視覚化しても情報の画一化を免れない問題点があった。
【0005】
【課題を解決する為の手段】然るにこの発明は、前記WWWを3次元空間にして観察できるように視覚化することに成功し、前記各問題点を解決したのである。
【0006】即ちこの発明は、情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中の特定ノードを持ち上げて3次元モデルとしたことを特徴とするハイパーメディアの視覚化システムである。また他の発明は、情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中の特定ノードを持ち上げて3次元モデルとし、前記持ち上げたノードを下げて他のノードを持ち上げる対話的な操作により、異なる視点から情報構造を俯瞰できるようにしたことを特徴とするハイパーメディアの視覚化システムである。また他の発明は、情報単位であるノードを2次元平面に配置して夫々リンクし、ついで前記2次元平面のノード中から選定した特定ノードを持ち上げて3次元モデルとし、この3次元モデルを回転させたり、部分的に拡大して該特定ノードを俯瞰し、見易くすることを特徴としたハイパーメディアの視覚化システムである。
【0007】この発明は、従来のWWWにおける問題点を解決することを目的としたものであるが、その特質を理解する為に、前記問題点について説明する。
【0008】前記WWWは、人間の連想記憶に基づいた極めて自由度の高いシステムである。ハイパーメディアはその高い自由度ゆえにインターネットの中心的なアプリケーションとなったということもできる。
【0009】しかしユーザは依然としてハイパーメディアの中で「迷っている」。欲しい情報を得るためにどこを探せばよいのか分からずに迷い、かつ、新しい情報を登録するためには、どこにどのようにすればよいのかわからないでいる。このような不備は情報の多様化と共に益々深刻になっている。
【0010】従来のハイパーメディアは、1つのアプリケーションや1つのグループの中に閉じたものがほとんどであった。そのためにデータモデルに基づく統一的な作成システムやガイドラインを用いることによって、整然としたハイパーメディアを構築することが可能であった。また、多くの人達に解放された広くオープンなハイパーメディアの場合でも、技術を持った専門のライターが、統一的なガイドラインによって構築すればよいことにはかわりがなかった。
【0011】前記ハイパーメディアは、WWWという形で広く一般的なものになり、それにともない、誰でもハイパーメディアを書き、情報を発信することができるようになった。そして個々のユーザは、ガイドラインに全く捕らわれる必要なく、完全に自由な環境を手にいれてしまったのである。
【0012】このように、誰でもが「自由に」ハイパーメディアを書けることになり、広くオープンな環境が整ったがために、ハイパーメディアの迷子問題はさらに深刻なものとなっている。例えば、1つのグループの中で統一的なデータモデルを採用したとしても、WWWの他のグループは全く異なるガイドラインの元にハイパーメディアを構築してしまうので、もはや、単に統一的なアプローチを定義しただけではこの問題を解決することができない。
【0013】さらに、WWWによって変わった点は、ハイパーメディアが有限な世界ではなくなったということである。それは、もはや、無限といってもよいほどの広さを持った情報空間へと日々進化を続けている。
【0014】この点に着目すれば、既存のハイパーメディア理論はほとんどすべてハイパーメディアが有限な世界であるという大きな前提のもとで成り立っていたということが判明されたということができる。既存の理論は「デザイン理論」「検索理論」はまだしも、グラフィカルマップに代表される「ナビゲーション理論」などは、全くと言ってよいほどその有限性に依拠したものであった。
【0015】いままでのナビゲーションシステムは、ノードとリンクがほとんどすべて判明している(判明させることができる)ということが暗黙の了解事項であった。そこでユーザは、ハイパーメディアの中で迷うことがあっても、システムは常に全体構造が把握できるという前提があった。
【0016】しかし、そのような前提はWWWでは当てはまらない。ユーザは勿論のこと、システムでさえも、もはやハイパーメディアの全体像をつかむことができないのである。ハイパーメディアは完全に「見知らぬ大地」となったのである。
【0017】前記のようにハイパーメディアの迷子問題はますます深刻なものになっているわけであるが、この解決手段として、この発明は互いに補間し合う2つのアプローチを提案する。
【0018】(1)情報視覚化:情報と情報の関わりあいを扱うハイパーメディアは、複雑なグラフ構造を取るため、その全体像をなるべく簡単な構造として見せるための工夫が必要である。
(2)協調検索:人間と人間の関わりあいを扱う複数のユーザがグループを形成して情報を検索することによって、検索作業を分担し、情報の見落としを防ぎ効率よく情報を収集することを支援する。
【0019】情報空間を視覚化する技法は、言い替えれば情報と情報との関わりあいを分かりやすく表現したものだと言える。情報視覚化については、その代表的な手法について、前記人間の処理能力を越えるような膨大な情報を分かりやすく表示するという情報視覚化の手法によって検索の効率を高めることが可能になる。
【0020】視覚化が情報同士の関係に着目したものであるとすれば、協調検索を円滑に進めるための技術は、人間と人間の関わりあいに着目したものであるといえる。
【0021】協調検索の必要性およびアプローチの方法については、グループの複数の仲間がお互いに助け合うことによって、これもまた、検索の効率を高めることが可能である。
【0022】しかし、ハイパーメディアの構造はとても2次元空間に表されるような単純なものではないため、それはほとんど不可能ではないかという意見が存在していることも述べた。確かに、その考え方には一理ある。ハイパーメディアは極めて複雑なグラフ(ネットワーク)構造であるし、その制作においては何らの基準も存在していない。結局、ハイパーメディアがグラフ構造であるということを尊重した上での視覚化の手法はないのであろうかということになる。
【0023】実際、既存の多くのシステムでは、ハイパーテキストを無理矢理階層化してしまったり、線形化してしまったりする。しかし、これらの方法はハイパーメディアをハイパーメディアではない一般のデータベースシステムにレベルダウンしているという点を見逃してはならない。このような方法は、ハイパーメディアにおける自由な情報同士の関連という視点を希薄にしてしまっており、ユーザーが本当に望むような形態ではない。
【0024】前記階層化およびクラスタリング手法の一般的な問題点として、ハイパーメディアの全体構造、またはほとんど全部のテキストが判明していなければならないという問題点がある。
【0025】すべてのリンク構造が分かっていない限り、その連結状態から分割を進めることはできないし、すべてのテキストが分かっていない限り、テキスト集合の特性を判断して分割をすることができない。
【0026】つまり、階層化手法はWWWのようにコンピュータネットワークに広がるオープンなハイパーメディアでは、ある範囲を決めた限定的な利用方法しかできないことになる。コンピュータネットワークではすべての情報を得ることは、ネットワークに対するアクセス量とその応答時間という観点からして、不可能なことなのである。
【0027】さて、グラフ構造に対する優れたビューであるグラフィック魚眼レンズビューが、WWWのようなコンピュータネットワークに広がるハイパーメディアシステムには応用できるか否か検討する。
【0028】前記魚眼レンズビューは、大局的な構造と細部の詳細を同時に知ることができるので、まさしくハイパーメディアに適したビューであるかのように思える。しかし、このグラフィック魚眼レンズビューをハイパーメディアに用いることは困難である。何故ならばグラフィック魚眼レンズビューの最大の問題点は、それが1枚の「画像」を対象にしているということである。さらにその画像に描かれたグラフ構造は平面的に整然と配置され、滅多に変化しないものであるという前提に立っている。一方WWWのようにコンピュータネットワークを介したアクセスのもとでは、ハイパーメディアの全体構造をあらかじめ調べておくことはほとんど不可能である。したがって、平面上に整然とノードとリンクを配置するなどということは期待できない。また、よしんばハイパーメディアの全体構造が分かっていたとしても、それは高速道路網のように2次元平面上に配置できるような単純な代物ではない。さらに、オープンな環境におけるハイパーメディアの構造は常に変化している。ハイパーメディアの構造が変化するたびに最適なノード配置を計算していては、そのたびに地図が変わってしまう。頻繁に変化する地図などは地図としての役割を果たさないのである。
【0029】前記におけるアクセスしたノード(情報)から順に(インクリメンタルに)作成できること、すべてのノードのリンクの状態を知らなくてもマップを作成できること及びコンピュータネットワークにおいては、通信量と応答時間の2つの観点からアクセスは最小限にしなければならない。
【0030】(1)マップの準備(ノードの配置など)は、簡便な処理によって可能であること。上記インクリメンタルであることに関連する。
(2)ノードの属性などの新しい付加データは、必要最小限に抑えること、普及している既存のシステムの上で十分に機能することおよび新しい属性を必要とするようなシステムでは、それが世界中に広まるまでコンピュータネットワークでは使えないことになる。
(3)ハイパーメディアにおける、ノードとリンクという概念を尊重したモデルであることと、既存のいくつかのグラフィカルマップでは、アルゴリズムとしての理論的な一貫性を確保するために、人間にとってはとても直観的でないビューを提示しているものもある。しかし、この発明においては、ハイパーメディアの基本情報であるノードと、その関連であるリンクが視覚的に判ることが重要である。
(4)魚眼レンズビューのような効果のあること、魚眼レンズビューのように大局的な構造と、細部の詳細が同時に判るようなシステムであることが望ましい。そのためには「注目」という概念をサポートし、「注目」しているノードの付近を目立つように表示することが必要である。
(5)同じノードは常に同じ位置にあるように一貫性があること、ナビゲーションアプリケーションを実行するたびに、ノードの位置などの表示のされ方が変化してしまっては、ユーザは過去のアクセスにおける記憶が活用できないことになる。それでは、ユーザは迷子になるので、過去のアクセスにおける記憶を活用できるために、位置的な一貫性を確保しなければならない。
(6)ノードの連結状態が変化してもマップの全体像(景色)の変化は最小限であること、1つのノードの連結状態が変化したがために、全体のノードの位置を再計算しなければならないのでは、応答時間が掛かり、すでに述べた位置的な一貫性が確保されないことになる。
(7)マルチユーザに対応していること、他のユーザがどこにいるのかマップ上に分かりやすく表示する手段を持っていること、及びこれは協調検索と関連するが、グループで協力して検索を進める上では自分以外のユーザ(グループの仲間)がどこにいるのかマップの中に簡単に表示できることが必要である。
(8)システムの御仕着せのものだけではなく、対話的に多様な視点からハイパーメディアを俯瞰することができることと、階層化システムの中ではシステムの提示した階層(分類方法)による視点を強制されるものもある。情報空間をナビゲートする上では、多様な視点から全体構造を俯瞰できることが望ましく、それも対話的に行ない得ることが望ましい。
【0031】この発明において、もはや2次元平面の中でハイパーメディアのグラフィカルマップを作成しようという試みには限界があることが明らかとなった。そこで、2次元平面でなく、3次元空間を用いればよいのではないかと考えるにいたった。
【0032】実際、最近の情報視覚化の研究においては、3次元空間の利用ということが盛んにいわれており注目されている。2次元平面では滅茶苦茶になってしまうノードとリンクの配置でも、3次元空間ならばうまくいくのではないかという思想のもとに「納豆ビュー」を発明したのである。
【0033】納豆ビューでは、ハイパーメディアを恰も納豆の如くモデル化する。どういうことかというと、「ノードを納豆の豆にし」そして「リンクを納豆の糸にし」たとえるわけである。あるノードに注目してそれを取り出そうとすると、それにリンクでつながって関連付けられたノードがあたかも納豆のようにずるずると一緒についてくるという寸法である。
【0034】以下納豆モデルを実現する納豆ビューの作成アルゴリズムの基本事項を説明する。
【0035】(1)3次元空間を活用する。
(2)ノードは球、リンクは線で表す。
(3)まず、x−y平面上にノードを配置する。このとき情報所在の統一表現法(Uniform Resource Locator、以下URLという)によって一意に定まる位置に配置する。
(4)注目するノードを上(z方向)に引っ張りあげると、つながったノードがついてくる。
(5)座標系の拡大、回転によって見やすい位置から見ることができる。
【0036】その他にも、いろいろな味付け部分はあるが、これが納豆ビューの基本である。このように簡単な納豆ビューの最大のポイントは、ユーザが対話的(インタラクティブ)に操作することができるということである。
【0037】納豆ビューは、ユーザの「注目」をサポートする。ユーザが「注目」するノードを決定し、それを選択するとそのノードとそこから出ていくリンクは目立つように違う色で表示される。
【0038】さらに、ノードを持ち上げることによって、1番下の乱雑なノードの集合体の中から注目するノードを取り出し、そこから出ていくリンクはより明らかになる。
【0039】そして、さらにノードを持ち上げれば、注目するノードから出ていくリンクにつながったノードがずるずると取り出され、そのリンクの関係がよく分かるように表示される。
【0040】このように、納豆ビューでは注目するノードを選択して持ち上げたり、座標空間を回転する作業を行なうことによって、ユーザはハイパーメディア全体の大局的構造を俯瞰したり、注目するノードの近くの様子を取り出して拡大して見ることができる。
【0041】また、納豆ビューの特筆すべき点としてユーザの対話的な操作によって、色々な角度からハイパーメディア空間を眺められるということがある。
【0042】既存の多くの階層化システムでは、どのノードを起点として階層化するかという点において、ユーザの便宜を考えてシステムが自動的に決定されるものが多い。また、ユーザが指定するようなシステムでも、起点となるノードを指定してから階層化プロセスが終了するまで、長い時間待たされることになる。
【0043】しかし、この納豆ビューでは、ユーザはコンピュータとの対話の中で少しづつ必要なだけ階層化処理を進めていくことができる。さらにそのプロセスは、ノードを引っ張りあげるという極めて分かりやすい操作であるために、ユーザは不要な認知的負担を掛けられることがない。
【0044】前記納豆ビューでは、ユーザは自分の注目する任意のノードを対話的に選んで決定し、そのノードを起点として他のノードがどのように関連しているのか必要なだけ対話的に調べることができる。つまり、納豆ビューは1つのハイパーテキストを色々な視点から多面的に見ることができるわけである。
【0045】納豆ビューは協調検索を進める上で大切なマルチユーザへの対応も容易である。グループの仲間がどこにいるのか表示するためには、ノードの色を変えるなどの措置を取ればよい。
【0046】次に納豆モデルとその表示形態である納豆ビューの説明の最後として、それがナビゲーションマップとしての必要条件を満たしていることを述べる。
【0047】納豆ビューは、コンピュータネットワークへの対応という面では、次の特質がある。
【0048】(1)アクセスしたノードから順に(インクリメンタルに)作成していける。
(2)マップの準備は、非常に簡便な処理によって可能である。
(3)ノードの属性などの新しい付加データはない。
【0049】また、ユーザインタフェースに関する面では、次の特質がある。
【0050】(1)ハイパーメディアにおける、ノードとリンクという概念を尊重している。表示はそのままノードとリンクを表している。
(2)魚眼レンズビューのように注目という概念をサポートしている。
(3)x−y座標では、位置的な一貫性がある。よって納豆ビューを真上(z+)から見た場合、同じ情報は常に同じ位置にある(図3)。
(4)ノードの連結状態が変化してから、それに関わるノードにだけ影響が出る。
(5)3次元空間に比較的多くの情報が表示できる。
(6)マルチユーザに対応していること。
(7)対話的に多様な視点からハイパーメディアを俯瞰することができる。
【0051】前記検索は、主として個人の検索能力の向上に焦点を当てているものが多かった。しかし個人の能力では限界があることは否めない。例えば日常生活の中で何かを調べする際に、1人ではなく何人かで協調しながら検索をした方が効率がよいことは明らかである。そこで、ハイパーテキストにおける情報検索にも、この協調の概念を取り入れようとした。一般に情報の量が多くなればなるほど、また検索の範囲が広くなればなるほど検索をするのが大変になってくる。このような場合には、とくに一人ではなく何人かで検索した方が効率が良い。
【0052】個人の検索能力に限界があることから、複数で行えば効率がよいという考えの他にも、この協調検索にはもっと根本的なことに関する長所がある。これまでの検索方式では、どうしてもそれがコンピュータであるがゆえの限界のようなものが生じる。検索するのは人間であって言葉1つに対してもあらゆるイメージやとらえ方が存在し、まさに十人十色なのである。それを数値的なデータだけによって解析しようというのは極めて困難なことである。
【0053】もちろんWWWにも情報を探す手段として検索可能なメタインデックスを用意しているサーバはいくつか存在している。しかしこれもキーワードによる検索のため、必要としない情報が入ってきたり、必要な情報が得られなかったりすることはよくあることである。
【0054】ユーザの何人かで力を合わせて何かをするという時には、「協調」よりも「共同」のほうが馴染み深い。例えば図書館で何か本を探すという時には目的の本を何人かで手分けをして探す、などということが多い。また、いままでに考えられてきたシステムも、同じ目的をもった非常に限られたグループ内での情報の共有や検索といったものがほとんどであった。
【0055】しかし、これからの情報化社会に向けて、そういったグループ内だけにとどまらず、もっと広い範囲での情報を共有しそして検索も必要になってくる。そのことはまた、人間の興味や関心も多岐にわたっていくことを示している。たとえ同じグループであっても、そのグループ内での役割などによって検索したい情報というものは大抵違うものである。つまり、検索の目的が異なった人に対する支援が必要である。
【0056】よって、同じ目的を持った人が集まって「共同」検索をすることも重要であるが、さらに様々な目的を持った人が集まって「協調」検索をする必要性が出てくる。共同で検索を行なうためには、同じような目的を持った仲間を集めてから行なわなければならない。しかし必ずしも同じ目的を持った仲間がいるとは限らないし、たとえいるとしても今すぐには見つからないということがある。それでは、自分が検索したい時にいつでも検索できるというわけではない。
【0057】そこで、違う目的をもった者同士でも、いつでも力を合わせて検索できるようにするために、「協調検索」が必要になってくるのである。
【0058】前記協調検索については、次の必要条件が考えられる。
【0059】(1)検索目的の相互理解:グループの仲間同士でどんな情報が欲しいのか、互いに教え合う仕組み。
(2)検索履歴の相互把握:グループの仲間がどこの情報にアクセスしているのか、一覧できる仕組み。
(3)評価情報の交換:グループの仲間に有用な情報の存在を、教えてあげるための仕組み。そして今回これらに加え、特に焦点を当ててとりあげているのが次の点である。
(4)検索者間の関係の考慮:検索している情報の内容や検索者同士の人間関係などに応じたコミュニケーションを支援する仕組み。
【0060】以上の用件を満たすため協調検索はこの発明の実施例であるが、これを行うには、グループの各メンバ情報をリストとして表示し、必要なコミュニケーションを行うことのできるインタフェースを提供する。そのインタフェースデザインには以下の事を考慮した。
【0061】この発明では、意志の疎通をスムーズに出来るようにする事で協調検索の効率をあげようと考えた。意志の疎通で、最も重要なのは自分が今何を検索したいかを正確に相手に伝える事である。つまり自分がどんな事にまつわる情報を探しているのかを示す事は協調検索には欠かせない。逆に言えばこれが分からないと協調のしようがないともいえるほど重要なものである。
【0062】そこで、本システムにおいては検索したい情報に対する短いコメントを表示するようにしており、この点も重要なところであって、物事を正確に伝達するにはキーワードのような単語より文章の方が効果的であるのは明らかであろう。
【0063】これは、自分がどこのどういう情報を検索中かを知らせておく、WWWなどの非常に巨大な空間では、どこに有力な情報があるかは分からない。そういった状況で他のメンバと同じ所やその近辺を探していたのでは非効率的であるため、できるだけ他の人がアクセスしていないところ、すなわちあらゆる角度から探った方がよりよい結果が得られる可能性が高いのである。こういう点においても協調のメリットは大きいと思われる。次にメンバーのグループ内では地位(会社における役職などに相当)が高い人を優先する。地位が高い人つまりそのグループの主導権を握り管理する立場にあるわけで、そういう人に優先して情報を提供する事によってそのグループの方向性も明確になりスムーズに作業が進んでいくものである。
【0064】自分に対して有力な情報を提供してくれる頻度の高い人を優先する。これは自分に対してそれだけ貢献してくれているわけであるから、情報をもらった人に対してはお返しをしてあげるようにしないと、以後その人からの情報提供が途絶える事も考えられる。
【0065】またこのように情報の授受をしていかないと、特定の人だけが自身の検索作業以外に他のメンバの手助けをするようになったり、逆にメンバのことには気遣わずに自身の検索作業のみ行い、他のメンバから寄せられる情報を受けるばかりといった作業量の不均衡が生じてくる。それを防ぎ、人間関係を円滑に保つためにも自分に対する貢献度の考慮は重要である。
【0066】まず、複数の人間が存在する場合には、それぞれに均等に注意を払うのは大変であり、その数が増えるとなるとさらに困難を極める。従ってこの発明のシステムにおいては表示されたメンバ全員の事を考えながら検索を行うのは不可能である。よってメンバの表示には優先順位を付ける事でこの点を解決することを試みた。
【0067】協調検索をすすめる上では、検索者(グループのメンバ)同士のコミュニケーションをシステムとしてサポートしなければならない。そこで、以下の基本的なインターネット上のコミュニケーションツールとの融合を計るには、電子メールによる非同期的なコミュニケーションと、会話または通信による同期的なコミュニケーションが必要となる。
【0068】検索者自身も実際にインターネットにアクセスして検索作業を行ってる間の情報交換などのコミュニケーションが行える事はもちろん必要であるが、検索者自身が実際に検索作業に携わっていない場合、つまり非同期的なコミュニケーションをもサポートするべきである。
【0069】こうすることにより実作業時間の短縮につながり能率が向上する事が期待できる。また、メンバ個人の作業の進行具合によって自由に検索を行っていけばいいわけで、グループとして作業を行うために、それぞれのスケジュールの調整を行ったりする必要もなくなる。
【0070】この機能を実現するためには、検索者がともに協調検索に携わっている(ログオンしている)ときには同期的に働き、そうでないときには一時的に蓄積しておくという非同期的な働きをする専用のメッセージシステムが必要である。
【0071】
【発明の実施の形態】この発明は、2次元平面のハイパーメディアを3次元空間に上げ下げすると共に、必要に応じて回転したり、部分拡大して対話的に操作し、求める情報を明確に把握するようにしたハイパーメディアの視覚化システムである。
【0072】
【実施例1】この発明の実施例を図面に基づいて説明する。
【0073】この発明の実施に使用するシステムの全景は図1の通りである。
【0074】実装は大きく分けて2つの部分からなる。すなわち、情報視覚化によるハイパーメディア空間の俯瞰図である「納豆ビュー」をユーザに提示するナットウビュー(NattoView)1と、一実施例として使用する協調検索のためのコミュニケーションツールを提供するコラボリバー(CollaboRiever)である。
【0075】実装したプログラムは、サンマイクロシステム(Sun Microsystems)社のサンスパークワークステーション(SunSparc Workstation)およびその互換機のもとで開発したUNIX及びXウィンドウシステム(X−Window System)の機能を用いて実装している。ナットウビューの実装では、SGIのオープンジーエル(OpenGL)ライブラリのフリーなクローンであるメサ(Mesa)3Dグラフィックライブラリを3次元処理のために用いている。また、コラボリバーの実装ではOSF/Motifを用いている。
【0076】ナットウビューの起動に伴う処理は以下のようなものである。
【0077】(1)ナットウビューを起動すると、まず、注目ノード3、4としてユーザのデフォルト値が選択される。注目ノード3、4を持ち上げると、これに連結するノード5、6、7、8が持ち上げられる(図2)。
(2)ナットウビューを外部のプログラムからコントロールするためのFIFO(以下コントロールFIFO)を開く。
(3)ナットウビューは地図化システムサーバリンクマネージャー(LinkManager)に注目ノード付近のリンク情報を取得することを依頼する(リンクマネージャーのSCAN命令によって行なわれる)。
(4)リンクマネージャーからの応答に基づいて、リンク情報を解析し「納豆ビュー」を表示する。
(5)ユーザからの入力を待つGUIのイベントループに入る。
【0078】コントロールFIFOというのは、後述するナットウビューのコントロールパネルやコラボリバーがナットウビューの表示を制御するためのものであり、ナットウビューに対するほとんどすべての操作が行なえる。
【0079】またリンクマネージャーへのアクセスは、TCP接続によってプロトコルにしたがって行なわれる。図2は納豆ビューを実現するためのブラウザナットウビューの全体像である。
【0080】ナットウビューにおいてはノードは球体、リンクはその球体同士を結ぶ線分として表示される。以下にその表示方法を説明する。
【0081】図2において、チェッカー盤のような模様で表示されている平面がちょうどz座標が0であるx−y平面2である。まず、はじめにノードは、このx−y平面2における位置を決められる。その手順は以下のようなものである。
【0082】(1)ノードのURLを求める。
(2)そのURLから/でつながったディレクトリ名を含まないファイル名を求める。つまり、URLのうち/を含まない最後の文字列を求める。
(3)ただし、URLの最後が/で終っているディレクトリ名の場合は、そのディレクトリ名に対して同じように/を含まない最後の文字列を求める。同じくURLの最後がホスト名の場合には、そのホスト名を仮にファイル名として用いる。
(4)以上のようにして求めた文字列の1文字目と2文字目をチェッカー盤の座標値(x、y)と見立ててそこのマスに移動する。
リンクス(links)−www→(“L”,“I”)
(5)次には文字列の3文字目と4文字目を同じように(x、y)座標と見立てて、マスの中で同じように移動する。つまり、1つのマスの中でさきほどチェッカー盤に配置したように配置をする。
リンクス−www→(“L”:“N”,“I”:“K”)
(6)以下同様に再帰的に位置を決定する。アルファベット以外は「?」として扱われる。
リンクス−www→(“L”:“N”:“S”:“W”:“W”,“I”:“K”:“?”:“W”)
【0083】このような手順を用いることによって、ノードの(x、y)座標を一意に決定し、さらにノード同士がなるべく重なり合わないように分散させることができる。また、ノードの位置の決定を無作為にするのではなく、URLを用いているので検索時に便利である。
【0084】実際、ナットウビューを真上から眺めると(図3)、どんな操作をしてもノードの位置は移動しないので、過去のアクセスにおける記憶が有効活用できる。
【0085】多くのリンクに関係しているノードは、他のノードに分岐するためのメニューのように重要なノードである可能性が高い。このようなノードはランドマークとしての役割をはたすことも多く、通常のノードよりも目立つように表示すべきである。
【0086】そこで、ナットウビューでは、ノードの関係しているリンクの本数によって、その大きさと初期z座標値(バイアス)を決定している。具体的には対数を用いて以下のように決定している。
【0087】(1)そのノードを始点とするリンク(出ていくリンク)の本数をnoutとする。
(2)同様にそのノードを終点とするリンク(入ってくるリンク)の本数をninとすると、(3)ノードの半径はR=R0 log(nout+nin+1)。
(4)ノードのバイアスはzb =zb0log(nout)。
【0088】ノードに関わる総リンク数は、ハイパーメディアにおいてそのノードがどれだけ出現するかという意味を持っているので、どれだけ存在感があるかということであると考えて、ノードの半径に対応させた。
【0089】また、ノードから出るリンク数は、そのノードがメニューのように他のノードよりも階層的に上の方にあると考えられるので、バイアスに対応させることとした。
【0090】もちろん、ネットワークへのアクセスを繰り返すと、ノードの数が増えていき、それにともなって関係するノードの数も変化するので、バイアスと大きさが徐々に変化(増加)していくノードもある。
【0091】通常のノードの色は黄色であるが、そのノードに注目するために選択するとオレンジ色になる。それにともなって、そのノードから出ていくリンクの色も通常白から緑色に変化させてある。
【0092】なお、リンクの描画では多くのリンクが重なり合ってその背後が見えなくなることがないように、半透明色を用いている。これによって、注目していないリンクの存在感がずいぶんと薄くなり、注目しているノードおよびリンクを目立たせることができた。
【0093】さらに、すでにアクセスされており、そのノードから出ているリンクの状態が判明したノードに関しては、その色をまだアクセスされていないノードに比べて暗めにすることでユーザにどこがまだ見ていないノードであるのか分かるようにした。
【0094】ノードの上(z座標)には、ノードのHTMLタイトルの書いたプレートが表示される。画面表示が繁雑にならないために、プレートに書かれる文字は8文字であるが、注目している(選択されている)ノードに関してはタイトルが完全な形で表示される。また、通常はプレートが紺色で文字は白であるが、選択されるとプレートがあずき色に変化する。
【0095】座標系全体の拡大回転などの操作は、コントロールパネル(図4)から行なうことができる。
【0096】コントロールパネルは、ナットウビューとは別のプログラムであり、Tcl/Tkを用いて実装されている。これは、いわばナットウビューのコントロールFIFOに対するインタフェースであり、ナットウビューのコントロールFIFOに命令となるデータを送ることでナットウビューをコントロールすることができる。
【0097】なお、3次元操作は、システムメニュー(図5)の移動回転メニューを選択することでも行なってもよいし、コントロールパネルのガイドにしたがって、直接キーボードを打ってもよい。おそらく応答性という面から考えるとキーボードによるインタフェースが最も実用的であろう。
【0098】ナットウビューの最下行はステータスラインになっており、通常は現在選択している(注目している)ノードに関する情報(URL、およびタイトル)が表示されている。この行はシステムからのメッセージを表示するものであり、ネットワークに対するアクセスの状態などをユーザに知らせる。
【0099】コントロールパネルおよびシステムメニューからはその他に、プログラムの終了、デフォルトの視点位置への復帰、ワイヤーフレームモードなどの機能を選択することができる。
【0100】高速なマシンを使用していない場合にはワイヤーフレームモード(図6)にすれば、多少は速度が改善される。
【0101】納豆ビューにおいてノードである情報を扱うためには、注目するノードを選択しなければならない。ここでは、ノードの選択に関連する実装と操作方法を説明する。
【0102】ノードを選択するためには、選択したいノードに狙いを定めてクリックする。すると、マウスカーソルに重なるすべてのリードの一覧がポップアップメニュー(図7)として表示される(なお、ここでリンクスサブメニューを選択すると、リンクに関する情報を見ることもできる)。
【0103】ノードを選択するとそのノードはオレンジ色に表示され、そのノードから出るリンクは緑色になる。また、選択したノードを上から下に(z軸方向に)串ざしにするように青色の線も表示される。
【0104】この青色の線は、選択したノードが他のノードの背後に隠れてしまうなどして見えなくなったときでもその場所を指し示すための「カーソル」である。また、このカーソルをクリックすることによって表示されるポップアップメニュー(図8)から、各種の操作を行なうことができる。
【0105】ノードを選択した後、カーソルのメニュー(図8)やコントロールパネル(図4)のブロウス(Browse)ボタンを選択すればネットスケープ(Netscape)をコントロールして、そのノードの実体をハイパーテキスト(HTML)として閲覧することができる。
【0106】この機能を用いることによって、ユーザはリンクをたどらずにナットウビューから直接ブラウジングをすることができ、グループの仲間のアクセスしているノードを直ちに参照することも可能になる。
【0107】なお、現在のところこれはネットスケープ専用の機能を使って実装されている。
【0108】理想的に考えれば、ナットウビューにおいて「カーソル」は使うべきではなかったであろう。ノードはそのままドラッグして動かしたり、ダブルクリックによってブラウザをコントロールできるべきである。
【0109】しかし、現実的にはいろいろと問題がある。
【0110】(1)専用のグラフィックワークステーションではない通常の計算機では、マウスのクリックを検知してから、選択されたオブジェクトを判断するまでに「多少」(これはかなり控えめな表現である)のタイムラグが生じてしまう。するとユーザはこの間にマウスから手を離してしまう(ドラッグにならない)。
(2)多くのノードの陰に隠れているノードに対する操作をすることが困難になる。
(3)選択したいノードが他のノードの陰に隠れているときには、座標系回転をすればよいのだが、計算および描画の速度から考えて実用的ではないなどなど・・・要するにハードウェアの性能が最も大きな要因となってカーソルを採用せざるを得なかった。
【0111】まだ1度も選択したことのないノードを選択すると、リンクマネージャーを通じてネットワークにアクセスし(SCAN命令)、自動的にそのノードの1つ先のノードに関して、タイトルなどのドキュメント情報と、リンク情報を取得する。そして、すでに述べたアルゴリズムによってノードの新しい(x、y、z)座標を決定する。
【0112】つまり、新しくノードを選択するたびに、その1つ先のノードが表示されていくことになる。このようにして選択を繰り返すことによってノードの数が増え、マップ空間は拡大する。
【0113】次に「納豆ビュー」の最大のセールスポイントであるノードを上げ下げすることによって、自分の注目する情報に関して詳しく調べ、多様な視点からハイパーメディアを俯瞰できる機能について説明する。
【0114】ノードを選択したならば、そのノードを上げ下げさせるには、コントロールパネル(図4)またはカーソルを選択したときのポップアップ(図8)で、リフトアップ/ダウンを選べばよい。現在選択されているノードが、1段階上に引き上げ(下げ)られる。
【0115】さらに2段階、3段階と引き上げれば、リンクのつながりにつれられてそのノードから近い(すなわち、そのノードからリンクをたどって簡単に行くことができる)ノードが引き上げられてくる(図9、11)。
【0116】この機能によって、ユーザは自分の注目するノードの近くを絡まった糸を解きほぐすように見ることができる。また、御仕着せの階層構造ではなくて、自分で色々なノードを最上位の階層に見立てながら、多面的にハイパーメディアを俯瞰することができる。
【0117】ナットウビューをコラボリバーと連携させて用いると、グループの仲間の位置をマップ中に表示するようになる(図10)。グループの仲間のアクセスしているノードは緑色で表示され、タイトルにそのメールアドレスが加わる。
【0118】この機能によって、誰がどの情報にアクセスしているのか直ちに分かることができ、評価情報の交換に役立てることができる。また、ブラウザを呼び出す機能を用いれば、そのノード(ドキュメント)を直ちに閲覧することも可能である。
【0119】なお、実装においては、これはメンバの名前を表示するための特別の機能としてではなく、汎用的な「マーク」機能として実現されている。よって、一時的に記憶しておきたいノードがあればそこをマークすることができる。
【0120】図12の右上1番右のアイコンボタンをクリックすると、図13のようなウィンドウがポップアップされる。ここで、上から順に名前、メールアドレス、検索したい内容に対してのコメント、ホーン(phone)アドレス(現在ログインしているホスト名を含んだアドレス)を入力してウィンドウの左下のOkボタンを押す。
【0121】次にサーバユーザマネージャーに対して、ユーザの属性値をセット命令によって設定することで行なわれる。また、重要な属性値の設定を変更した場合にはユーザマネージャーの通知サービスによって直ちに全ユーザに通知されるようになっている。
【0122】このようにして登録が完了すれば、この先他のメンバ(クライアント)からの要求に応じてこれらのデータがサーバによって参照されコミュニケーションができるようになる。
【0123】コラボリバーでは、ユーザの名前の隣にそのユーザが現在参照しているURLが表示されるようになっている。この機能によって、ユーザはグループのメンバが現在どこにいるのか把握することができるようになっている。
【0124】この表示は、グループのメンバの移動にともなってリアルタイムに行なわれ、その実現にはユーザマネージャーの通知サービスが用いられている。
【0125】コラボリバーでは、既存のインターネットのコミュニケーションツールである電子メールとホーン通信を実行することができる。
【0126】メンバ一覧ウィンドウ上では、インターネットで提供されている通常の電子メールサービスも利用することができ、図12の右から2つめと3つめのアイコンボタンをクリックすれば、それぞれ送られたメールを読んだり、誰かにメールを送ることができる。
【0127】上記の電子メールサービスの他にホーンも利用できるようになっている。これは協調検索を行なっているときに、ある人にとって非常に有力とおもわれる情報を発見した際など即座にリアルタイムのコミュニケーションを取って知らせたい場合などに備えたものである。
【0128】実際に利用するときには、ホーンをかけたい相手の名前の表示部分(図12のNAME:欄)12上でマウスの真ん中のボタンを押し(ドラッグ)、そのまま図12の右から4つめのアイコンボタンの所まで持っていきボタンを離す(ドロップ)操作をするだけで後は自動的にホーンコマンドが実行される。
【0129】実装では、ホーンアドレスはユーザマネージャーに登録されているものを与えることで得ている。
【0130】電子メールサービスやホーンに加えて本システム独自の非同期、同期の統合化された情報交換も行なうことができる。利用の仕方は次の通りである。
【0131】まず他のメンバにメッセージを送りたい場合には、その相手の名前の表示部分をドラッグし、図12の右から5番目のアイコンボタン13まで持っていきドロップすると図14のようなウィンドウがポップアップされる。ここでメッセージを入力してウィンドウ左下のポスト(Post)ボタンを押すだけでよい。
【0132】メッセージの送信機能は、ユーザマネージャーのポスト命令によって実現されている。メッセージは、その相手がログオン状態にあれば直ちに通知されるが(ユーザマネージャーの通知サービス)、相手がログオン状態でない場合には、ユーザマネージャーサーバに一時的に蓄積される。
【0133】自分に送られてきたメッセージを見たいときは、図12の右から6つめのアイコンボタン14をクリックすれば、図15のようなウィンドウが現れ、誰からどんな情報が送られたのかを調べる事ができる。
【0134】自分がログオンしている間にメッセージが送られてきた場合には、ユーザマネージャーの通知サービスを通してメッセージは直ちに受信される。また、自分がログオンしていなかった間のメッセージは、ユーザマネージャーサーバに対してRECV命令を要求する事によって取得している。
【0135】コラボリバーにおいては、メンバ情報は1人ずつ属性データを横1列に表示し、左から順に名前、検索したい内容に対するコメント、最も最近アクセスしたサイト、グループ内における地位、自分に対するそのメンバの重要度となっている。
【0136】このなかで、最後の自分に対する重要度を示すスケール(図12のスケール:欄)はこのアプリケーションの最大の特徴の一つであり、メンバ表示の際の優先順位を決める基準となるものである。具体的には下記の通りである。
【0137】(1)自分とのコミュニケーションの頻度が高い。
(2)自分に有力な情報を提供してくれた。
(3)グループ内での地位が高い。
などの条件を満たすとスケール値がアップし(図中右方向へ移動)、この値の高い人を上から順に表示するようになっている。つまりこのメンバリストの表示順は時間の経過と共に絶えず変化するものである。
【0138】
【実施例2】サーバシステムの実装はユニX(UNIX)上で主にパール(perl)言語を用いて行なった。また、システムの全体像を図16に示す。この図を見れば明らかなように、サーバとして実装したのは「地図化システムサーバ」「協調検索システムサーバ」「プロキシサーバの改造」の3点である。以下、「地図化システムサーバ」と「協調検索システムサーバ」をそれぞれの名前からリンクマネージャー(LinkManager)、ユーザマネージャー(UserManager)と呼ぶことにする。プロキシサーバは既存のデレゲイト(delegate)を用いている。
【0139】それぞれの役割の概要を以下に示す。
【0140】(1)リンクマネージャー(地図化システムサーバ):納豆ビュークライアントからの要求に応じて、WWWにアクセスすることによって注目ノード付近のリンク情報をスキャンし、結果をクライアントに返す。このスキャン結果は、一定時間キャッシュとして保存しており、ネットワークに対するアクセスを軽減し、応答時間の短縮をはかっている。
(2)ユーザマネージャー(協調検索システムサーバ):協調検索環境に登録されているグループのメンバについての情報を管理する。具体的には、各メンバのWWWに対するアクセス状況、協調検索にログオンしているかどうか、メッセージ交換システムの維持、各メンバに設定できる属性値の管理を行なっている。
(3)デレゲイトによるプロキシ:WWWブラウザによるアクセス情報をユーザマネージャーに知らせるために用いる。このデレゲイトのおかげで、ユーザマネージャー協調検索に関する情報を管理することができる。
【0141】リンクマネージャー、ユーザマネージャーでは実装方法やプロトコルの形式に関して共通点が多いというのも、当初の予定では、この2つのサービスは同一のサーバによって提供する考えだったからである。
【0142】後になって、技術的な問題から、これら2つの機能を分けるべきであるという結論になったものの、分かりやすさに配慮してプロトコルの形式は同じになっている。
【0143】サーバへの要求(問合せ)及びサーバからの応答にはTCP/IPにおけるTCPプロトコル(コネクション型)を用いており、電子メールのSMTPやWWWのHTTPと同じような行指向のテキストベースのプロトコルを採用している。こうすることによって、テキスト処理に向いた言語パールで組みやすく、またデバッグや動作試験も容易になった。
【0144】サーバへの要求(問合せ)は、通常次の1行形式をとる。
command arg1[arg2…]
このとき、コマンドは問合せ命令の種類を表す文字列であり、アーグ1(その引数)はその引数である。ただし、引数は最後のものを除いて空白類を含めることはできない(最後の引数だけは例外で、命令によっては、改行以外の空白類を含めることができる)。
【0145】サーバからの応答または通知は、通常次の1行形式をとる。
「status type version response−reason」
【0146】ただし、例外的に結果が複数行になることもある。
【0147】それぞれの意味を以下に示した。
【0148】ステータス:問合せに対する処理が成功したかどうかを表わす3桁の整数。ステータス値の意味はそのリーズンフィールドとともに表1に示す。
【0149】
【表1】

【0150】タイプ:サーバとサービスの種類を表わすQ、N、Lのいずれかの文字、表2に示す。
【0151】
【表2】

【0152】バージョン:サーバの応答のプロトコルバージョンレスポンス:応答(通知)データリーズン:付加的な説明(主にデバッグに使うためのもの)
この節ではユーザの情報を管理し、協調検索システムを支えるユーザマネージャーについて説明する。
【0153】ユーザマネージャーは、協調検索システムに関するありとあらゆるデータを管理する。その役割は大きく分けて参加者データベースの管理と、WWWアクセス情報の取得と管理である。
【0154】ユーザマネージャーは、コラボリバークライアントからの各種問合せがあった場合に応答として、それに対する情報を返す。これが問合せサービスである。また、それに加えてユーザマネージャーは、グループのメンバによるデータベースへの重要な変更に関しては、その他のメンバに対しても、その変更を通知しなければならない。それが、通知サービスである。以下この2つのサービスに関する概要をまとめた。
【0155】(1)問合せサービス:ユーザマネージャーの管理するデータベースに関する問合せに対する処理を行なう。クライアントは、データベースに関する必要な情報を取得・設定したいときにこの問合せサービスに接続し、処理を依頼する。この接続はずっとつなぎっぱなしにしている必要はなく、むしろ問合せのたびに接続しなおすほうがよい。
(2)通知サービス:グループの他のメンバやシステムデータベースに関する重要な変更が加えられたときに、その変更を現在接続中のすべてのクライアントに対して通知する。クライアントは、協調検索をする上でセッションのはじめに通知サービスに接続しなければならない。1度接続されるとそれ以後ログオン状態となり、協調検索の状態からログオフして接続を切断するまで、協調検索に必要な情報が次々とサーバから送られて来ることになる。
【0156】ユーザマネージャーへの接続要求があると、ユーザマネージャーはインターネットのアイデンティフィケーションプロトコル(IdentificationProtocol)(RFC1413)によって接続相手のユーザを識別する。そして、エイリアスデータベースを検索して、そのユーザのユーザマネージャーへの登録メールアドレスを取得する。以後、このメールアドレスがユーザ名(ユーザ識別子)として用いられる。
【0157】ユーザマネージャーは、協調検索のグループのユーザに関する情報を属性値として管理する。属性値は、セット命令およびゲット命令によってそれぞれ設定と取得ができる。
【0158】ユーザを識別するIDとしては、アイデンティフィケーションプロトコルとエイリアスデータベースから求めた、そのユーザのメールアドレスが用いられる。また、ユーザ名パブリックは誰からも読み書き可能なデータを格納するためのユーザ名として用いることができる。
【0159】属性値には以下のようなものがある。
【0160】#LOGON#:ユーザが最近に通知サービスに接続した時刻。
#LOGOFF#:ユーザが最近通知サービスを切断した時刻。
!NAME!:ユーザの名前。クライアント(コラボリバー)の一覧表に表示されるユーザ名。
!URL!:ユーザが最近WWWブラウザで閲覧したページ。
!ステータス!:ユーザの地位。クライアントに表示される。
ホーン:ユーザのphoneアドレス。
*NRECV*:他のメンバから送信されて、サーバ(ユーザマネージャー)に蓄積されている自分宛のメッセージの数。属性値に関するシステムの扱いは以下のように分類できる。
*ネーム*:システムが設定し、ユーザには書き換えできないもの。
#ネーム#:システムが設定し、ユーザには書き換えできず、さらに変更があったときには通知サービスを利用して、全クライアントにそれが通知されるもの。
!ネーム!:ユーザが自由に設定でき(システムも書き換えられる)、変更があったときには、全クライアントに通知されるもの。
ネーム:通常の属性。ユーザが自由に設定できるもの。
【0161】なお、属性値の数などには制限はなく、必要な属性値を必要なだけクライアント側で用意することができる。属性値の実装は、GDBMのもちいたハッシュ表で実現されている。
【0162】グループのメンバのWWWブラウザによるアクセス先を管理するためには、ユーザのWWWへのアクセス情報をサーバ側で取得し、他のグループのメンバが利用できるように準備しなければならない。
【0163】そのために本システムでは、各ユーザ(WWWブラウザ)は専用の代理サーバ(proxy serber)を仲介してWWW情報にアクセスするようにした。プロキシサーバとしてはデレゲーテッド(delegated)を用い、そのログをFIFOで直接ユーザマネージャーに渡すことによってユーザマネージャーはユーザのアクセス情報を知ることができる。
【0164】ユーザマネージャーの側では、このログ情報を解析して、各ユーザの!URL!属性に値を設定し、通知サービスを通して全クライアントに通知する。
【0165】
【発明の効果】この発明は、情報単位であるノードを2次元平面に配置して夫々リンクし、2次元平面を持ち上げて3次元空間に展開させたので、特定ノードを詳細に観察し得る効果がある。
【0166】また前記3次元空間による特定ノードを回転し、又は一部拡大して観察できるようにしたので、複雑かつ多量の情報から、必要な情報を正確かつ容易に検索できる効果がある。
【出願人】 【識別番号】391023987
【氏名又は名称】松下 温
【識別番号】392008231
【氏名又は名称】岡田 謙一
【識別番号】395008687
【氏名又は名称】有限会社フィンテック
【出願日】 平成8年(1996)4月23日
【代理人】 【弁理士】
【氏名又は名称】鈴木 正次
【公開番号】 特開平9−288556
【公開日】 平成9年(1997)11月4日
【出願番号】 特願平8−101727