Open Geodata Reuse: Towards Natural Language Interfaces to Web APIs
著者
ミュンスター大学地理情報学研究所
読んだ理由
タイトルとアブスト読んで面白そうだなーと思ったため
どんなもの?
APIを利用したい時、学習コストが大きい
加えて既存のAPIは単一の提供者が提供する機能をカプセル化することに成功しているが、シナリオやWeb全体でのAPIの再利用で問題あり
本研究はOpen Government datasetsに対して、利用者が学習しやすいようなWeb APIの設計について提案
API design、自然言語のterm、地理情報検索の3つを組み合わせることによって達成
参考)Open Data
2600以上のオープンデータポータル
先行研究と比べてどこがすごい?
3つの違い
その1:API Design
既存: Web APIに高度な機能を提供し、Webでの情報の取得とタスクの実行を自動化することを目的としている
本研究:シナリオ全体で学習の労力を最小限に抑えることを目的としている
その2: NLP
既存:自然言語の用語を使用してAPIの作成を容易にするアイデアの追求
本研究:APIの使用、つまりAPIを介したデータセットの取得に焦点
その3: NLP
既存:NLPのアプローチ
本研究:NLPのアプローチ。ただしAPIクエリ用のNLPインターフェイスの学習性に焦点
API全体で学習の労力を減らすことを目的として、地理データセットを公開するAPIに使用できる設計規則を模索
(これ4つめでは?)
技術や手法のキモはどこ?
既存のopen government data (OGD) はCKAN, DKAN, Socrata, and Junaなどで提供されている
CKAN:
/api/action/package_search?q={QUERY}
/api/action/resource_search?query={QUERY}
Socrata
/resource/dataset.json?{PARAMETERS}
上記形式の問題点
地理情報の空間的、時間的、主題的なコンポーネントがすべて同様に扱われている点
データセットのfilterに使えるパラメータに慣れるために時間がかかる点
提案するRestful APIのデザイン
3つのパラメータ (Space, Theme and Time)
(1) api/:time
(2) api/:theme
(3) api/:space
組み合わせたり
(1) api/:time/:theme and api/:theme/:time
全部入りでも
(1) api/:time/:theme/:space (略)
すなわち順序を問わない
実装
ユーザーの入力からパラメータを抽出(sherlock.js)
リクエストが themeとtimeに属さない場合、OpenStreetMap nominatim APIを呼び、結果をMongoDBに格納
Postman を使用してリクエストを行うクライアントをシミュレート
現在の実装では、一致するデータセットを返す検索は、データの内容ではなくメタデータに対して行われる
学習性の評価では、NLI APIと非NLI APIを比較しない
理由:
(i)API学習性のベンチマークが不足(つまり、利用可能なAPIはたくさんあるが、使いやすさや学習性の指標に関するパフォーマンスに関する文書がめったにない)
(ii)RESTful APIのタイプの分類法が欠如している
どうやって有効だと検証した?
lab baseで20名の参加者で評価
実験の流れ
インフォームドコンセントに同意
APIへの精通度合いとAPIの使用頻度について質問
APIドキュメントに進む
8つのタスクを行う(15の組み合わせをカバー)
https://gyazo.com/bb97e9db56301a9a216707172dc13161
Web appで実験
https://gyazo.com/f0c0e2116752008d7335e930ebde46ca
結果
参加者全員8つの質問に正しく答えられた
タスクに取り組む前に約6分±52秒でドキュメントに精通した
https://gyazo.com/1a546bcab8c1d36a425afd949c81fba0
タスク6以外はすべて1回の試行
タスク6はユーザーがいくつかの追加パラメーターの入力を要求することにより、自然言語のみのアプローチからわずかに逸脱したタスク
クオリティフィードバック
「このAPIを使用してクエリをすばやく書く方法を学んだ」
90 %が強く同意、10 %が同意
「このAPIをどう使うかを学ぶのは簡単だ」
95 %が強く同意、 5 %が同意
「APIの使い方を簡単に思い出せた(覚えられた?)」
50 %が強く同意、 45 %同意、 5 %がどちらとも言えない
「APIの満足度」
85 %がとても満足、 15 %が満足
すべての参加者(100%)が、APIを他の人に推奨することに熱心である
議論はある?
この形式を標準化して各オープンデータ提供者が準拠するのだろうか
データサイズ大きくなった時のスケール問題、既存のAPIのmigrationが気になった
以下はメモ
2600以上のオープンデータポータル
Tracking the ‘true prevalence and impact of open data initiatives around the world’ is one of the goals
3rd editionでは “More elaborated APIs that facilitate access to data are still very rare among government data”
より 'elaborated'な web APIsを実現するためのアイデアが提案されている
semantic APIs
typeにしたがってデータを取得するAPI
smart API
54のAPIメタデータ要素を含むメタデータテンプレート(見つけられる可能性を向上するため)
APIは単一のプロバイダーが提供する機能をカプセル化することに成功しているが(そのため、コードの再利用が容易になります)が、シナリオやプロバイダー全体でのWeb APIの再利用で問題あり
新しいAPIが出ても学習コストがかかってしまう
APIの3つのkey roles
契約(contracts)
開発者は並行して独立して作業できる
境界(boundaries)
開発者は同僚から分離されて自分の作業に集中できる
コミュニケーションメカニズム(communication mecanisms)
開発者が話し合うべきことを定義することにより、開発者間のコミュニケーションを容易にする
プロバイダーに依存しない方法で機能を抽象化するメカニズムがなければ、小さな組織やコミュニティ内ではAPIは上記3つの役割を果たすことで成功するが、Webの規模では失敗する。
研究の目的は自然言語の用語を使用してAPIをクエリする方法を提案およびテストすることにより、WebスケールでAPIプロバイダー全体で再利用できるようにすること
web API
API for geographic information retrieval
API design
地理参照されたopen government dataは都市データに近い
Webにおける地理情報検索
Open Geospatial consortiumの活動を通じて、新たにいくつかの標準がある
Webマップサービス(マップ画像の取得)
Web機能サービス(地理的特徴の取得)
センサー監視サービス(リアルタイムセンサーデータの取得)、
SensorThings API(IoTの相互接続)
RDF(Resource Description Framework)形式で地理データセットを提供するAPIは、GeoSPARQLを介してクエリを実行できる。
既存研究:GeoSPARQLに基づく視覚クエリを調査して、セマンティックの専門家ではないユーザーへのジオデータ取得を容易にする
本研究:API全体で学習の労力を減らすことを目的として、地理データセットを公開するAPIに使用できる設計規則を模索