List of Metadata [text.Baldanders.info]

ブログ記事に OGP article メタデータを追加した

2026-08-10T06:20:48+00:00

他所のブログ記事を眺めてたら <head> 要素内のメタデータに

<meta property="article:tag" content="foo">

みたいな記述が見える。 article なんてあったか？と思い，調べてみたら，どうやら OGP の中で定義されている語彙（vocabulary）のようだ。

オブジェクトタイプに article を指定する

article を使うためには prefix に article の語彙を定義し og:type に article を指定する。

<html>
<head prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#">
  ...
  <meta property="og:type" content="article">
  ...
</head>

content 属性は本来リテラルデータを指すので内容に（RDF 上の）意味はないのだが，どうやらただの文字列ではなく， Web 上のリソースを指定しなければいけないようだ。したがって <head> 要素に

<meta property="og:type" content="article">

と書きたければ <head> 要素の prefix 属性を使って

<head prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#"> ... </head>

のように記述する必要がある。まぁ RDFa の設計思想的には間違ってるけどね。もう，私は気にしないことにしている。

OGP では article を含め，以下の語彙が定義されている。

IRI	resource	types
`music`	`https://ogp.me/ns/music#`	`music.song`, `music.album`, `music.playlist`, `music.radio_station`
`video`	`https://ogp.me/ns/video#`	`video.movie`, `video.episode`, `video.tv_show`, `video.other`
`article`	`http://ogp.me/ns/article#`	`article`
`book`	`http://ogp.me/ns/book#`	`book`
`payment`	`http://ogp.me/ns/payment#`	`payment.link`
`profile`	`http://ogp.me/ns/profile#`	`profile`
`website`	`http://ogp.me/ns/website#`	`website`

これ以外の語彙が欲しいなら独自に定義するしかない。

article のメタデータ

article の語彙で使えるメタデータは以下の通り

property	content	description
`article:published_time`	ISO 8601 形式の日時	記事の公開日時
`article:modified_time`	ISO 8601 形式の日時	記事の最終更新日時
`article:expiration_time`	ISO 8601 形式の日時	記事の有効期限
`article:author`	`profile` リソース	記事の著者情報
`article:section`	文字列	記事のセクション（カテゴリ）
`article:tag`	文字列	記事のタグ

article:author に正しくリソース（通常は URI）を指定している Web ページを見たことがない（笑）みんな名前を文字列で書いてるっぽい。私も profile の語彙でわざわざメタデータを書く気にならないので，名前の文字列をセットしている。文法的には content 属性はリテラル値なので，ただの文字列でも文法上はエラーにならないのだが。

article:author や article:tag が複数ある場合は <meta> 要素を複数書けばよい。

<meta property="article:tag" content="foo">
<meta property="article:tag" content="bar">

article:section や article:tag には文字列を指定するとあるが，それって意味なくね？普通はセクションやタグの情報を示すリソースを示すものなんじゃないのか？

OGP は，やっぱり OGP だった

以上を踏まえて，このブログサイトも <head> 要素に OGP の article メタデータを追加している。まぁ article メタデータがどのくらい活用されているのかは分からないけど。しばらくは様子見ということで。

OGP は（RDFa に則ってるのに）相変わらずセマンティック・ウェブからかけ離れたところにいるのがいい感じである（笑）

ブックマーク

JSON-LD に対応してみた

2017-11-17T14:40:05+00:00

以前，このサイトを Twitter Cards に対応させたのだが，今回も思いつきで JSON-LD に対応させることにした。

JSON-LD - JSON for Linking Data

JSON-LD の特徴は複数の情報のかたまりを IRI¹ で繋ぐことで複雑なデータ構造を記述できる点にある。これを使ってネット上のリソースのメタデータとその関係を表現するわけだ。

ただし Web ページの場合は， RDFa や Microdata などと違って，語彙を HTML の要素に埋め込むことが出来ないため冗長にならざるを得ない。まぁ CMS を使ってサイトや Web ページを管理しているなら，一度テンプレート等を作ってしまえば済む話なので，大した手間ではないかもしれないが。

