Semantic Wikipedia
セマンティックウェブという技術が近年注目されている。これはウェブページ中の個々の単語に意味を付与（タグ付け）して機械が扱い易い用にしようとする試みである。これが実現されるとWeb全体が一つのデータベースとして機能できるようになり、様々な知的発見が可能となる。本論文はWikipediaをセマンティックに扱えるようにしようとする試みである。本論文はこちら
http://www.aifb.uni-karlsruhe.de/WBS/hha/papers/SemanticWikipedia.pdf
1. INTRODUCTION
本稿ではWikipediaの機能をセマンティックウェブ技術を用いて拡張するという事について述べる。Wikipediaは世界最大の百科事典で、そしてボランティアによって運営されているものである。ところがこのWikipediaは未だに様々な分野のアプリケーションに対して応用されていない。現在のWikipediaの利用法は単に人が読むものであるに過ぎなく、形式化されていないためコンピューターが理解できない。そこでこの知の集積といえるWikipediaを機械が処理できるようにするために我々はいくつかの試みをしてみた。その試みは技術的な側面もあるが、主にはセマンティック技術を導入してそれをWikipediaに定着させることである。我々は解釈されたセマンティックデータをユーザに見せるためにウィキリンク構文と記事の表示方法の拡張を提案する。WikipediaをRDF, 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
WikipediaはWikiソフトウェアをベースに作られたものであり、誰でも辞書の内容を変更したり追加したりすることができる。またWikipediaにはローマ教皇を名前順や就任期間の長い順に並べたリストなど、ブラウジングを支援するための記事も存在する。しかしこれらのリストの編集はすべて人手で行わなければならず、リストに変更、追加、削除などがあった場合も人手で対処せねばならず非常に面倒である。また記事へのアクセス方法について言えば、フルテキストサーチ機能とハイパーリンクをたどるぐらいの事しかできない。とりわけ欠点といえることは人が読むことでしか記事にアクセスできず、機械が自動で情報を収集して２次利用する事が困難な状態にある。
3. GENERAL IDEA
誰でも簡単に編集でき、参加者同士で記事が妥当か判断し、直接的な規制は施さないという本来のWikipediaの考えを継承した上で我々のシステムに必要な他の考えも取り入れる。それには主に次の４つがある。
Usability
ユーザーが特別な知識を持たなくても簡単に編集を行えるようにしなければならないExpressiveness(表現性)
機械が可読にしやすいフォーマットを選ぶ必要があるが、それを追求しすぎるとユーザビリティとパフォーマンスに支障をきたす可能性があるため良く考える必要があるFlexibility
ユーザが自然とwikiを使えるようになる必要があるScalability
常に増加し続ける知識ベースに対応できるだけの拡張性を確保してパフォーマンスを維持しなければならないInterchange and compatibility（交換と互換の問題）
機械可読にするために具体的なインターフェースと輸出関数（機械語に置き換える関数？）が必要となる
ここからは編集する人の観点からとくにUsabilityとExpressivenessとFlexibilityに焦点をあてて述べていく。
3.1 The Big Picture(全体像)
何度も説明しているが、現在のWikipediaの使用法を継承しながら機械可読な形式に持っていくことがこの研究の目的であるが、それを実現するために次のような核要素にたどり着いた。
種類(categories)：内容によって記事を分類する
種類別リンク(typed link)：記事間のリンクをその種類によって分類
属性(attributes)：記事の内容に関連した特性を明確に述べる
Categoryについては既にWikipediaに存在するがそれは主にブラウジングの支援のためにある。Typed linkとattributesについては新しい要素である。Typed linkの例としては“ロンドン”の記事から“イギリス”の記事へのリンクがあったとき、その関係を「is a capital of」と記述する。そうすることにより簡単な検索アルゴリズムでも十分「イギリスの首都はどこ？」という問いに答えられるようになる。またattributesは多くのデータの値を統合することが出来るもう一つの機械可読データである。我々のシステムの核となる特徴はFigure2のようになる。
３.２ 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は編集側にとって非常に自由度の高いリンクである。
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”と書いても同じ意味になる、そこでシステムがこれらの表記の違いを自動で吸収することにする。その結果figure2のatributeの欄には[[area:=609 square mile]]と表記しただけにも関わらずarea:1557303㎢（６０９ ）と表記された。後のセクションで詳しく説明するが、ここではユーザーが単位の選択に迷うことがないとだけ言っておこう。
Semantic Templates
セマンティック情報をあらかじめ埋め込んだテンプレートを用意し簡単にセマンティック情報の入った記事が書けるようにするってことを言っている。（完全なる予想だが例えばWikipediaである都市についての記事を書くとする、その時に人口を書く項目がテンプレートであったとするとあらかじめdatatypeのinteger(人口は整数値)を埋め込んでおいたりすると自動的にセマンティック情報が付加される。）
User Experience
Typed linkは”inverse searches”によってその価値を増す、”inverse searches”とは例えばHyde Parkがロンドンにあるとかかれた記事について、そこにあるinfoboxをクリックしただけでロンドンに位置する他の物についても検索してくれるのである。さらにデータの値はある特定のデータタイプと結びつけることも出来る。例えばある土地の座標を書いた記事があればそれが外部マップと結びつきどこにその土地があるのかが簡単にわかるなどである。（まだこの機能は完成してはいないが取り合えず例を挙げた）
4. DESIGN
この章では具体的な実装について説明する。全体の構成について紹介し、次にtyped link とattributesについての評価の流れについて議論する。attributesについては宣言、エラーの扱い、単位の変換を含む。我々の提案するシステムをどのような形で実現しようか考えたところ、我々のシステムがほとんどRDFによって表現されうる事に気がついた。Typed linkは基本的にRDFリソース間のRDF特性（プロパティ）について述べているし、attributeは記事とRDFデータリテラルの間の特性と一致する。またRDFとRDFSをシステムに採用することによりwikipediaの運営に不可欠で適当なフリーソフトも利用できる。またクエリー言語であるSPARQLにより簡単なデータアクセスが実現でき、RedlandのようなRDFソフトウェアライブラリにより外部からWikipediaを利用することも容易になる。全体のシステム像は図５のようになる。
4.1 Typed Links
次にMediaWiki内のTyped linkの入力、処理、出力の具体的な構造について説明していく
Typed linkはRDFのプロパティに対して適切なURIを生成するために使われる文字列でありユーザがデータタイプを宣言する必要がなく、また自由にlinkに名前をつけることが可能である。しかしスキーマ情報が完全に欠如しているとアノテーションのタスクが困難となる。そしてたくさんの名前が同じ関係を表すのに使われていたり、同じ名前が異なる意味で使われるということが起こる。これらの問題は現在のwikipediaでも問題となっているがそれほど致命的な欠陥でもない。しかしこの問題に取り組むことによりほとんどの記事にたいして人間が可読な特殊な記事を作り出すことが可能となる。また同様にして（これもメタデータを増やし誤解が生じないようにする工夫？）Relationという名前空間を導入し二つの記事の間の関係を記述できるようにする。（たくさんの名前が同じ関係を表すのに使われているという問題に対処できていない例を示す。戦国大名というカテゴリがあったとする、このとき「織田」と「織田信長」が同一人物であるにもかかわらず違う人物としてリストに列挙されている場合が考えられる。このような問題を避けるためにスキーマ情報を増やして対処しようということである。）
これらを追加したにもかかわらず、ユーザによって入力されたtyped linkの処理は関係に関する記事を含まない。だからストレージのバックエンドとして働くRDFトリプルストアに蓄えられるRDFトリプルにtyped linkを変換するためにローカルデータソースのみアクセスされる必要がある（意味不明）
トリプルストアが記事に含まれていない情報を含んでいないということを確実にするため、我々は期限切れのトリプルを新しい情報を保存する前に削除しなければならない。
まとめるとユーザーによって引き起こされる記事の更新には次の３ステップがある
構文解析により記事からリンクタイプを抽出する
セマンティック情報をRDF tripleに変換する
古いtripleを削除して新しいtripleに更新する
これらの操作は最小限のリソースで遂行されトリプルストアの更新は記事が保存された後に非同期的に達成される、編集が同時に行われることによって起こる衝突はMediawikiソフトウェアによって発見され解決される。（データの衝突、記事の更新時に古いデータが残ってしまう危険性の回避？）
また我々のシステム構造はトリプルストアに検索要求をかけることにより現在のセマンティック情報にはいつでもアクセス可能になる。これは非常に便利である。なぜならセマンティックデータ上で動くアプリケーションがストレージインタフェースを参照するにあたって残りのシステムとは独立して実行できるからである。（良くわからないが処理速度の向上？）
4.2 Attributes
このセクションでは正式に属性データの語彙表現とXMLスキーマが表現するところのデータを関連付けて行きたいと思う。これを実現するには、エラー処理や単位の問題を考える前にセマンティック属性のデータタイプの宣言について十分に考える必要がある。
4.2.1 Value Processing and Datatypes
属性に関してまず最初に難しいことは、与えられた属性値を正しく認識することである。属性値はリンクとは違い構文解析を行ってその意味を見つけ出さなくてはならない。それゆえ適切にフォーマットすることはtyped linkと比べるとずっと難しくなる。
形式的にvalue spaceとlexical spaceというものを区別する。例えばvalue spaceは整数の集まりで、lexical spaceは整数値を表現する文字列の集まりである。RDFにおいてデータタイプを表現するときに似たような概念化が行われるが、それはXSDに基づいている。
現在wikipedia内で属性の支援をXSDデータタイプに基づいて行うことを試している。本当はRDFトリプルのデータの値を蓄えるのにXSD表現を使いたかったのだが、英語以外の言語の人が使えないという欠点があったので、ユーザがWikipediaの所定のlexical spaceからデータを入力できるようにした。これはXSDのlexical spaceとは同じではない。形式的にデータ表現の間にある２つの変換を組み合わせる。１つはWikipediaのlexical spaceとXSDのvalue spaceの変換、もう一つはvalue spaceとXSDのそれに相当するlexical spaceの変換。このようにすることによりあらゆる言語の人が編集してもデータの互換性を保つことができるようになるのである。
ユーザに属性のデータタイプを宣言させるために、我々は新しくWikipediaに”Attribute”という名前空間を導入した。記事の中に関係とカテゴリーの時と同じように人間が可読な記述を与えることもできるがさらにデータタイプを明記したセマンティック情報も加えられるようにする。新しい統語構造の量を最小化するために我々はデータタイプのための３つ目の名前空間である”Type”を導入する。そして、内蔵されたセマンティックとの関係を使って、我々は単純に[[hasType::Type:integer]]と書けばよいだけにする。これは３．４節で説明されたテンプレートの作成を容易にする。
一般的な作業の流れは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のツールではmileとkilometerのような異なる単位系統同士を比較できないということである。
そこで解決策として、ひとつは我々の手により自動単位変換を行い大部分のデータを同じ単位としてデータベースに蓄えてやる。もう一つは単位変換がまだサポートされていないものについてもその単位を認識し他の単位の値と混合するのを避けようとする事である。
単位の自動変換において重要なことはスタンダードな単位をできるだけ少なくするということ（たくさん単位があるとわかりづらいのである程度統一してしまおうということ）と、ユーザが直感的に単位の自動変換が行われたのだとわかることである。
形式上、単位サポート機能の追加が、Wikipediaのデータタイプのlexcical spaceを拡張したことになる。したがって単位情報もまたデータタイプによって与えられるようになる。
5. CURRENT IMPLEMENTATION
セクション４で説明した重要な部分はもうすでに実装した。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も登場してきている。
0 件のコメント:
コメントを投稿