検索技術が創造する新たなコンテンツ
利用者から見た検索サービス
- さがす - たしかめる - 発見する
- 検索の過程で、ユーザの知識や意識などが変化していく
- 曖昧な状態から整理された状態、さらに新しい切り口へ
知りたいことを探す
- 資源発見のためのアクセスポイント
- どのような項目で検索ができるか
- 属性指定検索と全文検索
- キーワード(統制語彙 vs タグ)と分類
- 検索結果の指標
- 精度(pricision):検索結果のうち適合するものの割合
- 再現率(recall):適合するもの全てのうち、検索できた割合
- 精度と再現率は一般に反比例、何が「適合する」ものかは曖昧
役立つかどうか確認する
- 識別、同定のためのメタデータ
- 検索結果を直接閲覧することなく、適合するものかどうかを確かめる
- タイトル、著者、日付などの基本情報
- 抄録、要約
- ISBN、URI、請求記号(配架番号)
- メタデータを、誰がどうやって付与するか
- 検索結果を直接閲覧することなく、適合するものかどうかを確かめる
- 検索結果を扱いやすく並べる
- 検索結果が非常に多い場合、適合度などでの順位付けが必要
- 索引語句の重み付け
- 検索結果のランク付け
- リスト表示以外に、ネットワーク型、地図型などの可視化方法
- 検索結果が非常に多い場合、適合度などでの順位付けが必要
発見し、発展させる
- 検索とブラウジング
- 書架などに分類配置されたものを眺めてさがす
- 目次、ハイパーリンクをたどりながら欲しい情報を探す
- 検索結果を「ブラウジング」する
- 最初に思い描いた目的とは違うところに、意外に面白いものが
- ノイズの中に新しい展開の種が
- 検索結果の組み合わせと発展
- 検索結果に付加価値を与えて、発展させる
- 位置情報データ+地図、日付データ+カレンダーなどの組み合わせ
- シソーラスや統計的クラスタに基づく連想検索
- 検索APIを利用した、検索結果組合せ・表現の新サービス
- 検索結果に付加価値を与えて、発展させる
全文検索と属性検索
- 全文検索
- 一般に高再現率、低精度
- 大きなリソースを必要とするが、自動化しやすい
- 属性検索
- うまく使えば高精度。再現率は低くなる可能性
- 多くの資源に適切な属性値を与えるのは高コスト
コンテンツ提供者とメタデータ
- メタデータ提供のコストを下げる
- コンテンツ作者に意識させず、可能な限り自動化する
- 既存の仕組みを生かしつつ相互運用性を高める
- XHTMLとメタデータ
- meta、link、dfnなどメタデータを表現できる要素を活用
- XSLTを用いてRDFに変換する方法もある(GRDDL)
- CMSツールからのメタデータ自動生成
- データ交換モデルとしてのRDF
- データベースやウェブサービスは独自のスキーマでデータ蓄積
- スキーマをRDFにマッピングすることで、データの交換・共有が可能に
RDFクエリ言語SPARQL
- セマンティック・ウェブのSQL
- RDFデータベースからグラフのパターンにマッチする部分グラフを取得
- SELECT, WHEREなど、SQLによく似た構文
- グラフパターンは、turtle型のトリプル列挙で記述。名前空間接頭辞も使える
(例)
PREFIX rss: <http://purl.org/rss/1.0/> PREFIX dc: <http://purl.org/dc/elements/1.1/> SELECT ?title ?date WHERE { ?item rss:title ?title . ?item dc:date ?date . FILTER (?date >= "2006-01-01") }
WSをつなぐSPARQLプロトコル
- やり取りのためのプロトコル規格も定義
- WSDL2.0に基づくHTTP、SOAPのバインディング
- ウェブサービス間の標準的な検索構築も可能
SPARQLを使ってみる
- 写真に写っている人物の検索
- 写真のどこに誰が写っているかを記述するRDF
- 検索結果からスタイルシートで写真の該当部分だけを表示
- コンサートカレンダーの検索
- iCalendarをRDFとして記述する語彙とカレンダー表示スタイルシート
- 検索結果をCONSTRUCTによって元のRDF/XMLと同じ書式にし、スタイルシートを適用
- 位置情報データと地図との組み合わせ
- GPSカメラで撮影した写真データのRDF
- 緯度経度を範囲で検索
- 結果を地図上に表示