逆に RESTful API でメタデータを提供する場合は JSON-LD はかなり有力な手段となるだろう。

真面目に JSON-LD を扱うとなると相当凝ったことができるみたいだが²，今回は軽めに Google の検索サービスが解釈できる範囲で調整してみようと思う。

なお JSON-LD を導入するのなら Microdata の記述はページから削除することをお勧めする。 Microdata は未完成のまま開発が終了しており，もはや推奨されない。

Web ページに JSON-LD を埋め込む

JSON-LD を Web ページに埋め込む際は，以下のように <script> 要素で囲む。

<script type="application/ld+json">
{
  ...
}
</script>

メディア・タイプに注意すること。どうやらこの記述はページ内にいくつ置いてもいいようだ（少なくとも Google のテストツールには怒られなかった）。

<script type="application/ld+json">
{
  ...
}
</script>

<script type="application/ld+json">
{
  ...
}
</script>

JSON-LD の詳細

JSON-LD の中身だが，まずは @context と @type を指定する。

{
  "@context": "http://schema.org",
  "@type": "WebSite"
}

@context で語彙を定義するのだが，どうやら Google は Microdata の語彙（のひとつ）である schema.org を前提にしているらしい。 @type には schema.org で定義される content type を指定する。このサイトは一応ブログサイトなので，以下の content type を使うことにする。

更に，これらが参照する content type として以下も使用する。

まずは WebSite から。

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "WebSite",
  "@id": "https://text.baldanders.info/",
  "inLanguage": "ja",
  "name": "text.Baldanders.info",
  "url": "https://text.baldanders.info/",
  "publisher": {
    "@id": "https://text.baldanders.info/#org"
  },
  "author": {
    "@type": "Person",
    "@id": "https://text.baldanders.info/#maker",
    "name": "Spiegel",
    "url": "https://baldanders.info/profile/",
    "image": "https://text.baldanders.info/images/avatar.jpg"
  },
  "image": "https://text.baldanders.info/images/avatar.jpg",
  "description": "帰ってきた「しっぽのさきっちょ」"
}
</script>
<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Organization",
  "@id": "https://text.baldanders.info/#org",
  "name": "text.Baldanders.info",
  "logo": {
    "@type": "ImageObject",
    "@id": "https://text.baldanders.info/#logo",
    "url": "https://text.baldanders.info/images/avatar.jpg"
  }
}
</script>

@id は IRI を定義または参照する。 @id によって Organization のデータを publisher から参照しているのがお分かりだろうか。これをテストツールにかけるとこんな感じになる。

Structured Data Testing Tool (1)

publisher に Organization のデータが入っているのがわかると思う。

本来の schema.org の定義では publisher には Organization と Person のどちらも有効な筈なのだが，テストツールは Organization しか受け付けないようだ。これではうちのような個人サイトは大変に困るのだが，しょうがないので Organization にテキトーな情報を入れてお茶を濁している。何とかしてよ Google 先生！

次は Blog の情報をセットする。

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Blog",
  "@id": "https://text.baldanders.info/remark/",
  "url": "https://text.baldanders.info/remark/",
  "inLanguage": "ja",
  "name": "しっぽのさきっちょ",
  "description": "とりとめのない四方山話。",
  "image": "https://text.baldanders.info/images/attention/remark.jpg",
  "publisher": {
    "@id": "https://text.baldanders.info/#org"
  },
  "author": {
    "@type": "Person",
    "@id": "https://text.baldanders.info/remark/#maker",
    "name": "Spiegel",
    "url": "https://baldanders.info/profile/",
    "image": "https://text.baldanders.info/images/avatar.jpg"
  }
}
</script>

publisher の参照先は WebSite と同じなので省略する。これをテストツールにかけるとこんな感じになる。

Structured Data Testing Tool (2)

