出版物マニフェスト

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
バグを報告する
コミット履歴
プルリクエスト

公開後に報告されたエラーや問題については、正誤表を確認してください。

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

この文書は、次の非規範的形式でも入手できます: EPUB

Copyright © 2020 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

概要

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

この文書のステータス

このセクションは、公開時点におけるこの文書のステータスを説明する。他の文書が この文書に優先する可能性がある。現在のW3C 出版物の一覧およびこの技術報告の最新改訂版は、https://www.w3.org/TR/ のW3C技術 報告インデックスで確認できる。

この文書は、Publishing Working Groupにより勧告として公開された。

この仕様に関する議論には、GitHub Issuesが推奨される。 あるいは、メーリングリストにコメントを送ることもできる。コメントはpublic-publ-wg@w3.org（アーカイブ）宛てに送信してください。

W3C勧告とは、広範な合意形成を経た後、 W3Cおよびその会員の支持を受けた仕様である。W3Cは、この仕様をWebの標準として広く展開することを推奨する。 この勧告の将来の更新には、新機能が組み込まれる可能性がある。

この文書は、2017年8月1日付W3C特許ポリシーの下で運営されるグループにより作成された。W3Cは、このグループの成果物に関連して行われた特許開示の公開リストを維持しており、 そのページには特許を開示するための手順も含まれている。個人が、必須 クレームを含むとその個人が考える特許について実際の知識を有する場合、その情報をW3C特許ポリシーの第6節に従って開示しなければならない。

この文書は、2020年9月15日付W3Cプロセス文書により管理される。

1. はじめに

1.1 範囲

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

この仕様は、異なるユーザーエージェントアーキテクチャを促進することも意図している。従来の Webユーザーエージェント（ブラウザー）が出版物マニフェストを利用できることが期待される一方で、 これは他の可能な種類のユーザーエージェント（例: スタンドアロンまたはユーザーエージェント内で動作する アプリケーション、あるいは独自のユーザーインターフェイスを含む出版物）の機能を制限するべきではない。

この仕様は、マニフェスト形式を使用する出版物をユーザーエージェントがどのようにレンダリングすることが期待されるかを定義しない。

1.2 マニフェスト形式

このセクションは非規範的である。

デジタル出版物は、そのマニフェストによって記述される。マニフェストは、リンクトデータ用の JSON-LD [json-ld11]（JSON [ecma-404]の一種）の特定の形で表現される プロパティの集合を提供する。

マニフェストは、ユーザーエージェントがデジタル 出版物の境界とそのリソース間のつながりを理解できるようにするものである。 出版物はその構成リソースを超えた同一性と性質を持つため、マニフェストにはデジタル出版物を記述する メタデータが含まれる。マニフェストはまた、デジタル出版物に属するリソース一覧と 既定の読書順序を提供し、これによってリソースを単一の連続した作品として接続する。

マニフェストのプロパティは、ユーザーエージェントが出版物を処理およびレンダリングするために必要とする基本情報を記述する。 理解しやすくするため、これらのプロパティは次のように分類される:

記述的プロパティ

記述的プロパティは、デジタル出版物のタイトル、作成者、言語などの側面を記述する。

リソース分類プロパティ

リソース分類プロパティは、リソース一覧や既定の 読書順序など、共通のリソース集合を記述または識別する。これらのプロパティは、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プロパティに対応する場合、そのプロパティ 定義はマッピングを識別し、定義元の型（例: CreativeWorkまたはBook）を括弧内に含める。

Schema.orgにはさらに、出版に関連するものの、この仕様では言及されない多くのプロパティが含まれる。 この文書はマニフェスト項目の最小集合のみを定義するため、これらのプロパティはマニフェストで使用できる （§ 4.7.3.2 追加のマニフェストプロパティを参照）。

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

追加のSchema.orgプロパティの使用に関する詳細情報は、§ 4.5 出版物 タイプおよび§ 4.7.3.2 追加のマニフェストプロパティにも記載されている。

2. 用語

この仕様はInfra標準[infra]に依存する。

境界

デジタル出版物は、その内容を表す有限個の リソース集合で構成される。この範囲はその境界として知られ、§ 5. 出版物リソースで説明されるように、そのマニフェスト内で定義される。

デジタル出版物

デジタル出版物とは、マニフェストのプロファイルを使用する 形式で作成された任意の出版物である。

内部表現

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

曖昧さや欠落情報がない場合、マニフェストで表現された情報が、ユーザーエージェントによって作成される 内部表現と同等である可能性がある。

マニフェスト

マニフェストは、情報提供メタデータ、リソース一覧、および既定の読書順序など、出版物に関する構造化情報を表す。

プロファイル

プロファイルとは、この仕様で定義されるマニフェスト形式を使用して、 自らの境界と内容を記述する出版形式（例: オーディオブック）である。 これらの形式は、プロファイル固有の用語および/または新しい要件によって、この仕様の中核定義を拡張できる。

プロファイルは構造要件および内容要件において異なる場合があるが、そのような差異は、形式間の高い予測可能性を 維持するために制限される。（§ 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] 真偽値 （trueまたはfalse）として表現しなければMUSTならない。

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

さまざまなマニフェストプロパティは、[json] オブジェクトとして表現されることが期待される。 通常は明示的オブジェクトの使用が推奨されるが、次のセクションでは文字列値の使用も 許容される場合を特定する。これらの文字列は、ユーザーエージェントによるマニフェストの処理中に自動的にオブジェクトへ 変換される（テキスト値からオブジェクトへの正確な対応付けは各定義に含まれる）。

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

マニフェストプロパティがローカライズ可能なテキスト文字列を 値として期待する場合、その値は次のいずれかとして表現しなければMUSTならない:

単一の文字列値は、valueプロパティがその文字列のテキストであり、 その言語および基底方向がマニフェスト内の他の情報から決定される暗黙的オブジェクトを表す。

ローカライズ可能文字列は値の複数言語表現を容易にすることを意図しているため、 ローカライズ可能文字列を受け入れるプロパティは常にこれらの値の配列を受け入れる。 このため、単一の文字列またはオブジェクトだけを作成すればよい場合でも、 そのような値は処理の一貫性のため配列へ変換される。

LocalizableStringは、次の プロパティから成る[json] オブジェクトである:

用語 説明 必須値 値カテゴリ [schema.org]対応付け
value ローカライズ可能文字列の値。REQUIRED。 テキスト。 リテラル （なし）
language 値の言語。OPTIONAL。 整形式の言語 タグ [bcp47]。 リテラル （なし）
direction 値の基底方向。OPTIONAL。 ltrまたはrtl リテラル （なし）

基底方向値の意味は次のとおりである:

  • ltr: テキスト値が左から右のテキストとして明示的に方向付けられていることを示す。
  • rtl: テキスト値が右から左のテキストとして明示的に方向付けられていることを示す。

基底方向値がない場合、そのテキスト値は、Unicode双方向アルゴリズム [bidi]の規則に従い、 強い方向性を持つ最初の文字の方向へ明示的に設定されることを意味する。

注記

最後の例で基底方向値が設定されていない場合、そのテキストは、 Unicode双方向アルゴリズム [bidi]に従い、また文字列の先頭に ラテン文字が存在するため、次のように表示される:

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

しかし、それは正しくない。望ましい表示を得るには、追加のdirection値が 必要である:

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

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

さらなる説明と例については、[string-meta] 文書も参照。

