CyberLibrarian

【注意】 このドキュメントは、W3CのPublication Manifest W3C Recommendation 10 November 2020の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2021年1月14日


出版マニフェスト

W3C勧告

本バージョン:
https://www.w3.org/TR/2020/REC-pub-manifest-20201110/
最新公開バージョン:
https://www.w3.org/TR/pub-manifest/
最新編集者草案:
https://w3c.github.io/pub-manifest/
実装報告書:
https://www.w3.org/publishing/groups/publ-wg/implementation/results.html
旧バージョン:
https://www.w3.org/TR/2020/PR-pub-manifest-20201001/
編集者:
Matt Garrish (DAISY Consortium)
Ivan Herman (W3C)
参加可能:
GitHub w3c/pub-manifest
File a bug
Commit history
Pull requests

公開以後に報告されたエラーや問題がないか正誤表を確認してください。

翻訳版も参照してください。

このドキュメントは、規範以外の形式でも入手できます: EPUB


要約

この仕様は、デジタル出版物に関する情報を表すための一般的なマニフェスト形式を定義しています。これにより、[json-ld11]でシリアル化し、出版物に関する様々な構造プロパティーを含むように拡張した[schema.org]のメタデータを用いて、表す必要のある情報の多様性に対応しつつ、出版形式間の相互運用性が可能になります。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、https://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、Publishingワーキンググループによって勧告として公開されました。

この仕様の議論にはGitHub Issuesをお勧めします。または、メーリング・リストにコメントを送信することもできます。コメントはpublic-publ-wg@w3.org(アーカイブ)に送信してください。

W3C勧告は、広範な合意形成の後、W3Cとそのメンバーの協賛を得た仕様です。W3Cは、この仕様をWebの標準として広く展開することを推奨します。この勧告の将来の更新には、新しい機能が組み込まれる可能性があります。

このドキュメントは、2017年8月1日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権(Essential Claim(s))を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

このドキュメントは、2020年9月15日のW3Cプロセス・ドキュメントによって管理されています。

1. はじめに

1.1 範囲

この仕様は、出版物を記述するための一般的なマニフェスト形式を定義しています。特殊な出版物を作成するためにモジュール化のアプローチを規定することにより、オーディオブックの制作など、特定の出版分野のニーズに適応できるように設計されています。

この仕様は、様々なユーザ・エージェントのアーキテクチャを容易にすることも目的としています。従来のウェブ・ユーザ・エージェント(ブラウザ)は出版マニフェストを利用できると思われますが、これによって、(アプリケーション(スタンドアロンでも、ユーザ・エージェント内で実行されるものでも)、または独自のユーザ・インターフェイスを含んでいる出版物ですら)他の種類の可能なユーザ・エージェントの機能が制限されるべきではありません。

この仕様では、マニフェスト形式を採用した出版物をユーザ・エージェントが表示する方法については定義していません。

1.2 マニフェスト形式

この項は非規範的です。

デジタル出版物は、マニフェストで記述され、それは特定の形のJSON-LD[json-ld11](リンクト・データ用のJSON[ecma-404]の一種)を用いて表したプロパティーの集合を提供します。

マニフェストは、ユーザ・エージェントがデジタル出版物境界とその資源間の結びつきを理解できるようにするものです。出版物はその構成資源を超えるアイデンティティと性質を持っているため、マニフェストにはデジタル出版物について記述したメタデータが含まれています。マニフェストは、デジタル出版物に属する資源のリストデフォルトの読み上げ順序も提供し、そのようにして、複数の資源を結び付けて1つの連続する作品にします。

マニフェストのプロパティーには、ユーザ・エージェントが出版物を処理、表示するために必要な基本情報を記述します。理解しやすいように、このプロパティーを次のように分類します。

記述プロパティー

記述プロパティーは、デジタル出版物のタイトル作成者言語などの特徴を記述します。

資源分類プロパティー

資源分類プロパティーは、資源リストデフォルトの読み上げ順序などの資源の一般的な集合を記述または識別します。このプロパティーは、HTMLドキュメント、画像、スクリプト、メタデータ・レコードなどの1つ以上の資源を参照します。

マニフェストは、リンク関係を用いてデジタル出版物の主要な資源の識別も行います。この関係は、LinkedResourceオブジェクト(つまり、デフォルトの読み上げ順序、資源リスト、リンクの項において各資源を表すJSONオブジェクト)のrelプロパティーで定義します。

これらの関係が識別する資源の型を次のように分類します。

参考情報の資源

参考情報の資源は、プライバシー方針アクセシビリティ報告書プレビューなど、出版物に関する付加的な情報を含んでいる資源です。

構造資源

構造資源は、表紙画像目次ページ・リストなど、出版物の主要なメタ構造です。

1.3 JSON-LDのオーサリングと処理

この仕様では、出版マニフェストを特定の「形」の[json-ld11]と定義しています。これは、JSON-LD構文が提供するすべての可能性とは対照的に、この仕様で定義している構文構造のみを用いてマニフェストを表すべきである(SHOULD)ということを意味します。

この形は、非公式に、この仕様で定義している制約を表すJSONスキーマ[json-schema]でも定義されています。このスキーマはhttps://www.w3.org/ns/pub-schema/manifest/で管理されています。

出版マニフェストには、オーサリング上の柔軟性やコンパクトなオーサリング表現もいくつかあります。例えば、オブジェクトの型は、それが欠落していれば処理中に自動的に生成されるため、必ずしも明示的に作成する必要はありません(詳細については、§ 4.2.4 明示的・暗黙的なオブジェクトを参照)。マニフェスト・データの内部表現は別個に定義されます。詳細については、§ A. 内部表現データ・モデルを参照してください。

したがって、ユーザ・エージェントは完全なJSON-LDプロセッサである必要はありません。ユーザ・エージェントは、特定の形のマニフェストを読み取り、データを取り込むことができればよいだけです。

1.4 Schema.orgとの関係

この項は非規範的です。

マニフェスト・プロパティー、特に記述プロパティーと分類されているプロパティーは、主にSchema.orgとその提供されている拡張機能[schema.org]に基づきます。その結果、このプロパティーは、Schema.orgの構文とセマンティクスを継承しており、そのため、マニフェストのオーサリングはSchema.orgのオーサリングと互換性を有しています。

マニフェストのアイテムがSchema.orgのプロパティーに対応している場合は、そのプロパティーの定義でマッピングを示し、括弧内に(CreativeWorkBookなどの)定義の型を挙げています。

さらに、Schema.orgには、出版に関連があるけれども、この仕様では触れていない多くのプロパティーが含まれています。このドキュメントでは最小限のマニフェストのアイテムしか定義していませんが、マニフェストでこれらのプロパティーを用いることができます(§ 4.7.3.2追加のマニフェスト・プロパティーを参照)。

追加のSchema.orgプロパティーを用いる場合は、それがマニフェストで指定されている出版物の型に有効であることを確認してください。語彙で用いている継承モデルの結果として、プロパティーは、多くのSchema.orgの型を使用できることが多いですが、すべての型にすべてのプロパティーを使用できるわけではありません。どの型がどのプロパティーを受け入れるかの詳細は、[schema.org]を参照してください。

追加のSchema.orgプロパティーの使用に関する詳細は、§ 4.5 出版物の型§ 4.7.3.2 追加のマニフェスト・プロパティーにもあります。

2. 用語

この仕様は、インフラ標準[infra]に依存しています。

境界(Bounds)

デジタル出版物は、そのコンテンツを表す有限の資源の集合で構成されます。この範囲はその境界として知られており、§ 5. 出版物資源で説明しているとおり、マニフェスト内で定義します。

デジタル出版物(Digital Publication)

デジタル出版物は、マニフェストプロファイルを用いた形式で作成された出版物です。

内部表現(Internal Representation)

マニフェストの内部表現は、マニフェストを処理して考えられるすべての曖昧さを取り除き、別の情報源から推測可能な欠落している値を組み込む際にユーザ・エージェントが作成するデータ構造です。

マニフェストで表される情報は、曖昧さや欠落した情報がなければ、ユーザ・エージェントが作成した内部表現と同等である可能性があります。

マニフェスト(Manifest)

マニフェストは、参考情報のメタデータ、資源のリストデフォルトの読み上げ順序など、出版物に関する構造化された情報を表します。

プロファイル(Profile)

プロファイルの仕様で定義しているマニフェスト形式を用いて境界とコンテンツを記述した(オーディオブックなどの)出版物の形式です。この形式により、プロファイル固有の用語や新しい要件を用いて、この仕様のコア定義を拡張できます。

プロファイルの構造の要件とコンテンツの要件が一致しない可能性がありますが、そのような違いは、形式間の高度な予測可能性を維持するために制限されています。(§ 8. モジュラー拡張を参照。)

3. 適合性

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

このドキュメントの「することができる/してもよい(MAY)」、「しなければならない(MUST)」、「してはならない(MUST NOT)」、「選択できる/任意である(OPTIONAL)」、「推奨される(RECOMMENDED)」、「必須である/要求される(REQUIRED)」、「すべきである/する必要がある(SHOULD)」、「すべきでない/する必要がない(SHOULD NOT)」というキーワードは、ここで示しているように、すべて大文字で表示されている場合にのみ、BCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

すべてのアルゴリズムの説明は参考情報です。

4. 出版マニフェスト

4.1 要件

マニフェストには、次のプロパティーを設定しなければなりません(MUST)。

次のプロパティーを推奨します(RECOMMENDED)。

その他のすべてのプロパティー資源関係の優先順位は任意(OPTIONAL)ですが、マニフェスト形式の実装によって変更できます(MAY)。

一部のプロパティーは、明示的に作成されていなければ代替情報から編集されるため、暗黙的に必須です。詳細については、§ A. 内部表現データ・モデルを参照してください。

4.2 値のカテゴリ

この項では、出版マニフェストのプロパティーで使用できる値のカテゴリについて説明します。

4.2.1 リテラル

マニフェストのプロパティーが、その値としてリテラルのテキスト文字列(コード値や日付などの言語に依存しないもの)を想定している場合、値は[json]文字列で表さなければなりません(MUST)。

例えば、オブジェクトに変換される可能性のある他の値とは異なり、リテラル値はマニフェストの処理中に変更されません。

4.2.2 数値

マニフェストのプロパティーが、その値として数値を想定している場合、値は[json]数値で表さなければなりません(MUST)。

4.2.3 ブール

マニフェストのプロパティーが、その値としてブール値を想定している場合、値は[ecmascript]ブール値(truefalse)で表さなければなりません(MUST)。

4.2.4 明示的・暗黙的なオブジェクト

様々なマニフェストのプロパティーは、[json]オブジェクトで表されると想定されます。通常は、明示的なオブジェクトを用いることをお勧めしますが、次の項では、文字列の値の使用も許容されるケースを示します。その文字列は、ユーザ・エージェントによるマニフェストの処理中に自動的にオブジェクトに変換されます(テキスト値からオブジェクトへの正確なマッピングは、個々の定義で記載しています)。

4.2.4.1 ローカライズ可能な文字列

マニフェストのプロパティーが、その値としてローカライズ可能なテキスト文字列を想定している場合、値は次のいずれかで表さなければなりません(MUST)。

1つの文字列の値は、valueプロパティーが文字列のテキストであり、言語と基本書字方向がマニフェスト内のその他の情報から決定される暗黙的なオブジェクトを表します。

ローカライズ可能な文字列は、値の複数言語表現の促進を目的としているため、ローカライズ可能な文字列を受け入れるプロパティーは、常にこれらの値の配列を受け入れます。そのため、作成する文字列やオブジェクトは1つだけでなければなりませんが、処理の整合性を保つために、そのような値は配列に変換されます。

LocalizableStringは、次のプロパティーからなる[json]オブジェクトです。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
value ローカライズ可能な文字列の値。必須(REQUIRED)。 テキスト。 リテラル (なし)
language 値の言語。オプション(OPTIONAL)。 整形式の言語タグ[bcp47]。 リテラル (なし)
direction 値の基本書字方向。オプション(OPTIONAL)。 ltrrtl リテラル (なし)

基本書字方向の値の意味は次のとおりです。

  • ltr: テキスト値の方向性が、明示的に左から右のテキストに設定されていることを示します。
  • rtl: テキスト値の方向性が、明示的に右から左のテキストに設定されていることを示します。

基本書字方向の値の欠落は、テキストの値の方向性が、Unicode双方向アルゴリズム[bidi]の規則に従い、強い方向性を持つ最初の文字の方向に明示的に設定されていることを意味します。

直前の例で基本書字方向の値が設定されていなければ、Unicode双方向アルゴリズム[bidi]に従い、かつ、文字列の先頭にラテン文字があるため、テキストは次のように表示されます。

HTML היא שפת סימון.

しかし、これは正しくありません。表示を制御して次の値を生成するためには、directionの値を追加する必要があります。

HTML היא שפת סימון.

この例のvalueフィールドは、メモリに格納されているテキストを表しているため、ここで示している2つの表示との間に相違があることに注意してください。テキスト・エディタが、JSON値を(Unicode双方向アルゴリズムのみを用いるなどの)異なる方法で表示する場合もあります。

詳細な説明と例については、[string-meta]ドキュメントも参照してください。

4.2.4.2 エンティティー

マニフェストのプロパティーがエンティティー(つまり、作成の様々な側面に責任を有する個人や組織)を想定している場合、その値は次のいずれかで表さなければなりません(MUST)。

1つの文字列の値は、nameプロパティーが文字列のテキストであり、typePerson(人)[schema.org]であると想定されるEntityオブジェクトのインスタンスを表します。

エンティティーは、次の最小限のプロパティーの集合を持つ[schema.org]のPerson(人)かOrganization(組織)の型のインスタンスとして定義されています。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
type エンティティーの型。オプション(OPTIONAL)。 1つ以上のテキスト。シーケンスには「Person」か「Organization」が含まれていなければなりません(MUST)。 リテラル配列 (なし)
name エンティティーの名前。必須(REQUIRED)。 1つ以上のテキスト。 ローカライズ可能な文字列配列 name
id エンティティーに関連付けられている正規の識別子。オプション(OPTIONAL)。 URLレコード[url]。 識別子 (なし)
url エンティティーに関連付けられているアドレス。オプション(OPTIONAL)。 有効なURL文字列[url]。 URL url
identifier (ORCIDなどの)エンティティーに関連付けられている識別子。オプション(OPTIONAL)。 1つ以上のテキスト。 リテラル配列 identifier

この最小限のプロパティーの集合に限定されません。著者は、必要に応じて、[schema.org]のPersonOrganizationの型用に定義されている追加のプロパティーを含めることができます。ユーザ・エージェントも同様に、前述のプロパティーのみを解釈することに限定されません。

4.2.4.3 リンクされた資源

マニフェストのプロパティーは、1つ以上の資源にリンクする場合、次のいずれかで表さなければなりません(MUST)。

  1. 資源のURLをエンコードした[json]文字列。または、
  2. LinkedResourceのインスタンス。

文字列の値は、urlプロパティーを文字列の値に設定した暗黙のLinkedResourceオブジェクトを表します。

LinkedResourceオブジェクトは次のように定義されています。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
type 資源の型。オプション(OPTIONAL)。 1つ以上のテキスト。シーケンスには「LinkedResource」が含まれていなければなりません(MUST)。 リテラル配列 (なし)
url 資源の位置。必須(REQUIRED)。 有効なURL文字列[url]。追加の制限については、この型を受け入れるプロパティー定義を参照してください。 URL url
encodingFormat (text/htmlなど)資源のメディア・タイプ。オプション(OPTIONAL)。 MIMEメディア・タイプ[rfc2046]。 リテラル encodingFormat
name アイテムの名前。オプション(OPTIONAL)。 1つ以上のテキスト。 ローカライズ可能な文字列配列 name
description アイテムの内容記述。オプション(OPTIONAL)。 1つ以上のテキスト。 ローカライズ可能な文字列配列 description
rel 資源と出版物の関係。オプション(OPTIONAL)。