どんどん行こう。 BlogPosting はこんな感じ。

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "BlogPosting",
  "@id": "https://text.baldanders.info/remark/2017/11/qiitadon/",
  "url": "https://text.baldanders.info/remark/2017/11/qiitadon/",
  "mainEntityOfPage": "https://text.baldanders.info/remark/2017/11/qiitadon/",
  "inLanguage": "ja",
  "name": "Qiita って Mastodon やってたのか",
  "description": "私にとって今年最初の大外しは「GW 過ぎたら Mastodon のことなんかみんな忘れてる」だったが，本当に忘れていたのは私だけだったようだ。",
  "headline": "私にとって今年最初の大外しは「GW 過ぎたら Mastodon のことなんかみんな忘れてる」だったが，本当に忘れていたのは私だけだったようだ。",
  "keywords": "mastodon, communication",
  "image": "https://text.baldanders.info/images/attention/remark.jpg",
  "datePublished": "2017-11-10T13:49:58+09:00",
  "dateModified": "2017-11-16T10:09:40+09:00",
  "publisher": {
    "@id": "https://text.baldanders.info/#org"
  },
  "author": {
    "@type": "Person",
    "@id": "https://text.baldanders.info/remark/2017/11/qiitadon/#maker",
    "name": "Spiegel",
    "url": "https://baldanders.info/profile/",
    "image": "https://text.baldanders.info/images/avatar.jpg"
  },
  "license": "https://creativecommons.org/licenses/by-sa/4.0/"
}
</script>

Google 検索は BlogPosting の内容を参照している。 Google 検索が BlogPosting で要求するプロパティは以下の通り。

Properties	Data Type	AMP	non-AMP
`mainEntityOfPage`	`URL`	recommended	ignored
`headline`	`Text`	required	recommended
`image`	`ImageObject` or `URL`	required	recommended
`publisher`	`Organization`	required	ignored
`publisher.name`	`Text`	required	ignored
`publisher.logo`	`ImageObject`	required	ignored
`publisher.logo.url`	`URL`	required	ignored
`publisher.logo.height`	`Number`	required	ignored
`publisher.logo.width`	`Number`	required	ignored
`datePublished`	`DateTime`	required	ignored
`dateModified`	`DateTime`	required	ignored
`author`	`Person` or `Organization`	required	ignored
`author.name`	`Text`	required	ignored
`description`	`Text`	recommended	ignored

AMP (Accelerated Mobile Pages) と non-AMP で要求が異なるが，テストツールは AMP を前提にしているようで，これらのプロパティがないとエラーまたは警告を吐く³。

これもテストツールにかけてみよう。こんな感じ。

Structured Data Testing Tool (3)

最後に BreadcrumbList （パンくずリスト⁴）はこんな感じになる。

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "BreadcrumbList",
  "@id": "https://text.baldanders.info/remark/2017/11/qiitadon/#breadcrumb-list",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@id": "https://text.baldanders.info/"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@id": "https://text.baldanders.info/remark/"
      }
    }
  ]
}
</script>

Google 検索は BreadcrumbList の内容も参照している。 Google 検索が BreadcrumbList で要求するプロパティは以下の通り。

Properties	Data Type	Requirement
`image`	`URL`	optional
`item`	`Thing`	required
`name`	`Text`	required
`position`	`Integer`	required

上述のコードでは item を @id の参照先と繋げている。具体的には，最初の階層に WebSite データの @id を，2番目の階層に Blog データの @id を指定している。これによって item の中に name や image が含まれるため，不足なく情報を網羅できている。

ブックマーク

IRI (Internationalized Resource Indicator) というのは JSON-LD 独自の用語のようだが，ここでは大雑把に URL (Uniform Resource Locator) や URI (Uniform Resource Indicator) と同じようにネット上のリソースを一意に識別する識別子であると理解しておけばよい。なお，テストツールを見るかぎり Google 検索では IRI からメタデータの場所（URL または URI）を推測して取得するといったことはしないようだ。したがって Web ページに JSON-LD を設置する場合には，関連する全てのメタデータを記述する必要がある。冗長すぎるやろ。 ↩︎
JSON-LD の仕様を見るかぎり，Microdata や RDFa の語彙を流用したり自前で語彙を作ったりできるっぽい。 ↩︎
ただし publisher.logo.height と publisher.logo.width は例外のようで，これらのプロパティがなくてもテストツールではエラーにならなかった。まぁ画像のサイズは画像データから読み取れるからね。 ↩︎
一応説明しておくと「パンくずリスト」とはサイト内のページ位置を見失わないようにするためのナビゲーション表示を指す。名前で想像される通り「ヘンゼルとグレーテル」の童話が語源になっているらしい。まぁ，いまどきパンくずリストがないと迷子になってしまうようなダサい構成のサイトは少なくなってると思うけど。 ↩︎

