gihyo.jpサイトのロゴ

WebエンジニアにとってのIoT　～Physical Webが拓く未来～

第3回Physical Web技術解剖（2）－Metadata Resolver

2015-04-10

第2のポイント－Metadata Resolver

前回は技術的な概要のうち、UriBeaconについての解説をさせていただきました。今回はもう1つのポイントであるMetadata Resolverについて解説をして行きます。

Metadata Resolverは、現状ではUriBeaconと違い、しっかりとした規格は用意されておらず、あくまでリポジトリのコードの中で利用されているに過ぎません。

しかし、その現状の仕様や、Physical Webの今後の応用について考えていくと、やはりこちらも重要な役割を担う可能性を持っていることがわかってきます。

サーバサイドのコードは、Pythonで用意されているものがこちらで確認できます。

連載第1回の概要説明で簡単には説明しましたが、今度はもう少し詳細を加えながらそのフローを見て行きましょう[1]⁠。

Metadata ResolverのInterface

対応アプリケーションがUriBeaconから放出されたアドバタイジングパケットをスキャンすると、その中から抽出したURLについてMetadata Resolverに問い合わせるのでした。

図1　抽出したURLについてMetadata Resolverに問い合わせる
図1　抽出したURLについてMetadata Resolverに問い合わせる

Request

問い合わせたいURLについて、次のようなJSONの文字列を作成し、POST BODYとしてリクエストを送ります。上記で紹介したPythonのWebアプリケーションのコードでは/resolve-scanのパスに対して問い合わせるようになっています。

{"objects": [{"url": "http://goo.gl/f7BSAj"}]}

次のように複数のURLについてまとめて問い合わせることも出来るようになっています。

{"objects": [
  {"url": "http://goo.gl/f7BSAj"},
  {"url": "http://goo.gl/EKqGSz"}
]}

Response

次のようなJSONがレスポンスデータとして返ることになっています。

{"metadata":[
  {
    "id":"http://goo.gl/f7BSAj",
    "title":"The Physical Web",
    "url":"http://google.github.io/physical-web/",
    "icon":"http://google.github.io/physical-web/images/logo-black.png",
    "description":"Walk up and use anything",
    "json-ld":[]
  }
]}

次のようなパラメータを持つオブジェクトが渡されているのがわかると思います。 これがMetadataになります。

  • id
  • title
  • url
  • icon
  • description
  • json-ld

複数のURLについて同時に問い合わせたのであれば、次のようになります。

{"metadata":[
  {
    "id":"http://goo.gl/f7BSAj",
    "title":"The Physical Web",
    "url":"http://google.github.io/physical-web/",
    "icon":"http://google.github.io/physical-web/images/logo-black.png",
    "description":"Walk up and use anything",
    "json-ld":[]
  },
  {
      "id":"http://goo.gl/EKqGSz",
      "title":"google/uribeacon · GitHub",
      "url":"https://github.com/google/uribeacon",
      "icon":"https://avatars2.githubusercontent.com/u/1342004?v=3\u0026s=400",
      "description":"uribeacon - The Web Uri Open Beacon for the Internet of Things",
      "json-ld":[]
  }
]}

Metadata

名前と実際に返された値の組み合わせを見れば、何となくはわかると思いますが、各パラメータについて解説をしておきます。

また現状のコードの中で、それぞれのパラメータがどのように取得されているかも合わせて見て行きましょう。

id

この値はリクエストの時に使ったURLになります。

url

idの値が短縮URLでなかった場合は、idの値と同じURLになります。idの値が短縮URLだった場合には、それを展開した最終的なURLになります。

title

URLの先が示すHTMLドキュメントのtitleになります。ソースコードを追うと、次のようなxpathを使い、フォールバックしながら値を取得していくのがわかります。

  • //head//title/text()
  • //head//meta[@property='og:title']/attribute::content

つまり、次のようなHTMLのtitleタグから取得するか

<head>
  <title>ここから取得</title>
</head>