1つ以上の関係

キーワードはASCIIの大文字と小文字を区別しない[infra]であり、そのように比較しなければなりません(MUST)。

リテラル配列 (なし)
integrity 資源の整合性を検証可能にする資源の暗号ハッシュ。オプション(OPTIONAL)。

1つ以上の空白区切りの整合性メタデータの集合[sri]。値はメタデータ定義[sri]に準拠しなくてはなりません(MUST)。

ユーザ・エージェントがサポートすることが期待される暗号ハッシュ関数のリストについては、[sri]を参照してください。

リテラル (なし)
duration 時間ベースのメディア資源の全体的な時間長。オプション(OPTIONAL)。 [iso8601-1]で定義されている時間長の値。 リテラル duration(プロパティー)
alternate

代替形式の資源の1つ以上の変形への参照で、encodingFormatは変形の形式を指定します。オプション(OPTIONAL)。

次の1つ以上。

  • 代替形式の資源の変形のURLを表す文字列。または、
  • LinkedResourceオブジェクトのインスタンス

文字列の値は、urlプロパティーを文字列の値に設定した暗黙のLinkedResourceオブジェクトを表します。

リンクされた資源配列 (なし)

integrityプロパティーに対するユーザ・エージェントのサポートはオプションですが(OPTIONAL)、このプロパティーを用いて暗号ハッシュ比較をサポートするユーザ・エージェントは、[sri]に従ってそれを行わなければなりません(MUST)。

この仕様では、代替形式からの選択用にalternateプロパティーのみを定義しています(つまり、encodingFormatに基づくか、URLを検査するか)。プロファイルは、この動作を拡張して、他の基準に基づく選択を可能にすることができます(MAY)。代替を選択するプロセスについては、§ B. 代替資源の選択で記述しています。

LinkedResourceオブジェクトを定義する場合は、常にencodingFormatプロパティーを用いて資源のメディア・タイプを指定することをお勧めします。そうすることで、ユーザ・エージェントは資源のユーザビリティをより容易に判断できます。

4: コンテンツのSHA-256ハッシュを用いている資源
{
    "type"           : "LinkedResource",
    "url"            : "chapter1.html",
    "encodingFormat" : "text/html",
    "name"           : "Chapter 1 - Loomings",
    "integrity"      : "sha256-13AE04E21177BABEDFDE721577615A638341F963731EA936BBB8C3862F57CDFC"
}
5: 代替形式を用いている資源
{
    "type"           : "LinkedResource",
    "url"            : "chapter1.mp3",
    "encodingFormat" : "audio/mpeg",
    "name"           : "Chapter 1 - Loomings",
    "alternate"      : [
        "chapter1.html",
        {
            "type": "LinkedResource",
            "url": "chapter1.json",
            "encodingFormat": "application/vnd.syncnarr+json",
            "duration": "PT1669S"
        }
    ]
}
4.2.4.4 オブジェクト

マニフェストのプロパティーが、この項やプロファイルで定義していない種類のオブジェクトを想定している場合、それは[json]オブジェクトで表さなければなりません(MUST)(つまり、プロパティーの値を処理してオブジェクトが作成されることはありません)。

4.2.5 URL

URLは、デジタル出版物に関連付けられる資源を識別するために用います。プロパティーがURLの値を想定している場合、それは有効なURL文字列[url]でなければなりません(MUST)。

相対URL文字列の場合、基底URL[url]を用いて絶対URL文字列に対して解決します。

相対URL文字列に対する基底URLは次のように決まります。

結果として、組み込まれたマニフェストの相対URL文字列は、ドキュメントで基底URL(つまり、ヘッダーの<base>要素で)が宣言されていなければ、マニフェストを参照しているドキュメントのURLに対して解決されます。

4.2.6 識別子

識別子は、デジタル出版物とその作成に責任のあるエンティティーを永続的かつ明確な方法で参照するために用います。URLURNDOIISBNPURLはすべて、出版でよく用いられる永続的識別子の例です。

識別子はURLレコード[url]で表さなければなりません(MUST)。

4.2.7 配列

マニフェストのプロパティーで、(リテラルオブジェクトURLなど)それぞれの型の1つ以上の値が許されている場合、これらの値は[json]の配列として表されます。しかし、プロパティーの値が1つの要素であれば、配列構文は省略できます(MAY)。

4.3 マニフェストのコンテキスト

マニフェストには、次の2つの要素を持つJSON-LDコンテキスト[json-ld11]を、指定されている順序で設定しなければなりません(MUST)。

  1. [schema.org]のコンテキスト: https://schema.org
  2. 出版物のコンテキスト: https://www.w3.org/ns/pub-context

Schema.orgはhttpのURIスキームを用いて参照されること多いですが、デフォルトとして安全なhttpsスキームを用いるように語彙が移行されつつあります。その結果、出版マニフェストのコンテキストではhttpsスキームのみが認識されます。

8: コンテキスト宣言の設定
{
    "@context" : [
        "https://schema.org",
        "https://www.w3.org/ns/pub-context"
    ],
    …
}

出版物のコンテキストのドキュメントはSchema.orgで定義されているプロパティーに、(作成者プロパティーが順序を保持するための要件などの)機能を追加します。

この仕様のプロファイルでは、コンテキストのURLを追加する必要がありえますが(MAY)、そのURLの順序は、これら2つの要素より後でなければなりません(MUST)。

出版物のコンテキストの後のオブジェクトに、グローバルな言語と方向の宣言などの追加のパラメーターを含めることで、コンテキストを拡張できます。

{
    "@context" : [
        "https://schema.org",
        "https://www.w3.org/ns/pub-context",
        {
            "language" : "es"
        }
    ],
    …
}

4.4 マニフェストの言語と方向

(タイトル作成者など)マニフェストの個々の自然言語のプロパティーの値には、デフォルトの自然言語があり、これは、(英語、フランス語、中国語などの)それが表される言語です。また、それが書かれる自然な基本書字方向(左から右または右から左の表示方向)もあります。

デジタル出版物のマニフェストは、これらの両方の概念をグローバルに設定する機能と個々のアイテムに設定する機能を提供し、ユーザ・エージェントによるメタデータの解釈と表示を支援します。

基本書字方向を設定する機能は、JSON-LD 1.1[json-ld11]の機能です。言い換えると、出版マニフェストは、(以前のバージョン1.0[json-ld10]ではなく)バージョン1.1のJSON-LD仕様に依存しています。

4.4.1 グローバルな宣言

自然言語のマニフェスト・プロパティーに対するグローバルな言語と基本書字方向の宣言は、それぞれlanguagedirectionのキーワード[json-ld11]を用いてコンテキストで設定します。これらの値は、マニフェストの処理中にシンプルな文字列の値をローカライズ可能な文字列へと展開するため、また、それを省略したローカライズ可能な文字列に言語と基本書字方向を提供するために用います。

languageの値は、整形式の言語タグ[bcp47]でなければなりません(MUST)。

directionの値には次のいずれかの値がなければなりません(MUST)。

  • "ltr": テキスト値の方向性が、明示的に左から右のテキストに設定されていることを示します。
  • "rtl": テキスト値の方向性が、明示的に右から左のテキストに設定されていることを示します。

グローバルな言語と基本書字方向の宣言が存在する場合は、出版物のコンテキストに従わなければなりません(MUST)。

グローバルな言語や基本書字方向のデフォルト値は規定していません。

4.4.2 アイテム固有の宣言

localizable stringを用いて、マニフェスト内の任意の自然言語の値に言語や基本書字方向をローカルに設定できます。

languagedirectionのキーワード[json-ld11]となりうる値は、グローバルな宣言の場合と同じです。さらに、どちらの値もnullという(JSONの)値にすることができ、これは、明示的な言語または方向が設定されていないことを示します。

(「Google」など)関連する言語なしに(組織名などの)値が一般的に用いられている場合に、languageの値をnullに設定すると便利です。

言語や基本書字方向のローカルな宣言は、グローバルな宣言よりも優先されます。

4.5 出版物の型

デジタル出版物のマニフェストは、typeキーワード[json-ld11]を用いてその出版物の型を定義します。型は任意の[schema.org]の型にマッピングできますが(MAY)、型が指定されていない場合はCreativeWorkデフォルトとして想定されます。

14: 出版物の型をCreativeWorkに設定
{
    "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
    "type"     : "CreativeWork",
    …
}

ArticleBookTechArticleCourseなどのCreativeWorkのより具体的なサブタイプを、CreativeWorkの代わりに、またはCreativeWorkに加えて使用できます。

15: 出版物の型をBookに設定
{
    "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
    "type"     : "Book",
    …
}

個々のSchema.orgの型は、Schema.orgで有効に使用できるプロパティーの集合を定義しています。マニフェストをSchema.orgに対応したプロセッサで確実に検証し処理できるようにするためには、選択した型に関連付けられているプロパティーのみをマニフェストに含めるべきです(SHOULD)。

複数の型のプロパティーが必要な場合、マニフェストに複数の型の宣言を含めることができます(MAY)。

16: BookとVisualArtworkのプロパティーを組み合わせた出版物のtypeプロパティーを設定
{
    "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
    "type"     : ["Book", "VisualArtwork"],
    …
}

ユーザ・エージェントは、宣言されたSchema.orgの型に有効でないマニフェストの処理に失敗すべきではありません(SHOULD NOT)。

完全なCreativeWorkのサブタイプのリストについては、Schema.orgのサイトを参照してください。

4.6 プロファイルの適合性

デジタル出版物は、conformsToプロパティーを用いて、そのマニフェストとコンテンツが準拠しているプロファイルを示します。

用語 説明 必須の値 値のカテゴリ [dcterms]マッピング
conformsTo プロファイルのURL。 フラグメント付き絶対URL文字列[url]。 リテラル配列 conformsTo

プロファイルに用いるURLは、それぞれの仕様で定義されています。

conformsToプロパティーを用いて、([wcag21]などの)他の仕様や標準への適合性を示すこともできます。

17: デジタル出版物がW3Cオーディオブックの仕様に準拠していることを識別
{
    …
    "conformsTo" : "https://www.w3.org/TR/audiobooks/",
    …
}

4.7 プロパティー

4.7.1 記述プロパティー

4.7.1.1 要約版

abridgedプロパティーは、デジタル出版物が元の形式から短縮されているかどうかに関する情報を提供します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
abridged その本が要約版であるかどうかを示します。 truefalseのいずれか。 ブール abridged (Book)
18: 出版物が要約版であると設定
{
    …
    "abridged" : true,
    …
}
4.7.1.2 アクセシビリティ

アクセシビリティのプロパティーは、望ましい読み上げ方式が多様なユーザによる利用に対するデジタル出版物の適合性に関する情報を提供します。このプロパティーは概して、[wcag21]で提供されているような確立されたアクセシビリティ基準に対する評価を補完するものです。

次のプロパティーを、アクセシビリティのプロパティーとして分類しています。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
accessMode 人が情報を処理したり認識したりできる、人間の感覚知覚システムまたは認知能力。 1つ以上のテキスト。 リテラル配列 accessMode (CreativeWork)
accessModeSufficient 資源のすべての知的コンテンツを理解するのに十分な1つまたは組み合わせによるアクセス・モードのリスト。 1つ以上のItemList オブジェクト配列 accessModeSufficient (CreativeWork)
accessibilityFeature アクセシブルなメディア、代替手段、アクセシビリティのためにサポートされている拡張機能などの、資源のコンテンツ機能。 1つ以上のテキスト。 リテラル配列 accessibilityFeature (CreativeWork)
accessibilityHazard 一部のユーザにとって生理的に危険な、記述資源の特性。 1つ以上のテキスト。 リテラル配列 accessibilityHazard (CreativeWork)
accessibilitySummary 他のアクセシビリティのメタデータと整合性がある、特定のアクセシビリティの機能や不備に関する人間が読める要約。 テキスト。 ローカライズ可能な文字列配列 accessibilitySummary (CreativeWork)

これらのプロパティーとの使用が想定される値を含む、これらのプロパティーの詳細な説明は、[webschemas-a11y]にあります。

これらのプロパティーで表現できるよりも多くの情報が必要な場合は、詳細なアクセシビリティ報告書への参照を提供することもできます。

19: 純粋なテキスト形式で読めるように、画像ごとに適切な代替テキストと長い説明文を提供するアクセシビリティのメタデータを出版物に設定
{
    …
    "accessMode"              : ["textual", "visual"],
    "accessibilityFeature"    : ["alternativeText", "longDescription"]
    "accessModeSufficient"    : [
        {
            "type"            : "ItemList",
            "itemListElement" : ["textual", "visual"]
        },
        {
            "type"            : "ItemList",
            "itemListElement" : ["textual"]
        }
    ],
    …
}
4.7.1.3 アドレス

アドレスは、デジタル出版物の発信元の位置を識別するURLです。これはurlプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
url 出版物のURL。 有効なURL文字列[url]。 URL配列 url (Thing)

デジタル出版物に複数のアドレスを含むことができますが(MAY)、すべてのアドレスが同じドキュメントに対して解決されなければなりません(MUST)。

出版物のアドレスは、識別子のリンク関係[link-relation]の値としても使用できます。
20: 出版物のアドレスを設定
{
    …
    "url" : "https://publisher.example.org/frankenstein",
    …
}
4.7.1.4 正規の識別子

デジタル出版物の正規の識別子のプロパティーは、デジタル出版物に一意の識別子を提供します。これはidプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
id 優先バージョンの出版物。 URLレコード[url]。 識別子 (なし)

正規の識別子に関する一意性の保証は、この仕様の範囲外です。実際の達成可能な一意性は、用いる識別子スキームの規定や識別子の割り当てに対する制御の程度などの要因によって異なります。

正規の識別子がマニフェストで提供されていなかったり、値が無効なURLであったりする場合は、デジタル出版物には正規の識別子がありません。ユーザ・エージェントは、マニフェストで提供されている他の識別子から正規の識別子を構築しようとしてはなりません(MUST NOT)。

正規の識別子の仕様は、identifierプロパティー[schema.org]やそのサブタイプを用いて追加の識別子の型を含めることによって補完できます(MAY)。

21: 正規の識別子とアドレスをURLとして設定
{
    …
    "id"  : "http://www.w3.org/TR/tabular-data-model/",
    "url" : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
    …
}
22: 正規の識別子にURNを使用
{
    …
    "id"  : "urn:isbn:9780123456789",
    "url" : "https://publisher.example.org/wuthering-heights",
    …
}
4.7.1.5 作成者

作成者は、デジタル出版物の作成に責任を有する個人や組織です。

次のプロパティーを、作成者として分類しています。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
artist 鉛筆画やデジタル線画以外の媒体による、出版物の主なアーティスト。 1つ以上のPerson エンティティー配列 artist (VisualArtwork)
author 出版物の著者。 1つ以上のPersonおよび/またはOrganization エンティティー配列 author (CreativeWork)
colorist インク画に色を加える個人。 1つ以上のPerson エンティティー配列 colorist (VisualArtwork)
contributor 役割がこの表の他の役割のいずれにも適合しない貢献者。 1つ以上のPersonおよび/またはOrganization エンティティー配列 contributor (CreativeWork)
creator

出版物の作成者。

このプロパティーを用いると、ユーザ・エージェントで矛盾した結果が生じる可能性があります。[schema.org]では著者の同義語と記されていますが、どちらを優先するか、またはどのようにそれらを組み合わせるかに関する指針はありません。より具体的な著者プロパティーを優先しつつ、どちらか一方のみを用いることをお勧めします。

