9/12 追記
GitHubにプロジェクトを立てて、コンセプト説明用のWebページを置きました。ここに書いたものからは諸々変わっています。
https://minomo.github.io/
前置き
Physical Web とは
- Googleの提唱する、物や場所とWebコンテンツ/サービスを繋ぐオープンな標準規格
- BeaconからブロードキャストされたURLをスマホ等で受信し、そのURLへブラウザ等でアクセスして情報やサービスの提供を受ける。
- Webコンテンツへ誘導するだけなのでサービス毎に専用のアプリなどが不要。（Google ChromeがURLスキャンに対応済み）
- 周囲のBeaconの確認やWebコンテンツへのアクセスはユーザーが自発的・能動的に行う。Beaconの受信範囲に入っても通知はされない。
現在紹介されている利用例は、Beacon受信を起点とするというよりは、ユーザー操作を起点としたプル型のソリューションになっている。
Beacon Platform とは
- Beaconに付属情報を紐付けて登録し、その情報をAPI経由で取得できるGoogleのサービス
- Eddystone-UIDやIBeaconのような識別IDだけを送信するタイプのBeaconに付属情報を紐付けることができる
- Beaconを利用するアプリを登録しておくと、Nearby Notificationsを有効にしているAndroidデバイスがBeaconを受信した際に、当該アプリのインストールを即す通知を表示させることができる
- Attachment情報はそれぞれのサービス毎に自由な形式で登録できる。
Beaconに紐付けて登録された情報は、そのBeaconを登録した事業者が提供するサービスからだけ利用されるというのが前提だと思う。
実現したいこと
Beaconの設置と、そのBeaconを利用するアプリが密結合してサービスを提供するのではなく、Beacon受信をトリガとして、様々なBeaconデバイスと様々なサービスが、IFTTT等でのトリガ/アクションの関係のように、自由な組み合わせで繋がるオープンなネットワーク。
そのために
Beacon設置者側が実行させたいアクションを自らのコントロールのもと実行させるという発想を転換して、Beaconは様々な受信側システムから認識してもらうためのトリガ情報だけを発信し（後続アクションに対しては期待はしても関与はしない）、受信側システムの方が「どのようなトリガを対象にどのようなアクションを実行するか」をコントロールする、という自動アクションのための標準規格を提案する。
Beaconを受信するどのようなシステムからも「発信元デバイスが何であるか、あるいはその発生を通知された出来事がどのようなものであるか」を認識可能とするメタデータのオープンな標準規格を策定し、Beaconはそれに従ったトリガ情報を発信する。
トリガ情報の受け渡しは次のいずれかで行う。
（Beaconが発信できるアドバタイジングパケットには短いデータしか含められないので）
Eddystone-URLに準拠したBeaconデバイスが発信するURLの指し示す先のWebドキュメントにメタデータを記述
Eddystone-UID, IBeacon, AltBeaconに準拠するBeaconデバイスは、Google Beacons Platform上にIDと紐付けてAttachment情報を登録
Googleのサービスに依存しない前者が望ましいが、後者はIBeaconなどの別の規格のBeaconも利用できる
それにより
Beacon発信デバイスの製造者
- 常時または特定の事象の発生したタイミングで
- デバイス独自のトリガURLまたは、デバイス設置ユーザーの設定したURLを
- Eddystone-URLの仕様で発信する機能をデバイスに持たせるだけで
-
自社デバイスを「世界中の様々な受信側システムからトリガとして利用可能なWoTデバイス」とすることができる。
仕様が固まらないうちに先走りで製造・出荷してしまっても、出荷時に想定しなかった新たなサービスで扱ってもらいたい場合でも、ネットに直接接続しておらず更新が困難である場合の多いデバイス側の更新を行う必要はなく、Webデータだけを更新すればよい。
受信側システムの提供者
- 当規格に準拠したメタデータを格納したWebドキュメントのURLをEddystone-URL経由で受信したタイミングで
- メタデータを解析し、そのシステム独自のルールまたはシステム利用者の定義したルールに従い
- 何らかの自動処理を行う機能を提供することで
- 世界中の様々なデバイスを自社サービスのトリガとして利用することができる。
利用者
- 利用したいデバイスの機能を活用するために専用アプリをインストールしなくても
- 利用したいサービスを活用するために専用デバイスを購入しなくても
- 様々なデバイスと様々なサービスを自由に選んで組み合わせて利用することができる
Examples
上記標準規約に従ってトリガ情報を発信するBeaconや、それを受け取るシステム/サービスが普及した場合に、実現されるであろうシナリオを以下に示す。
シナリオ１：
無くしては困る大事な小物にEddystone-URLを発信するBeaconを付けました。
通常時は他人から探索されて欲しくありませんので、そのBeaconが発信するURLの指し示す先にはトリガ情報は記述しません。
自身のスマホには、このURLのBeacon信号を一定期間受信しなければアラートを出すレシピを登録しています。
...アラートが出ました。
どこかに置き忘れてしまったようです。Webドキュメントを更新してトリガ情報を加えましょう。
[Lost Things]汎用トリガが適当です。このトリガでは、位置情報通知用の[End Point]が指定できます。
公開レシピ『[Lost Things]汎用トリガを受信すれば（正確に言えば当該トリガのメタデータが記述されたWebドキュメントを指すEddystone-URLを受信すれば）、指定の[End Point]に匿名で位置情報を送信する。』を登録しているユーザーも増えています。
...早速位置情報が送られてきました。すぐに回収に行きましょう。
[Lost Things]には、[schema:Product]だけでなく[schema:Person]や[Pet]も含み、それぞれに応じたプロパティを記述することができます。
児童や認知症患者の見守り用として似たようなシステムが既に有りますが、それらの場合は専用のBeaconデバイスを対象の児童・高齢者に持たせ、かつ近在の協力者に専用のアプリをインストールしてもらう必要がありました。
このシステムなら、安価な汎用Eddystoneデバイスと、様々な用途に利用できる汎用アプリ、あとは個々のWebドキュメントだけで成立します。
送られた位置情報を利用者に転送するEndPointと、そのEndPointを指定した[Lost Things]専用トリガURLを、セットで提供するサードパーティサービスも登場するでしょう。
シナリオ２：
複数の有力小売事業者が、拡張トリガ[Coupon]のスキーマを定義して公開しました。
多くの事業者がこのスキーマを採用すると表明したため、IFTTT等の「Physical Webチャネル（仮）」で、このトリガが条件に使えるようになっています。
駅に直結する商業ビルでは入口にBeaconを設置して、このスキーマに基づく[Coupon]を配布しています。
今日は[xxxx]と[yyyy]の２つの[Brand]が、[Twenties]の[Women]を[Target]とした[Coupon]を配布します。
Beaconが発信するURLの先には、メタデータだけでなく顧客にアクセスしてもらうWebコンテンツも用意しています。
自分の指定した条件に合致する[Coupon]の受信でプッシュ通知を受けるようにレシピを登録したユーザーが通りかかれば、高い確率で来店が期待できるでしょう。
毎日の発信情報の更新でBeaconを操作する必要はありません。Webドキュメントをメンテするだけです。
シナリオ３：
高齢の母親が一人で済む家に、受信したEddystone-URLをWebサービスに転送するホームゲートウェイを設置し、このゲートウェイから[Event Logging]トリガURLが転送されてくれば、別のサービスに記録するレシピを登録しました。
多くの家電製品が操作イベントを[Event Logging]トリガとして、（同室内程度の近接範囲に）Eddystone-URLで送る機能を提供するようになったので、面倒な設定の必要もなく生活状況を記録することができます。
所有する家電にこのような機能が付いてなくても、それだけのために買い換える必要はありません。汎用のモーションセンサー付きのBeaconを居室のドアに付ければ部屋への出入りを見守ることができます。人感センサーや温度センサーも役立つでしょう。
記録されたログを分析して、不審な状況があれば通知するサードパーティサービスも登場するでしょう。
シナリオ４：
自宅のドアに開閉センサーを取り付けました。ホームゲートウェイが開閉トリガを受信したにも関わらず、自分のスマホが同じトリガを受信しなければアラートするようにしておけば、簡易的な侵入検知システムの出来上がりです。
番外：
Beaconを受信すると、トリガ情報を独自解釈してゲーム内イベントを発生させる位置情報ゲーム
Rad freedom of handling of the trigger!
仕様
データフォーマット
JSON-LDとする。
人間向けに提供されるHTML文書にscriptタグで挿入しても、単独でContent-Type:application/ld+jsonで送出することもできる。
※ 現在公開されている Physical Web Service （リゾルバ）にもHTMLドキュメントからJSON-LD形式のメタデータを取得するコードが含まれている。
データ定義（未策定）
デバイスやイベントを分類・認識するためのメタデータスキーマを新たに策定し、トリガの種類ごとに必須orオプションのプロパティを定義する。
各属性項目の定義にはFOAFやschema.org等既存のスキーマを利用する。
汎用のデータを送りつつ自社サービス専用で利用する専用のデータも扱う、等の目的で独自の拡張スキーマを定義してもよいものとする。
今後の予定
- 英語でドキュメント作成
- physical-web-discuss@googlegroups.com あたりに提案
- GitHubにプロジェクト立てる
- プロジェクト説明のページ
- データ定義のリポジトリ
- 実際に動くサンプル/デモ
できるだけたくさんの方からのご意見を頂きたいと思っています。また、一緒にプロジェクトをやっていただける方を歓迎します。