マイクロデータとは何ですか？

Scrapeless Universal Scraping APIは、JavaScriptでレンダリングされた可視コンテンツを含む、構造化データ抽出ワークフローのためのウェブページを取得します。

マイクロデータはHTMLに組み込まれた構造化データの構文です。これにより、パブリッシャーはページに記載されたもの—製品、イベント、人、レシピ、記事など—を特定し、そのものに属するプロパティにラベルを付けることができます。ブラウザは同じ見出し、リンク、画像、テキストをレンダリングします。追加の属性は、パーサー、クローラー、検索システム、アクセシビリティツール、データ抽出ソフトウェアのための追加の機械可読レイヤーを作成します。

申し訳ありませんが、テキストが指定されていません。翻訳したい内容を提供してください。 HTML標準のWHATWGマイクロデータセクション 処理モデルを定義します。その標準の文脈が重要なのは、Microdataが視覚的なウィジェットや検索エンジンのプラグインではないからです。これはドキュメント自体の一部であり、その意味はアイテムのスコープ、プロパティ値、URL、およびネストされたアイテムに関するルールに従います。

エンティティを表すマイクロデータ

マイクロデータは、エンティティをゼロまたは複数のプロパティを持つアイテムとして表現します。アイテムは、以下を持つHTML要素で始まります。 itemscope 属性。オプションの itemtype 属性は、アイテムが表すエンティティの種類を定義する1つ以上の語彙URLを供給します。子要素は持つ itemprop そのアイテムに名前付きの値を追加します。

値は必ずしも見えるテキストから来るわけではありません。リンクはそのURLを提供し、画像はそのソースURLを提供し、時間要素は機械可読な日時値を提供し、メタ要素は通常の文章として表示される必要のない値を持つことができます。したがって、パーサーはタグを削除して残ったテキストを読み取るのではなく、Microdataの値のルールに従います。

シンプルなネスティングでは表現できない関係をカバーする2つの追加属性があります。 itemid 語彙がサポートしている場合、型付きアイテムにグローバル識別子を付与します。 itemref ポイントは、アイテムに含めるべきプロパティを持つ、同じドキュメント内の他の要素を指します。これらの機能はリアルテンプレートで役立ちますが、抽出器は孤立したものをスキャンするのではなく、完全なモデルを実装しなければならないことも意味します。 itemprop 文字列。

マイクロデータ属性の概要

Schema.orgがどこに適合するか

Schema.orgは共有語彙であり、Microdataはシリアライズ構文です。 Schema.orgの入門資料 製品やイベントなどの文書タイプと、名前、画像、startDateなどのプロパティを提供します。発行者は、Microdata、RDFa、またはJSON-LDを使用して、同じ用語の多くを表現できます。構文を変更しても語彙や意図するエンティティモデルは自動的には変わりません。

この区別は一般的な計画の誤りを防ぎます。チームは「Schemaを使用している」と言うかもしれませんが、実際の質問は別々です: どの語彙タイプがビジネスエンティティを正しく説明していますか？ どのフォーマットがレンダリングスタックに適していますか？ どの消費者が選択した組み合わせをサポートしていますか？ 特定の検索機能に適用される検証ルールは何ですか？ それらの質問を独立して回答することで、クリーンなマークアップとより信頼性の高い抽出が得られます。

パーサーはどのようにMicrodataを抽出するか

準拠した抽出器は最上位のアイテムから始まり、各アイテムのタイプと識別子を決定し、子孫および参照されたノードからプロパティ値を解決します。ネストされたアイテムは関連のないテキストにフラット化されるのではなく、構造化された値として残ります。URL値のプロパティは文書のベースURLに対して解決されるため、最終的な値はソースHTMLに見つかるリテラル属性とは異なる場合があります。

生成抽出にはもう一つの質問があります: どの文書が解析されるべきですか？ サーバーHTMLにはすでにMicrodataが含まれている場合があり、クライアントアプリケーションがJavaScriptを実行した後に属性を追加することがあります。生のHTTPレスポンスとレンダリングされたDOMは、したがって異なる構造化データを暴露することができます。取得段階は出力と共に記録されるべきであり、下流のユーザーはデータセットがソースHTMLを反映しているのか、ブラウザがレンダリングした状態を反映しているのかを知ることができます。