1つ以上のPersonおよび/またはOrganization エンティティー配列 creator (CreativeWork)
editor 出版物の編集者。 1つ以上のPerson エンティティー配列 editor (CreativeWork)
illustrator 出版物のイラストレーター。 1つ以上のPerson エンティティー配列 illustrator (Book)
inker 鉛筆画をインクでトレースする個人。 1つ以上のPerson エンティティー配列 inker (VisualArtwork)
letterer アートワークに吹き出しや効果音などのレタリングを加える個人。 1つ以上のPerson エンティティー配列 letterer (VisualArtwork)
penciler 主に物語性のあるアートワークを描く個人。 1つ以上のPerson エンティティー配列 penciler (VisualArtwork)
publisher 出版物の発行者。 1つ以上のPersonおよび/またはOrganization エンティティー配列 publisher (CreativeWork)
readBy 出版物(オーディオブック用)を読む(実行する)人。 1つ以上のPerson エンティティー配列 readBy (Audiobook)
translator 出版物の翻訳者。 1つ以上のPersonおよび/またはOrganization エンティティー配列 translator (CreativeWork)

作成者は、次のいずれかで表さなければなりません(MUST)。

  1. Person[schema.org]の名前をエンコードした[json]文字列。または、
  2. PersonまたはOrganization[schema.org]のインスタンス。

1つの文字列の値は、nameプロパティーをその文字列の値に設定した[schema.org]のPersonの省略形です。(§ 4.2.4.2 エンティティーも参照。)

マニフェストには、各型の作成者を複数含むことができます(MAY)

23: 本の著者を設定
{
    …
    "url"      : "https://publisher.example.org/alice-in-wonderland",
    "author"   : {
        "type"  : "Person",
        "name"  : "Lewis Carroll"
    }
}
24: 編集者、著者、出版者を分ける。一部の人は、オブジェクトではなく単純な文字列として表現
{
    …
    "author"     : [
        "Jeni Tennison",
        {
            "type"       : "Person",
            "name"       : "Gregg Kellogg",
        },
        {
            "type"       : "Person",
            "name"       : "Ivan Herman",
            "id"         : "https://www.w3.org/People/Ivan/"
            "identifier" : "0000-0003-0782-2704",
        }
    ],
    "editor"    : [
        "Jeni Tennison",
        {
            "type" : "Person",
            "name" : "Gregg Kellogg",
        }
    ],
    "publisher" : {
        "type" : "Organization",
        "name" : "World Wide Web Consortium",
        "id"   : "https://www.w3.org/"
    }
    …
}
4.7.1.6 時間長

グローバルな時間長は、(オーディオブックや一連のビデオ・クリップで構成される本などの)時間ベースデジタル出版物の全体の長さを示します。これはdurationプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
duration 時間ベースの出版物の全体の時間長。 [iso8601-1]で定義されている時間長の値。 リテラル duration (Property)
25: グローバルな時間長を秒単位で設定
{
    …
    "type"     : "Audiobook",
    "id"       : "https://example.org/flatland-a-romance-of-many-dimensions/",
    "url"      : "https://w3c.github.io/pub-manifest/experiments/audiobook/",
    "name"     : "Flatland: A Romance of Many Dimensions",
    …
    "duration" : "PT15153S",
    …
}

関連するウィキペディアのページで、ISOの時間長の構文について簡潔に説明されています。

4.7.1.7 最終修正日

最終修正日は、デジタル出版物が最後に更新された日付(つまり、マニフェストを含む出版物の任意の資源に最後に変更が加えられたとき)です。これはdateModifiedプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
dateModified 出版物の最終修正日。 DateまたはDateTimeの値[schema.org]。どちらも、それぞれISO 8601の日付または日時の形式で表します[iso8601-1]。 リテラル dateModified (CreativeWork)

最終修正日は、(デジタル出版物の形式でサード・パーティーのコンテンツに参照できるなどの場合)必ずしも出版物に対するすべての変更を反映したものではありません。ユーザ・エージェントは、個々の資源の最終修正日をチェックし、変更が行われていて更新が必要かどうかを判断すべきです(SHOULD)。

26: 出版物の最終修正日を設定
{
    …
    "dateModified" : "2015-12-17",
    …
}
4.7.1.8 公開日

公開日は、デジタル出版物が最初に公開された日付です。これは、出版物のライフサイクルにおける静的なイベントを表し、その後の改訂を識別して比較できるようにします。これはdatePublishedプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
datePublished 出版物の作成日。 DateまたはDateTime。どちらも、それぞれISO 8601の日付または日時の形式で表します[iso8601-1]。 リテラル datePublished (CreativeWork)

正確な出版時点に関しては、意図的に解釈の余地を残しています。それは、出版物が最初に利用可能になったとき、または出版物が出版前に最終的なものと見なされた時点でありえます。

27: 出版物の作成日と修正日を設定
{
    …
    "datePublished" : "2015-12-17",
    "dateModified"  : "2016-01-30",
    …
}
4.7.1.9 出版言語

デジタル出版物には、(英語、フランス語、中国語などの)コンテンツが表現されている言語である自然言語が少なくとも1つあります。マニフェストには、この概念を設定するために次のプロパティーが含まれており、これは、例えば、(あらかじめ辞書やテキスト読み上げエンジンを読み込むなどの)ユーザ・エージェントの動作に影響を与える可能性があります。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
inLanguage 出版物のデフォルト言語 1つ以上の整形式の言語タグ[bcp47]。 リテラル配列 inLanguage (Property)

自然言語は整形式の言語タグ[bcp47]でなければなりません(MUST)。

ユーザ・エージェントが出版言語を要求する場合で、マニフェストではそれを得られない、または得られた値が整形式[bcp47]でない場合、ユーザ・エージェントは、内部表現の生成時に出版言語を決定することができます(MAY)。この仕様では、そのような言語タグの作成方法を義務付けていません。ユーザ・エージェントは次のような方法を使用できます。

ユーザ・エージェントが出版物の主要言語を要求する場合で、複数の言語が指定されていれば、inLanguage配列内の最初のエントリーを主要言語として認識しなければなりません(MUST)。

出版物の言語を、それを構成する個々の資源の言語と区別することが重要です。例えば、そのような資源がHTMLであれば、その資源にも言語を設定する必要があります。出版物の言語は継承されません。

4.7.1.10 読み上げの進行方向

読み上げの進行方向は、デジタル出版物内のある資源から次の資源への読み上げ方向を確立します。これは、メニューの位置、タッチ・ジェスチャー、方向の切り替え、前後ページ用のタップ・ゾーンなどの出版物レベルの相互作用に適応するために用います。読み上げの進行方法は、readingDirectionプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
readingProgression ある資源から別の資源への読み上げの進行方向。 ltrrtlのいずれか。 リテラル (なし)

このプロパティーの値は、次のいずれかでなければなりません(MUST)。

  • ltr: 左から右。または、
  • rtl: 右から左。

デフォルト値はltrです。readingProgressionが設定されていなければ、ユーザ・エージェントは内部表現の生成時にこのデフォルト値を用いなければなりません(MUST)。

このプロパティーは、個々の主要な資源の表示には影響を与えず、ある資源から別の資源への進行方向にのみ関係します。

28: 読み上げの進行方法を明示的にltr(左から右)に設定
{
    …
    "readingProgression" : "ltr",
    …
}
4.7.1.11 タイトル

タイトルは、デジタル出版物の人間が読める名前を提供します。これはnameプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
name 出版物の人間が読めるタイトル。 1つ以上のテキスト。 ローカライズ可能な文字列配列 name (Thing)

タイトルがマニフェストに含まれていなければ、ユーザ・エージェントはタイトルを作成しなければなりません(MUST)。タイトルを取得するプロセスは、§ 7.4.3 デフォルト値の追加で定義しています。

タイトルが指定されていなければ、ユーザ・エージェントが出版物に意味のあるタイトル[wcag21]を生成することは期待されません。

29: 本のタイトルを明示的に設定
{
    …
    "name" : "Heart of Darkness",
    …
}

4.7.2 資源分類プロパティー

出版物資源は、この項で定義しているように、デフォルトの読み上げ順序資源リスト、およびリンクによって指定します。このリストには、プライバシー方針などの参考情報の資源と、目次などの構造資源への参照が含まれます。

このリストのいずれにもマニフェストへの参照を含める必要はありません。

4.7.2.1 デフォルトの読み上げ順序

デフォルトの読み上げ順序は、一連のデジタル出版物資源を通じた特定の進行方法です。ユーザはコンテンツを介して別の経路をたどる可能性がありますが、そのような相互作用がなければ、デフォルトの読み上げ順序により、ある資源から次の資源への予想される進行方法が定まります。

デフォルトの読み上げ順序は、readingOrderプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
readingOrder デジタル出版物の資源を通じた進行の順序。

1つ以上のLinkedResource

リンクされた資源配列 (なし)

readingOrderプロパティーの各要素は、次のいずれかで表さなければなりません(MUST)。

1つの文字列の値は、urlプロパティーが文字列のテキストであるLinkedResourceオブジェクトのインスタンスを表します。

アイテムの順序は重要です。

読み上げ順序で表すURLにはフラグメント識別子を含むことができますが(MAY)、この仕様のプロファイルでは、その使用と、サポートされるスキームおよび機能の両方を制限できます(MAY)。(ユーザの移動先である開始位置や、読み上げ順序で次のアイテムに移動する前に表示するコンテンツの範囲などの)フラグメント識別子は、それぞれの仕様によって定義されているものとして解釈されます。

読み上げ順序に資源を複数掲載すべきではありません(SHOULD NOT)。これは、(資源へのリンクが読み上げ順序の正しいインスタンスに対して解決されないなど)ユーザ・エージェントに予測しない結果をもたらす可能性があるためです。

デジタル出版物マニフェストにリンクされている資源のみで構成されている場合は、デフォルトの読み上げ順序を省略できます(MAY)。ユーザ・エージェントは、デフォルトの読み上げ順序がなければ、内部表現の編集時にリンク資源のエントリーを含めなければなりません(MUST)。詳細については、§ 7.4.3 デフォルト値の追加を参照してください。

デフォルトの読み上げ順序には、マニフェストの処理後に少なくとも1つの資源が含まれていなければなりません(MUST)。

30: 読み上げ順序をシンプルなURLのリストとして表現
{
    …
    "readingOrder" : [
        "html/title.html",
        "html/copyright.html",
        "html/introduction.html",
        "html/epigraph.html",
        "html/c001.html",
        …
    ],
    …
}
31: より多くの情報を提供するために、読み上げ順序をLinkedResourceオブジェクトとして表現
{
    …
    "readingOrder" : [
        {
            "type"           : "LinkedResource",
            "url"            : "html/title.html",
            "encodingFormat" : "text/html",
            "name"           : "Title page"
        },
        {
            "type"           : "LinkedResource",
            "url"            : "html/copyright.html",
            "encodingFormat" : "text/html",
            "name"           : "Copyright page"
        },
        …
    ],
    …
}
4.7.2.2 資源リスト

資源リストには、デフォルトの読み上げ順序にまだ掲載されていない、デジタル出版物の処理や表示で用いる追加の資源を列挙します。これはresourcesプロパティーを用いて表します。

用語 説明 必須の値 値のカテゴリ [schema.org]マッピング
resources 出版物の処理や表示で用いる追加の出版物資源リスト。

1つ以上のLinkedResource

リンクされた資源配列 (なし)

resourcesプロパティーの各要素は、次のいずれかで表さなければなりません(MUST)。

1つの文字列の値は、urlプロパティーが文字列のテキストであるLinkedResourceオブジェクトのインスタンスを表します。

アイテムの順序は重要ではありません

資源に関する情報の競合を避けるために、特定の資源のURLを資源リスト内で繰り返すべきではありません(SHOULD NOT)。

資源リストで表示するURLにフラグメント識別子を含めるべきではありません(SHOULD NOT)。

資源リストの完全性は、(オフライン読み上げ機能などの)特定の読み上げシナリオにおけるデジタル出版物の使いやすさに影響を与える可能性があります。このため、デフォルトの読み上げ順序に掲載しているもののみでなく、出版物を構成するすべての資源の包括的なリストを提供することを強くお勧めします。

場合によっては、(情報源の深部から資源を参照するサード・パーティーのスクリプトなど)これらの資源の包括的なリストを容易に作成できない場合もありますが、ユーザ・エージェントは、(資源なしにオフラインになっているなどの場合)これらの資源の一部が出版物に属していると識別されない場合でも出版物を表示できるべきです(SHOULD)。

32: シンプルなURL文字列とLinkedResourceオブジェクトの組み合わせで資源のリストを表現
{
    …
    "resources"  : [
        "datatypes.html",
        "datatypes.svg",
        "datatypes.png",
        "diff.html",
        {
            "type"           : "LinkedResource",
            "url"            : "test-utf8.csv",
            "encodingFormat" : "text/csv"
        },
        {
            "type"           : "LinkedResource",
            "url"            : "test-utf8-bom.csv",
            "encodingFormat" : "text/csv"
        },
        …
    ],
    …
}

4.7.3 拡張性

マニフェストは、デジタル出版物を表示・提示する際にユーザ・エージェントが用いる基本的なプロパティーの集合を提供するように設計されていますが、次の方法で拡張できます(MAY)。

  1. リンクされたメタデータ・レコードを提供する。または、
  2. マニフェストに追加のプロパティーを含める。

この仕様は、マニフェストの内部表現でユーザ・エージェントがこのような追加のプロパティーを編集、保存し、公開する方法を定義していません。ユーザ・エージェントは、拡張プロパティーの一部またはすべてを無視できます(MAY)。

4.7.3.1 リンクされたレコード

マニフェストは、LinkedResourceオブジェクトを用いて、ONIX[onix]やBibTeX[bibtex]などのメタデータ・レコードへのリンクによって拡張できます(MAY)。その場合、

  • LinkedResourcerelプロパティーには、関連する識別子を含みます(例えば、リンクされたレコードに記述メタデータが含まれていれば、describedby識別子[iana-link-relations]を使用できます)。
  • 該当する場合、encodingFormatの値で、その特定の型のレコード用に定義されているMIMEメディア・タイプ[rfc2046]を識別します。

リンクされたレコードは、出版物の一部である場合は、資源リストに含まれます(つまり、単なるマニフェストの拡張性以上である場合に必要です)。そうでない場合は、リンク・リストに含まれます。

33: 本のメタデータ・レコードのための外部ONIXへのリンク
{
    …
    "links"  : [
        {
            "type"            : "LinkedResource",
            "url"             : "https://www.publisher.example.org/time-machine/onix.xml",
            "encodingFormat"  : "application/onix+xml",
            "rel"             : "describedby"
        },
        …
    ],
    …
}
編集者のメモ

application/onix+xmlというMIMEタイプは、このドキュメントの執筆時点ではまだIANAに登録されておらず、例示のみを目的として例に含んでいます。

4.7.3.2 追加のマニフェスト・プロパティー

追加のプロパティーは、[schema.org]や[dcterms]などの公的なスキームを用いてマニフェストに直接含めることができます(MAY)。独自の用語を用いることもできますが(MAY)、そのような用語は、接頭辞をコンテキストの一部として定義した短縮IRI[json-ld11]を用いて含めることをお勧めします(RECOMMENDED)。

完全なJSON-LDプロセッサでマニフェストを用いるためには、接頭辞と短縮IRIを適切に用いる必要がありますが、それは、この仕様で定義している処理アルゴリズムの要件ではありません。完全なJSON-LD処理を期待する場合は、接頭辞付き用語の検証を別途行う必要があります。

34: 語彙接頭辞宣言を用いて基本データセットを拡張
{
    "@context" : [
        "https://schema.org",
        "https://www.w3.org/ns/pub-context",
        {
            "language" : "en",
            "ex"       : "https://example.org/vocab"
        }
    ],
    …
    "ex:region" : "North America",
    …
}

Schema.orgのコンテキスト・ファイル[schema.org]は、ダブリン・コアの用語(dcterms)[dcterms]や要素セット(dc)[dc11]、FOAF語彙(foaf)[foaf]、書誌オントロジー(bibo)[bibo]など、一般的に用いられている語彙に対していくつかの接頭辞を定義しています。これらの語彙のプロパティーは、接頭辞を宣言しなくても使用できます。

