2010年1月6日水曜日

Flickr Tag Recommendation based on Collective Knowledge

Abstract
本論文では我々は人々がどのようにタグを付けるのか、あるいはどのような情報がタグに含まれるのかを調査・分析して人々にタグを推薦するシステムを構築し評価を行う。

1.はじめに
 近年Web上の様々なリソース(画像や動画、Webページなど)にタグを付ける事が一般的になってきた。タグは意味のある記述をオブジェクトに与え、ユーザがコンテンツを整理することができる。特に大規模なリッチメディア(例えば動画や画像)の検索システムには不可欠なものと言えるだろう。
 この論文での貢献は2つある。
1つ目:どのようにユーザは写真にタグを付けるのか?(1つの写真にどれくらいのタグがあるのか?あるいはあるタグがフリッカー中でどれくらいの頻度でつかわれているのかなど)またどのような種類(例えば位置や建物名)のタグをユーザは付けるのかを5200万枚の代表的なスナップショットに基づいて分析する。
2つ目:4つの異なるタグの推薦システムを提案する。また実験により評価を行う。
 推薦するタグはタグの共起関係に着目する事で決定する。また本研究の状況設定であるが、最初に写真のオーナーがタグを付け、そのタグを元に更に追加でタグを付けるという状況の元行う。(写真のオーナーが最初にタグを付け、次に他の人がタグを追加していく場合とオーナーが追加でつける場合が考えられるが、おそらくオーナーが追加でつける場合を想定していると思われる、というのはyoutube,flickerなどにはタグを他の人が追加で付けるという機能がないからである。youtubeに至っては現在タグはキーワード検索用でしかなく、動画ページにタグへのリンクがないためタグを辿って目的の動画にたどり着くという事ができない。ニコニコ動画ではタグの編集を他の人が自由にする事ができる、また動画投稿を行ったユーザのタグを消して新しいタグに変える事もできるが、動画投稿を行ったユーザがタグを消されないように設定することもできる。)
 評価については200の写真セットをランダムで選び行った。1つのタグしか付いていないものもあれば6つ以上のタグが付いているものもあった。パフォーマンスを詳細に評価するため4つの評価指標と4つのレコメンデーション戦略で評価を行った。(5、6章に詳細)
 以後2章で関連研究、3章でフリッカーのタグの分析、4章でフリッカーで写真のアノテーションを拡張するための4つのタグ推薦戦略を提案5章で評価実験の概要、6章で実験の結果を提示、7章で結論と今後の方向性を述べる。

2.関連研究
タグのシステムについて詳細に説明したもの(タグの目的、意義など)[13][16]
タグを時間軸、あるいは空間で整理するとアクセスを改善できたという研究(時間軸整理[9],空間整理[3])
タグ付けのモチベーションを調査した研究[4]→ほとんどのユーザが一般大衆に向けて写真にタグ付けをするモチベーションがあるとわかった
(他明らかでないタグはユーザを混乱させる、またユーザはあまり関連性がなくてもsuggested tag(タグの推薦機能もあるということか?)を加えたがる)

自動的にタグを付与する研究群
画像解析により写真にタグを自動で付与する研究[5,15]
画像を見て連想する単語を挙げ、同じ単語を連想するゲームにより、人々にタグをつけさせる研究[23]
ZoneTagというサービス(フリッカーに簡単に写真をアップロードできるアプリケーション)では個人の履歴、写真の地理的位置、時間を利用してタグの推薦を行っている[24]
これらそれぞれは相互補完的に作用しえるものである。(それぞれの手法が独立であり組み合わせることで精度を高めることができる)我々の研究はphotoのアップロード者が付けたタグという他と異なるデータを入力データとして利用するためこれらと相互補完的に使える。

我々の共起解析は、情報検索やセマンティックWebの領域で研究が盛んな単語ヒエラルキーやオントロジーと関係がある[20,17,21](20はテキストから単語ヒエラルキーを構築するもの、21はフリッカータグからオントロジーを構築しようとするもの)しかしフリッカーは用いられる語彙が限定的であり、またグラフのノード間の関係が制御できない性質を持っているため、我々はこれら2つの側面にも関わらずタグ関係を分析するのに、これらとよく似た概念を用いる。(意味不明、Despiteの訳し方に疑問?おそらく2つの側面を持っているためこの欠点を補うべく共起解析を行ったという意味ではあるが)

フリッカータグにセマンティックラベルを付加する先行研究として、フリッカーのジオタグと時間を利用して、タグがイベントなのか地名なのかを分ける研究がある。[18]我々の研究はこれをより豊かにできる。よりリッチなセマンティックタグを加えるためにWorldNet(英語の概念辞書)を用いる方法でこの手法を補う。

3.フリッカーでのタグのふるまい
タグの振る舞いにおいて我々が特に知りたい事は2つあり、「どのようにタグを付ける?(タグを付ける個数)」と「何をタグとする?(場所や建物名など)」である。「なぜタグを付ける?」についても疑問はあるが、これに関する研究はなされており[23,16,14,4]、社会的な動機によると結論付けられている。

3.1 使用データ(フリッカーの写真集合)
2004年2月から2007年6月までのユーザが定義したタグが少なくとも1つついている5200万枚の写真。タグの種類は凡そ370万であり、タグ総数は1億8800万である。1つの写真につき凡そ3つか4つのタグがついているものが平均的である。

3.2 一般的なタグの特徴
 どのようにユーザはタグを付けるのか?
図1はあるタグについて、登場したタグの回数を縦軸にとり、登場回数が多い(写真によく登場する)タグから順に並べたグラフである。これを見るとあるタグの登場回数はべき則に従う事がわかる。なお最も多いタグは上から順に2006,2005,wedding,party,2004であり、タグとして一般的過ぎるものであった。また少ないものは誤字や複雑なフレーズのものであり1570万以上のタグが一度だけしかフリッカー内で使われないものであった。(ここ良くわからない、uniqueタグの数が370万と言っているのにグラフでx軸は370万の所にない、また1570万以上のタグが一度しか使われていないと書いてあるがuniqueタグが370万であり、個の数を超えているのはおかしい。とりあえずベキ即に従っていることだけはわかる。)図2は1つの写真に付くタグの数を縦軸とし、数が大きい写真順に並べたものである。これもべき則に従うことがわかる。(ただしこれも図の表記方法は不明、図1では重複を許さない370万のタグがあり、それを横軸としているにもかかわらず、5000位のタグしかないみたいにみえる??)

3.3 タグのカテゴライズ
どんなタグをつけるの? 
場所→28%、人工物・芸術品→16%、人々・グループ→13%、行動・イベント→9%、時間→7%、他27%
ユーザは写真の見えている部分にのみタグを付けるのではなくより広いコンテクスト(場所、時間、行動など)に対してタグ付けを行う。

4. タグ推薦戦略
 本章ではタグレコメンデーションシステムの詳細について述べる。

4.1 タグレコメンデーションシステム概要
図4はタグレコメンデーションの全体図である。ユーザが定義したタグが与えられるとm個のタグ候補が与えられる。タグ候補は共起関係に基づいている。候補タグのリストはランキングされて、順位が高いn個のタグが最終的に推薦される。

4.2 タグの共起
2つのタグの共起を、両方のタグが使われている写真の数であると定義する。タグの共起係数を求める式は、式(1)、式(2)のようになる。
J(t_{i},t_{j}) := \frac{|t_{i}\cap t_{j}|}{|t_{i}\cup  t_{j}|}   ・・・(1)   P(t_{j}|t_{i}) := \frac{|t_{i}\cap t_{j}|}{|t_{i}|}   ・・・(2) 
式(1)は共起したタグの回数を、少なくともどちらか一方のタグが出現した回数で割った式であり、2つのタグの類似度を計測するために広く用いられる。式(2)は非対称な指標であり、タグt_{i} が出現したときにどれくらいの確率でタグt_{j} が登場するかを示している。非対称な共起では文献[20,17,21]が詳しい。例えばエッフェル塔(Eiffel Tower)で共起係数の高い順にランキングしたところ、対称な指標である式(1)を用いた場合はTour Eiffel,Eiffel,Seine,La Tour Eiffel,Parisとなったのに対し、非対称の指標である式(2)を用いた場合はParis,France,Tour Eiffel,Eiffel,Europeであった。結論として非対称なタグの共起が、対称なタグの共起と比べてより適した共起タグの多様性を与えてくれると言える。

4.3 タグ集合と促進
ユーザ定義タグ(User-defined tags)を U
候補タグ(Candidate tags)を C_{u}
推薦タグ(Recommended tags)を Rとおく
推薦タグは候補タグの中から絞る事で得られる。
候補タグから推薦タグを決定するときに2つの戦略を用意した。
一つ目:投票戦略⇒共起の時に用いた係数を用いない戦略
二つ目:summing戦略⇒共起の時に用いた係数を用いる戦略
なお各候補タグごとにスコアを算出し高いものから推薦タグに選ばれる。
投票戦略はユーザ定義タグからの共起関係によって得られる候補タグで、同じ単語の個数を足したものである。スコア算出式は式(3),(4)で表される。
vote(u,c)=\begin{cases}<br />1 & if  \:\: c\in C_{u} \\<br />0 & otherwise<br />\end{cases}  ・・・(3)   score(c) := \sum_{u\in U}{vote(u,c)}   ・・・(4)
例えば図4ではSpain,Gaudi,Catalunyaという単語がユーザ定義タグのSagrada FamiliaとBarcelonaのそれぞれの共起語として挙げられているためスコアは2であり、他の単語はどちらか一方の共起語として挙げられているためスコアは1である。
summing戦略は式(5)のようになる。
score(c) := \sum_{u\in U}{P(c|u)} \:\:\:\:\:\:\:\; ,if\;c \in C_{u}  ・・・(5)
これは4.2で求めたタグの共起係数を利用して、スコアに重みを与えたものである。我々はこれら2つをベースラインとして評価する。