Microdata、JSON-LD、そしてRDFa

MicrodataはプロパティをHTML要素に直接配置します。JSON-LDは通常、スクリプトブロック内にJSONオブジェクトを保持し、可視コンテンツから分離されます。RDFaもマークアップを注釈しますが、RDFデータモデルから来ており、典型的なSchema.org発行ワークフローを超えたリンクデータパターンをサポートしています。3つすべてが構造化データを表現できますが、異なるメンテナンスと抽出のトレードオフを生み出します。

Google Search Centralの構造化データガイダンス は、サイトのセットアップがサポートされている場合、JSON-LDを推奨します。なぜなら、プレゼンテーションからの分離がネストされたデータのメンテナンスを容易にするからです。その推奨はMicrodataを無効にしません。テンプレートがすでに各セマンティックプロパティを可視要素にバインドしており、組織がその要素に合わせて注釈を移動させたい場合、Microdataは合理的です。

一般的なMicrodataの失敗モード

壊れたスコープは最も基本的な失敗です。プロパティは関連するアイテムを所有する要素の外側に配置でき、パーサーが他の場所に接続したり無視したりする原因となります。ネストされたエンティティも誤ってモデル化されることがあります: アドレスはしばしば自分自身のプロパティを持つアイテムであるべきであり、近くにある任意のテキストから組み立てられた文字列ではありません。

語彙の漂流は、より微妙な欠陥を生み出します。プロパティ名は一つのタイプには有効ですが別のタイプには無効かもしれません。また、検索機能は一般的な語彙がオプショナルと見なすフィールドを要求する場合があります。したがって、検証は2つのレベルで行われるべきです: 構文とデータモデルの正しさ、その後に消費者特有の適格チェックが行われます。1つのテストに合格しても、豊かな結果や特定のプレゼンテーションが保証されるわけではありません。

重複した真実は別のリスクです。サイトはMicrodataとJSON-LDを並べて持ち、それぞれ異なる価格、日付、または正規のURLを公開することがあります。抽出器は出所を保持し、権威ある表現を選択するか、対立を報告するべきです。出版者は、すべての構造化フォーマットを1つのデータソースから生成するべきであり、独立して編集するべきではありません。

検索外観を超えた実用的な使用法

Microdataを選択し維持する方法

セマンティックアノテーションが安定したサーバー生成要素に自然に属し、開発チームがマークアップをテンプレートの一部としてテストすることに慣れている場合は、Microdataを選択します。エンティティグラフが複雑で、いくつかの表示要素が1つのレコードに寄与する場合、またはコンテンツとプレゼンテーションが異なるスケジュールで変化する場合は、JSON-LDを優先します。リンクデータ要件がそのグラフモデルにより適している場合は、RDFaを優先します。

メンテナンスにはテンプレートレベルのテスト、代表的なレンダリングページ、語彙の検証、消費者固有のチェックを含めるべきです。ページのURL、キャプチャメソッド、抽出タイムスタンプ、アイテムタイプ、生のプロパティ値、正規化された値、および検証結果を追跡します。これらのフィールドにより、再デザインによって属性が移動したり、クライアントスクリプトが挿入を遅延させたりした場合の変更が説明可能になります。

ウェブスケールコレクションの場合、取得と解析は別々であるべきです。 Scrapeless Universal Scraping API は抽出段階にページコンテンツを供給し、パーサーがMicrodataルールを適用し、その結果を安定したダウンストリームスキーマにマッピングします。レビュー Scrapelessの価格 は計画されたページボリュームの取得コストを見積もる際に確認してください。

結論

MicrodataはHTMLネイティブの構造化データです：アイテムはエンティティを定義し、プロパティは値を定義し、語彙は共有された意味を提供します。セマンティックアノテーションが安定した表示要素に整合している場合、うまく機能します。信頼できる使用は、完全なアイテムモデルを解析し、正しいページ表現をキャプチャし、語彙ルールを検証し、複数の構造化フォーマットが共存する際に起源を追跡することに依存します。