35: Schema.orgの「copyrightYear」と「copyrightHolder」という用語を用いて基本データを拡張
{
    …
    "copyrightYear"   : "2015",
    "copyrightHolder" : "World Wide Web Consortium",
    …
}
36: ダブリン・コアの「主題」(subject)という用語を2012ACM分類用語とともに用いて基本データセットを拡張
{
    …
    "dcterms:subject" : ["Web data description languages","Data integration","Data Exchange"],
    …
}

4.8 資源関係

4.8.1 構造資源

4.8.1.1 表紙

表紙は、(ライブラリや本棚で、または最初に出版物を読み込む際などに)ユーザ・エージェントがデジタル出版物を提示するために使用できる資源です。

表紙は、coverというリンク関係で識別されます。

表紙へのリンクは、リンク・リストで指定してはなりません(MUST NOT)。

編集者のメモ

coverという用語は現在IANAのリンク関係に登録されていませんが、ワーキンググループが追加する予定です。

37: HTMLの表紙ページの識別
{
    …
    "resources" : [
        {
            "type"           : "LinkedResource",
            "url"            : "cover.html",
            "encodingFormat" : "text/html",
            "rel"            : "cover"
        },
        …
    ],
    …
}

(HTML資源に組み込まれているかどうかに関係なく)表紙が画像であれば、代替テキストと拡張記述を提供するために、達成基準1.1.1[wcag21]に従うことを強くお勧めします。この情報を組み込めない画像形式の場合は、LinkedResourcenamedescriptionのプロパティーを用いて、それぞれ代替テキストと拡張記述を提供できます。その場合は、nameプロパティーを常に設定すべきです(SHOULD)(装飾的な画像の場合はプロパティーを空のままにしておくことができます。)

38: 表紙画像の識別。代替テキストと内容記述を、それぞれnameとdescriptionのプロパティーで提供
{
    …
    "resources" : [
        {
            "type"           : "LinkedResource",
            "url"            : "whale-image.jpg",
            "encodingFormat" : "image/jpeg",
            "rel"            : "cover",
            "name"           : "Moby Dick attacking hunters",
            "description"    : "A white whale is seen surfacing from the water to attack a small whaling boat"
        },
        …
    ],
    …
}
39: 装飾的な表紙。nameプロパティーは空のまま
{
    …
    "resources" : [
        {
            "type"           : "LinkedResource",
            "url"            : "cover.jpg",
            "encodingFormat" : "image/jpeg",
            "rel"            : "cover",
            "name"           : "",
        },
        …
    ],
    …
}

ユーザ・エージェントでインターフェイスにアクセスできるようにするためには表紙画像の代替テキストが必要で、nameプロパティーが指定されていなければ、出版物のメタデータから代替テキストの構築を試みることができます(MAY)。この仕様では、そのような代替テキストの作成方法を義務付けていません。1つの方法は、画像が表紙であることを識別する文字列で代替テキストを構築し、その後に出版物のタイトルを続けることです。

表紙として識別できる(MAY)資源は1つだけですが、(代替の大きさや解像度を提供するなどのために)alternateプロパティーを用いて追加の表紙を指定することができます(MAY)。

40: JPEG形式とSVG形式の表紙画像を提供
{
    …
    "resources" : [
        {
            "type"           : "LinkedResource",
            "url"            : "lilliput.jpg",
            "encodingFormat" : "image/jpeg",
            "rel"            : "cover"
            "alternate"      : [
                 {
                     "type"           : "LinkedResource",
                     "url"            : "lilliput.svg",
                     "encodingFormat" : "image/svg+xml",
                     "rel"            : "cover"
                 }
            ]
        },
        …
    ],
    …
}
4.8.1.2 ページ・リスト

ページ・リストは、デジタル出版物内の静的なページの境界線のリストが含まれているナビゲーション支援です。

ページ・リストはpagelistというリンク関係で識別されます。

編集者のメモ

pagelistという用語は現在IANAのリンク関係に登録されていませんが、ワーキンググループが追加する予定です。

ページ・リストが含まれている資源として識別できる(MAY)のは1つのみです。複数のインスタンスが指定されていれば、ユーザ・エージェントは、読み上げ順序を優先して最初に検出されたインスタンスを用いなければなりません(MUST)。

ページ・リストへのリンクをリンク・リストで指定してはなりません(MUST NOT)。

41: ページ・リストが含まれている資源を識別
{
    …
    "resources" : [
        {
            "type" : "LinkedResource",
            "url"  : "toc_file.html",
            "rel"  : "pagelist"
        },
        …
    ],
    …
}
4.8.1.3 目次

目次は、デジタル出版物の主要な構造部分へのリンクを提供するナビゲーション支援です。

目次が含まれている資源はcontentsというリンク関係[iana-link-relations]で識別されます。適切な目次は、§ C.2 HTML構造で定義しているように、roleの値であるdoc-tocを持つその資源内の最初の要素です。

目次が含まれている資源として識別できる(MAY)のは1つだけです。複数のインスタンスが指定されていれば、ユーザ・エージェントは、読み上げ順序内の資源を優先して最初に検出されたインスタンスを用いなければなりません(MUST)。

この仕様のプロファイルでは、contents関係で資源が識別できない場合に、目次が含まれている資源を指定する方法を定義することができます(MAY)。

リンク・リストで目次へのリンクを指定してはなりません(MUST NOT)。

推奨される(RECOMMENDED)目次の構造と処理モデルは、§ C. 機械処理可能な目次で定義しています。

42: 目次が含まれている資源を識別
{
    …
    "resources" : [
        {
            "type" : "LinkedResource",
            "url"  : "toc_file.html",
            "rel"  : "contents"
        },
        …
    ],
    …
}

4.8.2 参考情報の資源

4.8.2.1 アクセシビリティ報告書

アクセシビリティ報告書は、望ましい読み上げ方式が多様なユーザによる利用に対するデジタル出版物の適合性に関する情報を提供します。この報告書は通常、[wcag21]が提供しているような、確立されたアクセシビリティ基準に対する評価結果を識別するものであり、出版物のユーザビリティを決定する際の重要な情報源です。

アクセシビリティ報告書はaccessibility-reportというリンク関係で識別されます。

編集者のメモ

accessibility-reportという用語は現在IANAのリンク関係に登録されていませんが、ワーキンググループが追加する予定です。

報告書を出版物の資源として含め、出版物をオフラインで読み上げるときなどに利用できるようにすると便利です。

アクセシビリティ報告書をHTML[html]などの人間が読める形式で提供すると、ユーザが確実にアクセスして理解できるようになります。Schema.org[schema.org]で提供されているような、機械処理可能なメタデータで報告書を強化すると、機械処理がさらに容易になります。

4.8.2.2 プレビュー

(サイトの登録ユーザに限定されている場合があるなど)すべてのデジタル出版物を、すべてのユーザが利用できるわけではありません。そのような場合に、公開者は、コンテンツのプレビューを提供してユーザにフルバージョンへのアクセスを促したいと考えるかもしれません。

プレビューは、previewというリンク関係[iana-link-relations]で識別されます。

プレビューは、外部に置くことも、デジタル出版物の資源として含めることもできます(MAY)。

44: プレビューをデジタル出版物の音声資源として識別
{
    …
    "links" : [
        {
            "type"           : "LinkedResource",
            "url"            : "preview.mp3",
            "encodingFormat" : "audio/mpeg",
            "rel"            : "preview"
        },
        …
    ],
    …
}
4.8.2.3 プライバシー方針

多くの場合、ユーザは、自身に関してどのような情報が収集され、その情報がどのように、また、どれくらいの期間保存されるか、個人を特定可能かどうか、どのように消去できるかを知り、管理する法的権利を持っています。したがって、そのようなプライバシーに関する懸念への取り組みに関して声明を含めることは、デジタル出版物を公開する上で重要な要素でありえます。情報が収集されないとしても、そのような宣言は、そのコンテンツに対するユーザの信頼性を高めます。

この目的のために、プライバシー方針へのリンクをマニフェストに含めることができます。例えば、出版物をオフラインで読む際に利用できるように、プライバシー方針を出版物の資源として含めると便利です。

プライバシー方針は、privacy-policyというリンク関係[iana-link-relations]で識別されます。

4.8.3 拡張

この仕様で定義しているもの以外の付加的な関係を表す必要がある場合は、次のいずれかの方法でrelプロパティーを拡張できます。

5. 出版物資源

デジタル出版物に属している一意の資源のリスト(その境界)は、readingOrderに掲載されている資源と、alternate資源が含まれているresourcesとの和集合から得られます。このリストを作成するための正確な手順は、マニフェストの処理アルゴリズムで記述されます。

(linksの項に掲載されている資源や、ウェブ上の外部資源へのコンテンツ内のハイパーリンクなど)その他のすべての資源は、デジタル出版物の境界の外です。

この仕様では、出版物の資源に制限を設けませんが、この仕様のプロファイルは、コンテンツの型と資源の位置の両方を制限できます(MAY)。

ユーザ・エージェントは、資源がデジタル出版物の境界内にあるかどうかに応じて、(出版物のオフライン版やパッケージ版から外部資源を除外するなど)資源を異なる方法で処理して表示することを選択できます(MAY)。

6. マニフェストの発見

6.2 組み込み

デジタル出版物の形式でマニフェストをHTMLドキュメントに組み込むことが許されている場合、マニフェストは、type属性をapplication/ld+jsonに設定した[json-ld11]script要素[html]に含まれていなければなりません(MUST)。

50: HTMLドキュメントに組み込まれた出版物マニフェストのscriptタグ
<script type="application/ld+json">
    {
        "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
        …
    }
</script>

6.3 その他の発見方法

デジタル出版物の形式は、(制限された名前や位置を用いてマニフェストを発見できるなど)マニフェストに対するリンクやマニフェストの組み込みを伴わないマニフェストを発見する代替方法を定義できます(MAY)。この仕様では、そのような方法に制限を加えません。

7. マニフェストの処理

この項は、インフラ標準[infra]に依存しています。

7.1 はじめに

この項は非規範的です。

デジタル出版物のマニフェストは[json-ld11]として作成されますが、この項で記述しているマニフェストの処理ステップでは、ユーザ・エージェントがマニフェストをデータの内部表現に変換する方法について詳細に説明します。アルゴリズムは、[infra]で定義されている用語とデータ型を用いてプロセスを記述し、成功した場合は、返されるデータの[infra]のマップになります。

用いられる言語に関わらず、このアルゴリズムの実際の実装では、対応する構成とデータ型を用います。

7.2 エラー処理

処理アルゴリズムでは、次のエラー・タイプを用います。

ユーザ・エージェントは検証エラーと致命的なエラーの両方を公開すべきですが(SHOULD)、この仕様ではそれを行う方法を規定していません。

検証エラーの場合、ユーザ・エージェントはエラーの重大性(つまり、必須事項に違反しているのか、推奨事項に違反しているのか)を区別すべきです(SHOULD)。

7.3 コンテキストの処理

処理アルゴリズムのステップの一部は、(urlは、出版物マニフェストの直接的なプロパティーの場合にのみURL配列を想定するなど)用語の想定される値のカテゴリに依存するため、用語を用いるコンテキストが処理に影響を与える可能性があります。これらの使用を区別するために、特定の関数の呼び出しにコンテキストを提供します。このコンテキストは、処理の呼び出しを開始するオブジェクトの型に対して設定します。

認識されている型のデフォルトのリストには、PersonOrganization、およびLinkedResourceが含まれます。プロファイルでこのリストを拡張し、追加のオブジェクトの型を含めることができます(MAY)。

関数にコンテキストが提供されていない場合は、処理されている用語はグローバルなコンテキストの一部と見なされます(つまり、マニフェストの直接の子です)。

認識されている型のリストを拡張する際には、すべてのオブジェクトに型が確実に指定されるように、(文字列の値が自動的にオブジェクトに展開されるなどの場合は)データの正規化の関数も拡張する必要がありえます。

7.4 内部表現の生成

このアルゴリズムは次の引数を取ります。

このアルゴリズムでは、マニフェストを検出し取得する方法は記述していません。そのためのステップは、それぞれのデジタル出版の形式によって定義されます。

内部表現を生成するためには、次のステップを実行します。

  1. processedを、マニフェストの内部表現を含む空のマップとします。

  2. manifestを、textを条件としてJSONをInfraの値へと解析した結果とします。manifestマップでなければ、致命的なエラーとなり、失敗を返します。

    説明

    出版マニフェストは、配列ではなくJSONオブジェクトで表さなければなりません。マニフェストを[infra]の型に変換した後に、結果の構造がマップであることを確認する追加のチェックが行われます。

  3. (§ 4.3 マニフェストのコンテキスト)manifest["@context"]リストに設定されていない場合や、manifest["@context"]の最初と2番目のアイテムが「https://schema.org」と「https://www.w3.org/ns/pub-context」(この順序で)という文字列の値でない場合は、致命的なエラーとなり、失敗を返します。

    説明

    コンテキストのURLが想定どおりに設定されていなければ、JSONデータは出版マニフェストを表しません。

  4. (§ 4.6 プロファイルの適合性)processed["profile"]を、マニフェストが準拠しているプロファイルとします。processed["profile"]を次のように設定します。

    1. manifest["conformsTo"]が設定されていない場合や、ユーザ・エージェントが処理や表示を行えると認識しているプロファイルが含まれていない場合は、ユーザ・エージェントは、読み上げ順序内の資源のメディア・タイプを調べて、処理や表示を行えるプロファイルに出版物が一致しているかどうかを判断すべきです(SHOULD)。一致していれば、検証エラーとなり、processed["profile"]を一致したプロファイルに設定します。そうでない場合は、致命的なエラーとなり、失敗を返します。

    2. そうでない場合は、processed["profile"]を、ユーザ・エージェントが処理や表示を行えるmanifest["conformsTo"]の最初のURLに設定します。

    プロセスのこのステップでは、manifest["conformsTo"]の値は文字列リストでありえます。

    説明

    出版物が準拠しているプロファイルによって、処理中に実行しなければならない追加の拡張ステップが決まります。このステップは、それぞれの仕様で定義されています。

    conformsToはプロファイル識別子に限定されないため、profileという新しい用語が作成されました(つまり、この新しい用語は、内部表現内のプロファイルの永続的な識別子を提供します)。

  5. (§ 4.4.1 グローバルな宣言)langをグローバルな言語とし、dirをこのステップで取得するグローバルな方向とします。それぞれを最初に空の文字列に設定します。

    manifest["@context"]contextごとにcontextマップであれば、最後のアイテムから最初のアイテムへと移動しながら、

    1. langが空の文字列で、context["language"]が定義されていれば、langcontext["language"]に設定します。
    2. dirが空の文字列で、context["direction"]が定義されていれば、dircontext["direction"]に設定します。
    3. langdirも空の文字列でなければ、中断します。

    langが空の文字列でも整形式の[bcp47]言語タグでもなければ、検証エラーとなり、langを空の文字列に設定します。

    dirが空の文字列でも、「ltr」か「rtl」のいずれの値でもなければ、検証エラーとなり、dirを空の文字列に設定します。

    説明

    ここで取得したグローバルな言語と方向の宣言は、宣言のないローカライズ可能な文字列にそれぞれ言語と基本書字方向を設定するために用います。

    最後の言語と方向の宣言が以前の宣言を上書きするため、イテレータは@contextを逆方向に移動します。

  6. (§ 4.3 マニフェストのコンテキスト)プロファイルでマニフェストのコンテキストの追加検証が必要であれば、そのステップはここで実行します。

    説明

    この拡張ステップでは、(追加のコンテキストのURLやパラメーターなどの)プロファイルに必要な情報がマニフェストのコンテキストに存在するかどうかを検証できます。@contextという用語は、次のステップでデータの正規化の一部として削除されるため、このステップはこの時点で実行しなければなりません。プロファイルのデータを処理するためのより一般的なステップは、後のステップで提供します。

  7. termmanifesttermごとに、成功した場合は、processed[term]を、termvaluelangdirbaseを条件としてデータの正規化を呼び出した結果に設定します。失敗が返された場合は、processedtermを追加しません。

    説明

    データの正規化ステップでは、入力するマニフェストのデータを標準化して、オブジェクトや配列が想定される場所で文字列を用いる機能など、オーサリングの便利な機能を排除します。その結果として処理されたデータは、processedという変数に追加され、後続のステップに影響を及します。

  8. processedを、processedを条件としてデータ検証を実行した結果に設定します。

    説明

    データの検証チェックにより、入力するデータは、想定される値のカテゴリと確実に一致するようになります。このステップでは、想定される値に対する制限も適用され、最終的な表現から無効なデータが削除されます。

  9. プロファイルで、実行する必要のある追加の処理機能が指定されていれば、そのステップはこの時点で実行します。

  10. 成功した場合は、processedを、指定されている場合はprocesseddocumentを条件としてデフォルト値の追加を実行した結果に設定します。そうでない場合は、処理を終了し、失敗を返します。

    説明

    このステップでは、マニフェストで欠落している情報を、ドキュメントにリンクされているHTMLドキュメントやその他の情報源から取得できるかどうかをチェックします。

  11. processedを返します。