Promotion
さらに推薦精度を上げるためにヒューリスティックな関数をもちいる
・Stability-promotion
ユーザ定義タグで登場回数が少ないものは多いものと比べて信頼性が低い、そこで式(6)の関数
stability(u):=\frac{k_{s} }{k_{s}+abs(k_{s}-log|u|)  }  ・・・(6)
を用いて信頼性の高いタグに重みをつける。ここでuはあるユーザ定義タグの登場回数でありk_{s} はこの関数のパラメータであり学習を行う事で決定される。
・Descriptiveness-promotion(描写性促進?)
使用される頻度がとても高いタグは一般的になりすぎる傾向がある。よってこのようなタグの効果を次の式(7)により抑える
descriptive(c) := \frac{k_{d} }{k_{d}+abs(k_{d}-log(|c|)} ・・・(7)
|c|は候補タグとして登場した回数であり、登場した回数が多すぎると重みが小さくなるようになっている。(記述はないが逆に少なすぎても重みが小さくなる)

・Rank-promotion
タグの共起の値はユーザ定義タグと候補タグの関係性の良い推測を提供する。原理上はsumming戦略で既に使われている。しかしこの値は非常に速く減衰する。ランク関数は共起の値に注目せずユーザ定義タグが与えられた時の位置rに注目し次の式(8)で表す。
rank(u,c)=\frac{k_{r}}{k_{r}+(r-1)} ・・・(8)
ここでk_{r}は減衰係数である。(ここでrについての記述がposition rとしかないためあまり定かではないが、おそらく共起の値が大きい順に1,2,3,4と値をつけていくのだと思われる、これによりゆるやかなsumming戦略で使われている急激な値の減衰からゆるやかな値の減衰に変わりパフォーマンスが向上する)
この3つを組み合わせてプロモーション関数は次の式(9)のように定義される
promotion(u,c) := rank(u,c)\cdot stability(u)\cdot descriptive(c)・・・(9)
この関数を投票戦略、あるいはsumming戦略の関数に適用する。投票戦略の場合は次の式(10)のようにスコア関数がアップデートされる。
score(c):=\sum_{u\in U}{vote(u,c)\cdot promotion(u,c)} ・・・(10)
(なおsumming戦略についてのアップデートした後の関数の記述がない、しかし今後ほとんど議論に入ってこないのでここは紙面の都合上かわからないが省かれたのだろう。)ここで設定しなければならないパラメータとして(m,k_{r},k_{s},k_{d})がある。これらは次のセクションにて適切な設定を行う。そして下の図のようにプロモーション関数を用いた場合、用いない場合、投票戦略を用いた場合、summing戦略を用いた場合

votesum
no-promotionvotesum
promotionvote+sum+
の4パターンの戦略に対して推薦されるタグが適切であるかの評価を行う。

5.実験
5.1 タスク
システムがタグを推薦して、使用者がリストからユーザ定義タグと関連するタグを選んでアノテーションを増やす事ができるか?

5.2 写真集合
推薦されたタグと写真との関連性が妥当であると査定人が判断できるようににてbasketball,Iceland,sailingなどの高レベルな(カテゴリ階層が上位の)トピックの写真をフリッカーAPIで抽出した。331の写真を抽出し、131枚を訓練用に用い、200枚を評価用に用いた。(個人的な意見だが若干抽出方法にはランダムに写真を抽出できているか疑問は残る、できていないのだろうが推薦されたタグが妥当かどうか判定する査定人は本来ならば写真を投稿したユーザだが実験上写真を投稿したユーザに査定を行ってもらう事は不可能なので分かりやすいトピックにせざるを得なかったという実験者の苦悩が伺える)

5.3 査定
タグの妥当性の評価はblind review pooling methodによって手動で行われる。
1.プールを構成するために、4つの戦略それぞれに対してトップ10の推薦が取り出される。
2.査定人は推薦されたタグのそれぞれの詳細度を査定するように頼まれる。
3.仕事を助けるために、査定人は写真、タイトル、タグ、オーナーの名前、description(記述、写真説明?)が与えられる。
4.査定人はフリッカーの写真を見て、必要に応じて追加のコンテクストを発見する。
 査定人は非常に良い、良い、あまりよくない、わからないの4段階(とても良い、良い、あまり良くない、わからない)でタグの妥当性を判断するように求められる。その結果972がとても良いで984が良いであり、2811があまりよくないで、289が分からないであった。

5.4 Evaluation Metrics(評価指標)
異なる側面からパフォーマンスを評価するために我々は3つの評価指標を採用した。

Mean Reciprocal Rank(MRR)
ランキング中のどこでシステムによって最も関連性のあるタグが返されるのかについて指標、全写真での平均を取る。これによりタグの中で最も関連しているタグを返せるかの能力がわかる。(具体的にどのようにこの値を評価しているかは不明)
Success at rank k(S@k)
上位k個の中で良いタグが見つけられる確率で評価
Precision at rank k(P@k)
上位k個のタグのうち良いタグである割合。全ての写真の平均を取って求める。

5.5 システムのチューニング
131枚のトレーニングセットを用いて(m,k_{r},k_{s},k_{d})の最適なパラメータを決定した。その結果をテーブル3に示す。次のセクションではこのパラメータを用いてテストセットを評価する。

6.評価結果
評価は4つのセクションがある。最初に我々は2つの集合戦略の結果を報告する、そしてセクション6.2ではプロモーション関数のパフォーマンスを調べる
6.3では異なるタグクラス(クラス1はユーザ定義タグが1つ、クラス2は2~3、クラス3は4~6、クラス4は6より多い)での結果を報告する
6.4では推薦され、更にユーザに受け入れられるタグのタイプを分析する

6.1 集合戦略
個のセクションでは集合戦略であるsumming戦略とvote戦略のパフォーマンスを評価する。その結果は図4のようになった。ベースラインではsum戦略の方がvote戦略よりも勝っている。これはvote戦略が候補リストのランキングの異なったポジションで起こるタグ間を区別しないからである。(例えば10番目の共起タグも1番目の共起タグも同等と見なされてしまう。)

6.2 プロモーション
もう一度プロモーション関数のパフォーマンスに注意をむける。テーブル4の中間がプロモーション関数を導入した場合のsum,vote戦略の結果である。全体的にパフォーマンスが向上しているのがわかる。またvote+のP@5(トップ5のタグが正確である割合)の精度がかなり向上した。

6.3 タグクラス
我々のプロモーション関数はユーザ定義タグが大きい場合(Class IV,すなわちユーザ定義タグが6より大きい場合)パフォーマンスがかなり上昇したがそれ以外ではそれほど変わらなかった。(図5参照)

6.4 意味解析
どのようなタグが推薦され、また受け入れられたのか?図5はタグ推薦プロセスに参加した全てのタグのWordNetカテゴリーを表している。各グループの最初の列はフリッカーの写真オーナーによって与えられたタグであり、2番目の列が推薦された上位5個のタグであり、最後の列が受け入れられたタグである。図6はWordNetのカテゴリーの違いによる享受率である。すなわち推薦されたタグのうち各カテゴリーごとにどれだけ受け入れられたかを示す確率である。これから我々のタグ推薦はLocation,Artifact or Objectで良い結果を挙げていることが分かる。

6.5 まとめ
 結果を要約すると次のような事が言える。最初に、我々が提案した戦略は効果的であり、推薦されたタグは有用なものを多く含んでいるといえる。7割に近い写真についてランキングトップのタグに関しては良い推薦であるという評価を受け、94%の写真についてトップ5の推薦されたタグのうち1つは有用なタグを含んでいることがわかった。5つのタグが推薦された場合その半分以上は有効であるとわかった。次にプロモーション関数が一般的に正の効果を与える事が証明された。取り分け5番目のタグの正確さP@5に関しては効果が大きい事がわかった。最もパフォーマンスが良かったvote+はあらゆるクラスの写真について安定したパフォーマンスを発揮した。推薦されるタグの種類としてはLocation,Artifact or Objectがボリューム、享受率の両方で他と比べて良いパフォーマンスを発揮した。

7今後の課題
本研究ではフリッカーのタグを推薦するシステムを提案し、評価を行った。今後は他のタグを推薦する研究(例えば画像処理からタグを推薦するもの)と組み合わせてより精度を上げていきたい。









2009年1月26日月曜日

アイトラッキングでのスクリーンリーダ、Webデザイン改善などについての研究

Validating the Use and Role of Visual Elements of Web Pages in Navigation with an Eye-Tracking Study

アイトラッキングについての研究、内容が複雑なので詳しくはIntroductionで示している 。論文は→http://delivery.acm.org/10.1145/1370000/1367500/p11-yesilada.pdf?key1=1367500&key2=0750692321&coll=GUIDE&dl=GUIDE&CFID=19681038&CFTOKEN=82522043

  1. INTRODUCTION

この論文では、我々は眼が見える人々があるタスクを遂行するためにどのようにvisual
elements
(視覚要素、ロゴやヘッダー、フッターなど) と features(レイアウトの事だと思われる。)を認識するのかを調査するアイトラッキングの研究を発表する。前回の研究では、我々はウェブのナビゲーション、すなわちWebページを自由に行き来するという意味で旅行のメタファを用い、ウェブの構成要素であるヘッダーやメニュー、検索ボックス、ロゴなどをトラベルオブジェクトとして位置づけた。そしてそれらのオブジェクトをシステムで発見するために、我々はTAF(travel analysis framework)というものを提案した。その提案したTAFに基づいてトラベルオブジェクトを発見するシステム「Dante」を作成し、トラベルオブジェクトに対してアノテーションを付与した(ページ内のある部分はどのような役割を果たしているのかといった情報)。そしてそのアノテーションをスクリーンリーダー(ウェブページの読み上げソフト、主に視覚障害者のために用いられる)に応用したところ、視覚障害者がより簡単にWebページの内容を知る事ができるようになった。ところが実際に我々が作成したTravel Analysis Frameworkは十分に正確なのだろうか?実際に視覚正常者はどの程度トラベルオブジェクトを認識して、どの程度TAFで定義した内容どおりにオブジェクトを見るのだろうか?。

2.TRAVEL ANALYSIS FRAMEWORK

Wayfinding(町で如何に迷わず移動できるかを研究する分野)と都市や建築デザインの分野における現実世界の移動の研究では、人々は正しい道のりを確認するために物理環境(自然環境)の様々な物体を使用するという事を明らかにしている[14,21]。この物理環境の様々な物体(看板、目印等)に対応するものがWebページ上にも存在する。我々はそれをトラベルオブジェクトと名づけ、トラベルオブジェクトを大まかに3つのカテゴリに分類した。その3つは以下のようなものである

1.Way Points

道の途中で前進運動を手助けする決定を行うポイント(よくわからない。次の行動を決定するためのキーとなるポイントみたいなニュアンス)。これらはDecision Points(例:メニュー)やWay Edges(例:色の境界)、Navigation points(例:ハイパーリンク)Reference Points(例:サイトロゴ)を含む

2.Orientation Points

設立(establishing)と方向を保つ両方のために使われる。そのようなobjectReference Point(例:ロゴ)、direction(例:戻る、進むのボタン)Location and Position(例:メニューをハイライトする動的なアイテム?)のオブジェクトなどである

3.Travel Assistants

道に迷った時に再び方向付けを行うため、目が見える人、見えない人両方によって使われる異なった戦略。この戦略はInformation Points(例:サーチボックス)、Travel Aids(例:サイトマップ)TravelMemory(例:履歴リスト)やTravel Support(例:guided tour)


このトラベルモデルに基づいて、我々はトラベル解析フレームワークを作成した。それはトラベルをサポートする目的でシステマティックにウェブページを解析するために使われるフレームワークである。このフレームワークは2つの段階でできている。

  1. ウェブページを調査し、トラベルオブジェクトを発見し、トラベルオブジェクトの一覧表を作成する。

  2. それぞれのトラベルオブジェクトを、そのオブジェクトが果たす役割別に分類する

このフレームワークの評価[31]は、このフレームワークは一貫してトラベルオブジェクトを発見、分類する事に使われうるという事を示している。

  1. DANTE TRANSCODING PAGE

トラベルオブジェクトがページ上で発見された後Dante(システム名)はthe Web Authoring for Accessibility(WAfA) オントロジーからの条件と共にセマンティックアノテーション技術を用いる事でアノテーションを付与する。Danteはそれからこれらのアノテーションを用いウェブページを変換(トランスコーディング)し、よりscreen readerが読みやすい形に変える。詳細は[23,32]トランスコーディングの性能はTAFの性能と密接に関係するため、TAFの性能を引き上げる事が必要である。そこで視覚正常者がどのようにトラベルオブジェクトを認識するのかをよりよく理解しTAFに応用していく必要がある。4章ではその事を踏まえ視覚正常者によるアイトラッキングの実験について述べる。

  1. EVALUATION

視覚正常者の目の動きをDanteの評価で使われたタスクセットを用いて計測した。ここでは、我々はどのように視覚正常者が視覚の注目をどのオブジェクトに向けるのかを調査する

1.Method


この研究の主な目的は我々のフレームワークによって発見されたトラベルオブジェクトと視覚の注目を受けるページの場所との関係を調査する事である。

参加者:18人の21歳から35歳までのボランティア


アイトラッキング装置:ページのどの部分が最も注目を集めたかを決定してくれる優れたツール


実験対象サイト:Googleの結果ページ、インターネット映画データベースページ(IMDb)、マンチェスター大学のページ(UM)。なおこれらのページは以前の研究によりTAFを用いて解析が行われている。


手順:被験者はインデックスページから実験をはじめ、以下のタスクのうち1つをこなす。一つのタスクが終わればインデックスページに戻る。被験者は練習としてグーグルページでのタスクを最初に行う。その後はランダムで以下のタスクをこなしていく。以下タスク

1.「オリンピック」とクエリを投げたとして、2番目の検索結果を読み出す(task google)

2.IMDbページ上のメインコンテンツの最初の文章を読み出す。(task IMDb1)

3.IMDbページ上でその日の映画の名前を調べ、その前にあるセクションとその後にあるセクションのタイトルを読み出す。 (task IMDb2)

4.UMページのレイアウトを表現する。(task UM1)

5.マンチェスター大学の図書館に繋がる2つのリンクのうち1つを発見し、その場所をマウスで指し示す(task UM2)


これらのタスクは主に異なるトラベル原則に取り組むようにデザインされており[32]、ブラウジングやサーチング、スキャニング等広範囲の手法をカバーする。(要するに探し方がそれぞれ異なるという事)。すべてのタスクが終了した後に、どれくらい普段これらのサイトを使っているのかを尋ねる。サイトへ対する馴染度合いがパフォーマンスに影響を与えるかどうか調べるためである。


仮定:全体の目的(フレームワークによって発見されたトラベルオブジェクトと視覚の注目を受けるページの場所との関係を調査すること)をサポートするために、我々は次の3つの仮定を調べた。(フレームワークでの仮定、これがアイトラッキングで正しいと証明しようとしている)


H1:人々は自分の場所を確かめるためにページに入ってすぐReference Point(サイトロゴ)を参照する。
H2:Way Edgeはページを分断し、人々がどこに視線を向ければよいのかを決定する信頼の置ける手段である。
H3:人々は特にIdentification Pointshタグにあたる部分)にページを見渡す時に焦点を合わせる。そして目的の情報に届いたか確認するのである。