Twitter Card メタデータに対応した

2017-10-29T07:00:38+00:00

なんとなく思いついてこのブログをいわゆる “Twitter Cards” に対応させた。

実は Twitter Cards が登場し始めたときに Tumblr などで適用していたのだが，あまりに酷い仕様で HTML Validator にかけるとエラーの嵐になるし，そもそも Semantic Web を無視した設計に腹が立って忌避していたのだ。しかし，まぁ，もう Semantic Web なんか誰も見向きもしなくなってるみたいだし， Web コンテンツを解析する手段は AI 技術を利用したものへシフトしてるようだし，もう（どうでも）いいかな，と。

Twitter Cards の仕様も随分シンプルになった。まず，カード種別が以下の4種類のみになった。

Player card は動画やスライドショウのページ用， App card はアプリページ用なので，それ以外の Web ページでは Summary card か Summary card with large image を選択することになる。

Summary card with large image はアイキャッチ¹ 用の大きめの画像（300×157から4096×4096で5MB以下）を含むカードで，メディア・サイトなどが多用するあのウザいやつである。とはいえ，写真やイラストなどを中心としたサイトでは Summary card with large image が向いているだろう。

Summary card with large image にしないのなら Summary card を選択する。うちのブログはもちろん~~オリーブオイル~~おっと Summary card で²。

Summary card で必須のメタデータは以下の2つである。これを指定しないと，そもそもカードが表示されない。

twitter:card
twitter:title

具体的には <meta> 要素の name-content 属性の組み合わせを使って以下のように記述する。

<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="Codic API を利用するパッケージを作ってみた — プログラミング言語 Go | text.Baldanders.info">

ちなみに twitter:card の値はカード種別ごとに以下の通り。

カード種別	twitter:card 値
Summary card	`summary`
Summary card with large image	`summary_large_image`
Player card	`player`
App card	`app`

ただ，このままではページの説明（description）やアイコン画像が表示されないため（何故 optional なのに無理くり表示しようとするのだろう），以下のメタデータも追加する。

twitter:description
twitter:image

アイコン画像には144×144から4096×4096までのサイズで5MB以下のデータが使える。これらを合わせると以下の記述が最低限必要と言える。

<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="Codic API を利用するパッケージを作ってみた — プログラミング言語 Go | text.Baldanders.info">
<meta name="twitter:description" content="spf13/viper を使ってみたかったのだ。">
<meta name="twitter:image" content="https://text.baldanders.info/images/attention/go-code.png">

以上のメタデータを <head> 要素内に設置する。これで以下のように表示される（筈）。

Twitter Card: Summary

以前は twitter:image 等を property-content 属性の組み合わせで記述させようとしていたが（これのせいで HTML Validator がエラーを吐いていた），さすがに改心したようである（笑）

サイトのオーナーやページの作成者が Twitter ユーザの場合は以下のメタデータも使える。

twitter:site
twitter:creator

これも同じように

<meta name="twitter:site" content="@spiegel_2007">
<meta name="twitter:creator" content="@spiegel_2007">

とすればよい。カードの見た目には全く関係ないが Twitter アナリティクスか何かで使うのだろう，多分。

メタデータの幾つかは OGP の語彙と置き換えることができる。

一応説明しておくと， OGP は Facebook が最初に考えた仕様で，元々はネット上のコンテンツと Facebook のアプリを関連付けて制御する仕組みだったのだが

Open Graph の相関図

RDFa の仕様の一部を借用した大変筋の悪いもので，本来の目的は明後日方向に飛んでいき，現在は <head> 要素内にメタデータを記述するための迂遠な手段に堕している³。ただし OGP で記述したメタデータを参照するサービスは多いため，今だに SEO 対策として用いられているようだ。