結果の構造の視覚化については、§ A.内部表現データ・モデルを参照してください。

7.4.1 データの正規化

グローバルな言語であるlangグローバルな方向であるdir基底URLであるdir、およびオプションのコンテキストであるcontextを用いて、termというプロパティーのvalueデータを正規化するためには、次のステップを実行します。

  1. normalizedvalueの値とします。

    説明

    データの正規化ステップは、このステップで定義しているnormalized変数に保持されている入力値のコピーに対して実行します。この変数は、正規化プロセスが正常に終了したときに返されます。

  2. (§ 4.3 マニフェストのコンテキスト)term@contextであれば、失敗を返します。

    説明

    @contextは、マニフェストの初期処理のために情報を提供しますが、内部データ表現には保持されません。用語を削除するために失敗の通知を返します。

  3. (§ 4.2.7 配列)contextに応じて、term配列を想定していて、valueリストではなければ、normalizedリスト、つまり、≪ value ≫に設定します。

    説明

    様々な用語では、値は配列である必要がありますが、便宜上、著者は1つの要素の配列ではなく、1つの値を使用できます。例えば、

    {
        …
        "name"   : "Et dukkehjem",
        "author" : "Henrik Ibsen",
        …
    }

    によって次が生成されます。

    ≪[
        …
        "name"   → ≪ "Et dukkehjem" ≫,
        "author" → ≪ "Henrik Ibsen" ≫,
        …
    ]≫
  4. (§ 4.2.4.2 エンティティー)contextに応じて、termエンティティー配列を想定していれば、normalizedentityごとに

    1. entity文字列であれば、entityマップに設定します。

      ≪[
          "type" → ≪ "Person" ≫,
          "name" → entity
      ]≫
    2. そうでない場合は、entityマップでなければ、検証エラーとなり、normalizedからentity削除します。

    3. そうでない場合は、entity["type"]が設定されていなければ、それをリスト、つまり、≪ "Person" ≫に設定します。entity["type"]が設定されているけれども、PersonOrganizationという値が含まれていなければ、Personという値をリスト追加します。

    説明

    (著者、編集者などの)作成者は、オブジェクトとして明示的に定義されることが期待されますが、便宜上、マニフェストで指定しなければならないのは、その名前のみです。例えば、

    {
        …
        "author": "Ralph Ellison",
        …
    }

    この規則は、このような文字列の値をPersonというデフォルトの型を持つマップに変換し、それにより、前の例は次のようになります。

    ≪[
        …
        "author" → ≪ 
            ≪[
                "type" → ≪ "Person""name""Ralph Ellison"
            ]≫
        ≫,
        …
    ]≫

    シンプルにするために、nameのローカライズ可能な文字列への変換については、後のステップで説明します。

  5. (§ 4.2.4.1 ローカライズ可能な文字列)contextに応じて、termローカライズ可能な文字列配列を想定していれば、normalizeditemごとに

    1. item文字列であれば、itemマップに設定します。

      ≪[
          "value" → item,
          "language" → lang,
          "direction" → dir
      ]≫

      langdirが設定されていない場合や、空の文字列である場合は、それぞれitem["language"]item["direction"]削除します。

    2. そうでない場合は、itemマップでなければ、検証エラーとなり、normalizedからitemを削除します。

    3. そうでない場合は、item内のマップを次のように処理します。

      1. item["language"]が設定されていなければ、langが設定されていて、空の文字列ではない場合に、それをlangの値に設定します。

        そうでない場合は、item["language"]nullであれば、item["language"]削除します。

      2. item["direction"]が設定されていなければ、dirが設定されていて、空の文字列ではない場合に、それをdirの値に設定します。

        そうでない場合は、item["direction"]nullであれば、item["direction"]削除します。

    説明

    自然言語のテキスト値は、ローカライズ可能な文字列オブジェクトとして明示的に定義されることが期待されますが、便宜上、マニフェスト内のシンプルな文字列にすることができます。例えば、グローバルな言語の宣言により言語情報が提供されていなければ、次のようになります。

    {
        "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
        "name"     : ["La Comedie humaine"],
        …
    }

    これによって次が生成されます。

    ≪[
        "name"     → ≪
            ≪[
                "value""La Comedie humaine"
            ]≫
        ≫,
        …
    ]≫

    しかし、マニフェストで明示的な言語が指定されていれば、その言語はローカライズ可能な文字列オブジェクトに追加されます。例えば、

    {
        "@context" : [
            "https://schema.org",
            "https://www.w3.org/ns/pub-context",
            {"language": "fr"}
        ],
        "name"     : ["La Comedie humaine"],
        …
    }

    によって次が生成されます。

    {
        "name"     → ≪
            ≪[
                "value""La Comedie humaine"
                "language""fr"
            ]≫
        ≫,
        …
    }

    ローカルな設定やローカルなnull値は、グローバルな値が有効になることを防止します。

    {
        "@context" : [
            "https://schema.org",
            "https://www.w3.org/ns/pub-context", 
            {"language":"fr"}
        ],
        …
        "name" : [{
            "value" : "La Comedie humaine"
        }],
        "publisher" : [{
            "type":["Organization"],
            "name":[{
                "value": "Hachette",
                "language": null
            }]
        }],
        …
    }

    これによって次が生成されます。

    {
        "name"     → ≪
            ≪[
                "value""La Comedie humaine"
                "language""fr"
            ]≫
        ≫,
        "publisher"    → ≪
            ≪[
                "type" → ≪ "Organization" ≫,
                "name" → ≪
                    ≪[
                        "value""Hachette",
                    ]≫
            ]≫
        ≫,
        …
    }
  6. (§ 4.2.4.3 リンクされた資源)contextに応じて、termLinkedResources配列を想定していれば、normalizedresourceごとに

    1. resourceが文字列であれば、resourceマップに変換します。

      ≪[
          "type" → ≪ "LinkedResource" ≫,
          "url" → resource
      ]≫
    2. そうでない場合は、resourceマップでなければ、検証エラーとなり、normalizedからresourceを削除します。

    3. そうでない場合は、resource["type"]が設定されていなければ、それをリスト、つまり、≪ "LinkedResource" ≫に設定します。resource["type"]が設定されているけれども、LinkedResourceという値が含まれていなければ、その値をリスト追加します。

    説明

    資源のリンクは、LinkedResource型のオブジェクトとして明示的に設計されていることが期待されますが、便宜上、マニフェストで指定しなければならないのは、その絶対URLか相対URLのみです。例えば、

    {
        …
        "resources" : [
            "css/book.css",
            …
        ],
        …
    }

    このステップでは、文字列の値をオブジェクトに変換し、それにより、前の例は次のようになります。

    ≪[
        …
        "resources" → ≪
            ≪[
                "type" → ≪ "LinkedResource" ≫,
                "url""css/book.css"
            ]≫,
            …
        ≫,
        …
    ]≫

    シンプルにするために、相対パスから絶対パスへの変換については、後のステップで説明します。

  7. (§ 4.2.5 URL)contextに応じて、termURLURL配列を想定している場合、

    1. normalized文字列であれば、成功した場合は、normalizedを、normalizedを条件として絶対URLへの変換を実行した結果に設定します。失敗が返された場合は、失敗を返します。

    2. そうでない場合は、normalizedリストであれば、normalizeditemごとに、成功した場合は、itemを、normalizedを条件として絶対URLへの変換を実行した結果に設定ます。失敗が返された場合は、normalizedからitem削除します。

    3. そうでない場合は、検証エラーとなり、失敗を返します。

    説明

    マニフェスト内の相対URLは、絶対URLを得るために、基底の値に対して解決されます。例えば、

    "url": "chapter01.html"

    https://example.org/publications/wuthering-heightsで提供されている出版物の場合は、次が生成されます。

    "url""https://example.org/publications/wuthering-heights/chater01.html"
  8. (§ 8. モジュラー拡張、拡張ポイント)プロファイルで、プロファイル固有の用語に対する処理ステップが定義されていれば、そのステップはこの時点で実行します。

  9. 次のようにnormalizedを再帰的にチェックして、すべてのプロパティーが正規化されていることを確認します。

    1. normalizedリストであれば、マップであるnormalizeditemごとに

      1. item["type"]が設定されていて、認識されている型が含まれていれば、keyitemkeyValueごとに、成功した場合は、keyを、keykeyValuelangdirbaseを条件として、item["type"]をコンテキストとして用いてデータの正規化を実行した結果に設定します。失敗が返された場合は、itemからkey削除します。

      2. そうでない場合は、何もしません。

    2. そうでない場合は、normalizedマップであれば、

      1. normalized["type"]が設定されていて、認識されている型が含まれていれば、keynormalizedkeyValueごとに、成功した場合は、keyを、keykeyValuelangdirbaseを条件として、normalized["type"]をコンテキストとして用いてデータの正規化を実行した結果に設定します。失敗が返された場合は、normalizedからkey削除します。

      2. そうでない場合は、何もしません。

    3. そうでない場合は、何もしません。

    説明

    マニフェスト内のすべてのプロパティーが確実に処理されるようにするために、このステップでは、処理する追加のマップのエントリーに関してnormalizedを再帰的にチェックします。normalizedがリストであれば、各アイテムを検査し、処理可能なマップであるかどうかを判断します。

    失敗が返された場合は、アイテムはマップから削除されます。

  10. normalizedを返します。

7.4.1.1 絶対URLへの変換

基底URLであるbaseを用いて絶対URLであるurlに変換するためには、次のステップを実行します。

  1. urlまたはbase文字列ではない場合や、空の文字列である場合は、検証エラーとなり、失敗を返します。

    説明

    このステップでは、urlbaseの両方が空でない文字列であることをチェックした後で、それらを用います。

  2. 成功した場合は、urlを、urlを入力としてbaseを基底URLとして用いてURLパーサー[url]を実行した結果に設定します。失敗が返された場合は、検証エラーとなり、失敗を返します。

    説明

    このステップでは、処理するURLに対してURLパーサー関数を呼び出します。URLが絶対URLでなければ、パーサーは基底URLを用いてそれを変換します。

    解析で失敗が返された場合は、URLを削除するように指示するために、呼び出し元に失敗が返されます。

  3. urlを返します。

7.4.2 データ検証