2.Result
ロゴがReference Point として働いている人もいるが、ユーザーはよりヘッダーとメインタイトルにページに入る時固執している事がわかった。Way Edgesはかなり人々がどのように注意を割り当てるかに影響を与え、メインコンテンツが最も凝視する人が多く、フッターと右側のコラムが非常に凝視する人が少なかった。Identification Pointが人々がページを見ているとき一般的に最も多くの凝視を集めた、これはIdentification Pointがサイト内ナビゲーションで重要な役割を担っている事を示している。

1.Reference Points
フレームワークは一つのReference Pointをそれぞれのページで発見した。それはページの左上にあるサイトのロゴである。フレームワークによればこのReference Pointは人々がサイトに入った時、現在位置を確認するために用いられる。参加者でページに入ってから1秒以内にロゴを見た人は実際50%以下であった(表1参照)。これは多数の人がフレームワークによって予想されたような方法でロゴを使っていないという事を示している。替わりにUMIMDbのページではヘッダーやタイトルのIdentification Pointがこの役割を果たしていた。これらのオブジェクトも考慮すると70%以上の参加者がページに入った瞬間にReference Pointを見ていた。しかしグーグルのページでは44%の参加者しかロゴかヘッダーを見ておらず、直接メインコンテンツを見るものが多かった。これはグーグルのサイトを良く知っているからかかなりページが単純かのどちらかであるだろう

2.Way Edges
それぞれのページは巨大なセクションに分類される。これらはヘッダー、フッター、メインコンテンツ、左右のコラムで構成される。図2は視覚の配分(どこをユーザが見つめるか)にWay
Edge
は強い影響があることを示している。メインコンテンツが最も見られ、ヘッダーと左側のコラムが続いた。右側のコラムとフッターはあまり視界に入らなかったようでほとんどの場合無視された。ここで図4の場合は右のコラムとメインコンテンツの間に境界があり右のコラムはほとんど見られていない。一方で図6の場合右側に図4にあるようなWay
Edge
が存在しないため視線が右側にも集まっている

3.Identification Points
TAF(Travel Analysis Framework)は人々はページの周囲を見渡し、目的の情報へたどり着いたかを確認するためにIdentification Pointhtmlのタグにおいて見出しhにあたるポイント)を使うという事を予想している。アイトラッキングのデータはこの仮説を支持するのか?表2は、それぞれのタスクにおいて、部分別で最も注目を集めた平均回数と平均の注目した時間である。図7は全てのタスク(5つのタスク)合わせた時の、それぞれのオブジェクトごとの平均の凝視回数である。図8は図7を各タスクごとに分解したものである。これによると最も注目を集めているのがIdentification Pointsであり、これはIdentification
Points
を人々がページの周囲を見渡し、目的の情報へたどり着いたか確認するために使っている強い証拠となる。図9は全てのタスク合わせた時の平均のオブジェクトを注目した時間で図10は各タスクごとのそれであるが、オブジェクトタイプと注目した時間の相関はそれほど見られなかった。


5.DISCUSSION

この研究の主な目的は別のコードに変換する(transcodingする)フレームワークを立証する事である。Danteはトラベルオブジェクトを正しく認識できるのか、改善の余地はあるのか?タスクはオブジェクトが使われる過程に影響を与えるのか?ページの表現力を上昇させるタスクに共通する要素はあるのか?データは視覚正常者がページのVisual Elementをどのように使うのかについて興味深い問題をいくつか提示している。ユーザはページの現在位置(Page’s identity)を確認するためにロゴよりもヘッダーやタイトルに目を向けるのか?Way EdgesBanner blindnessの現象に貢献しているのか?グーグルのページとUMIMDbのページとのオブジェクトに対する視線の向け方の違いはページに対する馴染の違いによるものなのか、あるいはページの複雑さによるものなのか?我々はこれらの問題をトランスコーディングともっと一般的なWebデザインの観点からこのうちのいくつか議論する。


仮説の検証