Twitter Cards のメタデータと置き換え可能な OGP の述語を以下に示す。

Twitter Cards	OGP
`twitter:card`	`og:type`
`twitter:description`	`og:description`
`twitter:title`	`og:title`
`twitter:image`	`og:image`

これらの述語を既に使っている場合は Twitter Cards のメタデータで記述する必要はない。なお og:type は本来はメディア・タイプ（MIME タイプや RDF/RDFa の語彙で定義されるタイプ）を指定するものなので Twitter Cards 用に使うべきではない。

OGP は（一応） RDFa の仕様に従っているのでメタデータ指定には name-content 属性の組み合わせではなく property-content 属性の組み合わせで記述する。例えば以下の通り⁴。

<head  prefix="og: http://ogp.me/ns#">
  ...
  <meta property="og:title" content="Codic API を利用するパッケージを作ってみた — プログラミング言語 Go | text.Baldanders.info">
  <meta property="og:description" content="spf13/viper を使ってみたかったのだ。">
  <meta property="og:image" content="https://text.baldanders.info/images/attention/go-code.png">
  ...
</head>

<head> 要素に prefix 属性を付けるのを忘れずに（HTML5 の場合）。なぜ <html> 要素ではなく <head> 要素に付けるかというと， OGP は <head> 要素外での使用を考慮していないからである。まぁ Twitter 側はそんなこと微塵も気にしてないだろうけど。おそらく接頭辞を og 以外にしたら Twitter 側は認識できなくなるんじゃないのかな（馬鹿らしいので試さない）⁵。

ちなみに <head> 要素内の <title> 要素や description メタデータはまるっと無視するようである。本当に何でこんな頭の悪い仕様になってるのか知らないが⁶，最初に書いたように，いまさら Semantic Web なんか気にする人はいないだろうし，どうでもいいか。

ブックマーク

参考図書

セマンティック HTML/XHTML: 神崎正英 (著); 毎日コミュニケーションズ 2009-05-28; 単行本（ソフトカバー）; 483993195X (ASIN), 9784839931957 (EAN), 483993195X (ISBN); 評価

[Comment] 残念ながら紙の本は実質的に絶版なんですよねぇ。是非デジタル化を希望します。

reviewed by Spiegel on 2014-08-17 (powered by PA-APIv5)

この記事を書くにあたってちょっと調べたのだが「アイキャッチ」というのは和製英語なんだそうだ。ただし，コメントで頂いた情報では “eye-catcher” という言葉はあるらしい（thx!）。なお “eye” は “attention” に置き換えることができるそうで，その場合は “catch the reader’s attention” みたいな言い回しになるとか。ふぅ。英語は難しいぜ。 ↩︎
実は一度 Summary card with large image を試したのだが，自分で眺めてやっぱりウザかったので Summary card にした。 ↩︎
RDF/RDFa は Web 上の（URI で記述可能な）あらゆるリソース同士の関係を「主語・述語・目的語」の3つ組（triple）で表すことで machine-understandable な「意味」を与える Semantic Web の実装のひとつである。もちろん Facebook はそんな思想背景など微塵も考慮していなかったと思うが。 ↩︎
og:image の目的語は URL なので， RDFa 仕様としては property-content 属性ではなく（<link> 要素を使って） rel-href 属性の組み合わせとするのが正しい。のだが， OGP は馬鹿なので property-content 属性とする（つまりリテラル・データとして扱う）よう求めている。私が間違ってるわけではない，決して。ホントなんだよこのクソ仕様は。ブツブツブツ… ↩︎
ちなみに prefix 属性ではなく vocab 属性を使えば接頭辞が不要になる。どうなるかなんて試さないよ（笑） ↩︎
ちなみに Facebook は <title> 要素を認識して使っている。はっきり言って <title> 要素と twitter:title メタデータが独立して存在してるってのは詐欺の匂いがするんだが，誰も気にしないのかね。アイキャッチ画像につられて詐欺みたいなサイトに誘導されるってのは Facebook でも見られるが（笑） ↩︎