マップdataデータ検証を実行するためには、次のステップを実行します。

  1. termdatavalueごとに、成功した場合は、termを、termvalueを条件としてグローバルなデータ・チェックを実行した結果に設定します。失敗が返された場合は、data[term]を削除します。

    説明

    このステップでは、各エントリーを、値に対して、および値内の任意のプロパティーに対して再帰的に実行する必要がある一連のグローバルな検証チェックに渡します。

    プロパティーが無効で、削除しなければならない場合は、失敗を返します。

  2. プロファイルで、データの検証チェックが指定されていれば、そのステップはこの時点で実行します。

    説明

    プロファイルの検証ステップはデフォルトのステップよりも優先されるため、例えば、プロファイルが異なるデフォルト値を適用する場合には、その値が適用されます。

  3. (§ 4.5 出版物の型)data["type"]が設定されていない場合や、空のリストである場合は、検証エラーとなり、≪ "CreativeWork" ≫に設定されます。

  4. (§ 4.7.1.2 アクセシビリティ)data["accessModeSufficient"]が設定されていれば、data["accessModeSufficient"]itemごとにitem["type"]が設定されていない場合や、「ItemList」が含まれていない場合は、data["accessModeSufficient"]からitem削除します。

  5. (§ 4.7.1.4 正規の識別子)data["id"]が設定されていない場合や、空の文字列である場合は、検証エラーとなります。

  6. (§ 4.7.1.6 時間長)data["duration"]が設定されていて、[iso8601-1]による有効な時間長でなければ、検証エラーとなり、data["duration"]削除します。

  7. (§ 4.7.1.7 最終修正日)data["dateModified"]が設定されていて、[iso8601-1]による有効な日付や日時でなければ、検証エラーとなり、data["dateModified"]削除します。

  8. (§ 4.7.1.8 公開日)data["datePublished"]が設定されていて、[iso8601-1]による有効な日付や日時ではなければ、検証エラーとなり、data["datePublished"]削除します。

  9. (§ 4.7.1.9 出版言語)data["inLanguage"]が設定されていれば、data["inLanguage"]itemごとにitem整形式[bcp47]でなければ、検証エラーとなり、data["inLanguage"]からitem削除します

  10. (§ 4.7.1.10 読み上げの進行方向)data["readingProgression"]が設定されていなければ、「ltr」に設定します。そうでない場合は、それが必須の方向の値の1つでなければ、検証エラーとなり、「ltr」に設定します。

  11. (§ 5. 出版物資源)次のように、出版の境界内の一意のURLを取得して検証します。

    1. readingOrderが設定されていれば、readingOrderURLsを、readingOrderを条件として一意のURLの取得を実行した結果とします。そうでない場合は、readingOrderURLsを空の順序付き集合にします。

    2. resourcesが設定されていれば、resourcesURLsを、resourcesを条件として一意のURLの取得を実行した結果とします。そうでない場合は、resourcesURLsを空の順序付き集合にします。

    3. data['uniqueResources']readingOrderURLsresourceURLs和集合に設定します。

    説明

    このステップでは、読み上げ順序と資源リスト内の一意のURLのリストを取得します。次に、data['uniqueResources']をこれら2つの集合の和集合に設定します。これは、出版物の境界内の一意の資源の完全なリストを表します。

    このステップでは、readingOrderresourcesのいずれかに重複する資源の宣言が含まれている場合にも警告を出します。検証エラーは、各リストから一意のURLを取得する際に出されます。

  12. (§ 4.8.1 構造資源)次のように構造関係の使用について検証します。

    1. 定義されている場合は、resourcesdata["readingOrder"]の値に設定し、そうでない場合は、空のリストに設定します。定義されている場合は、data["resources"]resources拡張します。

    2. resources内の複数のアイテムに、大文字と小文字を区別しない値である「contents」が含まれているrelエントリーがあれば、検証エラーとなります。

    3. resources内の複数のアイテムに、大文字と小文字を区別しない値である「pagelist」が含まれているrelエントリーがあれば、検証エラーとなります。

    4. resources内の複数のアイテムに、大文字と小文字を区別しない値である「cover」が含まれているrelエントリーがあれば、検証エラーとなります。

      表紙に画像のメディア・タイプ(image/*)を指定しているencodingFormatエントリーがあり、nameエントリーがなければ、検証エラーとなります。

    説明

    これは、読み上げ順序と資源リストで指定されている資源をチェックし、目次、ページ・リスト、表紙のインスタンスが1つだけ指定されていることをチェックします。

    表紙に関しては、アクセシビリティを目的として、画像ベースの形式に名前が設定されていることもチェックします。

  13. termdataの値ごとにtermvalueの変数を条件として空の配列の削除を実行すると失敗を返す場合は、data["term"]削除します。

    説明

    マニフェストの処理には様々な段階で無効な値の削除が伴うため、最終的なデータ構造は、値がまったく含まれなくなったリストになる可能性があります。このステップでは、データを繰り返し処理し、そのような空のリストをすべて削除します。

  14. dataを返します。

7.4.2.1 グローバルなデータ・チェック

オプションのコンテキストであるcontextを用いてtermというプロパティーのvalueグローバルなデータ・チェックを処理するためには、次のステップを実行します。

  1. (§ 4.2 値のカテゴリ)termに既知の値のカテゴリがあれば、成功した場合は、valueを、termvaluecontextという変数を条件として値のカテゴリの検証を呼び出した結果に設定します。失敗が返された場合は、失敗を返します。

    そうでない場合は、valueを返します。

    説明

    このステップでは、用語の値がその用語に必要な想定されるカテゴリと一致することを検証します。例えば、要約された用語にはブール値が必要であるため、この用語にその他の値を用いると失敗に終わります。

    関数の呼び出しで失敗が発生すれば、このステップでも失敗が返されるため、プロパティーは最終的なデータセットから削除されます。

    既知の値のカテゴリがない用語は処理されないため、入力値が返されます。

  2. 最初にサブプロパティーをチェックするために、次のように再帰的にvalueへと降下します。

    1. valueマップであれば、

      1. value["type"]認識されている型が含まれていれば、keyvaluekeyValueごとに、成功した場合は、value[key]を、keykeyValueを条件として、value["type"]をコンテキストとして用いてグローバルなデータ・チェックを実行した結果に設定します。失敗が返された場合は、value[key]削除します。

      2. そうでない場合は、何もしません。

    2. そうでない場合は、valueリストであれば、valueitemごとにitemマップであれば、

      1. item["type"]認識されている型が含まれていれば、keyitemkeyValue ごとに、成功した場合は、item[key]を、keykeyValueを条件として、item["type"]をコンテキストとして用いてグローバルなデータ・チェックを実行した結果に設定します。失敗が返された場合は、item[key]削除します。

      2. そうでない場合は、何もしません。

    3. そうでない場合は、何もしません。

    説明

    マニフェスト内のすべてのプロパティーが確実に処理されるようにするために、このステップでは、処理する追加のマップのエントリーに関して各エントリーを再帰的にチェックします。値がリストであれば、各アイテムを検査し、処理可能なマップであるかどうかを判断します。

    これを置くことで、すべてのサブプロパティーが最初に確実にチェックされるため、無効な値が削除された後で、ステップの後半のより高レベルなチェックを行えます。

  3. (§ 4.4.1 グローバルな宣言§ 4.4.2 アイテム固有の宣言)termLocalizableStrings配列を想定していれば、valueitemごとに

    • item["value"]が設定されていなければ、valueからitem削除します。

    • item["language"]が設定されていて、その値が整形式[bcp47]でなければ、検証エラーとなり、item["language"]削除します。

    • item["direction"]が設定されていて、その値が「ltr」か「rtl」のいずれかでなければ、検証エラーとなり、item["direction"]削除します。

    説明

    このステップでは、ローカライズ可能な文字列に値があること、その言語の宣言が整形式であること、その方向の宣言に「ltr」か「rtl」の値があることをチェックします。

  4. (§ 4.2.4.2 エンティティー)termエンティティー配列を想定していれば、valueitemごとにitem["name"]が設定されているかどうかをチェックします。

    • そうでない場合は、検証エラーとなり、valueからitem削除します。

    • そうである場合は、item["name"]nameごとにname["value"]が設定されていない場合や、空の文字列である場合は、item["name"]からname削除します。
    説明

    このステップでは、すべてのエンティティーに名前があることを確認します。名前のないエンティティーは削除されます。

  5. (§ 4.2.4.3 リンクされた資源)termLinkedResources配列を想定していれば、valueresourceごとに

    • resource["url"]が設定されていない場合や、その値が空の文字列である場合は、検証エラーとなり、valueからresource削除し、その後に続行します。

      そうでない場合は、resource["url"]が有効なURL[url]でなければ、検証エラーとなり、valueからresource削除し、その後に続行します。

    • resource["duration"]が設定されていて、[iso8601-1]による有効な時間長の値ではなければ、検証エラーとなり、resource["duration"]削除します。

    説明

    このステップでは、LinkedResourceの用語に次の2つのチェックを実行します。

    1. URLが指定されていない場合や、無効である場合は、LinkedResourceを削除します。
    2. 資源の時間長が指定されている場合や、ISO 8601の時間長の値でない場合は、時間長のプロパティーを削除します。
  6. valueを返します。

7.4.2.2 値のカテゴリの検証

コンテキストであるcontexttermというプロパティーのvalue値のカテゴリの検証を行うためには、次のステップを実行します。

  1. contextに応じて、term配列を想定していれば、

    1. valueリストでなければ、検証エラーとなり、失敗を返します。

    2. そうでない場合は、valueitemごとに

      1. itemが配列の想定している値のカテゴリと一致しない場合は、検証エラーとなり、valueからitem削除し、その後に続行します。

      2. itemマップであれば、keyitemkeyValueごとにkeyに想定している値のカテゴリがあれば、keyを、keykeyValueを条件として、item["type"]をコンテキストとして用いて値のカテゴリの検証を実行した結果に設定します。itemの処理結果が空のマップであれば、検証エラーとなり、valueからitem削除します。

      valueの処理結果が空の配列であれば、検証エラーとなり、失敗を返します。

  2. そうでない場合は、contextに応じて、termマップを想定していれば、

    1. valueマップでなければ、検証エラーとなり、失敗を返します。

    2. そうでない場合は、keyvaluekeyValueごとにkeyに想定している値のカテゴリがあれば、keyを、keykeyValueを条件として、value["type"]をコンテキストとして用いて値のカテゴリの検証を実行した結果に設定します。valueの処理結果が空のマップであれば、検証エラーとなり、失敗を返します。

    このステップは現在、プロファイルで用いるためにのみ存在しています。この仕様で定義しているプロパティーはすべて、オブジェクトの配列を受け入れます。

  3. そうでない場合は、contextに応じて、valuetermの想定している値のカテゴリと一致しなければ、検証エラーとなり、失敗を返します。

  4. valueを返します。

説明

この関数は、処理中の用語の値がその想定している値のカテゴリと一致することをチェックします。値がリストやマップであれば、関数は再帰的に呼び出され、マニフェスト内のすべてのプロパティーが確実にチェックされます。

7.4.2.3 一意のURLの取得

resourcesから一意のURLを取得するためには、次のステップを実行します。

  1. uniqueURLsを空の順序付き集合とします。

  2. resourcesresourceごとに、

    1. urlを、exclude fragment flagを設定してresource["url"]URLシリアライザー[url]を実行した結果とします。

    2. uniqueURLsurl含まれていれば、検証エラーです。そうでない場合は、uniqueURLsurl追加します。

    3. resource["alternate"]が設定されていれば、resource["alternate"]alternateごとに、

      1. alt_urlを、exclude fragment flagを設定してalternate["url"]URLシリアライザー[url]を実行した結果とします。

      2. uniqueURLsalt_url含まれていれば、検証エラーです。

      3. そうでない場合は、alt_urluniqueURLs追加します。

  3. uniqueURLsを返します。

説明

この関数は、(読み上げ順序か資源リストのいずれかから)LinkedResourceオブジェクトのリストを取得し、一意のURLの集合を返します。重複が検出されれば、警告が出されます。

7.4.2.4 空の配列の削除

termというプロパティーのvalueから空の配列を削除するためには、次のステップを実行します。

  1. valueが空のリストであれば、失敗を返します。

  2. そうでない場合は、valueマップであれば、keyvaluekeyValueごとにkeykeyValueを条件として空の配列の削除を実行すると失敗を返す場合は、value[key]削除します。

説明

この関数は、処理中の用語の値が空のリストではないことをチェックします。当初リストを持っていた用語は、処理されると(つまり、リストのアイテムが無効な場合)エントリーを失う可能性があります。

7.4.3 デフォルト値の追加

オプションのHTMLドキュメント(DOM)ノード[html]documentを用いて、マップdata内の欠落しているプロパティーにデフォルト値の追加を行うためには、次のステップを実行します。

  1. (§ 4.7.1.11 タイトル)data["name"]が設定されていなければ、

    • titleを空のマップとします。その値を次のように設定します。

      • documentが設定されていれば、documenttitle要素[html]が設定されていて空でなければ、title["value"]title要素のテキストのコンテンツに設定します。

        利用可能な場合はtitle["language"]言語[html]に設定し、その値が利用可能でその値が「ltr」か「rtl」のいずれかであれば、title["direction"]基本書字方向[html]に設定します。

      • そうでない場合は、検証エラーとなり、title["value"]に対して値を生成します(詳細については別の注記を参照)。生成されたタイトルに応じて、title["language"]title["direction"]を設定します。

    • data["name"]リスト、つまり、≪ title ≫に設定します。
    説明

    このステップでは、マニフェストでnameプロパティーが指定されていない場合に、documenttitle要素のコンテンツを追加します。例えば、

    <html>
    <head lang="en">
        <title>The Golden Bough</title><script type="application/ld+json">
        {
            "@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
            …
        }
        </script>

    によって次が生成されます。

    ≪[
        …
        "name" → ≪
            ≪[
                "value""The Golden Bough",
                "language""en"
            ]≫
        ≫,
        …
    ]≫
  2. (§ 4.7.2.1 デフォルトの読み上げ順序§ 6.1 リンク)data["readingOrder"]が設定されていなければ、

    説明

    デジタル出版物が参照ドキュメントのみで構成されていれば、デフォルトの読み上げ順序を省略でき、自動的に、その1つの資源で構成されます。

  3. ユーザ・エージェントが生成しなければならないデフォルト値がプロファイルで指定されていれば、そのステップはこの時点で実行します。

  4. (§ 6.1 リンク)document.URLが設定されていて、data["uniqueResources"]document.URL含まれていなければ、検証エラーです。

    説明

    マニフェストにリンクされているページが、コアと拡張のデフォルト値の規則を処理した後に、出版物の一意の資源として掲載されていなければ、それは出版物資源でなければならないため、エラーが発生します。

  5. dataを返します。

8. モジュラー拡張

この仕様で定義しているマニフェスト形式は、(オーディオブックや学術出版物などの)新しいプロファイルを作成する際に、出版コミュニティが実装して拡張するように設計されています。マニフェスト形式が提供する柔軟性により、各コミュニティの特定のニーズに合わせて調整できると同時に、プロファイルを処理する必要のあるユーザ・エージェントに共通の基盤を提供します(つまり、各プロファイル間の差異を最小限に抑え、相互運用性をシンプルにします)。

プロファイルがこの仕様と互換性を持つためには、次の条件を満たさなければなりません(MUST)。

  1. § 4. 出版マニフェストで定義しているマニフェストの構築要件に準拠していなければなりません(MUST)。
  2. 一意の適合するURLを定義し、適合する出版物がそのconformsToプロパティーにこのURLを含めることを必須としなければなりません(MUST)。
  3. マニフェストの発見には、リンク方法のいずれかまたは両方を用いなければなりません(MUST)。
  4. § 7. マニフェストの処理で説明している汎用的な処理ステップは、拡張したマニフェストでも有効でなければなりません(MUST)。これを達成するために、また、新しい用語を一般的なマニフェストに追加する場合は、次のとおりです。
    • 用語は、該当する場合に、アルゴリズムで用いる(配列ローカライズ可能な文字列などの)1つ以上の一般的な用語カテゴリに分類すべきです(SHOULD)。これは、関連する処理ステップがその用語に対して自動的に実行されることを意味します。
    • 必要に応じて、処理アルゴリズム内の指定された拡張ポイントで実行される独自の処理ステップをプロファイルで定義できます(MAY)。このような追加のステップは、一般的に処理アルゴリズム用に定義されているステップの結果を無効にしてはなりません(MUST NOT)。
編集者のメモ

利用できる場合には、オーディオブックのプロファイルなどによって追加された用語の例を追加すると良いでしょう。

9. セキュリティとプライバシーに関する留意点

マニフェストはJSON-LDを用いて表すため、その仕様で詳述されているプライバシーセキュリティの留意点[json-ld11]は、マニフェストのすべてのプロファイルにも当てはまります。

プロファイルに関するその他の一般的な留意点は次のとおりです。

より具体的なセキュリティとプライバシーに関する留意点は、デジタル出版物形式の性質によって異なるため、詳細については各プロファイルに委ねられています。

A. 内部表現データ・モデル

この項は非規範的です。

マニフェストには、デフォルト値、通常はオブジェクトが必須である場所で文字列を用いる機能、(タイトル読み上げ順序などの)他の情報源の情報の自動編集など、オーサリングに関する便利な機能がいくつか含まれています。マニフェストの処理はこれらの便利な機能を正規化し、その結果、ユーザ・エージェントにとって整合性があるデータセット(内部表現)が得られますが、このセットは、処理アルゴリズムから簡単に視覚化することはできません。

この付録では、結果のデータ構造を記述する[WebIDL]を用いた参考情報である抽象データ・モデルを提供します。この定義は、処理後のマニフェストのメンバーごとに、想定される名前、データ型、制限の候補を表します。

WebIDLの選択は、例示のみを目的としています。この仕様では、マニフェスト・データ公開用のAPIは定義していません。

A.1 PublicationManifest辞書

dictionary PublicationManifest {
             sequence<DOMString>         type = "CreativeWork";
    required DOMString                   profile;
             sequence<DOMString>         conformsTo;
             DOMString                   id;
             boolean                     abridged;
             sequence<DOMString>         accessMode;
             sequence<DOMString>         accessModeSufficient;
             sequence<DOMString>         accessibilityFeature;
             sequence<DOMString>         accessibilityHazard;
             sequence<LocalizableString> accessibilitySummary;
             sequence<Entity>            artist;
             sequence<Entity>            author;
             sequence<Entity>            colorist;
             sequence<Entity>            contributor;
             sequence<Entity>            creator;
             sequence<Entity>            editor;
             sequence<Entity>            illustrator;
             sequence<Entity>            inker;
             sequence<Entity>            letterer;
             sequence<Entity>            penciler;
             sequence<Entity>            publisher;
             sequence<Entity>            readBy;
             sequence<Entity>            translator;
             sequence<DOMString>         url;
             DOMString                   duration;
             sequence<DOMString>         inLanguage;
             DOMString                   dateModified;
             DOMString                   datePublished;
             TextDirection               readingProgression = "ltr";
    required sequence<LocalizableString> name;
    required sequence<LinkedResource>    readingOrder;
             sequence<LinkedResource>    resources;
             sequence<LinkedResource>    links;
             sequence<DOMString>         uniqueResources;
};

enum TextDirection {
    "ltr",
    "rtl"};

A.1.1 LinkedResource辞書

dictionary LinkedResource {
    required DOMString                   url;
             DOMString                   encodingFormat;
             sequence<LocalizableString> name;
             sequence<LocalizableString> description;
             sequence<DOMString>         rel;
             DOMString                   integrity;
             DOMString                   duration;
             sequence<LinkedResource>    alternate;
};

A.1.2 Entity辞書

dictionary Entity {
             sequence<DOMString>         type;
    required sequence<LocalizableString> name;
             DOMString                   id;
             DOMString                   url;
             sequence<DOMString>         identifier;
};

A.1.3 LocalizableString辞書

dictionary LocalizableString {
    required DOMString                   value;
             DOMString                   language;
             TextDirection               direction;
};

B. 代替資源の選択

この付録は、インフラ標準[infra]に依存しています。

LinkedResourceresourceに対して代替資源の選択を行うためには、次のステップを実行します。

成功すれば、このアルゴリズムは代替資源を返します。そうでない場合は、失敗を返します。

  1. possibleAlternatesを空のリストにします。

  2. resource["alternate"]が設定されていなければ、失敗を返します。

  3. resource["alternate"]alternateごとに

    1. alternate["encodingFormat"]が設定されていて、ユーザ・エージェントが指定されているメディア・タイプをサポートしていれば、possibleAlternates追加します。

    2. そうでない場合は、プロファイルで追加の選択基準が定義されていれば、それに対して、この拡張ステップでalternateを評価します。

    3. そうでない場合は、メディア・タイプに関する手がかりを得るために、オプションでalternate["url"]を調べます。資源がサポートされているようであれば、possibleAlternatesalternate追加します。

  4. possibleAlternatesが空のリストであれば、失敗を返します。

  5. そうでない場合は、possibleAlternatesサイズが1であれば、possibleAlternatesから資源を返します。

  6. そうでない場合は、ユーザ・エージェントの決定にしたがってpossibleAlternatesから資源を返します。

説明

この関数は、資源の代替形式を繰り返して、リストの候補を編集します。複数の候補が見つかった場合、ユーザ・エージェントは、優先順位を付けて最も良い代替案を選択する方法を決定します。

ユーザ・エージェントは、明示的なメディア・タイプが指定されていなければ、リストの候補に代替を追加する必要はありません。

C. 機械処理可能な目次

C.1 はじめに

この項は非規範的です。

ページ内およびサイト間のナビゲーションを容易にするために、HTMLではnav要素[html]でリンクのリストを表します。nav要素の目的は、デフォルトでは汎用的ですが、role属性[html]を用いるとより具体的に特定できます。特に、[dpub-aria-1.0]語彙のdoc-tocという役割は、nav要素をデジタル出版物の目次として特定します。

識別可能な目次を含めることは、任意のデジタル出版物の作成において利用しやすい方法ではありますが、HTMLのマークアップは柔軟であるため、(任意のページから利用できるカスタム・ビューの提供などの)意味のあるリンクの階層を抽出しようとするユーザ・エージェントにとっては課題もあります。様々な用途の目次が重複することを避けるために、この項では、ユーザ・エージェントの抽出のために十分な構造を提供しながら、人間にとってもわかりやすく一般的にも用いられる構文を定義します。

著者は、自身の目次を構築するために(順序付きか順序なしかの)リストの選択を行えます。このリスト内の各リンクをアンカー・タグ(a要素)内でタグ付けすることにより、ユーザ・エージェントは、必要な情報と、追加された周辺コンテンツ(aside)やスタイル・タグとを容易に区別できます。目次は、(href属性を用いた)アクティブなリンクと(href属性を除いた)アクティブでないリンクの両方で構成でき、(特定の見出しへのリンクを省略したり、プレビュー内の特定のコンテンツのみにリンクしたりなどの)目次の構成方法にさらなる柔軟性を提供します。

しかし、ユーザ・エージェントは、目次の表示に関する状況を保持する必要がない(つまり、ユーザ・エージェントは通常、すべての出版物に共通する方法で情報を表示するために情報を抽出する)ことに注意してください。例えば、ユーザ・エージェントは、リンク要素のテキストのコンテンツのみを保持することが期待されているため、テキストのスタイル、インライン画像、その他のテキストではないコンテンツは失われる可能性があります。同様に、リストのスタイル設定や、表示するリンクの深さのレベルさえも、ユーザ・エージェントの裁量に委ねられています。そのため、ユーザが機械処理されたものに限定されてしまわないように、表示用の目次にリンクすることをお勧めします。

C.2 HTML構造

目次は、[html]要素(通常はnav要素)で表されます。この要素は、role属性[html]の値である「doc-toc」[dpub-aria-1.0]で識別されなければならず(MUST)、そのrole値を持つドキュメント・ツリーの順序[dom]においてドキュメントの最初の要素でなければなりません(MUST)。この要素はユーザに非表示にすることができます(MAY)。

マニフェストは、目次が含まれている資源を識別すべきです(SHOULD)。

nav要素のコンテンツ・モデルには制限はありませんが、ユーザ・エージェントは、次のマークアップのガイドラインに従っている場合にのみ、利用可能な目次を抽出できます。

目次のタイトル

目次のタイトルはオプションですが、必要なときにユーザ・エージェントがプレースホルダーのタイトルを生成しないように、追加することをお勧めします。タイトルは、[html]のh1からh6の要素のいずれかを用いて指定します。この要素の最初のもののみがタイトルとして認識されることに注意してください。リンクのリストの前に見出し要素がなければ、ユーザ・エージェントはそれが指定されていないと見なします。

nav要素内で最初に検出される[html]のolまたはulのlist要素には、コンテンツへのリンクを定義しているリストが含まれていると見なされます。このリストは、例えば、アルゴリズムによってその処理に関係のない要素が無視されるため、div要素内で入れ子になっている場合でも見つかります。しかし、スキップする要素の内部にリストを含めることは、その内部のコンテンツが評価されないため、できません。

nav要素にこれらの要素の1つが含まれていなければ、ユーザ・エージェントは、デジタル出版物を、(機械表示のオプションは利用できないなど)利用可能な目次が含まれているものとして登録しません。

ブランチ

目次がリンクのツリーと見なされる場合、リンクのリスト内の個々のリスト・アイテム(li要素)は1つのブランチを表します。これらの各ブランチには、ユーザに表示するために名前と、オプションの行き先がなければならず、この情報は、入れ子になっている場所に関係なく、リスト・アイテム内で最初に見つかったa要素から得られます(ここでも、スキップする要素内のa要素を除く)。

ブランチのリンク先は、指定されていれば、a要素のhref属性から得られます。(プレビューなどで)リンクを利用できない場合や、(ヘッダーのグループ化などの)関連性がない場合には、この属性は省略できます。コンテンツへのリンクを提供する場合、(rel属性で)リンクされたドキュメントの関係性と、(type属性で)リンクされた資源のメディア・タイプを指定することもできます。

ブランチをラベル付けするa要素を見つけた後、ユーザ・エージェントは、別のリスト要素(つまり、サブブランチ)のマークアップを引き続き検査します。リストが見つかれば、処理する入れ子のブランチがなくなるまで、リンクを抽出するなどの同様の処理を継続します。

スキップする要素

誤った解釈を避けるために、目次の解析時に小さな要素は無視します。それは、[html]のセクショニング・コンテンツ要素セクショニング・ルート要素です。これらを無視する理由は、これらが独自のアウトラインを定義できる(つまり、自己完結型であり、必ずしもコンテンツ・リンクの構造に関連のない組み込みコンテンツを表すことができる)ためです。

非表示の要素はユーザが直接アクセスすることを目的としていないため、hidden属性が設定されている要素もスキップします。

これらの要素はnav要素に含めることができますが、(コンテンツへのすべてのリンクを含んでいるリスト・アイテムの周りにsection要素をラップしないなど)重要なコンテンツをそれらの要素に組み込まないように注意しなければなりません。

無視する要素

目次の抽出に関係がなく、スキップされない要素はすべて無視します。スキップする要素とは異なり、無視するということは、ユーザ・エージェントが要素内で関連コンテンツを検索し続けることを意味するため、利用可能なタグ付けの柔軟性が高まります。

C.2.1

この項は非規範的です。

C.3 ユーザ・エージェントの処理

この項は、インフラ標準[infra]に依存しています。

この項では、nav要素から目次を抽出するためのアルゴリズムを定義します。これは、DOMツリーのノード上をツリー順[dom]にウォークするという観点で定義しており、各ノードは、ウォーク中の入るときと出るときに訪問されます。ノードを訪問するたびに、入るイベントか出るイベントが生じると考えることができます。一部のステップでは、ユーザ・エージェントは、コンテンツ処理方法の選択肢を提供して、様々な表示モデルに柔軟性を提供します。

DOMから必要な情報を得るためにすべての子孫ノードを検査する必要があるとは限らないため、このアルゴリズムは純粋にイベント駆動型の用語では定義されていません。場合によっては、要素とそのすべての子要素は、入る時に処理された直後にスキップされます。イベントのアプローチを適用することもできますが、スキップしたノードを処理/無視するようにアルゴリズムを変更する必要があります。

ユーザ・エージェントは、データの最終形式を表すことができる任意の言語を用いて、結果の構造を処理して取り込むことができます。

このアルゴリズムの目的上、list要素は[html]のolulの要素として定義します。

次のアルゴリズムは、要素が非表示と宣言[html]されているか、表示されないようにCSSでスタイル設定されているかに関係なく、role属性の値であるdoc-tocを持つ、ドキュメント順序で最初の要素をルートとするDOMサブツリーのウォークに適用しなければなりません(MUST)。

目次要素が含まれている資源を見つけるための規則は、§ 4.8.1.3 目次で定義しています。

目次要素が見つからなければ、出版物には、機械表示の目的で利用できる目次はありません。

  1. tocを、目次を表すマップ≪[ "name" → "", "entries" → ≪ ≫ ]≫とします。

    説明

    このステップでは、目次のタイトルとブランチを格納するマップを初期化します。このマップでは、

    1. toc["name"]は、目次のタイトルを表します。
    2. toc["entries"]は、目次のブランチを表します。
  2. スタックbranchesを初期化し、作成時に目次のブランチを保持します。

    説明

    スタックは、未完成のブランチを保持するために用います。新しいサブブランチが検出されると、親がスタックにプッシュされ、後で取得できるようになります。

  3. current_toc_nodenullに設定された変数とします。

    説明

    current_toc_nodeは、現在処理中の目次のブランチを表すマップを保持するために用います。

  4. 目次の構築元である要素から始めて、DOM上をツリー順[dom]にウォークし、ウォークが要素に出入りするときに、要素ごとに次の最初の関連するステップを生じさせます。

    1. 見出しコンテンツ要素に入るときは、

      次のステップを実行します。

      1. branchesが空で、toc["name"]が空の文字列であれば、toc["name"]を次のいずれかに設定します。

        • 要素の子孫コンテンツ(HTMLタグを保持するため)。
        • (要素のアクセシブルな名前[accname-1.1]を計算するなどにより)子孫コンテンツから得たテキスト文字列。

        (表示要素を削除し、先頭と末尾の空白をすべて切り取った後などに)toc["name"]の結果の値が空の文字列であれば、toc["name"]をプレースホルダーの値かnullに設定します。

      2. それ以降の要素の処理をスキップして、次へ進みます。
      説明

      このステップでは、目次の見出しを識別します。見出しは、toc["name"]の値が空の文字列である(つまり、見出しが未検出である)場合にのみ処理されます。

      ユーザ・エージェントがnameを見出し要素の子孫コンテンツに設定するのか、(画像、MathML、rubyなどの容易にテキストに変換できないコンテンツを保持するなどのために)それからテキスト文字列を生成するのかは、子孫タグを表示で再利用するかどうかによって異なります。

      69: 見出しのあるtocオブジェクトの視覚化
      ≪[
          "name""Contents",
          "entries" → ≪ ≫
      ]≫

      nameが空の文字列でない場合や、nullである場合は、前の見出しは検出済みであるか、(見出しはリンクのリストを辿らないため、リストは処理済みであるなど)nav要素に見出しがないことを示すコンテンツが検出されています。

      70: 見出しのないtocオブジェクトの視覚化
      ≪[
          "name"null,
          "entries" → ≪ ≫
      ]≫

      見出しが指定されていなければ、ユーザ・エージェントは、後で用いるために独自の見出しを提供できます。

    2. リスト要素に入るときは、

      次の手順を実行します。

      1. toc["name"]が空の文字列であれば、toc["name"]nullに設定します。

      2. current_toc_nodenullでなければ、

        1. current_toc_node["entries"]nullまたは空でないリストであれば、それ以降の要素の処理をスキップして、次へ進みます。
        2. そうでない場合は、current_toc_nodebranchesプッシュし、その後にcurrent_toc_nodenullに設定します。
      3. そうでない場合は、branchesが空であれば、

        1. toc["entries"]nullまたは空でないリストであれば、それ以降の要素の処理をスキップして、次へ進みます。
        2. そうでない場合は、何もしません。
      説明

      このアルゴリズムは、1つのブランチやnav要素のルートにある複数のリストを処理しないため、リストが検出済みであれば(entriesプロパティーに1つ以上のブランチが含まれていたり、nullに設定されていれば)、このリストはスキップされます。

      リストが検出され、目次(toc)にまだ名前がなければ(つまり、見出し要素が検出されていなければ)、目次には見出しがない(つまり、最初のエントリーのリストの後に、目次の見出しを表示できない)と見なされます。それ以上は検出された見出しが適用されないため、nameプロパティーの値は、空の文字列からnullへと変更されます。

    3. リスト要素を出るときは、

      1. branchesが空でなければ、branchesからトップのマップポップし、current_toc_nodeをそれに設定します。

      2. そうでない場合は、toc.entriesに空のリストが含まれていれば、それをnullに設定します。

      説明

      このステップにより、すべての子のブランチを処理した後で、current_toc_nodeが親オブジェクトにリセットされます。

      スタックにブランチがなければ、アイテムがまったく含まれていない場合に、(ルート・レベルでそれ以上のリストが処理されないようにするために)toc.entriesがnullに設定されます。

    4. リスト・アイテム要素に入るときは、current_toc_nodeを次のマップに設定します。

      ≪[
          "name"null,
          "url"null,
          "type"null,
          "rel"null,
          "entries" → ≪ ≫
      ]≫
      説明

      各リスト・アイテムは、目次の新しいブランチの候補を表すため、それが検出されると、新しい空白のオブジェクトがcurrent_toc_nodeに作成されます。

      子孫のa要素とリストが検出されると、このオブジェクトに情報が入力されます。

    5. リスト・アイテム要素を出るときは、

      次のステップを実行します。

      1. current_toc_node["entries"]に空のリストが含まれていれば、それをnullに設定します。

      2. current_toc_node["name"]nullまたは空の文字列であれば、

        1. current_toc_node["entries"]nullでなければ、current_toc_node["name"]をプレースホルダーの値かnullに設定します。
        2. そうでない場合は、current_toc_nodenullに設定し、この処理ステップを出ます。
      3. branchesが空でなければ、current_toc_nodebranchesのトップにあるマップentriesプロパティーに追加します。そうでない場合は、current_toc_nodetoc["entries"]追加します。

      4. current_toc_nodenullに設定します。

      説明

      リスト・アイテムを出るということは、現在のブランチの処理が完了したことを示します。このブランチを親のentries配列に追加する前に、ブランチをテストして、名前および/またはサブブランチがあるかどうかをテストする必要があります。名前はないけれどもサブブランチがある場合は、ブランチは保持されます。ユーザ・エージェントは、独自に作成したプレースホルダーの値を提供するか、値をnullに設定できます。名前やブランチがなければ、無効となり破棄されます。

      ブランチを統合する場所を決定するために、スタックをチェックします。スタックにアイテムがなければ、ルートのtocオブジェクトのentriesプロパティーに追加されます(つまり、最上位のブランチです)。そうでない場合は、スタック内の直前のオブジェクトのentriesプロパティーに追加されます。

      最後のステップとして、current_toc_nodenullにリセットされます。

    6. アンカー要素に入り、current_toc_nodenullでないときは、

      次のステップを実行します。

      1. current_toc_node["name"]nullでなければ、何もしません。

      2. そうでない場合は、

        1. current_toc_node["name"]を次のいずれかに設定します。

          • アンカー要素の子孫コンテンツ(HTMLタグを保持するため)。
          • (要素のアクセシブルな名前[accname-1.1]を計算するなどにより)子孫コンテンツから得たテキスト文字列。
        2. 要素にhref属性があり、属性のURLがuniqueResources内の資源に対して解決されれば、current_toc_node["url"]を値に設定します。
        3. 要素にtype属性があり、先頭と末尾の空白を切り取った後に、属性の値が空の文字列でなければ、current_toc_node["type"]を切り取った値に設定します。
        4. 要素にrel属性があり、先頭と末尾の空白を切り取った後に、属性の値が空の文字列でなければ、切り取った値を空白で分割し、current_toc_node["rel"]を結果のトークンのリストに設定します。

        それ以降の要素の処理をスキップして、次へ進みます。

      説明

      このステップでは、アンカー・タグを処理して、ブランチのnameurlのプロパティーの値を取得します。

      現在のブランチの名前が定義済みであれば、この要素の処理は終了します(つまり、1つのブランチに対する複数のリンク処理を回避する)。

      ユーザ・エージェントがエントリーのnamea要素の子孫コンテンツに設定するのか、(画像、MathML、rubyなどの容易にテキストに変換できないコンテンツを保持するなどのために)それからテキスト文字列を生成するのかは、子孫タグを表示で再利用するかどうかによって異なります。

      href属性の指定に加えて、この仕様の要件を満たすためには、デジタル出版物に属する資源に対して解決する必要があります。そうしない場合は、ブランチは保持されますが、エントリーはリンク可能になりません。

      リンクのターゲットに関する追加情報(資源の型とその関係)も保持されます。

    7. セクショニング・コンテンツ要素、セクショニング・ルート要素、または非表示属性を持つ要素に入るときは、

      それ以降の要素の処理をスキップして、次へ進みます。

      説明

      セクショニング要素とセクショニング・ルート要素は独自のアウトラインを定義できるため、それらにまで降下すると目次の生成に問題が発生します(つまり、直接関連しないコンテンツが含まれる可能性があります)。その結果、これらは、子のコンテンツが処理されることを防ぐために、検出されたときにスキップされます。

    8. そうでない場合は、何もしません。

      説明

      その他のすべての要素で、このステップにより、それらの子孫要素の処理をを継続できます。

  5. DOMウォークの完了後、toc["entries"]に空でないリストが含まれていれば、tocを返します。そうでない場合は、nullを返します。

    説明

    (nav要素にリストが見つからなかったか、適合するリスト・アイテムがリストに含まれていなかったため)ルートのtocオブジェクト内のentriesの配列にブランチが含まれていなければ、アルゴリズムは使用可能な目次を生成しません。

D. 変更履歴

最初の公開草案以後の本質的な変更

対応済みの課題の完全なリストについては、GitHub trackerを参照してください。

E. IANAに関する留意点

この項は非規範的です。

F. マニフェストの例

この項は非規範的です。

F.1 基本的なマニフェスト

下記は、本のプロファイルの例のための基本的なメタデータの集合が含まれているマニフェストです。

このマニフェストの内部表現のJSONエンコーディングも利用できます。

{
    "@context": [
        "https://schema.org",
        "https://www.w3.org/ns/pub-context",
        {"language" : "en"}
    ],
    "conformsTo": "https://example.com/publication",
    "type": "Book",
    "url": "https://publisher.example.org/mobydick",
    "author": "Herman Melville",
    "dateModified": "2018-02-10T17:00:00Z",

    "readingOrder": [
        "html/title.html",
        "html/copyright.html",
        "html/introduction.html",
        "html/epigraph.html",
        "html/c001.html",
        "html/c002.html",
        "html/c003.html",
        "html/c004.html",
        "html/c005.html",
        "html/c006.html"
    ],

    "resources": [
        "css/mobydick.css",
        {
            "type": "LinkedResource",
            "rel": "cover",
            "url": "images/cover.jpg",
            "encodingFormat": "image/jpeg"
        },{
            "type": "LinkedResource",
            "url": "html/toc.html",
            "rel": "contents"
        },{
            "type": "LinkedResource",
            "url": "fonts/STIXGeneral.otf",
            "encodingFormat": "application/vnd.ms-opentype"
        },{
            "type": "LinkedResource",
            "url": "fonts/STIXGeneralBol.otf",
            "encodingFormat": "application/vnd.ms-opentype"
        },{
            "type": "LinkedResource",
            "url": "fonts/STIXGeneralBolIta.otf",
            "encodingFormat": "application/vnd.ms-opentype"
        },{
            "type": "LinkedResource",
            "url": "fonts/STIXGeneralItalic.otf",
            "encodingFormat": "application/vnd.ms-opentype"
        }
    ]
}

F.2 単一ドキュメントの出版物

以下は、記事プロファイルの例のマニフェストです。記事は、マニフェストが組み込まれているドキュメントのみで構成されています。タイトルと読み上げ順序は、これらのプロパティーが、処理中に、含まれているドキュメントのタイトルとURLからそれぞれ自動的に生成されているため、マニフェストから省略しています。

マニフェストの内部表現のJSONエンコーディング、および同じドキュメントのより複雑なバージョンも利用できます。

<!DOCTYPE html>
<html lang="en-US">
<head>
    <title>Model for Tabular Data and Metadata on the Web</title>
    <link href="#wpm" rel="publication" />
    ...
    <script id="wpm" type="application/ld+json">
    {
        "@context"        : [
            "https://schema.org",
            "https://www.w3.org/ns/pub-context",
            {"language" : "en-US"}
        ],
        "conformsTo"      : "https://example.com/article",
        "type"            : "TechArticle",
        "id"              : "http://www.w3.org/TR/tabular-data-model/",
        "url"             : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
        "copyrightYear"   : "2015",
        "copyrightHolder" : "World Wide Web Consortium",    
        "creator"         : ["Jeni Tennison", "Gregg Kellogg", "Ivan Herman"],
        "publisher" : {
            "type" : "Organization",
            "name" : "World Wide Web Consortium",
            "id"   : "https://www.w3.org/"
        },
        "datePublished"         : "2015-12-17",
        "resources"             : [
            "datatypes.html",
            "datatypes.svg",
            "datatypes.png",
            "diff.html",
            {
                "type"           : "LinkedResource",
                "url"            : "test-utf8.csv",
                "encodingFormat" : "text/csv"

            },
            {
                "type"           : "LinkedResource",
                "url"            : "test.xlsx",
                "encodingFormat" : "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
            }
        ],
    }
    </script>
</head>
<body>
    ....

    <section id="toc" role="doc-toc">
        <h2 resource="#h-toc" id="h-toc" class="introductory">Table of Contents</h2>
        <ul class="toc">
            <li class="tocline"><a class="tocxref" href="#intro">
                <span class="secno">1. </span>Introduction</a>
            </li>
            ...
        </ul>
    </section>
    ...

</body>
</html>

F.3 オーディオブック

次の例は、オーディオブックのプロファイル[audiobooks]に準拠しているマニフェストを示しています。

このマニフェストの内部表現のJSONエンコーディングも利用できます。

{
  "@context": [
      "https://schema.org",
      "https://www.w3.org/ns/pub-context",
      {"language": "en"}
  ],
  "conformsTo": "https://www.w3.org/TR/audiobooks/",
  "type": "Audiobook",
  "id": "https://librivox.org/flatland-a-romance-of-many-dimensions-by-edwin-abbott-abbott/",
  "url": "https://w3c.github.io/pub-manifest/experiments/audiobook/",
  "name": "Flatland: A Romance of Many Dimensions",
  "author": "Edwin Abbott Abbott",
  "readBy": "Ruth Golding",
  "publisher": "Librivox",
  "inLanguage": "en",
  "dateModified": "2019-11-14",
  "datePublished": "2008-10-12",
  "duration": "PT13774S",
  "license": "https://creativecommons.org/publicdomain/zero/1.0/",
  "abridged": false,
  "accessMode": "auditory",
  "accessModeSufficient": [{
      "type": "ItemList",
      "itemListElement": ["auditory"],
      "description": "Audio"
  }],
  "accessibilityFeature": ["readingOrder", "unlocked"],
  "accessibilityHazard": "noSoundHazard",
  "accessibilitySummary": "This is just a test summary",
  "readingProgression": "ltr",
  "resources": [
    {
      "rel": "cover",
      "url": "http://ia800704.us.archive.org/9/items/LibrivoxCdCoverArt12/Flatland_1109.jpg",
      "encodingFormat": "image/jpeg",
      "name": "Cover page with title and author"
    },{
      "rel": "contents",
      "url": "toc.html",
      "encodingFormat": "text/html"
    },{
        "rel": "accessibility-report",
        "url": "a11y.html",
        "encodingFormat": "text/html"
    },{
        "rel": "privacy-policy,",
        "url": "privacy.html",
        "encodingFormat": "text/html"
    }
  ],

  "readingOrder": [
    {
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_1_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1371S",
      "name": "Part 1, Sections 1 - 3"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_2_abbott.mp3",
      "encodingFormat": "audio/mpeg", 
      "duration": "PT1669S",
      "name": "Part 1, Sections 4 - 5"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_3_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1506S",
      "name": "Part 1, Sections 6 - 7"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_4_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1669S",
      "name": "Part 1, Sections 8 - 10"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_5_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1506S",
      "name": "Part 1, Sections 11 - 12"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_6_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1798S",
      "name": "Part 2, Sections 13 - 14"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_7_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1225S",
      "name": "Part 2, Sections 15 - 17"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_8_abbott.mp3",
      "encodingFormat": "audio/mpeg",
      "duration": "PT1371S",
      "name": "Part 2, Sections 18 - 20"
    },{
      "url": "http://www.archive.org/download/flatland_rg_librivox/flatland_9_abbott.mp3", 
      "encodingFormat": "audio/mpeg",
      "duration": "PT1659S",
      "name": "Part 2, Sections 21 - 22"
    }
  ]
}

G. プロパティーの索引

この項は非規範的です。

次の表は、マニフェスト・プロパティーを定義、拡張している場所を示しています。

名前 出版マニフェスト
abridged § 4.7.1.1 要約版
accessMode § 4.7.1.2 アクセシビリティ
accessModeSufficient § 4.7.1.2 アクセシビリティ
accessibilityFeature § 4.7.1.2 アクセシビリティ
accessibilityHazard § 4.7.1.2 アクセシビリティ
accessibilitySummary § 4.7.1.2 アクセシビリティ
artist § 4.7.1.5 作成者
author § 4.7.1.5 作成者
conformsTo § 4.6 プロファイルの適合性
@context § 4.3 マニフェストのコンテキスト
contributor § 4.7.1.5 作成者
creator § 4.7.1.5 作成者
dateModified § 4.7.1.7 最終修正日
datePublished § 4.7.1.8 公開日
direction § 4.4.1 グローバルな宣言
duration § 4.7.1.6 時間長
editor § 4.7.1.5 作成者
id § 4.7.1.4 正規の識別子
illustrator § 4.7.1.5 作成者
inker § 4.7.1.5 作成者
inLanguage § 4.7.1.9 出版言語
language § 4.4.1 グローバルな宣言
letterer § 4.7.1.5 作成者
link § 4.7.2.3 リンク
name § 4.7.1.11 タイトル
penciler § 4.7.1.5 作成者
publisher § 4.7.1.5 作成者
readBy § 4.7.1.5 作成者
readingOrder § 4.7.2.1 デフォルトの読み上げ順序
readingProgression § 4.7.1.10 読み上げの進行方向
resources § 4.7.2.2 資源リスト
translator § 4.7.1.5 作成者
type § 4.5 出版物の型
url § 4.7.1.3 アドレス

H. 資源関係索引

この項は非規範的です。

次の表は、資源関係の使用について定義している場所を示しています。

名前 出版マニフェスト
accessibility-report § 4.8.2.1 アクセシビリティ報告書
contents § 4.8.1.3 目次
cover § 4.8.1.1 表紙
pagelist § 4.8.1.2 ページ・リスト
privacy-policy § 4.8.2.3 プライバシー方針
preview § 4.8.2.2 プレビュー

I. 謝辞

この項は非規範的です。

編集者は、この仕様に貢献してくださったPublishingワーキンググループのメンバーに感謝します。

ワーキンググループはまた、この仕様への道を開いてくれたすべての努力に関し、Digital Publishingインタレスト・グループのメンバーに感謝申し上げます。

J. 参考情報

J.1 規範的な参考文献

[accname-1.1]
Accessible Name and Description Computation 1.1. Joanmarie Diggs; Bryan Garaventa; Michael Cooper. W3C. 18 December 2018. W3C Recommendation. URL: https://www.w3.org/TR/accname-1.1/
[bcp47]
Tags for Identifying Languages. A. Phillips; M. Davis. IETF. September 2009. IETF Best Current Practice. URL: https://tools.ietf.org/html/bcp47
[bibo]
Bibliographic Ontology Specification. Bruce D'Arcus; Frederick Giasson. Structured Dynamics LLC. 11 May 2016. URL: http://bibliontology.com/specification.html
[bibtex]
BibTeX Format Description. URL: http://www.bibtex.org/Format/
[bidi]
Unicode Bidirectional Algorithm. Mark Davis; Aharon Lanin; Andrew Glass. Unicode Consortium. 12 February 2020. Unicode Standard Annex #9. URL: https://www.unicode.org/reports/tr9/tr9-42.html
[dc11]
Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[dcterms]
DCMI Metadata Terms. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[dom]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[dpub-aria-1.0]
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
[ecmascript]
ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/
[foaf]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jagenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
Link Relations. URL: https://www.iana.org/assignments/link-relations/link-relations.xhtml
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[iso8601-1]
Date and time — Representations for information interchange — Part 1: Basic rules. ISO 8601-1:2019.. International Organization for Standardization (ISO). 2019. ISO 8601-1:2019. URL: https://www.iso.org/standard/70907.html
[json]
The application/json Media Type for JavaScript Object Notation (JSON). D. Crockford. IETF. July 2006. Informational. URL: https://tools.ietf.org/html/rfc4627
[json-ld11]
JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[mfrel]
Microformats Wiki: existing rel values. Microformats.. URL: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
[onix]
ONIX for Books. URL: https://www.editeur.org/83/Overview
[rfc2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. N. Freed; N. Borenstein. IETF. November 1996. Draft Standard. URL: https://tools.ietf.org/html/rfc2046
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[rfc5988]
Web Linking. M. Nottingham. IETF. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[rfc8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[schema.org]
Schema.org. URL: https://schema.org
[sri]
Subresource Integrity. Devdatta Akhawe; Frederik Braun; Francois Marier; Joel Weinberger. W3C. 23 June 2016. W3C Recommendation. URL: https://www.w3.org/TR/SRI/
[url]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
[wcag21]
Web Content Accessibility Guidelines (WCAG) 2.1. Andrew Kirkpatrick; Joshue O Connor; Alastair Campbell; Michael Cooper. W3C. 5 June 2018. W3C Recommendation. URL: https://www.w3.org/TR/WCAG21/

J.2 参考情報の参考文献

[audiobooks]
Audiobooks. Wendy Reid; Matt Garrish. W3C. 10 November 2020. W3C Recommendation. URL: https://www.w3.org/TR/audiobooks/
[ecma-404]
The JSON Data Interchange Format. Ecma International. 1 October 2013. Standard. URL: https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
[json-ld10]
JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Langhaler. 2014-01-16. W3C Recommendation. URL: https://www.w3.org/TR/2014/REC-json-ld-20140116/
[json-schema]
JSON Schema: core definitions and terminology. K. Zyp. Internet Engineering Task Force (IETF). 31 January 2013. Internet-Draft. URL: https://tools.ietf.org/html/draft-zyp-json-schema
Identifier: A Link Relation to Convey a Preferred URI for Referencing. H. Van de Sompel; M. Nelson; G. Bilder; J. Kunze; S. Warner. IETF. URL: https://tools.ietf.org/html/draft-vandesompel-identifier-00
[string-meta]
Requirements for Language and Direction Metadata in Data Formats. Addison Phillips; Richard Ishida. 2017-12-01. URL: https://w3c.github.io/string-meta/
[WebIDL]
Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/
[webschemas-a11y]
WebSchemas Accessibility. URL: https://www.w3.org/wiki/WebSchemas/Accessibility