H1ではサイトに訪れた人は現在位置を確認するためにReference Point を活用するということを述べた。データによるとこれは実際そうであり、大多数の人がページに入ってから1秒以内にサイトのアイデンティティを示すオブジェクト(サイトロゴ、ヘッダー、タイトル)を見ていた。フレームワークではサイトロゴだけをReference Pointとしていたが、実際はヘッダーやタイトルの方がより見られていた。ヘッダーやタイトルはIdentification Pointと同様にReference Pointとしての役割も果たしたのである。ページロゴよりもタイトルやヘッダーの方がページに入った時に見られるという実験結果はJakob Nielsonsの研究に反する(http://www.useit.com/alertbox/991003.html)。しかし我々の実験はまだ試作段階のものであるからバナーデザインやバナーデザインとページやサイトの関係にもっと注意を払って考えていく必要がある。


H2Way Edgesが人々が視覚的な注目を割り振る事に影響を与えるという事を述べた。ヒートマップによると実際に単純なオブジェクトの配置位置というよりもWay Edgesが注目する場所を決めている事がわかる。


H3は人々はIdentification Points(タイトル等hタグに関係するものと思われる)をページ内を見渡し、目的の情報にたどり着いたかを確認するために活用するという事を述べた。このタイプのオブジェクトが最も視線を集め、潜在的にユーザが素早くページをスキャンする事を助けている。


Banner blindness問題
Banner blindness の問題はBenwayLane[4]によって示された。ユーザは大きく、ピカピカした、カラフルなバナー情報はページ閲覧時に無視すると言うのである。この現象に物議をかもす論文[3]もあるが最近の研究[5]ではBanner blindnessは存在するということが確かめられている。この研究[5]はページのサイドにあるバナー広告に焦点を当てたものだった。しかし我々の研究から判断すると、Banner
blindness
の問題はバナーがカラフルであるというのと同じ位Way Edgesが寄与しているのではないかと考える。(バナーのカラフルさにより、ページ内のほかの部分との間にWays Edgeが生まれてしまうためユーザが避けてしまうという事だと思う)またある明確な目的を持っている場合は、あまり明確な目的を持っていない場合に比べて広告を無視する傾向が高いということも議論されている[19]。我々の研究のタスクでも特にUMページに対するものは異なるナビゲーションスタイルを要求している。2番目のタスク(マンチェスター大学の図書館に繋がる2つのリンクのうち1つを発見し、その場所をマウスで指し示す)のほうがより1番目のタスク(UMページのレイアウトを表現する)よりも明確な目的を持っている。我々のタスクでは、タスクが視線の分配に影響を与えると言うことを示しているが、両方のタスクで重要な類似点がある。それはヘッダーがメインコンテンツより見られていなく、フッターが最も見られていないと言うことである。よってタスクはページ内の見る場所に影響を与えるかもしれないが、彼らの視線はそれでもWay
Edges
によって導かれるのである。Way Edgesはメインコンテンツと他の部分を分離することに役立つのである。

6.RELATED WORK

この研究はウェブアクセシビリティとトランスコーディングとアイトラッキングの3つと関連がある。
Web accessibility
最近の研究で大抵のウェブサイトは基本的なアクセスの要求すら未だに満たせていないと示している。[1,7,28]。アクセスビリティについて意識的な改善はあるものの[2]、未だに視覚障害者がWebを使いこなすのは難しい[10]Takagiらは最近の研究で、視覚障害者は正常者に比べネットで物を購入するときに10倍以上時間がかかると言うことを示している。これはCoyneNielson[6]が発見したことと、Disability
Rights Commission
が発見したことと一致する。

Transcoding:
アクセスビリティが悪いページを改善する一つの方法が、ページを代替のわかりやすい方式に変換するトランスコーディングである。トランスコーディングは様々な方法で達成される。ヒューリスティックを使ったもの[25]、ユーザの嗜好を用いたもの[25]や外部のアノテーション(詳しくは不明)を用いたものなどがある。我々の研究ではトラベルオブジェクトの知識によってウェブページをトランスコードすることを目的としているため、我々はこれらのオブジェクトをコンピュータで扱えるように外部のアノテーションを用いている。生成されたアノテーションはスキップリンク(スクリーンリーダーでメニューや検索ボックスなどの部分を読み飛ばし、本文へジャンプするリンク、これにより無駄な文章をスクリーンリーダーが読まずに済む)の追加、フラグメンテーション、コンテンツの再構築などに用いられている[27,28]。現存する研究では、外部アノテーションに基づいたトランスコーディング技術は視覚障害者のアクセスビリティを改善したが、優れたトランスコーディング技術は優れたウェブページの理解によるものであることは明白である。アイトラッキングの研究がウェブページの理解に貢献すると我々は信じている。


Eye-tracking
最もわかりやすいアイトラッキングの応用が、ウェブページのレイアウトとデザインを改善してユーザビリティを高めることである[26]。他には様々な条件でのページ上でのアイテムの突出度(ページのどの部分が最も注目を集めるかという事だと思う)[9,20]を調べたもの、どのように目の動きは情報の匂(Information
scent
)によって変わるのか[22](Information foraging動物が獲物を捜す行動と、人間が情報を探す行動との間に類似性を見いだし、動物行動学における最適採餌理論を、情報探索行動に当てはめるという試み、よって獲物の匂いによって動物がどのように餌を見つけるのかという事を情報検索に当てはめ、情報を知るための何か手がかりになるものをInformation scentという言葉を使って表現したのだろう。)や、事前予測やページの複雑さによってどのようにメニューを探す過程が影響を受けるのか[16]などがある。

7.CONCLUSION
この論文では我々はどのように眼が見える人々が視覚要素(メニュー、コンテンツやバナー等)とウェブページの特徴(レイアウトの事だと思われる)をあるタスクを遂行する過程で認知するかを発表した。我々の前回の研究ではこれらの視覚要素を発見するフレームワークを紹介した[31](どの視覚要素がページ上でどのような役割を果たすのかをフレームワークとしてまとめ、オントロジーを用いて自動で視覚要素を割り出すシステムを作成した)、そしてそれを元にこれらオブジェクトが意図した目的をよりよく果たせるようにウェブページを再構築した[32][33]。そしてさらにこれらの視覚要素がどのように使われるのかについて理解を深め、我々のアプローチ(フレームワークが正しいこと)を立証するために今回のアイトラッキングを行った。その結果視覚を集めたページの部分とフレームワークによって提案されたトラベルオブジェクトの間には強い関係がある事を示した。


以下発見したこと
フレームワークで予想されたとおり、Reference
Points(ロゴ)がユーザがページに入ったときに現在位置を確認するために使われることを示した。しかしこのような方法で用いられる全てのオブジェクト(ヘッダーとタイトル)を特定できなかった。

・ページを目でスキャンするときにIdentification
Pointsh1,h2タグなどに相当する大見出し、小見出し)に注目を集めることが分かった。またタスクによって異なるものの最も視覚を集めたのもIdentification Pointsであった。

おそらく最も重要な結果はグループコンテンツをセクションに分解する視覚的構成物であるWay Edgeに関する事であろう。Way Edgeはページの再構成(スクリーンリーダーで用いる)の有用性に対する大きな証拠となっただけではなく、どのように人々が注目を分配しているかの理解も深めた。














2008年11月17日月曜日

マッシュアップサイト作成2

今回は前回に引き続き光速じゃらん について述べていきたいと思う。前回は言語の習得のしやすさとレンタルサーバでどの言語が使いやすいのかと言うような点から話を進めたが、今回はWebサイト全体のプログラミング構成やなぜこのようなインタフェースにしたか?、という点について様々な観点から説明して行きたい。



1.Javascriptでほとんどの処理を記述
今回作成したプログラムでサーバの担う役割はXmlHttpRequestによって送られた情報を読み取り、じゃらんWebサービスに送信するクエリを作成し、受け取ったデータをそのままクライアント側に送信するという極めてシンプルなものである。一方でjavascript側ではdomの操作、オブジェクト配列のソート等結構重い処理を行っている。これはサーバの負担の問題からである。javascriptを使いユーザ側のパソコンで処理させたほうがサーバの負担が少なくてすみ、アクセス数が上がっても耐える事ができる。それゆえ費用も少なくて済む。ただ、その分クライアント側のパソコンに負担が掛かって動作が鈍くなる可能性がある。しかし現在では現在Firefox3やGoogle Chome等次々とjavascriptを高速に動作させるブラウザが誕生してきているし、パソコンの性能も相当上がっているので今後問題とはならないであろう。Web動向全体の流れとしてもjavascriptを多用する方向に確実に向かっていると思う。光速じゃらんで99件のホテル情報を取得して安い順、口コミ順などに並び替える時、IE6,7を用いるを結構もっさりとした動作になるのだが最新のIE8はそこそこ高速であると聞いているしユーザをいらだたせる事もなくなるであろう。

 このような理由から処理をクライアント側にまわし、Webサービスからの情報の取得回数を減らし、こちら側のサーバとWebサービス側のサーバの負担の低減に努めた。Webサービス側のサーバの負担を低減させるためにできる限りクエリを短くするように配慮もしている。(というよりはクエリが長いと情報取得が遅くなるので短くするようにした。)



2.ユーザインタフェースについて


  • なぜ全画面で大きく表示せず全体をコンパクトにまとめたのか?
    大抵の地図マッシュアップサービスを見ているとページの余白領域をなくしできる限り大きく地図を表示していることが多い。インタフェース上でのメリットは画面を目いっぱい生かすことができ見やすいと事が挙げあられる、逆にデメリットとしては全画面を使う事により画面構成が難しくなる、画面が広くなりすぎる事によりマウスの移動に時間が掛かってしまうなどが挙げられると思う。文章も横いっぱいに広がると逆に読みにくくなる。大抵のサイトでも画面全体で表示すると言う事はあまり行っておらずせいぜいWidthが950くらいで固定されていることからもこのデメリットは大きいと思う。また解像度により画面が変わってしまい違和感を覚える人も多いと思う。で、サイトにもよるがどちらかと言えば画面全体を使うよりもwidth950くらいでレイアウトするのが最もインタフェース的に優れているのではないかと思う。そのような理由で全体をwidth960に抑える事にした、またサイトの現状がその程度の幅のものが多いためWebサイトに自然にマッシュアップサービスを埋め込ませるにはページ全体ではなくその程度の幅が求められる。そしてページにマッシュアップサービスを埋め込ませるという行為はSEO上で非常にメリットがある。通常のサイトのトップページにそのようなサービスを埋め込むとトップページのユーザ滞在時間(グーグルのアルゴリズムの一つとしてユーザがどれだけそのページに滞在したか?というデータを取っておりそれを利用している可能性は高い)も稼げ、そのページにブックマークしてくれる人も増えるであろう。逆にトップページから全体画面のマッシュアップサービスのページにリンクしているような場合であると、ユーザはどちらにブックマークするかも迷いそうであるし、トップページ下ではSEOが弱く、トップページに全体画面のマッシュアップサービスを持ってこようとすると、トップページのレイアウトが難しくなり、好きなキーワードをなかなか埋め込めなくなる可能性が高い。検索エンジン対策を考えるのであれば全体画面表示はやめた方が良いだろうとは思う。

  • 機能はドメインに特化させろ、Webにおいて「すべてある」は何もないのと変わらない
    ネットで何かを調べる時たいていの人は検索エンジンを利用する。検索エンジンにより情報のフィルタリングを行っているのである。ところがそのフィルタリングを行った先のサイトに何でもそろっていると返ってユーザは戸惑ってしまう。例えば「ホテル」と検索して地図情報なら何でも検索可能な「グーグルマップ」がトップに出てきても困る。このように我々は検索エンジンの返す結果に専門性というものを望み、何でもありでコンセプトがはっきりしないサイトを望むわけではないのである。でだ、このような背景があるにも関わらず「何でもよいから詰め込めるものは全部詰め込みました」っていうマッシュアップサイトが多い。そしてそのようなサイトは情報量が多すぎてうまく整理されていない場合が多く、分かりにくい。このような観点から見ればリクルートのドコイク?ってサイトは完全にミスっている。食べ物の口コミを調べるなら食べログの方が分かりやすいし、ホテルを検索するならば今回僕が作った光速じゃらんの方が断然分かりやすい。ドコイク?は目的が明確でない人が主なターゲットであり、リクルートというバックボーンがあってある程度認知されたものであり(検索エンジン起点で認知されるということはありえない)、個人がこのようなサイトを作ったところで誰からも見向きもされないことは目に見えている。色々なWebサービスを融合させたい気持ちも分かるが現状で儲かるサイトを作ろうと思ったらもう少しターゲットを明確にして機能をドメイン依存にすべきである。
  • 初心者でも簡単に使えるべき
    ユーザインタフェースの巨匠であるシュナイダーマンによると、良いインタフェースとは初心者でも簡単に扱え、上級者になれば更に素早く操作することが可能なものだそうだ。つまり最初からゴタゴタと使い方を読ますようなマッシュアップサイトは良いサービスとは言えない。使い方を読まずとも簡単に活用でき、使うに連れて徐々に理解できるサイトが良いマッシュアップサイトなのである。最初にごたごた説明を読ますサイトはRPGで言えば最初から全ての技・機能が使えるゲームみたいなものである、これではユーザは最初に何をやったらよいのかわからず困惑してしまう。できれば使い方を読まずとも徐々に使い方を理解して行けるというのが良いのである。一応光速じゃらんもそのような事を意識してつくっている。おそらくチュートリアルビデオを作っているようでは一般ユーザには普及しないであろう。まあチュートリアルビデオを見てでも使いたいほどの魅力があるならば話は別であるが・・・・

