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

第3回 Physical Web技術解剖(2)-Metadata Resolver

この記事を読むのに必要な時間:およそ 3 分

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>
注2)
上記のサンプルデータはhttp://json-ld.org/上のサンプルをそのまま拝借しました。

このように,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との比較を行っていきたいと思います。よろしくお願いします。

著者プロフィール

加藤亮(かとうりょう)

ソフトウェアエンジニア。

比較的プロトコルとフロントエンド寄り。

2014年7月よりリクルートテクノロジーズアドバンスドテクノロジーラボ所属。