それが無かった場合はOGPで指定されたtitleを探すわけです。

<head>
  <meta property="og:title" content="あるいはここから">
</head>

description

こちらもtitleと似たような感じで、次に挙げたxpathを順番に試していくようになってます。

  • //head//meta[@name='description']/attribute::content
  • //head//meta[@property='og:description']/attribute::content
  • //body//*[@class='content']//*[not(*|self::script|self::style)]/text()
  • //body//*[@id='content']//*[not(*|self::script|self::style)]/text()
  • //body//*[not(*|self::script|self::style)]/text()

500文字以上はカットしていたり、titleと同じであれば他の候補を使うようにしていたりしています。より詳しく知りたい方は実際にソースを読んでみると良いでしょう。

icon

iconも同様に次に挙げるxpathを順番に利用して値を取得しに行きます。

  • //head//link[@rel='shortcut icon']/attribute::href
  • //head//link[@rel='icon']/attribute::href
  • //head//link[@rel='apple-touch-icon-precomposed']/attribute::href
  • //head//link[@rel='apple-touch-icon']/attribute::href
  • //head//meta[@property='og:image']/attribute::content

これらから適切なアイコンの情報を得られなかった場合にはfavicon.icoを利用しようとします。

json-ld

現時点ではコードの中に存在するだけで、実際になんらかの拡張に使われているわけではありませんが、将来的にここを利用して、上記の基本的なデータ以外のデータも扱えるようにしていることがわかります。

データはJSON-LD（JSON for Linking Data）で記述します。

resolverでは、次のxpathを使って取得しています。

  • //head//script[@type='application/ld+json']/text()

なので、HTML側ではこのように記述しておけば良いことになります[2]⁠。

<head>
 <script type="application/ld+json">
 {
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
 </script>
</head>

このように、titleやicon（thumbnail⁠）⁠、descriptionなどの非常にベーシックなデータ以外の情報を渡したいときには、この部分を利用することが出来るようになっています。

Metadata Resolverの有用性と今後について

Metadata Resolverの振る舞いについて見てきましたが、そもそもこのエンドポイントがないとどのように困るのでしょうか？　ビーコンからURLを受け取ったアプリ自身が処理をするのとどう違いが出てくるのでしょうか？

まずわかりやすい部分として、拾ったURLが短縮サービスを使ったものだった場合、その展開のためのラウンドトリップを削減することが出来ます。また、resolver側でキャッシュを利用することで、キャッシュが効いているうちは時間をかけずに情報を取得することが出来るようになります。

URLが指し示す先のコンテンツが非常に大きいサイズである可能性もあります。モバイルのパケット代もタダではないので、こういうケースを考えるとバックグラウンド動作中に自動で直接取得しにいくのは問題となるでしょう。

また、将来spamとして振る舞うビーコンなどが出現した際には、フィルタリングなどをかけることが出来るポイントとして非常に重大な役割を担う可能性もあります。

以上のように、このresolverが重要なポイントであることは間違いないのですが、始めに説明した通り、UriBeaconと違い規格化などは進められておらず、まだ実験的に用意したものをサンプルとして使っているに過ぎません。

それは、明解な単一機能のUriBeaconの役割に比べると、まだ議論の余地があり、規格化を考えるにはまだ早いと言うことなのかもしれません。

上記のspamの例や今後でてくるであろうセキュリティに関する課題、DNSのように分散的な運用を目指すのか、あるいはGoogleのような特定の業者がサービスとして持ってしまうのかという運用に関する問題、さらに今回紹介したJSON-LDのような拡張を利用した応用の余地など、議題はたくさんあり、もう少し時間をかけた議論は確かに必要に見えます。

そんなわけで、今後、PhysicalWebの議論の中でMetadata Resolverがどのように扱われていくのかは注目すべき点となるでしょう。

次回について

次回はAppleのiBeaconとの比較を行っていきたいと思います。よろしくお願いします。

おすすめ記事

記事・ニュース一覧