4.2.4.2 エンティティ

マニフェストプロパティがエンティティ（すなわち、作成のさまざまな側面に 責任を持つ個人または組織）を期待する場合、その値は次のいずれかとして表現しなければMUSTならない:

単一の文字列値は、nameプロパティがその文字列のテキストであり、 typeがPerson [schema.org]であると仮定されるEntityオブジェクトの インスタンスを表す。

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]のPerson型またはOrganization型に定義される 任意の追加プロパティを含めることができる。ユーザーエージェントも同様に、上記の プロパティのみを解釈することに限定されない。

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（Property）
alternate

encodingFormatが再構成の形式を指定する場合における、 代替形式のリソースの1つ以上の再構成への参照。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 識別子

識別子は、デジタル出版物およびその作成に責任を持つ エンティティを、永続的かつ曖昧さのない方法で参照するために使用される。 URL、URN、DOI、ISBN、およびPURLはすべて、出版で頻繁に使用される 永続識別子の例である。

識別子はURLレコード [url]として表現しなければMUSTならない

4.2.7 配列

マニフェストプロパティが、それぞれの型（例: リテラル、オブジェクト、またはURL）の1つ以上の値を 許可する場合、これらの値は[json] 配列として表現される。ただし、 プロパティ値が単一要素である場合、配列構文は省略しても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で定義されたプロパティに機能を追加する（例: creatorプロパティが順序を保持することの要件）。

この仕様のプロファイルは、 追加のコンテキスト URLを要求してもMAYよいが、 そのようなURLは これら2つの構成要素の後に並べなければMUSTならない。

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

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

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

マニフェスト内の各自然言語プロパティ値（例: title、creators）には既定の自然言語があり、これはその値が表現される言語（例: 英語、 フランス語、中国語）である。また、それには書かれる際の自然な基底方向、 すなわち左から右または右から左の表示方向もある。

デジタル出版物マニフェストは、ユーザーエージェントがメタデータを解釈し 表示するのを支援するため、これら両方の概念をグローバルにも、個別項目にも設定できる機能を提供する。

注記

基底方向を設定できる機能は、JSON-LD 1.1 [json-ld11]の 機能である。言い換えれば、Publication Manifestは、以前の 1.0 [json-ld10]バージョンではなく、そのバージョンのJSON-LD仕様に依存している。

4.4.1 グローバル宣言

自然言語マニフェストプロパティに対するグローバルな言語および基底方向の宣言は、 コンテキスト内で、それぞれlanguage およびdirection キーワード [json-ld11]を使用して設定される。これらの 値は、マニフェストの処理中に単純な文字列値をローカライズ可能 文字列へ展開するために使用されるだけでなく、 言語または基底方向を省略したローカライズ可能文字列に対して、それらを提供するためにも使用される。

languageの値は、 整形式の言語 タグ [bcp47]でなければMUSTならない。

directionの値は、 次の値のいずれかでなければMUSTならない:

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

グローバルな言語および基底方向宣言が存在する場合、それは出版物コンテキストの後に続かなければMUSTならない。

グローバルな言語または基底方向には既定値は指定されない。

4.4.2 項目固有の 宣言

マニフェスト内の任意の自然言語値について、localizable stringを使用して、 言語または基底方向を局所的に設定できる:

languageおよび direction キーワード [json-ld11]の可能な値は、グローバル宣言の場合と同じである。さらに、どちらの値も nullの（JSON）値にでき、その場合は明示的な言語、または方向がそれぞれ設定されていないことを示す。

注記

languageの値をnullに設定することは、 値（例: 組織名）が関連付けられた言語なしで一般に使用される場合（例: "Google"）に有用である。

言語または基底方向の局所宣言は、それぞれグローバル宣言に優先する。

4.5 出版物タイプ

デジタル出版物の マニフェストは、 typeキーワード [json-ld11]を使用して、その出版物 タイプを定義する。型は任意の[schema.org]型に対応付けてもMAYよいが、 型が指定されていない場合は、CreativeWorkが既定として想定される。

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

CreativeWorkのより具体的なサブタイプ、たとえばArticle、Book、TechArticle、およびCourseは、CreativeWorkの代わりに、 またはそれに加えて使用できる。

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

各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 Audiobooks仕様に適合することを識別する。 
{
    …
    "conformsTo" : "https://www.w3.org/TR/audiobooks/",
    …
}

4.7 プロパティ

4.7.1 記述的プロパティ

4.7.1.1 抄約版

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

用語 説明 必須値 値カテゴリ [schema.org]対応付け
abridged 書籍が抄約版であるかどうかを示す。 trueまたはfalseのいずれか。 真偽値 abridged（Book）
例 18 : 出版物が抄約版であることを設定する。 
{
    …
    "abridged" : true,
    …
}
4.7.1.2 アクセシビリティ

アクセシビリティプロパティは、異なる好みの読書モダリティを持つユーザーによる利用に対して、 デジタル出版物がどの程度適しているかに関する情報を提供する。 これらのプロパティは通常、[wcag21]で提供されるような、 確立されたアクセシビリティ基準に対する評価を補足する。

次のプロパティはアクセシビリティプロパティとして分類される:

用語 説明 必須値 値カテゴリ [schema.org]対応付け
accessMode 人が情報を処理または知覚するために用いる、人間の感覚知覚系または認知能力。 1つ以上のテキスト。 配列（リテラルの） accessMode（CreativeWork）
accessModeSufficient リソースの知的内容すべてを理解するのに十分な、単一または組み合わせたアクセスモードの一覧。 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]ではauthorの同義語として マークされているが、どちらが優先されるか、またはそれらをどう組み合わせるかについての指針はない。 いずれか一方のみを使用し、より具体的なauthorプロパティを優先することが推奨される。

 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]のインスタンス。

単一の文字列値は、その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",
    …
}
注記

関連する Wikipediaページは、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 あるリソースから別のリソースへの読書進行方向。 ltrまたはrtlのいずれか。 リテラル （なし）

このプロパティの値は次のいずれかでなければ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ならない:

単一の文字列値は、その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ならない:

単一の文字列値は、その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 リンクされたレコード

マニフェストは、ONIX [onix]またはBibTeX [bibtex]などのメタデータレコードへのリンクを通じて、 LinkedResourceオブジェクトを使用して 拡張してもMAYよい。この場合:

  • LinkedResourceのrelプロパティには 関連する識別子が含まれる（例: リンクされたレコードが記述メタデータを含む場合、 describedby識別子[iana-link-relations]を使用できる）。
  • encodingFormatの値は、該当する場合、その特定の種類のレコードに対して 定義されたMIMEメディア型 [rfc2046]を識別する。

リンクされたレコードが出版物の一部である場合（すなわち、単なるマニフェスト拡張性以上の目的で必要な場合）、 それらはリソース一覧に含まれる。それ以外の場合は、リンク一覧に含まれる。

