コンテンツに適切な構造を与えることは、私達ができる最も重要な事の1つである。なぜならコンテンツの構造がより多ければ多いほど、より自由になるからである（訳注：いろんなデバイスやプラットフォームで表示されるようになるという意味です）。大抵の場合、構造化コンテンツの分類や分割は多数のプラットフォーム上におけるコンテンツのプレゼンテーション（表示）を可能にする。
コンテンツを自然なコンポーネンツに分類することによって、私達は現在および将来的な互換性を確保したり、様々なデバイスや環境で表示されることを確かなものとすることができる。サードパーティ・メタデータ・スキーマ（FacebookのOGP ：Open Graph ProtocolやTwitter Cardsなど）はこの理想を基盤としている。そしてそれらは迅速に、現代において完全なonline presence （オンライン・プレゼンス）を得ることに一役買うようになってきている。
FacebookのOGP （Open Graph Protocol）やOG（ちなみにこれはラッパーIce-T’sが1991年にリリースしたアルバム「O.G.」ではない）はコンテンツを適切な塊に分けることで得られる互換性の観念を基盤としているが、プラットフォーム固有の視点に立つものである。
TwitterもまたTwitterCardsと呼ばれる独自のメタデータスキームを展開した。これらのメタデータプロトコルは同様の機能を果たし、どちらもソーシャルプラットフォーム上で共有されるコンテンツに関してユーザーによりよいエクスペリエンスを提供するのに役立つ。
基本的にTwitterCardsとOGはメタデータの離散集合である。特定のソーシャルプラットフォームはそのメタデータを見て必要に応じて一部を表示する。Twitterに関しては、フィード中のニュース記事やイメージの要約として捉えられるかもしれない。Facebook上では、OGは共有されるウェブサイトのイメージ、タイトル、およびディスクリプションを表示する(これはFacebookが最近公開した「Graph Search」とは別物である。
OGはコンテンツのための共通言語を提供する一方、「Graph Search」はFacebook内にて、あなたとの関係や関連性を基にFacebookユーザーを検索するのを可能にするものである)。
さて、私達の残りのコンテンツがすでにフューチャーフレンドリーであれば、なぜ私達はそのようなことに対するニーズを持つのであろうか？
人々は物を共有する
私達はオンラインで気に入ったものを見つけるとそれを共有する。URLをコピー&ペーストして電子メールに添付して送る者もいるだろう。中にはをプリントアウトし、切手を貼って郵送する者もいるだろう。そしてその他大勢はFacebook、Twitter、LinkedInなどのお気に入りのソーシャルネットワークを使うだろう。
もしあなたが電子メール経由でリンクを共有するならば、あなたはたぶん少しなりとも文脈を提供するであろうから、受け取った側はそれが何についてのものなのかがわかるであろう。文脈のない電子メールに貼られ、要求してないのに送られてくるURLはあらゆる類のスパムメールやフィッシング詐欺という理由から警告を促す。
ほとんどの人々は「ねえ、この猫のビデオをチェックして！SOOO CUUUTEだから」のようなメッセージを追加してこの状況を避ける。しかしそれでさえも多少の努力を必要とする。
コンテンツの製作者はこの土俵では影響力を発揮できない。誰かがURLをブランクの電子メールに貼れば、私達はページのメタデータをそこに持って来ることができない。しかし、SNSの分野ではまだ少しその余地が残されている。
共有のための規格
昔は、よくある猫のビデオがFacebook上で共有されると、タイトル、ディスクリプション、およびイメージのスロットには、そこに存在するメタデータが勝手にあてがわれた。従って意味不明のタイトルになることもあった。1998年のディスクリプションが表示されることもあったかもしれない。画像には勝手に切り取られたバージョンのロゴなどが表示されていたかもしれない。これは明白である。規格が必要だったのである。
Facebookがソーシャルネットワークのフィード中に表示される小さな共有コンテンツボックスを追加するための規格を設定しようとした時、うれしいことにFacebookはそれをオープンな方式でしてくれた。広く支持される Dublin Core Metadata Element Set（ライブラリおよびコンピュータサイエンスの世界の標準）はその基盤と出発点として役立つ。
Facebookはこの規格を独自の使用のために創造した（Facebookが必要とする複雑性レベルと機能を持つ）。しかし、LinkedInやGoogle+のような他のプラットフォームも、OGメタデータを用いたコンテンツ共有ボックスを追加している。
Facebook、LinkedIn、およびGoogle+は共有コンテンツを扱う時OGに目を向ける。しかし、OGがないと、これらソーシャルプラットフォームは最終的にどのようなメタデータであろうがそれを取得する。企業にとってこれは最善策とはいえない。結局皆に質の低いエクスペリエンスを提供することになる。
一方TwitterCardsは、TwitterとTwitterをサポートするアプリのみにエクスペリエンスを提供するという一つの目的に適うものである。CardsとOGの小さな相違は、Twitterは独自のコンテンツと表示のニーズに目を向けたというところにある。
リツイート経由で共有というTwitter独自の環境は帰属問題（attribution problem）を生み出した。私はリンクを共有するかもしれないが、140の文字制限があるので常に一つのコメントにフィットするとは限らない。コンテンツ制作者またはオーナーへの適切な帰属情報が常にそこにフィットするとは限らないということである。そこでTwitterCardsはメタデータスキーマおいて公式に特定フィールドでコンテンツ著作者と所有権を確定し、保有することに努めている。
賢くも、Twitterは他のソーシャルプラットフォームと同等であるために独自のメタデータスキーマを作り上げた。TwitterCardsスキーマを組み入れるコンテンツ制作者やサイトオーナーは現在より豊かな共有コンテンツプレビューエクスペリエンスを提供することができる。
TwitterCardsによってユーザーはTwitter環境に居ながらにして、イメージ、ビデオ、およびオーディオのようなコンテンツを、見たり聞いたりできるようになる。その結果、人々はより長い間Twitter上で時間を過ごすことになる(それがTwitterのねらいである。もちろん親切心からだけではない。閲覧者や閲覧時間が長ければそれだけ多くの広告を配置できるというわけである)。
不滅のコンテンツフィールド
どう機能するのか？もしあなたが構造化コンテンツのパスをたどってみた、またはまさにそうしようとしているならば、サードパーティ・メタデータ・スキーマを追加することは比較的容易であろう。まず各ページの先頭に置かれたコードが大きな仕事をする。そして実際サードパーティメタデータは昔ながらのメタタグのすぐ下に配置される。
昔の人は1997年のHTML3.2のブラウザ固有のタグのことを覚えているかもしれない。運良く、OGとTwitterCardsはNetscape Navigatorに依存していない。何も心配することはない。しかし、OGとTwitterCardsも今が旬であるというだけかもしれず、私達はこれら外部の企業体によって決められる規格につなぎとめられる。構造化コンテンツはコンテンツを自由にすることを意図するものであって、それを抑制しようとするものではない。そこで、また別のメタデータスキーマがやってきたらどうなるのか？
もちろん、サードパーティメタデータスキーマとこれらブラウザ固有のタグの間には似ている点もある。となるとそれらを実施することは、フューチャーフレンドリーではないように見えるかもしれない。最終的にサイトオーナーはこれを実行するためのコストと、ユーザーエクスペリエンスの改良および大きな潜在的可能性のあるユーザーベース(Facebookやそのユーザー10億人)に対する利益とを比較検討するであろう。
とりあえずこれらのスキーマ両方において利用可能なフィールドオプションは複数のフォーマットやタイプを含むことができる。従って共有コンテンツが多くの形（ビデオからGIFアニメーション、通常の古いWebページまで）をとることができるから素晴らしい。
効率よくするために、基本に徹しあなたがパブリッシュしようとしているコンテンツのフォーマットやタイプのサポートだけを追加するのが最善である。もしオーディオがあなたのストックになくあなたが取り扱うものでなければ、そのためにサードパーティメタデータスキーマを扱うためのCMS（コンテンツ管理システム）を設定する必要はほとんどない。
OGとTwitterCardsの両方が、最もポピュラーなフォームでの共有コンテンツの適切かつプラットフォーム内でのプレゼンテーションを提供することをめざしている：
- 記事がテキストサマリーと小さなイメージプレビューを得る
- オーディオファイルがオーディオプレーヤーを得る
- ビデオクリップがビデオプレーヤを得る
- イメージはより大きなイメージプレビューを得る
OG開発者は所定のオブジェクト（ビデオ、オーディオファイル、Webページなどのようなコンテンツタイプ）をいくつも創造した。それぞれが独自のメタプロパティを伴う。オブジェクトタイプがオーディオファイルまたはビデオクリップである場合、必要に応じてメタデータはそれを適切なプレーヤーと結び付ける。この属性リストは一つの記事に対する各メタタグの詳細を提供する：
<meta property="og:url" content="URL of this object">
<meta property="og:site_name" content="Name of site hosting article">
<meta property="og:image" content="URL to an image">
<meta property="og:title" content="Name of article">
<meta property="article:author" content="URL to Author object">
<meta property="article:section" content="Section of article">
<meta property="article:tag" content="Keyword">
Facebook上ではこのように見えるようになる：
TwitterCardsも同様のプロトコルを有している。記事、ビデオ、オーディオ、およびイメージのために構築された特定のプロパティを伴う。記事タイプのコンテンツのTwitterCardsメタデータはこんな感じである：
<meta name="twitter:card" content="summary">
<meta name="twitter:url" content="URL of this content">
<meta name="twitter:title" content="Name of article">
<meta name="twitter:description" content="Description of content">
<meta name="twitter:image" content="URL to an image">
また、以下のようなオプションのTwitterCardsアイテムによって、コンテンツを企業やクリエーターのTwitter ハンドルネームに帰属させることができる：
Twitter上ではこのうように見える：
<meta name="twitter:site" content="@username">
<meta name="twitter:site:id" content="Twitter ID">
<meta name="twitter:creator" content="@username">
<meta name="twitter:creator:id" content="Twitter ID">
このコンテンツの作成：焦点を合わせて埋め尽くせ
メタデータもまたコンテンツである。それは、あなたがすでに適所に有しているかもしれない同じプロセス、ワークフロー、および制御プロトコルのすべてに左右される。いつものことだが、メタデータもまたページの中心的なメッセージをサポートするべきである。これらのサードパーティメタデータスキーマには実質的な制約もいくつかある。
フィールドの限界
一定のフィールドは異なるデバイス上では表示制限があることを念頭に置かなければならない（特にディスクリプションフィールド）。160文字以下に保つべきである。そうすればフィールドの文字が自動的に切り捨てられることもない（ディスプレイの表示制限にもよる）。
イメージ選択
効果的で適切なイメージがあるかないかで、友達があなたのニュースフィードにあるリンクをクリックするかしないかが異なる。OGでの記事タイプ（article-type）のページのためのイメージガイドラインは簡単である。最小200×200px 、最大縦横比3:1。しかし、真四角のイメージがスペースを一番有効に利用する。TwitterCardsはどのようなイメージでも120×120pxにリサイズするので、og：imageのためにすでに作成したのと同じ200×200pxイメージを使っても大丈夫であろう。
メッセージング
あなたはそのページが持つメッセージに焦点を合わせるだろう。メタデータ中でもそのメッセージに焦点を合わせるべきである。もしあなたが一つのアイデアやコンセプトを思い浮かべてそのページを作り上げたのであれば、結構容易にディスクリプションを思いつくだろう。
もしそうでなければ、優先度を付けて、メッセージが一貫していることを確認しなくてはならない。もし1つのページが4つのキーポイントを持っているとすれば、1つのものに焦点を合わせるべきである。
タイトル、ディスクリプション、およびイメージはすべて、あなたがこれらのソーシャルプラットフォーム中で示したいポイントと一致するべきである。
例えば、マイクロソフトの新しいタブレット「Surface」が登場したときメディアの話題を呼んだが、Microsoft.com上のSurface Windows 8 Proのページは新しいOpen Graph（OP）ワールドへの 配慮をしなかった(このページはOGもTwitterCardsも用いていない)。
このページにはいくつかのメッセージがあり、配置によって構築されたヒエラルキーが存在する。
- デバイスを購入すべきだ
- このデバイス上でアプリが使える
- このデバイスは安全である
- このデバイスで素晴らしいパフォーマンスを堪能できる
- このデバイスのスクリーンは素晴らしい
- このデバイス上ではPalm Pilotのようにタッチペンを使える
- デバイスを購入すべきだ
しかし、このヒエラルキーはメタデータによって補強されていない。マイクロソフトはページタイトルで「Surface Windows 8 Proはパワフルである」とSurfaceのパフォーマンスを売り物にしている。しかしページをスクロールして4番目のメッセージに達するまで、パフォーマンスについてのことは見当たらない。大きなずれを感じる。さらにページのメタディスクリプションに関しても伝えたいものがよりいっそう伝わってこない。
Facebookでこのリンクを共有してみよう。そうすれば、この焦点が合っていないアプローチはよりいっそう明白になる。どんなソーシャルプラットフォームのニュースフィードに表示されるイメージは、2つとも1280×450pxと理想的なサイズや縦横比からは程遠い。
お決まりの「Learn more（もっと知りたい）」でクリックを誘導する手法は、旧式の「click here（ここをクリック）」とまではいかないが、それでも旧式のマーケティングモデルにはかわらない。
ではマイクロソフトはこの状況において何をすればよかったのか？それは、コアページのメッセージの1つに焦点を合わせることによってソーシャルプラットフォーム上でページをよりよくプレゼンテーションすることである。
- より説得力のある記述的なタイトルを用いる。確かに、SurfaceWindows 8 Proはパワフルであるが、何と比べてそうなのか？競合商品？重量挙げ選手？フォード・マスタング？必要なことをするのにそれはどのように手助けしてくれるのか？それがタブレットであることがまだ述べられていない。これはかなり重要な詳細である。
- ディスクリプションの160文字を活用する。ここでページをまとめてようやく「Learn more」と言ってもよいだろう。このページを訪問したら何を知りえるのか？そこで購入できるのか？ソリティアは入っているか？なぜこれを競合商品と比べて考慮に入れるべきなのか？
- 興味を引くかつ代表的なイメージを提供する。ソーシャルプラットフォームがあなた与えるスペースは限られている。あなたのメッセージを正確に表し、それをサポートするイメージを作る。自動でイメージが切り取りされてしまうのを避けるために適切にフォーマットする。
- クリックする理由を与える。プラットフォームに適切なクリアで簡潔な呼び掛けを示す。そして、あなたのオファーが相手に届くものであることを確認する。(これらの秘訣すべては検証済みである)
ワークフローと実践は選別とトレーニングになる
OGとTwitterCardsをより古い既存のページに追加することは、新しいコンテンツにそれらを組み入れるより少し難しいかもしれない。特にあなたがものすごく多数のページを有していればなおさらである。
全体的なonline presence （オンライン・プレゼンス）に渡って一貫性を持たせるため、時間が許す限りより目立たないエリアの改善ができるように段階的なアプローチを考慮すべきである。まずはインパクトの強いアセット（すでに強いシェア行動が見られるページなど）を適所に持ってくることに集中する。それから他に関しても最低基準を満たすようにする。
厳密に言えばサイト上のほとんどのページが共有可能であるが、人々は必ずしもそれらを共有しようとしているわけではない。特に共有のために「Contact Us」ページを最適化しようというのは悪い考えである。あなたの現在のページタイプをいくつかのシンプルなサードパーティメタデータの分類（以下）にマッピングしなくてはいけない：
頻繁に共有されるページ
アクティブなキャンペーンをサポートするページ、ブログポスト、製品ページ、および人目を引くようなページ、トラフィックが多いページ。これらは、
- 最も多くの時間とリソースを必要とする。
- 内容領域専門家（SME：Subject Matter Expert）からのインプットによってページ固有のメタデータを作成する。他のマーケティングまたはプロモーション用のコンテンツと同じく深刻に捉えてメタデータを記述する。
- ユニークなタイトル、ディスクリプション、およびイメージを用いる。
まれに共有されるページ
トランザクションページ、トランジションページ、またはナビゲーションページ
- リソース集約度が低い
- セクションを作成する、または関連する詳細（ページレベルの詳細ではない）を提供するためにトピック固有のメタデータコンテンツを作成する。
- 具体的なタイトルとセクション固有のディスクリプションを用いるが、一般的なイメージを用いる(ロゴやアイコンのようなイメージ)。
共有を意図しないページ
これらはコンタクト、法的情報の公開、およびサイトマップのようなページを含む。
- リソースへのインパクトが最も低い。最も維持しやすい。
- 最低限のブランド基準を満たすために、一般的なメタデータコンテンツを作成する。
- 具体的なタイトルを用いるが、一般的で、サイト全体を説明するディスクリプションと一般的なイメージを用いる(ロゴやアイコンはここでもよく役割を果たす)。
これら新しいフィールドの重要性をコンテンツ制作者や認定者に伝えなければいけない(彼らの多くは熱心なFacebookユーザーと考えられる)。うまくOGを使ったサイトのよい例を提示するとよい。そこで、全くOGを使っていないサイトも例示する。彼らが即その必要性を感じる可能性は高い。
構造化されたコンテンツの塊の使用の明確な理解は、コンテンツ製作者らが適切なコンテンツを作成する必要があるというコンテキストを彼らに与えるだろう。（ここで注目したいのは、これがOGやTwitterCardsに特有のものではないことである。この理解は構造化コンテンツ全部にとって重要である）。
激励の(警告の)言葉
あらゆるサードパーティの関係と同様に、特定の事柄にはわずかにあなたの手に負えないものがある。私達はハードウェア、Google探索アルゴリズム、やFacebookプライバシー設定の定期的な変化に慣れてしまった。これらの変化は必ず混乱を生じさせるものである。だからこそしっかりとこれら(そして他の)サードパーティツールやプラットフォームの進化と発展を見守らないくてはならない。
サードパーティメタデータスキーマを実践することは、コンテンツ作成の仕事量を増加させるであろう。一方、その特別な努力は複数のプラットフォームやデバイス（現行および今後新しく登場するものの両方）全体を通してユーザーによりよいエクスペリエンスを提供するであろう。一般的応用や柔軟性を念頭に置いて離散的な塊でコンテンツを巧妙に作り上げることが未来の方法である。好むと好まざるとにかかわらず（うぉーー）。
The post 「いいね！」に値するコンテンツ： サードパーティ・メタデータであなたのメッセージを広めよう appeared first on A List Apart 日本語サイト.