以上長くなったがマッシュアップサイト作成の上で特に考慮した点である。何らかの参考にして欲しいし、何か異論があるようならば積極的に連絡して欲しいと思います。

2008年11月9日日曜日

マッシュアップサイト作成

まあこのサイトを見る人で知らない人はいないであろうが近年マッシュアップサイトというものが盛んに作られている。WebにおいてマッシュアップというのはグーグルやYahoo!などが提供しているWebAPIを組み合わせて何か新しいサービスを構築する事を言う。材料となるデータや地図を会社が提供してくれるので比較的簡単に高度なWebサイトを構築する事ができるのである。
それで何か作ってみようと思い立ち光速じゃらん というマッシュアップサイトを作成してみた。光速じゃらんはGoogle maps API とじゃらんWebサービスを利用しており、じゃらんnetのホテル情報をじゃらんWebサービスから取り出して、それをグーグルマップに重畳表示している。
このサイトを作るに置いて気付いた点、苦労した点などについて色々述べていこうと思う。恐らく今後このようなマッシュアップサイトを作る人にとって参考になるはずである。
まず言語の選択である。PHP,Perl,Python,Javaサーブレット+JSPなどなどサーバサイド技術は数多くあるが一体何が適しているのか、筆者はPerlは使った事がないのでよくわからないがPHP,Python,Javaサーブレット+JSPの中ではPHPが適しているということを今回実感した。サーバの問題と習得のしやすさの2点がその理由である 。

まずサーバの問題であるがJavaはリソースの消費が大きいためレンタルサーバでなかなか使えるところがない。だいたい月2000円は取られ少々懐が痛い。次にPythonはGoogle App Engineという2008年4月にスタートしたグーグルの新サービスを使えば無料でサーバーを貸してもらえる。そこではサーバーサイドとしてはPythonだけが使用できるのである。更にグーグルのインフラを用いるので頑健性がある、いざとなった時でも安全そうである。しかし唯一のWebAPIサービスへのアクセス手段となるurlfetchという関数が曲者である。これはWebサービスにアクセスして5秒応答が返ってこないと接続を自動で切ってしまうため少しWebサービス側の動作が遅いとすぐにタイムアウトして結局情報を得られなくなる事が多い。光速じゃらんを作成するにあたって、前に2つのサイトをGoogle App Engineで作ったのだが(楽天Webサービスを使った楽々ホテル検索じゃらんWebサービスを使った楽々ホテル検索)いずれも少し長めのクエリを投げればタイムアウトする事が多い、楽天のWebサービスは特に応答が遅すぎて使い物にならない、関係ないがクエリにより料金に矛盾などしょっちゅう生じている。楽天トラベルAPIを使ったサイトがほとんど出てこないのはこのような理由からであろうと悟った。まあWebサービスがJSONP形式に対応していればjavascriptだけでサーバを持たなくても良いのでurlfetchを使わなくてもWebサービスから情報を取得する事はできるのだが、現状のWebサービスでJSONPに対応しているところは少ない。Google App Engineのサーバが海外におそらくあるということも問題である。「光速じゃらん」とじゃらんWebサービスを使った「楽々ホテル検索」では同じクエリを投げても大抵国内のサーバを使用している光速じゃらんの方が圧倒的に速い。それもそのはずでユーザがブラウザからリクエストを投げる(国内)→グーグルのサーバがキャッチ(海外)→じゃらんにリクエストを飛ばす(国内)→グーグルがじゃらんからのリクエストを受け取る(海外)→結果をユーザのブラウザに返す

とアメリカと日本を2往復するのだから当然返って来るのが遅いわけである。よってGoogle App EngineでPythonを使用してマッシュアップサイトを作ると言うのはあまり得策ではないと言える。他のレンタルサーバはどうかというとJavaよりはましだがあまり対応してない模様である。

最後にPHPであるが、これはほとんどのレンタルサーバで対応しており最も素早くサービスをスタートできる。圧倒的に個人でマッシュアップサイトを作ろうとするとサーバではPHPが有利であると言える。

次に習得のしやすさであるが、言語的には最も記述が少なくて覚えやすいのがPythonであると思う。Javaは冗長で難しいし,PHPもPythonほど可読性は高くない。ところがPythonは世界的にはPHPより普及しているが日本ではほとんど普及していない、それゆえ良くわからない所を検索エンジンで調べてみてもなかなか解答までたどり着けない、逆にJavaやPHPなら、特にPHPならば書籍もWebでの情報も充実しておりマッシュアップがやりやすい。以前JavaでAjaxプログラムを組んだ事があるのだがJavaであってもまだまだ情報量が少ない感じであった。これらの事情を考えると最も習得しやすいのはPHPであろう。Pythonは今後が期待されるが今のところはまだ時期尚早といった感じである。勉強しておいて損はしないと思う。

これらの理由でPHPで安い国内サーバを借りてマッシュアップサイトを作っていくと言うのが現状の流れであると思う。

2008年10月9日木曜日

モバイル地図アプリケーションフレームワークの提案

現在のグーグルマップモバイルのようなモバイルのアプリケーションは単にデスクトップアプリケーションの縮小版であり、モバイルという特性が十分に生かされていない。モバイルの地図アプリケーションにおいてはGPS情報や向きの情報を利用でき、また表示できる情報量が少ないなどの特性がある。この研究ではモバイルに適した地図アプリケーションについての関連研究をまとめ、そのようなアプリケーションを我々が簡単に開発できるようなフレームワークについて提案している。近い将来この論文で述べられているような地図アプリケーションが必ず登場してくるであろう。本論文はこちら→http://www2007.org/papers/paper287.pdf

A Mobile Application Framework for the Geospatial Web

1. INTRODUCTION

地理情報を用いたWeb上のアプリケーションが急速に発展してきている。Google MapsYahoo MapsのようなWeb ベースで地図に情報をマッピングするアプリケーションがGoogle EarthNASA WORLD WINDのような3Dの地理情報閲覧アプリケーションと同様に多くのWebユーザと開発者を魅了した。モバイルの分野でもGPSやデジタルコンパスと連動した地図のナビゲーションシステムが登場してきている。


この論文ではモバイルにおける地理空間アプリケーションの発展について最近の流行を考慮して議論する。そして我々は新たなナビゲーションの特性(GPSや傾きセンサ)を持ったデバイス上で開発者が革新的な地理ユーザインタフェースを作れる事を可能にし、なおかつ従来のデバイスの操作性を失わないようなフレームワークを提案する。


論文の章立ては以下のようになる



  • Section2:関連研究

  • Section3:最新のツールや技術を用いたモバイルWebアプリケーションの発展について議論する。我々はモバイルの位置に基づいたインタラクションの3つの基本的なステップを定義し、それを例によって説明する。またこの例により一般的なモバイルWebアプリケーションのフレームワークが必要であるということを述べていく。

  • Section4:我々のアプリケーションフレームワークを紹介し、それはセクション3で述べた必要性を満たすものである。

  • Section5:地理データを表現するのに、デバイスに依存しないXMLフォーマットを用いたLocal Visibility Modelについて述べる。これが我々のフレームワークの主な革新点である。


  • Section 6:我々のフレームワークをセクション3での例に適用する。Local Visibility Modelのおかげで例のアプリケーションは、従来の操作性を失わず、さらにデジタルコンパスと傾きセンサなどを用いる事でよりユーザ体験を向上させる事ができるのである。

  • Section7:まとめと今後の展望


2.RELATED WORK


位置情報を知らせるインタラクションの研究は何年間も積極的に行われてきている。

  • 仮想のポストイットメモやデジタルな落書きなどのように実世界にデジタル情報を付けるというような研究([4],[7],[18])が数多く行われている。(ただ単にデジタル地図に情報を書き込んでいく感じでそれほど新しいとも思えない。大量のデジタルポストイットから重要な情報のみをフィルタリングするというような事をやっていた)

  • 位置を知らせてくれるデバイスを使ってユーザはその位置に着いての情報にアクセスし、協調マッピング作業や位置に基づいた社会的交流に従事する([19],[26])


他の研究はモバイルの地理的交流の分野のなかで特定のサブドメインに焦点を当てている:例えばユーザの位置データを蓄積することに関するプライバシーの問題にずっと取り組んでいる([3],[5],[31])


また都会でのGPSの信頼性や精度についてずっと調べられてきている。代替の位置計測方法(無線LANGSMの基地局からの情報)が都会や室内環境でより適していると言うことが述べられてきた。([16],[17])


またGPSの誤差の程度についてユーザに隠さず知らせることでユーザの不安を和らげる研究[37]GPSの誤差による矛盾を防ぐために、誤差をロケーション・ベース・ゲームの建物の配置を決定するのに用いるなどしている[2]


我々はこれらの研究活動が我々の研究の事前条件として重要であると考えている。しかし我々の論文での主要なトピックはユーザと地理情報のインタラクションである。ほとんどのモバイルの地図アプリケーションがただ単にデスクトップの縮小版に過ぎない。しかしデスクトップのインタフェースをそのままモバイルに適用するのには無理がある[15],


モバイルユーザはデスクトップユーザより迅速な応答を地図アプリケーションに求め、さらにより目的志向である[35]。それゆえあまりに情報が多い地図は寧ろ弊害となることがある[37]


結果としてモバイル専用のインタフェースを作ろうとかなりの努力が行われている。Egenhofer[6]Smart Compass,Smart Horizon,GeoWandという3つのインタフェースを考案している。Smart Compassは常に行きたい目的地の方向を指し示したコンパスであり、Smart Horizonは特定の方向を指し示す事で、その方向の目に見えない部分をディスプレイに映し出すことができるものである。GeoWandはユーザが棒で物体を指し示す事でその物体の情報を入手する事ができるものである。そしてそのような特性を備えた製品が表れつつある。




3.DEVELOPING MOBILE GEOSPATIAL WEB APPLICATION


我々は次のモバイル地理アプリケーションのステップとして、開発者が携帯電話によって提供される革新的な性質(GPSやジャイロセンサの事だと思う)を用いて手軽に開発が行えるような、標準化されたオープンなフレームワークが必要なのではないかと考える。


デスクトップ上でオープンWebAPIが熱烈な開発者のコミュニティーを育てたのと同様に、モバイルにおいてもそのような開発者に適したフレームワークを作ってやる事で革新的な地図アプリケーションができるのではないかと思われる。


このセクションでは、我々はそのようなフレームワークに必要となる要素を導き出す。開発者が既存のツールとAPIを用いてモバイル地理アプリケーションを構築する時に取り組まなくてはならない問題について簡単な例を挙げて議論する。