例 33 : 外部のONIX for Booksメタデータレコードにリンクする。 
{
    …
    "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]は、Dublin Core Terms（dcterms） [dcterms]およびElement Set（dc） [dc11]、FOAF 語彙（foaf）[foaf]、 およびBibliographic Ontology（bibo）[bibo]など、 よく使用される語彙のための複数の接頭辞を定義する。 これらの語彙のプロパティは、接頭辞を宣言しなくても使用できる。

例 35 : Schema.orgの'copyrightYear'および'copyrightHolder'用語を使用して 基本データを拡張する。 
{
    …
    "copyrightYear"   : "2015",
    "copyrightHolder" : "World Wide Web Consortium",
    …
}
例 36 : Dublin Coreの'subject'用語を2012 ACM Classification用語とともに使用して 基本データ集合を拡張する。 
{
    …
    "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]に従うことが強く推奨される。 この情報を埋め込む機能を提供しない画像形式については、nameおよびdescriptionプロパティを、LinkedResourceで使用して、 それぞれ代替 テキストおよび拡張説明を提供できる。このような場合、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つの方法は、 画像が表紙であることを識別する文字列に、出版物タイトルを続けて代替テキストを構築することである。

表紙として識別されるリソースは1つだけであってもMAYよいが、 追加の表紙は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リンク関係には登録されていないが、 ワーキンググループはこれを追加する予定である。

ページリストを含むものとして識別されるリソースは1つだけであってもMAYよい。 複数のインスタンスが指定されている場合、ユーザーエージェントは最初に検出した インスタンスを使用しなければ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を持つ最初の要素である。

目次を含むものとして識別されるリソースは1つだけであってもMAYよい。 複数のインスタンスが指定されている場合、ユーザーエージェントは最初に検出した インスタンスを使用しなければ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およびresourcesに列挙されたリソースの和集合から取得され、 これには任意のalternateリソースも含まれる。この一覧を 作成する正確な手順は、マニフェスト処理アルゴリズムで説明される。

その他すべてのリソースはデジタル出版物の境界外にある（例: linksセクションに列挙されたリソース、およびコンテンツ内の外部 Webリソースへのハイパーリンク）。

この仕様は出版物リソースにいかなる制限も課さないが、この仕様のプロファイルは、 リソースのコンテンツ型と場所の両方を制限してもMAYよい。

ユーザーエージェントは、リソースがデジタル出版物の境界内にあるかどうかに応じて、 リソースの処理およびレンダリングを異なる方法で行うことを選択してもMAYよい （例: 出版物のオフライン版またはパッケージ版から外部リソースを除外する）。

6. マニフェスト発見

6.2 埋め込み

デジタル出版物形式が、マニフェストを HTML文書内に埋め込むことを許可する場合、マニフェストは script 要素 [html]内に含めなければMUSTならず、そのtype 属性はapplication/ld+jsonに設定される [json-ld11]。

例 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標準[infra]に依存する。

7.1 はじめに

このセクションは非規範的である。

デジタル出版物のマニフェストは [json-ld11]として作成されるが、この セクションで説明されるマニフェスト処理の手順は、 ユーザーエージェントがマニフェストをデータの内部 表現へどのように変換するかを詳述する。このアルゴリズムは、[infra]で定義される用語および データ型を使用して処理を説明し、成功した場合には、データの[infra] mapが 返される結果となる。

注記

このアルゴリズムの実際の実装では、使用される言語に対応する構造および データ型が使用される。

7.2 エラー処理

次のエラー型は、処理アルゴリズムで使用される:

ユーザーエージェントは、検証エラーと致命的エラーの両方を公開すべきSHOULDであるが、 この仕様はその方法を規定しない。

検証エラーについては、ユーザーエージェントはエラーの重大度 （すなわち、必須または推奨される実践が違反されたかどうか）を区別すべきSHOULDである。

7.3 処理コンテキスト

処理アルゴリズムの一部の手順は、 用語の期待される値カテゴリに依存するため、用語が使用されるコンテキストは処理に影響を与える可能性がある （例: urlは、Publication Manifestの直接のプロパティである場合にのみ、URLの配列を期待する）。 これらの使用を区別するため、特定の関数呼び出しにはコンテキストが提供される。 このコンテキストは、処理呼び出しを開始するオブジェクトの型に設定される。

認識される 型の既定の一覧には、Person、Organization、および LinkedResourceが含まれる。プロファイルは、 追加のオブジェクト型を含めるようこの一覧を拡張してもMAYよい。

コンテキストが関数に提供されていない場合、処理される用語はグローバル コンテキストの一部（すなわち、マニフェストの直接の子）とみなされる。

注記

認識される型の一覧を拡張する場合、すべてのオブジェクトに型が 指定されていることを保証するために、データの正規化関数も 拡張する必要がある場合がある（例: 文字列値が自動的にオブジェクトへ展開される場合）。

7.4 内部 表現を生成する

このアルゴリズムは次の引数を取る:

注記

このアルゴリズムは、マニフェストがどのように発見され取得されるかを説明しない。そのための手順は、 各デジタル出版物 形式によって定義される。

内部表現を生成するには、次の 手順を実行する:

  1. processedを、マニフェストの内部表現を含むことになる空の mapとする。

  2. manifestを、textを与えてJSONをInfra 値へ解析する結果とする。manifestがmapでない場合、致命的 エラーとし、失敗を返す。

    説明

    出版物マニフェストは、配列ではなくJSONオブジェクトとして表現されなければならない。 マニフェストを[infra]型に変換した後、結果の構造が mapであることを追加で確認する。

  3. （§ 4.3 マニフェスト コンテキスト）manifest["@context"]がlistに設定されていない場合、または manifest["@context"]内の1番目および2番目のitemsが、 この順序でstring値 "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"]の値はstringまたはlistであり得る。

    説明

    出版物が適合するプロファイルは、処理中に実行されなければならない追加の拡張手順を決定する。 これらの手順は、それぞれの仕様で定義される。

    conformsToはプロファイル識別子に限定されないため、新しい用語 profileが作成される（すなわち、この新しい用語は内部表現内でプロファイルの永続的な識別子を提供する）。

  5. （§ 4.4.1 グローバル宣言）langをこの手順から取得されるグローバル言語とし、 dirをグローバル方向とする。それぞれを最初に空の stringに設定する。

    manifest["@context"]の各 contextについて、最後のitemから最初へ向かって 反復し、もし contextがmapであれば:

    1. langが空のstringであり、 かつcontext["language"]が定義されている場合、langを context["language"]に設定する;
    2. dirが空のstringであり、 かつcontext["direction"]が定義されている場合、dirを context["direction"]に設定する;
    3. langおよびdirのどちらも空のstringでない場合、breakする。

    langが空のstringでも、 整形式 [bcp47]の言語タグでもない場合、検証エラーとし、langを空文字列に 設定する。

    dirが空のstringでも、 値"ltr"または"rtl"のいずれでもない場合、検証 エラーとし、dirを 空文字列に設定する。

    説明

    ここで取得されるグローバルな言語および方向宣言は、宣言を持たないローカライズ可能文字列に対して、 それぞれ言語および基底方向を設定するために使用される。

    後の言語および方向宣言が以前のものを上書きするため、反復子は@contextを逆方向に移動する。

  6. （§ 4.3 マニフェスト コンテキスト）プロファイルがマニフェストコンテキストの追加検証を要求する場合、 それらの手順はここで実行される。

    説明

    この拡張手順により、プロファイルがマニフェストコンテキスト内に存在することを要求する任意の情報 （例: 追加のコンテキストURLまたはパラメーター）を検証できる。 これらの手順はこの時点で実行されなければならない。なぜなら、@context用語は次の手順での データ正規化の一部として削除されるためである。 プロファイルデータを処理するためのより一般的な手順は、後の 手順で提供される。

  7. manifestの各 term → valueについて反復し、 processed[term]を、成功した場合、term、value、 lang、dir、およびbaseを与えて データを正規化するを呼び出した結果に設定する。 失敗が返された場合、termをprocessedに追加しない。

    説明

    データ正規化手順は、受け取ったマニフェストデータを標準化し、オブジェクトや配列が 期待される場所で文字列を使用できるなどの作成上の便宜を取り除く。 結果の処理済みデータはprocessed変数に追加され、後続の手順で操作される。

  8. processedを、processedを与えてデータ 検証を実行した結果に設定する。

    説明

    データ検証チェックは、受け取ったデータが期待される値カテゴリに一致することを保証する。 期待値に関する制限もこの手順で適用され、無効なデータは最終表現から削除される。

  9. プロファイルが実行する必要のある追加処理関数を指定する場合、 それらの手順はこの時点で実行される。

  10. processedを、成功した場合、processedおよび指定されている場合は documentを与えて既定値を 追加するを実行した結果に設定する。そうでない場合、処理を終了し、失敗を返す。

    説明

    この手順は、マニフェストに欠落している情報を、その文書へリンクするHTML文書、 またはその他の情報源から取得できるかどうかを確認する。

  11. processedを返す。

注記

結果として得られる構造の可視化については、§ A. 内部表現データモデルを参照。

7.4.1 データを正規化する

プロパティtermの valueについて、グローバル言語 lang、グローバル方向 dir、基底URL base、および任意のコンテキスト contextを用いてデータを正規化するには、 次の手順を実行する:

  1. normalizedをvalueの値とする。

    説明

    データ正規化手順は、この手順で定義されるnormalized変数に保持されている 入力値のコピーに対して実行される。この変数は、正規化処理が成功した末尾で返される。

  2. （§ 4.3 マニフェスト コンテキスト）termが@contextである場合、失敗を返す。

    説明

    @contextはマニフェストの初期処理のための情報を提供するが、 内部データ表現には保持されない。失敗を返すことは、その用語を削除する合図となる。

  3. （§ 4.2.7 配列） contextに応じて、termが配列を期待し、かつvalueがlistでない場合、normalizedを 次のlistに設定する: « value »。

    説明

    さまざまな用語は値を配列にすることを要求するが、便宜上、作成者は1要素配列の代わりに 単一値を使用することが許される。たとえば、

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

    は次を生成する:

    例 52 
    «[
    …
    "name"   → « "Et dukkehjem" »,
    "author" → « "Henrik Ibsen" »,
    …
]»

  4. （§ 4.2.4.2 エンティティ）contextに応じて、termが 配列（エンティティの）を期待する場合、 normalizedの各 entityについて反復する:

    1. entityがstringである場合、 entityを次のmapに設定する: 

      «[
    "type" → « "Person" »,
    "name" → entity
]»

    2. それ以外で、entityがmapでない場合、検証エラーとし、 entityをnormalizedから削除する。

    3. それ以外で、entity["type"]が設定されていない場合、それを次のlistに設定する: « "Person" »。entity["type"]が設定されているが 値PersonまたはOrganizationを含まない場合、 値Personをlistに 追加する。

    説明

    作成者（著者、編集者など）は、明示的にオブジェクトとして定義されることが期待されるが、 便宜上、マニフェストには名前だけを指定すればよい。たとえば:

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

    この規則は、そのような文字列値を既定型Personを持つmapに変換し、 前の例について次を生成する:

    例 54 
    «[
    …
    "author" → « 
        «[
            "type" → « "Person" »
            "name" → "Ralph Ellison"
        ]»
    »,
    …
]»

    単純化のため、nameをローカライズ可能文字列へ変換する処理は 後の手順で説明する。

  5. （§ 4.2.4.1 ローカライズ可能文字列）contextに応じて、 termが配列（ローカライズ可能文字列の）を期待する場合、 normalizedの各 itemについて反復する:

    1. itemがstringである場合、 itemを次のmapに設定する: 

      «[
    "value" → item,
    "language" → lang,
    "direction" → dir
]»

      langまたはdirが設定されていない、または空のstringである場合、それぞれ item["language"]またはitem["direction"]を削除する。

    2. それ以外で、itemがmapでない場合、検証エラーとし、 itemをnormalizedから削除する。

    3. それ以外の場合、item内のmapを 次のように処理する:

      1. item["language"]が設定されていない場合、langが設定されており、 かつ空のstringでないとき、 それをlangの値に設定する。

        それ以外で、item["language"]がnullである場合、 item["language"]を削除する。

      2. item["direction"]が設定されていない場合、dirが設定されており、 かつ空のstringでないとき、 それをdirの値に設定する。

        それ以外で、item["direction"]がnullである場合、 item["direction"]を削除する。

    説明

    自然言語テキスト値はローカライズ可能文字列オブジェクトとして明示的に定義されることが期待されるが、 便宜上、マニフェスト内では単純な文字列にできる。たとえば、グローバル言語宣言を通じて言語情報が提供されていない場合:

    例 55 
    {
    "@context" : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
    "name"     : ["La Comédie humaine"],
    …
}

    は次を生成する:

    例 56 
    «[
    "name"     → «
        «[
            "value" → "La Comédie humaine"
        ]»
    »,
    …
]»

    一方、明示的な言語がマニフェストで提供されている場合、その言語が ローカライズ可能文字列オブジェクトに追加される。たとえば、

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

    は次を生成する:

    例 58 
    {
    "name"     → «
        «[
            "value"    → "La Comédie humaine"
            "language" → "fr"
        ]»
    »,
    …
}

    ローカル設定またはローカルのnull値は、グローバル値が有効になることを防ぐ。

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

    は次を生成する:

    例 60 
    {
    "name"     → «
        «[
            "value"    → "La Comédie humaine"
            "language" → "fr"
        ]»
    »,
    "publisher"    → «
        «[
            "type" → « "Organization" »,
            "name" → «
                «[
                    "value" → "Hachette",
                ]»
        ]»
    »,
    …
}

  6. （§ 4.2.4.3 リンクされたリソース）contextに応じて、termが 配列（LinkedResourcesの）を期待する場合、 normalizedの各 resourceについて反復する:

    1. resourceがstringである場合、resourceを次のmapに変換する:

      «[
    "type" → « "LinkedResource" »,
    "url" → resource
]»

    2. それ以外で、resourceがmapでない場合、検証エラーとし、 resourceをnormalizedから削除する。

    3. それ以外で、resource["type"]が設定されていない場合、それを次のlistに設定する: « "LinkedResource" »。resource["type"] が設定されているが値LinkedResourceを含まない場合、その値を listに追加する。

    説明

    リソースリンクは、LinkedResource型のオブジェクトとして明示的に設計されることが期待されるが、 便宜上、マニフェストでは絶対URLまたは相対URLだけを指定すればよい。たとえば、

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

    この手順は文字列値をオブジェクトに変換し、前の例について次を生成する:

    例 62 
    «[
    …
    "resources" → «
        «[
            "type" → « "LinkedResource" »,
            "url"  → "css/book.css"
        ]»,
        …
    »,
    …
]»

    単純化のため、相対パスを絶対パスに変換する処理は後の手順で説明する。

  7. （§ 4.2.5 URL）contextに応じて、 termがURLまたはURLの 配列を期待する場合:

    1. normalizedがstringである場合、 normalizedを、成功した場合、normalizedを与えて 絶対URLに変換するを実行した結果に設定する。 失敗が返された場合、失敗を返す。

    2. それ以外で、normalizedがlistである場合、 normalizedの各 itemについて反復し、成功した場合、 itemを、normalizedを与えて絶対URLに 変換するを実行した結果に設定する。失敗が返された場合、 itemをnormalizedから削除する。

    3. それ以外の場合、検証 エラーとし、失敗を返す。

    説明

    マニフェスト内の相対URLは、 絶対URLを取得するためにbase値に対して解決される。 たとえば:

    "url": "chapter01.html"

    https://example.org/publications/wuthering-heightsでホストされる出版物の場合、 次を生成する: 

    "url" → "https://example.org/publications/wuthering-heights/chater01.html"

  8. （§ 8. モジュール式 拡張、拡張点）プロファイルがプロファイル固有用語の処理 手順を定義する場合、それらの手順はこの時点で実行される。

  9. すべてのプロパティが正規化されることを保証するために、normalizedを次のように再帰的に確認する:

    1. normalizedがlistである場合、 normalizedのうちmapである各 itemについて反復する:

      1. item["type"]が設定されており、かつ認識される 型を含む場合、itemの各 key → keyValueについて反復し、 keyを、成功した場合、key、keyValue、 lang、dir、baseを与え、 item["type"]をコンテキストとして使用してデータを正規化するを実行した結果に設定する。 失敗が返された場合、keyをitemから削除する。

      2. それ以外の場合、何もしない。

    2. それ以外で、normalizedがmapである場合:

      1. normalized["type"]が設定されており、かつ認識される 型を含む場合、normalizedの各 key → keyValueについて反復し、 keyを、成功した場合、key、keyValue、 lang、dir、baseを与え、 normalized["type"]をコンテキストとして使用してデータを正規化するを実行した結果に設定する。 失敗が返された場合、keyをnormalizedから削除する。

      2. それ以外の場合、何もしない。

    3. それ以外の場合、何もしない。

    説明

    マニフェスト内のすべてのプロパティが処理されることを保証するため、この手順は normalizedを再帰的に確認し、処理すべき追加のmap項目があるか調べる。 normalizedがlistである場合、各itemを調べ、それが処理可能な mapであるかを判断する。

    失敗が返された場合、そのitemはmapから削除される。

  10. normalizedを返す。

7.4.1.1 絶対 URLに変換する

基底URL baseを用いて、urlを 絶対URLに変換するには、次の手順を実行する:

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

    説明

    この手順は、urlおよびbaseの両方が、使用を試みる前に 空でない文字列であることを確認する。

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

    説明

    この手順は、処理対象のurlに対してURLパーサー関数を呼び出す。urlが 絶対URLでない場合、パーサーは基底URLを使用してそれを絶対URLに変換する。

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

  3. urlを返す。

7.4.2 データ 検証

map dataに対してデータ検証を実行するには、 次の手順を実行する:

  1. dataの各 term → valueについて反復し、 termを、成功した場合、termおよびvalueを与えて グローバルデータチェックを実行した結果に設定する。 失敗が返された場合、data[term]を削除する。

    説明

    この手順は、各項目を、その値および値内の任意のプロパティに対して再帰的に実行する必要のある グローバル検証チェック群に渡す。

    プロパティが無効で削除する必要がある場合、失敗が返される。

  2. プロファイルがデータ検証チェックを指定する場合、 それらの手順はこの時点で実行される。

    説明

    プロファイル検証手順は既定の手順より優先される。これにより、たとえばプロファイルが 適用すべき異なる既定値を持つ場合、それらの値が適用される。

  3. （§ 4.5 出版物タイプ）data["type"]が設定されていない、または空のlistである場合、検証エラーとし、 « "CreativeWork" »に設定する。

  4. （§ 4.7.1.2 アクセシビリティ）data["accessModeSufficient"]が設定されている場合、 data["accessModeSufficient"]の各 itemについて反復し、item["type"] が設定されていない、または"ItemList"を含まない場合、 itemをdata["accessModeSufficient"]から削除する。

  5. （§ 4.7.1.4 正準識別子）data["id"]が設定されていない、または空の stringである場合、検証エラー。

  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]でない場合、検証エラーとし、 itemをdata["inLanguage"]から削除する。

  10. （§ 4.7.1.10 読書進行方向）data["readingProgression"]が設定されていない場合、 "ltr"に設定する。 それ以外で、それが要求される方向値のいずれでもない場合、 検証エラーとし、 "ltr"に設定する。

  11. （§ 5. 出版物リソース）出版物の境界内の一意なURLを、次のように取得および検証する:

    1. readingOrderが設定されている場合、readingOrderURLsを、 readingOrderを与えて一意なURLを取得するを実行した結果とする。 それ以外の場合、readingOrderURLsを空のordered setとする。

    2. resourcesが設定されている場合、resourcesURLsを、 resourcesを与えて一意なURLを取得するを実行した結果とする。 それ以外の場合、resourcesURLsを空のordered setとする。

    3. data['uniqueResources']を、 readingOrderURLsとresourceURLsの和集合に設定する。

    説明

    この手順は、読書順序およびリソース一覧内の一意なURLの 一覧を取得する。その後、data['uniqueResources']をこれら2つの集合の和集合に設定し、 これは出版物の境界内の一意なリソースの完全な一覧を表す。

    この手順は、readingOrderまたはresourcesのいずれかに重複する リソース宣言が含まれる場合にも警告する。検証エラーは、各一覧から一意なURLを 取得する一部として発行される。

  12. （§ 4.8.1 構造的リソース）構造的関係の使用を次のように検証する:

    1. resourcesを、定義されている場合はdata["readingOrder"]の値に、 それ以外の場合は空のlistに設定する。 定義されている場合、resourcesをdata["resources"]で拡張する。

    2. resources内の複数のitemが、 大文字小文字を区別しない値"contents"を含むrel entryを持つ場合、 検証エラー。

    3. resources内の複数のitemが、 大文字小文字を区別しない値"pagelist"を含むrel entryを持つ場合、 検証エラー。

    4. resources内の複数のitemが、 大文字小文字を区別しない値"cover"を含むrel entryを持つ場合、 検証エラー。

      表紙に、画像メディア型（image/*）を指定する encodingFormat entryがあり、 かつname entryがない場合、検証エラー。

    説明

    これは、読書順序およびリソース一覧で指定されたリソースを確認し、目次、ページリスト、 表紙のインスタンスがそれぞれ1つだけ指定されていることを検証する。

    表紙については、アクセシビリティ目的で、画像ベース形式にnameが設定されていることも確認する。

  13. dataの各 term → valueについて反復し、 変数termおよびvalueを与えて 空の配列を削除するを実行した結果が失敗を返す場合、 data["term"]を削除する。

    説明

    マニフェストの処理では、さまざまな段階で無効な値を削除するため、最終データ構造には もはや値を含まないlistが残ることがある。この手順はデータを再度反復し、そのような空のlistを削除する。

  14. dataを返す。

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

プロパティtermのvalueについて、任意のコンテキスト contextを用いてグローバルデータチェックを 処理するには、次の手順を実行する:

  1. （§ 4.2 値カテゴリ）termに既知の値カテゴリがある場合、valueを、 成功した場合、変数term、valueおよびcontextを与えて 値カテゴリを 検証するを呼び出した結果に設定する。失敗が返された場合、失敗を返す。

    それ以外の場合、valueを返す。

    説明

    この手順は、用語の値がその用語に要求される期待カテゴリと一致することを検証する。 たとえば、abridged用語は真偽値を要求するため、その用語に他の値が使用されると失敗となる。

    関数を呼び出して失敗が発生した場合、この手順も失敗を返し、そのプロパティが 最終データ集合から削除されるようにする。

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

  2. 任意の下位プロパティを先に確認するために、valueへ次のように再帰的に降りる:

    1. valueがmapである場合:

      1. value["type"]が認識される型を含む場合、 valueの各 key → keyValueについて反復し、 value[key]を、成功した場合、key、 keyValueを与え、value["type"]を コンテキストとして使用してグローバル データチェックを実行した結果に設定する。失敗が返された場合、 value[key]を削除する。

      2. それ以外の場合、何もしない。

    2. それ以外で、valueがlistである場合、 valueの各 itemについて反復し、 もしitemがmapであれば:

      1. item["type"]が認識される型を含む場合、 itemの各 key → keyValueについて反復し、 item[key]を、成功した場合、key、 keyValueを与え、item["type"]を コンテキストとして使用してグローバル データチェックを実行した結果に設定する。失敗が返された場合、 item[key]を削除する。

      2. それ以外の場合、何もしない。

    3. それ以外の場合、何もしない。

    説明

    マニフェスト内のすべてのプロパティが処理されることを保証するため、この手順は 各項目を再帰的に確認し、処理すべき追加のmap項目があるか調べる。 値がlistである場合、各itemを調べ、それが処理可能なmapであるかを判断する。

    この配置により、すべての下位プロパティが先に確認されるため、後の手順における 上位レベルのチェックは、無効な値が削除された後にテストされる。

  3. （§ 4.4.1 グローバル宣言および§ 4.4.2 項目固有の 宣言）termが配列（LocalizableStringsの）を期待する場合、 valueの各 itemについて反復する:

    • item["value"]が設定されていない場合、 itemをvalueから削除する。

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

    • item["direction"]が設定されており、その値が "ltr"または"rtl"のいずれでもない場合、 検証エラーとし、 item["direction"]を削除する。

    説明

    この手順は、ローカライズ可能文字列が値を持つこと、言語宣言が整形式であること、 方向宣言が値"ltr"または"rtl"のいずれかであることを確認する。

  4. （§ 4.2.4.2 エンティティ）termが配列（エンティティの）を 期待する場合、valueの各 itemについて反復し、 item["name"]が設定されているか確認する:

    • 設定されていない場合、検証 エラーとし、itemをvalueから削除する。

    • 設定されている場合、item["name"]の各 nameについて反復し、 name["value"]が設定されていない、または空文字列である場合、 nameをitem["name"]から削除する。
    説明

    この手順は、すべてのエンティティが名前を持つことを保証する。名前を持たないエンティティは削除される。

  5. （§ 4.2.4.3 リンクされたリソース）termが配列（LinkedResourcesの）を期待する場合、 valueの各 resourceについて反復する:

    説明

    この手順は、LinkedResourceの用語に対して次の2つのチェックを実行する:

    1. URLが指定されていない、または無効である場合、LinkedResourceは 削除される。
    2. リソースの継続時間が指定されている、または有効なISO 8601継続時間値でない場合、 durationプロパティは削除される。

  6. valueを返す。

7.4.2.2 値カテゴリを検証する

プロパティtermのvalueについて、コンテキスト contextを用いて値カテゴリを検証するには、 次の手順を実行する:

  1. contextに応じて、termが配列を期待する場合:

    1. valueがlistでない場合、検証 エラーとし、失敗を返す。

    2. それ以外の場合、valueの各 itemについて反復する:

      1. itemが配列の期待される値カテゴリに一致しない場合、 検証エラーとし、 itemをvalueから削除する。その後continueする。

      2. itemがmapである場合、 itemの各 key → keyValueについて反復し、 keyが期待される値カテゴリを持つ場合、keyを、 key、keyValueを与え、 item["type"]をコンテキストとして使用して値 カテゴリを検証するを実行した結果に設定する。itemを処理した結果が空のmapである場合、検証エラーとし、 itemをvalueから削除する。

      valueを処理した結果が空の配列である場合、検証エラーとし、失敗を返す。

  2. それ以外で、contextに応じて、termがmapを期待する場合:

    1. valueがmapでない場合、検証エラーとし、失敗を返す。

    2. それ以外の場合、valueの各 key → keyValueについて反復し、 keyが期待される値カテゴリを持つ場合、keyを、 key、keyValueを与え、value["type"]をコンテキストとして使用して 値 カテゴリを検証するを実行した結果に設定する。valueを処理した結果が空のmapである場合、検証エラーとし、失敗を返す。

    注記

    この手順は現在、プロファイルが使用するためだけに存在する。 この仕様で定義されるプロパティはすべて、オブジェクトの配列を受け入れる。

  3. それ以外で、contextに応じて、valueが termの期待される値カテゴリに一致しない場合、検証エラーとし、失敗を返す。

  4. valueを返す。

説明

この関数は、処理中の用語の値が期待される値カテゴリに一致することを確認する。 値がlistまたはmapである場合、この関数は再帰的に呼び出され、 マニフェスト内のすべてのプロパティが確認されることを保証する。

7.4.2.3 一意なURLを取得する

resourcesから一意なURLを取得するには、次の 手順を実行する:

  1. uniqueURLsを空のordered setとする。

  2. resourcesの各resourceについて:

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

    2. uniqueURLsが urlを含む場合、 検証 エラー。そうでない場合、urlをuniqueURLsに追加する。

    3. resource["alternate"]が設定されている場合、 resource["alternate"]の各alternateについて:

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

      2. uniqueURLsが alt_urlを含む場合、 検証エラー。

      3. それ以外の場合、alt_urlをuniqueURLsに追加する。

  3. uniqueURLsを返す。

説明

この関数は、読書順序またはリソース一覧のいずれかから得られるLinkedResourceオブジェクトの一覧を受け取り、 一意なURLの集合を返す。重複が見つかった場合、 警告が発行される。

7.4.2.4 空の配列を削除する

プロパティtermのvalueから 空の配列を削除するには、次の手順を実行する:

  1. valueが空のlistである場合、 失敗を返す。

  2. それ以外で、valueがmapである場合、 valueの各 key → keyValueについて反復し、 keyおよびkeyValueを与えて空の配列を削除するを実行した結果が失敗を返す場合、 value[key]を削除する。

説明

この関数は、処理中の用語の値が空のlistでないことを確認する。最初はlistを持つ用語でも、 処理されるにつれて項目が失われる可能性がある（すなわち、list項目が無効な場合）。

7.4.3 既定値を追加する

map data内の欠落プロパティに対して、任意のHTML Document (DOM) Node [html] documentを用いて 既定値を追加するには、次の手順を実行する:

  1. （§ 4.7.1.11 タイトル） data["name"]が設定されていない場合:

    • titleを空のmapとする。その値を 次のように設定する:

      • documentが設定されている場合、documentの title 要素 [html]が 設定されており、かつ空でないなら、title["value"]を title要素のテキスト内容に設定する。

        利用可能な場合はtitle["language"]を言語 [html]に設定し、 その値が利用可能であり、その値が"ltr"または"rtl"のいずれかである場合は、 title["direction"]を基底 方向 [html]に設定する。

      • それ以外の場合、検証 エラーとし、 title["value"]の値を生成する（詳細は別の注記を参照）。 生成されたタイトルに応じてtitle["language"] およびtitle["direction"]を設定する。

    • data["name"]を次のlistに設定する: « title »。
    説明

    この手順は、マニフェストでnameプロパティが指定されていない場合に、 documentのtitle要素の内容を追加する。たとえば:

    例 63 
    <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>

    は次を生成する:

    例 64 
    «[
    …
    "name" → «
        «[
            "value"    → "The Golden Bough",
            "language" → "en"
        ]»
    »,
    …
]»

  2. （§ 4.7.2.1 既定の読書順序および§ 6.1 リンク付け） data["readingOrder"]が設定されていない場合:

    説明

    デジタル出版物が参照元文書のみで構成される場合、既定の読書順序は省略できる。 それは自動的にその単一リソースで構成される。

  3. プロファイルがユーザーエージェントが生成すべき既定値を指定する場合、 それらの手順はこの時点で実行される。

  4. （§ 6.1 リンク付け）document.URLが 設定されており、かつdata["uniqueResources"]が document.URLを含まない場合、 検証エラー。

    説明

    マニフェストへリンクするページが、コアおよび拡張既定値規則の処理後に出版物の一意なリソースとして 列挙されていない場合、エラーが発生する。それは出版物リソースでなければならないためである。

  5. dataを返す。

8. モジュール式拡張

この仕様で定義されるマニフェスト形式は、新しいプロファイル（例: オーディオブックや学術 出版物）の制作において、出版コミュニティによって実装および拡張されるよう設計されている。 マニフェスト形式が提供する柔軟性により、各コミュニティ固有のニーズに合わせて調整できる一方で、 それらのプロファイルを処理する必要があるユーザーエージェントに共通の基盤も提供する （すなわち、各プロファイル間の差異を最小化し、相互運用性を簡素化する）。

プロファイルがこの仕様と互換であるためには、次の条件を満たさなければMUSTならない:

  1. それは、§ 4. 出版物 マニフェストで定義されるマニフェストの構築要件に従わなければMUSTならない。
  2. それは、一意な適合URLを定義し、適合する出版物がこのURLをconformsTo プロパティに含めることを要求しなければ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標準[infra]に依存する。

LinkedResource resourceについて代替リソースを選択するには、 次の手順を実行する。

成功した場合、このアルゴリズムは代替リソースを返す。それ以外の場合は失敗を返す。

  1. possibleAlternatesを空のlistとする。

  2. resource["alternate"]が設定されていない場合、失敗を返す。

  3. resource["alternate"]の各 alternateについて反復する:

    1. alternate["encodingFormat"]が設定されており、ユーザーエージェントが指定された メディア型をサポートする場合、possibleAlternatesに追加する。

    2. それ以外で、プロファイルが追加の選択基準を定義する場合、 この拡張手順でalternateをそれらに照らして評価する。

    3. それ以外の場合、任意でalternate["url"]を調べ、メディア型に関する手がかりを探す。 リソースがサポートされているように見える場合、alternateを possibleAlternatesに追加する。

  4. possibleAlternatesが空のlistである場合、 失敗を返す。

  5. それ以外で、 possibleAlternatesのsizeが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 リスト要素は、コンテンツへのリンクを定義する一覧を含むとみなされる。 この一覧は、たとえばdiv 要素の内部にネストされていても検出される。これは、アルゴリズムが処理に関係のない要素を 無視するためである。ただし、その内部内容が評価されないため、 この一覧はスキップされる要素の内部に出現できない。

nav要素がこれらの要素のいずれも含まない場合、ユーザーエージェントは デジタル出版物を使用可能な目次を含むものとして登録しない（例: 機械レンダリングされたオプションは利用できない）。

分岐

目次をリンクの木として考える場合、リンク一覧内の各リスト項目（li 要素）は1つの分岐を表す。これらの分岐はそれぞれ、ユーザーに提示されるために名前と任意の 宛先を持つ必要があり、この情報は、リスト項目内で見つかる最初のa 要素から取得される。これはどこに ネストされていても同様である（ただし、スキップされる 要素内のa要素は除外される）。

分岐のリンク先は、指定されている場合、a要素のhref属性から取得される。 リンクが利用できない（例: プレビュー内）または関連しない（例: グループ化見出し）場合、この属性は省略できる。 コンテンツへのリンクを提供する場合、リンクされた文書の関係（rel属性内）および リンク先リソースのメディア型（type属性内）を指定することも可能である。

分岐にラベルを付けるa要素を見つけた後、ユーザーエージェントは、別のリスト要素 （すなわち、サブ分岐）についてマークアップの調査を続ける。リストが見つかった場合、 同様に処理されてそのリンクが抽出され、処理すべきネストされた分岐がなくなるまでこれが続く。

スキップされる要素

目次の解析時に誤解釈を避けるため、小さな要素集合は無視される。 これらは、[html] のセクショニング コンテンツ要素およびセクショニング ルート要素である。これらが無視される理由は、それらが独自のアウトラインを定義できるためである （すなわち、自己完結しており、コンテンツリンクの構造に必ずしも関連しない埋め込みコンテンツを表せる）。

hidden 属性が設定された任意の要素もスキップされる。hidden要素はユーザーが直接アクセスすることを意図していないためである。

これらの要素をnav要素に含めることはできるが、重要なコンテンツをそれらの内部に 埋め込まないよう注意する必要がある（例: コンテンツへのすべてのリンクを含むリスト項目を section要素で囲まない）。

無視される要素

目次の抽出に関係なく、かつスキップされるものではないすべての要素は無視される。 スキップされる要素とは異なり、無視とは、ユーザーエージェントがそれらの内部を検索し続け、 関連するコンテンツを探すことを意味し、使用可能なタグ付けの面でより大きな柔軟性を可能にする。

C.2.1 例

このセクションは非規範的である。

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

このセクションはInfra標準[infra]に依存する。

このセクションは、nav要素から目次を抽出するアルゴリズムを定義する。 これは、DOMツリーのノードをツリー順序 [dom]で歩行するものとして定義され、 歩行中に各ノードが入るときと出るときに訪問される。 ノードが訪問されるたび、それはenterまたはexitイベントを発生させるものと見なせる。 一部の手順では、異なる提示モデルに柔軟性を提供するため、ユーザーエージェントにコンテンツの処理方法の選択が与えられる。

注記

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

注記

ユーザーエージェントは、データの最終形を表現できる任意の言語を使用して、 結果の構造を処理し内部化できる。

このアルゴリズムの目的において、リスト要素は、 [html] ol またはul 要素のいずれかとして定義される。

次のアルゴリズムは、role属性値doc-tocを持つ文書順序の最初の要素を根とする DOMサブツリーの歩行に適用しなければMUSTならない。 これは、その要素が宣言的に 隠されている [html]か、CSSによって表示されないようスタイル付けされているかにかかわらない:

注記

目次要素を含むリソースを特定する規則は、§ 4.8.1.3 目次で定義される。

目次要素が見つからない場合、その出版物には機械レンダリング目的で使用できる目次がない。

  1. 目次を表すmap «[ "name" → "", "entries" → « » ]»をtocとする。

    説明

    この手順は、目次のタイトルと分岐を保存するmapを初期化する。このmapでは:

    1. toc["name"]は目次のタイトルを表す。
    2. toc["entries"]は目次の分岐を表す。

  2. 目次の分岐が作成されるにつれて保持するためのstack branchesを初期化する。

    説明

    stackは、まだ完了していない分岐を保持するために使用される。新しいサブ分岐に遭遇すると、 後で取得できるよう親がstackにpushされる。

  3. current_toc_nodeをnullに設定された変数とする。

    説明

    current_toc_nodeは、現在処理中の目次の分岐を表すmapを保持するために使用される。

  4. 目次の構築元となる要素から開始し、ツリー 順序 [dom]でDOMを歩行し、 歩行が各要素に入るとき、およびそこから出るときに、以下の最初に該当する手順を発生させる。

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

      次の手順を実行する:

      1. branchesが空であり、かつtoc["name"]が空のstringである場合、 toc["name"]を次のいずれかに設定する:

        • 要素の子孫コンテンツ（任意のHTMLタグを保持するため）;
        • 子孫コンテンツから取得されるテキスト文字列（例: 要素のアクセシブル 名前 [accname-1.1]を 計算することによって）。

        toc["name"]の結果値が空のstringである場合（例: 任意の表示用要素を削除し、前後の空白をすべてトリミングした後）、 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"]が空のstringである場合、 toc["name"]をnullに設定する。

      2. current_toc_nodeがnullでない場合:

        1. current_toc_node["entries"]がnullまたは空でない listである場合、 その要素の以後の処理をスキップし、次へ進む。
        2. それ以外の場合、current_toc_nodeをbranchesへ pushし、 その後current_toc_nodeをnullに設定する。

      3. それ以外で、branchesが空である場合:

        1. toc["entries"]がnullまたは空でない listである場合、 その要素の以後の処理をスキップし、次へ進む。
        2. それ以外の場合、何もしない。
      説明

      このアルゴリズムは、単一の分岐内またはnav要素のルートで複数のリストを処理しない。 そのため、リストがすでに遭遇されている場合（entriesプロパティが1つ以上の分岐を含む、 またはnullに設定されている場合）、 このリストはスキップされる。

      リストに遭遇し、目次（toc）がまだ名前を持っていない場合 （すなわち、見出し要素が遭遇されていない場合）、目次には見出しがないとみなされる （すなわち、目次の見出しは最初の項目一覧の後には出現できない）。 nameプロパティの値は、空文字列からnullへ変更される。 以後遭遇される見出しも適用されないためである。

    3. リスト 要素から出るとき:

      1. branchesが空でない場合、branchesから最上位の mapをpopし、 current_toc_nodeをそれに設定する。

      2. それ以外で、toc.entriesが空のlistを含む場合、それを nullに設定する。

      説明

      この手順は、すべての子分岐が処理された後にcurrent_toc_nodeを 親オブジェクトへ戻す。

      stack内に分岐がない場合、toc.entriesに項目が含まれていなければ nullに設定される（ルートレベルで以後のリストを処理しないようにするため）。

    4. リスト 項目要素に入るとき、current_toc_nodeを次のmapに設定する: 

      «[
    "name" → null,
    "url"  → null,
    "type" → null,
    "rel"  → null,
    "entries" → « »
]»
      説明

      各リスト項目は目次内の新しい分岐の可能性を表すため、遭遇するたびに新しい空のオブジェクトが current_toc_node内に作成される。

      このオブジェクトは、子孫のa要素およびリストに遭遇するにつれて情報で埋められる。

    5. リスト 項目要素から出るとき:

      次の手順を実行する:

      1. current_toc_node["entries"]が空のlistを含む場合、それを nullに設定する。

      2. current_toc_node["name"]がnullまたは空文字列である場合:

        1. current_toc_node["entries"]がnullでない場合、 current_toc_node["name"]をプレースホルダー値またはnullに設定する;
        2. それ以外の場合、current_toc_nodeをnullに設定し、 この処理手順を終了する。

      3. branchesが空でない場合、current_toc_nodeを branchesの先頭にあるmapの entriesプロパティへ追加する。それ以外の場合、 current_toc_nodeをtoc["entries"]へ追加する。

      4. current_toc_nodeをnullに設定する。

      説明

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

      分岐をどこへ統合するかを決定するため、stackが確認される。stackに項目がない場合、 それはルートtocオブジェクトのentriesプロパティに追加される （すなわち、トップレベルの分岐である）。それ以外の場合、stack内で直前にあるオブジェクトの entriesプロパティに追加される。

      最後の手順として、current_toc_nodeは nullへリセットされる。

    6. アンカー 要素に入り、かつcurrent_toc_nodeがnullでないとき:

      次の手順を実行する:

      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"]を結果のトークンのlistに設定する。

        その要素の以後の処理をスキップし、次へ進む。

      説明

      この手順は、分岐のnameおよびurlプロパティの値を取得するために、 アンカータグを処理する。

      現在の分岐の名前がすでに定義されている場合、この要素の処理は終了する （すなわち、単一分岐に対して複数のリンクを処理することを避けるため）。

      ユーザーエージェントがentryのnameをa要素の子孫コンテンツに設定するか、 そこからテキスト文字列を生成するかは、提示において子孫タグ付けを再利用するかどうかに依存する （例: 画像、MathML、ruby、およびテキストへ容易に変換できないその他のコンテンツを保持するため）。

      href属性が指定されていることに加え、この仕様の要件を満たすためには、 それがデジタル出版物に属するリソースへ解決される必要がある。そうでない場合、 分岐は保持されるが、そのentryはリンク可能ではない。

      リンク先に関する追加情報 — リソースの型およびその関係 — も保持される。

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

      その要素の以後の処理をスキップし、次へ進む。

      説明

      セクショニング要素およびセクショニングルート要素は独自のアウトラインを定義できるため、 それらに降りていくことは目次の生成に問題を生じさせる（すなわち、直接関連しないコンテンツを含む可能性がある）。 その結果、遭遇したときには子コンテンツが処理されないように、それらはスキップされる。

    8. それ以外の場合: 何もしない。

      説明

      その他すべての要素について、この手順はその子孫要素が処理され続けることを可能にする。

  5. DOM歩行を完了した後、toc["entries"]が空でないlistを含む場合、tocを返す。 それ以外の場合、nullを返す。

    説明

    ルートtocオブジェクト内のentries配列に分岐が含まれない場合 （nav要素内にリストが見つからなかったため、またはリストに適合するリスト項目が含まれなかったため）、 このアルゴリズムは使用可能な目次を生成しなかったことになる。

D. 変更履歴

最初の公開 作業草案以降の実質的な変更:

対処されたissueの完全な一覧については、GitHub trackerを参照。

E. IANAに関する考慮事項

このセクションは非規範的である。

F. マニフェスト例

このセクションは非規範的である。

F.1 基本マニフェスト

次は、例示の書籍プロファイルの基本的なメタデータ集合を持つマニフェストである。

このマニフェストの内部表現のJSON 符号化も利用できる。

例 73 
{
    "@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 符号化も利用でき、同じ文書についてのより 詳細なバージョンも利用できる。

例 74 
<!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プロファイル [audiobooks]に適合するマニフェストを示す。

このマニフェストの内部表現のJSON 符号化も利用できる。

例 75 
{
  "@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 Working Groupのメンバーに感謝したい:

Working Groupはまた、この仕様の道筋を切り開くために多大な尽力をしたDigital Publishing Interest Groupのメンバーにも感謝したい。

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; Frédérick 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 Jägenstedt; 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