図1は例として用いるアプリケーションの概略である。アプリにはGPS、ブラウザ、地理コードが埋め込まれたウィキペディアの記事が備わっている。


我々はわかりやすくするため、インタラクションの流れを端末の位置を知るPositioning、端末の位置に基づいた内容をAPIやその他のメカニズムを用いて取り出すSpatial selection、取り出した内容を端末のディスプレイに表示するPresentationの三つにわける。そしてそれぞれについて説明していく。

3.1 Positioning


デバイスごとにGPSデータの取り出し方は様々であるため、どのデバイスであってもGPSデータを同じプログラムで取り出せるように標準化していく必要がある。そこでブラウザからJavaScriptGPSに直接アクセスして座標を取ってこれるようにActiveX controlでデバイスの違いを吸収する。

3.2 Spatial Selection


通常のデスクトップアプリケーションの場合、地図情報を取得するとき、地図の中心から半径○○メートル以内、あるいは現在表示されている地図の範囲内といった検索要求をして、その範囲内の


データを取得するが、モバイルアプリケーションの場合より重要となるのは建物が視界、目に見えるかどうかである(field of view and visibility)。目に見えている部分と判断するには3次元のマップデータが必要となる。これについては4章で詳しく説明する。

3.3 Presentation


空間の選択プロセスの次に、選択された結果はモバイルデバイスでの表示のためにフォーマットされる。我々の例では、フォーマットはサーバで、地理情報が入ったデータベースから取り出した検索結果とともに一般的なXHTMLテンプレートを投入することによって行われる。


考えるべきところは、デバイスの画面サイズ、サポートされている言語、含まれるセンサなどにより開発プロセスが複雑になっており、個々のデバイスに様々な対応をしなければならない点である。表示形式だけではなく、インタラクションのあり方まで入り込んで考える必要がある。このことを考慮したうえで我々が考えるフレームワークは次の2つのことを考慮する必要がある


・フレームワークは、すべてのモバイルデバイスに適合するような統合されたデータ出力フォーマットを提供することにより、主題の一貫性(thematic consistency)を施行しなければならない。


・フレームワークはデバイスの能力を最大限に引き出すように開発者に薦めなければならない。(例えばスペックの低いデバイスでも出力フォーマットを意味のあるテキストに変えられる、あらゆる機能を備えたデバイスであればより複雑なリアルタイムユーザインタフェースを実現できるようにすべきである)


4. A FRAMEWORK FOR MOBILE GEOSPATIAL APPLICATIONS


このセクションでは我々のフレームワークの実装について説明する。このフレームワークではユーザの位置から見える建物かどうかに基づいて内容を選択する空間クエリエンジンを特色とする。またクエリの結果はデバイスや結果の表示方法にとらわれないXMLデータ交換フォーマットで返されることとする。これにより主題の一貫性(thematic consistency)とデバイスの能力(capabilities)を最大限に生かすように開発者を促す仕組みが施行される。


4.1 2.5D Environment Model


ユーザの視界に入るかどうかを検証するためには、経度、緯度、高度を持った3次元環境モデルが必要となる。3次元モデルを実現することは最新の技術により容易になってきている。


実装において2つのデータセットが用いられた。1つ目はテスト用として手動で集めたデータセットであり、図4左に当たる。2つ目はかなり正確に作りこまれたデータセットであるであり図4の右に当たる。それぞれの建物は一つの2次元ポリゴンで表されており高さの値を持っている。


(何を持って2.5次元と言っているのかは不明だがおそらく2次元マップであるが高さの情報を持っているというところが2.5次元なのであろう。)


4.2 Query Engine


我々のフレームワークにおいてクエリエンジンの空間選択プロセスは2つのステップからなる。最初のステップは現在位置を考慮して2.5次元環境モデルをデータベースから取り出すことである。同時にその地域におけるコンテンツ情報も取得する。2つ目のステップとして、クエリエンジンは実際にユーザから見えているポイントを発見する。具体的には図5のようになる。QUERY LOCATIONが現在位置であり、あらかじめ設けておいたデータポイントが見えるかどうかを判断して見えるポイントと見えないポイントの2つに分けている。


4.3 XML Query Result


地図の多様な表現方法やインタラクション方法に対応するために、我々は新しいXMLデータ交換フォーマットを開発し、我々のクエリエンジンによって返される結果をXMLデータに変換しブラウザに渡してやることにした。


次のセクションでは我々は表現方法に依存しないXMLのクエリ結果フォーマットであるthe Local Visibility Model (LVis)について詳細を説明する。


5. THE LOCAL VISIBILITY MODEL


Local Visibility Modelは検索結果空間の単純化された自己中心の概念である。LVisは3次元の情報を持っている。また標準的な単位を使用しており、例えばXSLTを使う事で簡単に意味のあるテキスト出力が行える。またLVisは極座標表記を採用しておりSmart CompassGeoWandといった本来ならばデカルト座標(直交座標)から極座標への変換が必要なインタフェースを簡単に実現できる。開発が容易となるよう、LVisは単純な空間モデリングメタファであるPoints of Interest(POI)とビルボードを使用する。


5.1 Points of Interest


伝統的な地理検索クエリはジオコードが付随した内容への照会であった。照会結果のデータは一つの点座標で表される。このようなポイント型のジオコードで座標が示される内容はLVis中ではPoint of Interest(POI)で表現される。


LVisは極座標を用いるのでそれぞれのPOIはユーザからの距離、方向(heading)、高位によって定義される。このようにPOIのテキストの記述は複雑な計算なしに生成されるのである。図6はPOIの要素のためのXMLのサンプルコードを示している。またユーザの視界には入らないポイントを含めて表示する場合はhpoi(hidden-poi)としてpoiとは異なったXMLが生成される


5.2 Billboards


LVisでは通常のPOIだけでなく、実際の環境構造(3Dの構造)も表現する。このアプローチ(3次元データを取ってきて表現に生かす)のためのモチベーションは次の二つである


・一つ目として我々はモバイルデバイスの環境の形状のローカルな知識が幾つかの先進的なセンサを用いるインタフェースのためにおもしろいデザインの特徴であると言うことを主張する。(意味不明→おそらく先進的なセンサを用いた場合では、点で建物を表現するだけではセンサの良さが十分に活かしきれないのでビルボードという表現方法が必要となるってことを言っている)


・2つ目として我々は、我々の周囲に蓄えられた環境構造がリアルタイムユーザインタフェースのために必要な事前条件であるという事を主張する。もしクライアントが周囲の3次元構造についての情報を持っているならば、地図情報はもう一度クエリをサーバに送ると必要なしで統合されたセンサーから反応して変化することができる。(ユーザが動いてもすぐさま最新の状況に対応できる、ちょうどグーグルマップで地図を移動した時に周囲の地図については既にブラウザに読み込まれていて新たにサーバから地図データを取ってくる必要がないって事に似ている?)

GMLのような従来のベクター構造で2D、3Dを表現している場合、人間が読む事ができず画像の出力には複雑な計算を伴う。これは我々の、環境構造を簡単にテキストで表現するという目的に反するために、より簡潔な構造の表現方法が必要であると考えた。そこでLVisではビルボードメタファを用いて環境構造を表現する。ビルボードは建物の特徴をユーザと直接面する四角形の壁で近似するものである。このビルボードはPOIと同様極座標で表せ、近くの建物をテキスト記述で表せ、計算なしに直接XMLからビルボードを構築する事ができる。XMLでの記述方法はPOIでの記述にビルボードの横幅の角度を表すhwidthと縦幅の角度を表すvwidthが加わったのみである。


5.3 Occlusion Detection
クエリエンジンは基本的な線をスキャンするアルゴリズムを個々のビルボードの間でオクルージョンを決定するために使われる。ビルボードのオクルージョンの発見をスピードアップさせるために、アルゴリズムは実際の建物の中でオクルージョンを計算しない。その代わり、アルゴリズムはそれぞれの建物を最初のステップとしてvisible cross sectionによって置き換える。それぞれのcross sectionはそれからチェックされる。LVisの計算が我々のクエリエンジンにより完全に行われた結果は図10のようになる。図10の上の部分は上から下を見下ろした図であり、下の部分は360度のパノラマの図である。ビルボードを確認しやすくするため「viewing beam」というものをもうけており、(角度的に)高いビルボードほど明るい色になっている。パノラマの図では明るい色ほど遠くにあることを示している。


5.4 Limitations
LVis
モデルでうまく行かない場合として次の2つがある
1.図11のようなアーチを描いた建物の場合は、建物の先が見えるに


もかかわらず見えないものと勘違いしてしまう。
2.
図12のような、一つの建物が視界の180度以上を占めるとき、一つのビルボードでは表現しきれないため図12のように3つのビルボードを使って表現する。


6.GEOSPATIAL USER INTERFACES


アプリケーションフレームワークに基づいて、我々はWikipedia Finderを実装した。このセクションでは我々のフレームワークとLVisで、異なったセンサーを持ったデバイスを用いて、いくつか可能なユーザインタフェースを実演してみる。


6.1 GPS-Enabled PDA


新しいスクリプトが一定期間おきに新しいLVisをサーバからXMLHttpRequestを用いて取り出されそれに応じてユーザインタフェース(表示画面)を更新する


図13のように現在見えている部分のwikipediaのきじが見えていない部分の記事とは分離されており、この部分が図1とは異なっている。


6.2 Sensor-Equipped Mobile Phone


商用のデバイスでGPSとコンパスを備えているものがなかったため図14のものを自作した。そして2章で説明したSmart Compass,Geo-WandPanorama GUIというものを実装した。Smart Compassは図15の左図のようになり、円の中心にユーザがいて、建物の方向が示されている。この矢印はユーザがどこを向いているかによって動的に変化する。Geo-Wandはスキャニングデバイスのように使われる、しかしいまいちどうするのかよくわからない。(ユーザがゆっくりと環境に沿ってデバイスをパンしている間、ユーザインタフェースは見えているWikipediaの記事の位置を指し示すと書いてある)、最後にPanorama GUIは360度全体を図15の右のようにパノラマGUIで表しており、近くの建物の情報を見る事ができる。


7.SUMMARY AND FUTURE WORK


この論文で、我々は将来携帯電話に取り付けられるであろうセンサによりどのような革新的な地理アプリケーションやユーザインタフェースが可能になるのかについて議論した。


また我々はWeb上で地理データを取り出す新しいAPIが必要である事を発見し、局所的な地理情報のXMLデータ交換フォーマットの候補としてLocal Visibility Model(LVis)を提案した。


そしてLVisがいかに多様なインタラクションのスタイルに対応できるかということを示した。


今後はビルボードによる表示が簡単すぎるので、簡潔さを失わない程度で3D化する、都会だけではなく田舎においてもビルボードは適用可能かどうかを調べる。ナビゲーションの機能を充実させるといった事を考えていきたいと思う。










2008年7月27日日曜日

Web2.0とこれからの日本

初心者向けにWeb2.0の一部を解説、ネットに少しでも興味を持ってもらえれば程度の話
近年Web2.0という言葉がネットの世界でもてはやされている。これは定義は非常に曖昧なのだが2000年当初にはなかった新しいネット世界の動きである。キーワードとしてはロングテール、ブログ、ソーシャルブックマーク、Youtube、SNS、集合知、クラウドソーシングなどが上げられる。ユーザによって書き込まれる、あるいはユーザの商品の購買履歴等、アクセスログ等の大量のデータとそれから有用な情報を抽出しようという手法などが合わさって新しい動きが起きているのである。グーグルはアドセンスという手法によってロングテールを実現した。アドセンスのロングテールというのは今までとても広告が出せなかったような企業にも広告を出すチャンスを与え、塵も積もれば山となる方式で利益を得ようとする事である。アマゾンでも売り上げの3分の1は書店ではほとんど置かれるような事がない本から得ており(数字は目安)、本の売り上げ順位のテールの部分から大きな利潤を得ている。またアマゾンは「この商品を買った人はこんな商品も買っています」というワードに代表される協調フィルタリングという手法により綿密にユーザが買いそうな本を推薦してくれる。

 このような動きが出てきているのが日本のYahoo!や楽天はどうか?これらの会社でWeb2.0の戦略を見つけるのは難しい。これは日本のベンチャーがほとんど技術的バックグラウンドがないままに巨大に育ったためと思われる。

 しかし最近では大量のデータベースから有意な情報を探し出すデータマイニング、テキストマイニング、ユーザの行動を予測し、適した広告を配信するための行動ターゲティング、協調フィルタリング等様々な取り組みが行われ始めている。その際たる例としてNTT Docomoのマイライフアシストプロジェクトがある。これは個人のおさいふケータイでの購買履歴やメール文書、GPS情報など様々なものからユーザの行動・嗜好を予測して、その時々に適した広告を配信するのである。これからネットの世界はリアル世界と融合し加速していくだろう。


2008年7月15日火曜日

Semantic Wikipedia

Semantic Wikipedia

セマンティックウェブという技術が近年注目されている。これはウェブページ中の個々の単語に意味を付与(タグ付け)して機械が扱い易い用にしようとする試みである。これが実現されるとWeb全体が一つのデータベースとして機能できるようになり、様々な知的発見が可能となる。本論文はWikipediaをセマンティックに扱えるようにしようとする試みである。本論文はこちら

http://www.aifb.uni-karlsruhe.de/WBS/hha/papers/SemanticWikipedia.pdf

1. INTRODUCTION

本稿ではWikipediaの機能をセマンティックウェブ技術を用いて拡張するという事について述べる。Wikipediaは世界最大の百科事典で、そしてボランティアによって運営されているものである。ところがこのWikipediaは未だに様々な分野のアプリケーションに対して応用されていない。現在のWikipediaの利用法は単に人が読むものであるに過ぎなく、形式化されていないためコンピューターが理解できない。そこでこの知の集積といえるWikipediaを機械が処理できるようにするために我々はいくつかの試みをしてみた。その試みは技術的な側面もあるが、主にはセマンティック技術を導入してそれをWikipediaに定着させることである。我々は解釈されたセマンティックデータをユーザに見せるためにウィキリンク構文と記事の表示方法の拡張を提案する。WikipediaRDF, XSD, RDFS, OWLなどのW3Cに乗っ取った方法で標準化して機械が理解できるようにすることで、検索要求に対する応答や統計的な処理、あるいは知識を素早く引き出す能力などが向上する。このプロジェクトの主な目的は近い未来に実際にWikipediaに拡張機能を持たせることである。

この記事の構成は次のようになっている

  • Wikipediaの達成した業績と欠点について評価してみる(Section 2)

  • 我々の(Wikipediaのセマンティック化に対する?)基本的な考えと、それを実際に適応させたときの効果について論じる(Section 3)

  • 我々が提案するシステムの根幹をなす構成について述べる(Section 4)

  • システムの具体的な実装法について概観する(Section 5)

  • どのような知識ベースアプリケーションに応用できるかについて様々な可能性を述べる(Section 6)

  • 本研究に関連するセマンティックウィキに対して簡単に評価を与える(Section 7)

  • 結論と研究で明らかになった問題点を指摘する(Section 8)


2. TODAY’S WIKIPEDIA

WikipediaWikiソフトウェアをベースに作られたものであり、誰でも辞書の内容を変更したり追加したりすることができる。またWikipediaにはローマ教皇を名前順や就任期間の長い順に並べたリストなど、ブラウジングを支援するための記事も存在する。しかしこれらのリストの編集はすべて人手で行わなければならず、リストに変更、追加、削除などがあった場合も人手で対処せねばならず非常に面倒である。また記事へのアクセス方法について言えば、フルテキストサーチ機能とハイパーリンクをたどるぐらいの事しかできない。とりわけ欠点といえることは人が読むことでしか記事にアクセスできず、機械が自動で情報を収集して2次利用する事が困難な状態にある。

3. GENERAL IDEA

誰でも簡単に編集でき、参加者同士で記事が妥当か判断し、直接的な規制は施さないという本来のWikipediaの考えを継承した上で我々のシステムに必要な他の考えも取り入れる。それには主に次の4つがある。

  • Usability
    ユーザーが特別な知識を持たなくても簡単に編集を行えるようにしなければならない

  • Expressiveness(表現性)
    機械が可読にしやすいフォーマットを選ぶ必要があるが、それを追求しすぎるとユーザビリティとパフォーマンスに支障をきたす可能性があるため良く考える必要がある

  • Flexibility
    ユーザが自然とwikiを使えるようになる必要がある

  • Scalability
    常に増加し続ける知識ベースに対応できるだけの拡張性を確保してパフォーマンスを維持しなければならない

  • Interchange and compatibility(交換と互換の問題)
    機械可読にするために具体的なインターフェースと輸出関数(機械語に置き換える関数?)が必要となる

ここからは編集する人の観点からとくにUsabilityExpressivenessFlexibilityに焦点をあてて述べていく。
3.1 The Big Picture(全体像)

何度も説明しているが、現在のWikipediaの使用法を継承しながら機械可読な形式に持っていくことがこの研究の目的であるが、それを実現するために次のような核要素にたどり着いた。

  • 種類(categories):内容によって記事を分類する

  • 種類別リンク(typed link):記事間のリンクをその種類によって分類

  • 属性(attributes):記事の内容に関連した特性を明確に述べる

Categoryについては既にWikipediaに存在するがそれは主にブラウジングの支援のためにある。Typed linkattributesについては新しい要素である。Typed linkの例としては“ロンドン”の記事から“イギリス”の記事へのリンクがあったとき、その関係を「is a capital of」と記述する。そうすることにより簡単な検索アルゴリズムでも十分「イギリスの首都はどこ?」という問いに答えられるようになる。またattributesは多くのデータの値を統合することが出来るもう一つの機械可読データである。我々のシステムの核となる特徴はFigure2のようになる。


.2 Usage of Typed Links
typedlinkは記事間にある関係を単なるリンクではなくセマンティックな意味づけされた

関係として解釈する。Wikiの編集者はtyped linkに対して自由なラベル付けが行えるようにする。また全てのリンクをtyped linkとする必要はなく、ナビゲーションのためだけに存在するようなリンクは通常のリンクとして残す。typed linkの行い方は例えば、通常のリンクは[[England]]としていたが、それを[[is capital of::England]]と書き換えることで簡単に行える、この方法なら既存の記事も容易に再編集可能であるし、誰でも簡単に編集することが可能である。またリンク間のエッジに複数の意味を持たせることも出来るようにする。先ほどの例で行くと[[is capital of::is the biggest city of::England]]などのように書くことも出来る。Typed linkは編集側にとって非常に自由度の高いリンクである。


    1. Attributes and Types

これもtyped linkと非常に良く似ていて属性、属性値の関係を[[属性:=属性値]]と書くだけである、ロンドンの人口の例で行くと[[population:=7421328]]といった具合にする。またtyped linkとよく似ているが、一つの属性に、複数の属性値を持たせることが可能で(例えば[[population:=7421328around 7.5 million]])属性は編集者が任意に定めることが出来る。このデータ等を利用してヨーロッパの都市を人口順に並べて表示するといったことが可能になるがそれには強力なクエリー言語が必要である。幸いにSPARQLという強力なRDFクエリー言語が存在するのでこれを利用することにする。またSPARQLの構文を知らなくてもユーザが簡単に高度な検索ができるようにする必要もある。

Atrributesには単位をどう処理するかの問題がある。Figure 4[[area:=609 square mile]]とあるが”square mile” を”mi2”と書いても良いし”sqmile”と書いても同じ意味になる、そこでシステムがこれらの表記の違いを自動で吸収することにする。その結果figure2atributeの欄には[[area:=609 square mile]]と表記しただけにも関わらずarea:1557303㎢(609 )と表記された。後のセクションで詳しく説明するが、ここではユーザーが単位の選択に迷うことがないとだけ言っておこう。


    1. Semantic Templates

セマンティック情報をあらかじめ埋め込んだテンプレートを用意し簡単にセマンティック情報の入った記事が書けるようにするってことを言っている。(完全なる予想だが例えばWikipediaである都市についての記事を書くとする、その時に人口を書く項目がテンプレートであったとするとあらかじめdatatypeinteger(人口は整数値)を埋め込んでおいたりすると自動的にセマンティック情報が付加される。)

    1. User Experience

Typed linkは”inverse searches”によってその価値を増す、”inverse searches”とは例えばHyde Parkがロンドンにあるとかかれた記事について、そこにあるinfoboxをクリックしただけでロンドンに位置する他の物についても検索してくれるのである。さらにデータの値はある特定のデータタイプと結びつけることも出来る。例えばある土地の座標を書いた記事があればそれが外部マップと結びつきどこにその土地があるのかが簡単にわかるなどである。(まだこの機能は完成してはいないが取り合えず例を挙げた)


4. DESIGN
この章では具体的な実装について説明する。全体の構成について紹介し、次にtyped link attributesについての評価の流れについて議論する。attributesについては宣言、エラーの扱い、単位の変換を含む。我々の提案するシステムをどのような形で実現しようか考えたところ、我々のシステムがほとんどRDFによって表現されうる事に気がついた。Typed linkは基本的にRDFリソース間のRDF特性(プロパティ)について述べているし、attributeは記事とRDFデータリテラルの間の特性と一致する。またRDFRDFSをシステムに採用することによりwikipediaの運営に不可欠で適当なフリーソフトも利用できる。またクエリー言語であるSPARQLにより簡単なデータアクセスが実現でき、RedlandのようなRDFソフトウェアライブラリにより外部からWikipediaを利用することも容易になる。全体のシステム像は図5のようになる。


4.1 Typed Links

次にMediaWiki内のTyped linkの入力、処理、出力の具体的な構造について説明していく

Typed linkRDFのプロパティに対して適切なURIを生成するために使われる文字列でありユーザがデータタイプを宣言する必要がなく、また自由にlinkに名前をつけることが可能である。しかしスキーマ情報が完全に欠如しているとアノテーションのタスクが困難となる。そしてたくさんの名前が同じ関係を表すのに使われていたり、同じ名前が異なる意味で使われるということが起こる。これらの問題は現在のwikipediaでも問題となっているがそれほど致命的な欠陥でもない。しかしこの問題に取り組むことによりほとんどの記事にたいして人間が可読な特殊な記事を作り出すことが可能となる。また同様にして(これもメタデータを増やし誤解が生じないようにする工夫?)Relationという名前空間を導入し二つの記事の間の関係を記述できるようにする。(たくさんの名前が同じ関係を表すのに使われているという問題に対処できていない例を示す。戦国大名というカテゴリがあったとする、このとき「織田」と「織田信長」が同一人物であるにもかかわらず違う人物としてリストに列挙されている場合が考えられる。このような問題を避けるためにスキーマ情報を増やして対処しようということである。)

 これらを追加したにもかかわらず、ユーザによって入力されたtyped linkの処理は関係に関する記事を含まない。だからストレージのバックエンドとして働くRDFトリプルストアに蓄えられるRDFトリプルにtyped linkを変換するためにローカルデータソースのみアクセスされる必要がある(意味不明)

 トリプルストアが記事に含まれていない情報を含んでいないということを確実にするため、我々は期限切れのトリプルを新しい情報を保存する前に削除しなければならない。

まとめるとユーザーによって引き起こされる記事の更新には次の3ステップがある

  1. 構文解析により記事からリンクタイプを抽出する

  2. セマンティック情報をRDF tripleに変換する

  3. 古いtripleを削除して新しいtripleに更新する

これらの操作は最小限のリソースで遂行されトリプルストアの更新は記事が保存された後に非同期的に達成される、編集が同時に行われることによって起こる衝突はMediawikiソフトウェアによって発見され解決される。(データの衝突、記事の更新時に古いデータが残ってしまう危険性の回避?)

 また我々のシステム構造はトリプルストアに検索要求をかけることにより現在のセマンティック情報にはいつでもアクセス可能になる。これは非常に便利である。なぜならセマンティックデータ上で動くアプリケーションがストレージインタフェースを参照するにあたって残りのシステムとは独立して実行できるからである。(良くわからないが処理速度の向上?)

4.2 Attributes

このセクションでは正式に属性データの語彙表現とXMLスキーマが表現するところのデータを関連付けて行きたいと思う。これを実現するには、エラー処理や単位の問題を考える前にセマンティック属性のデータタイプの宣言について十分に考える必要がある。

4.2.1 Value Processing and Datatypes

属性に関してまず最初に難しいことは、与えられた属性値を正しく認識することである。属性値はリンクとは違い構文解析を行ってその意味を見つけ出さなくてはならない。それゆえ適切にフォーマットすることはtyped linkと比べるとずっと難しくなる。

 形式的にvalue spacelexical spaceというものを区別する。例えばvalue spaceは整数の集まりで、lexical spaceは整数値を表現する文字列の集まりである。RDFにおいてデータタイプを表現するときに似たような概念化が行われるが、それはXSDに基づいている。

 現在wikipedia内で属性の支援をXSDデータタイプに基づいて行うことを試している。本当はRDFトリプルのデータの値を蓄えるのにXSD表現を使いたかったのだが、英語以外の言語の人が使えないという欠点があったので、ユーザがWikipediaの所定のlexical spaceからデータを入力できるようにした。これはXSDlexical spaceとは同じではない。形式的にデータ表現の間にある2つの変換を組み合わせる。1つはWikipedialexical spaceXSDvalue spaceの変換、もう一つはvalue spaceXSDのそれに相当するlexical spaceの変換。このようにすることによりあらゆる言語の人が編集してもデータの互換性を保つことができるようになるのである。

 ユーザに属性のデータタイプを宣言させるために、我々は新しくWikipediaに”Attribute”という名前空間を導入した。記事の中に関係とカテゴリーの時と同じように人間が可読な記述を与えることもできるがさらにデータタイプを明記したセマンティック情報も加えられるようにする。新しい統語構造の量を最小化するために我々はデータタイプのための3つ目の名前空間である”Type”を導入する。そして、内蔵されたセマンティックとの関係を使って、我々は単純に[[hasType::Type:integer]]と書けばよいだけにする。これは3.4節で説明されたテンプレートの作成を容易にする。

 一般的な作業の流れはtyped linkと比べて複雑なものとなる、属性値を記事から抽出するまえに属性値のデータタイプを発見しなくてはならないからである。これにはストレージバックエンドへの追加読み込み要求などが必要となり負荷がかかる。


4.22 Error Handling

Typed linkの場合とは違い、たとえ記事が文法的に正しいとしてもattributeを扱うときには入力をシステムが適切に処理できないという場合が考えられる。このようなケースはユーザが何もデータタイプの宣言をせずにattributeに言及した時だけではなく入力値がいずれのデータタイプのlexical spaceにも存在しない場合に起こる。この問題に対処するにはエラー内容をユーザに知らせてやれば良いのだが、知らせたところでユーザはそれに対処できないであろうから我々のシステムでは、エラーに対してある程度耐えられるようにしておき、またエラーを検知し、ユーザには単にエラーメッセージを出すだけとする。データタイプ宣言のエラーが生じたとき実行できるデータタイプを入力の構造から推定してエラーを回避する、基本的には数字の時には浮動小数点として、それ以外は文字列として処理する。データタイプ宣言されたがそのデータタイプがlexical spaceに存在しない場合はセマンティック情報を蓄えず、エラーメッセージだけを出すことにする。


4.2.3 Units of Measurement

現実的に“質”を表現するときには数値だけではなく単位も必要となる。単位の付け方はユーザによってまちまちで異なる単位系統(例:kilometers miles)や異なったスケール(例:kilometers と miles)で与えられる。ここで問題となることはRDFのツールではmilekilometerのような異なる単位系統同士を比較できないということである。

 そこで解決策として、ひとつは我々の手により自動単位変換を行い大部分のデータを同じ単位としてデータベースに蓄えてやる。もう一つは単位変換がまだサポートされていないものについてもその単位を認識し他の単位の値と混合するのを避けようとする事である。

 単位の自動変換において重要なことはスタンダードな単位をできるだけ少なくするということ(たくさん単位があるとわかりづらいのである程度統一してしまおうということ)と、ユーザが直感的に単位の自動変換が行われたのだとわかることである。

 形式上、単位サポート機能の追加が、Wikipediaのデータタイプのlexcical spaceを拡張したことになる。したがって単位情報もまたデータタイプによって与えられるようになる。


5. CURRENT IMPLEMENTATION

セクション4で説明した重要な部分はもうすでに実装した。MediaWikiの機能を拡張して、元のコードには修正を加えていないため、拡張した機能が大部分元のコードと独立しており簡単に実際に動くシステムを導入することができた。他により高機能な検索エンジンやXMLシリアライゼーションにおいてRDFを出力するモジュールなどを開発している。データの出力は外部アプリケーションからWikipediaの知識を利用するのに使われる。


6. APPLICATIONS

多岐にわたるアプリケーションがセマンティック情報により拡張されたWikipediaを基礎として実現可能となる。例えばwikipediaの知識をデスクトップアプリケーションに統合することや、高度なフォークソノミーを実現することや、多言語対応辞書の作成といったことが可能となる。

 多くのデスクトップアプリケーションはユーザにwikipediaからの関連情報を提示してやることでユーザビリティを向上させることが出来る。既にこれに相当することは行われていてamaroK メディアプレーヤーではシームレスにWikipediaからアーティストやアルバム情報を取得し、それをユーザに提示している。セマンティック情報が利用可能になれば更に高度なアプリケーションが利用可能になる。また領域限定のクエリー、例えば“ビートルズの影響を受けた音楽”というような要求にも答えられるようになる。さらに教育用アプリケーションにも利用できるし、カレンダーで現在の日付に起こった事についての項目を加えることもできる。これらはデスクトップアプリケーションに限定されずWebベースシステムでも同様に利用可能である。Webで言えば、様々な情報源からデータを集めるポータルサイトは明らかにWikipediaは有益となる。

 フォークソノミーの例で言えば現在タグは言語や文脈で区別されていない、例えば“gift”というタグがあるとそれはドイツ語での“毒”という意味か、英語の“贈り物”なのかわからない、また違った単語が同じ意味で使われている場合(例えば“country”,“state”,“nation”)もある。これらの問題に対してセマンティック情報は有益に働きタグの持つあいまいさを解消することが出来る。さらにセマンティックウィキペディアは多言語対応しており、例えば犬の画像を調べようとしてアラビア語で”犬”と打ち込むと、MediaWikiに取り込まれている辞典(Wiktionary)を利用することで他の言語の“犬”に相当する単語を検索にかけアラビア語の“犬”以外の“犬”についても写真を表示してくれるようになる。








7. RELATED APPROACHES
セマンティックな知識ベースを協力して編集するためにWikiを使おうという考え方は魅力的で、これを達成するのに多くのアプローチがなされている。

  • Playtypus Wiki(2004)
    最初のセマンティックウィキ、ユーザが セマンティック情報を専用の入力スペースに書き込むことで実現する。そのスペースは普通のwikiのテキストを書くスペースと分離されていた。ユーザはN3というソフトウェアを使いセマンティックデータを記述した。このアプローチはRhizome Wikiのような後のシステムにも影響を与えた。しかしこの両方ともRDF中心になりすぎたためRDFの理解とN3で記述する技術が必要となり一般人には理解しがたいものであった。

  • WikSAR(2005)
    セマンティックの内容をWikiテキストと同じスペースに書くことが出来るようになりユーザビリティが向上した。しかし機械可読なデータと人間が呼んで編集できるテキストとの統合が不十分であった。

  • S.Auer.Powlらのシステム
    正式な構造により重みをおいたアプローチもある。すなわちオントロジーの編集を重視しており彼らのWikiシステムはよりオントロジーのエディタに近いものであった、しかしリンクが作りにくいという致命的な欠点があった。

  • その他のWikiシステム
    最近では協力して作るのではなく個人用のデスクトップアプリケーションとしてのセマンティックWikiも登場してきている。