Publication Manifest 日本語訳

要約

この仕様は、デジタル出版物に関する情報を表現するための一般的なマニフェスト形式を定義する。[schema.org] メタデータを使用して、表現する必要のある情報の差異に対応しながら出版物フォーマット間の相互運用性を実現するために、[JSON-LD] でシリアル化された出版物に関するさまざまな構造プロパティを追加する。

2. 出版物のマニフェスト

2.1 導入

2.1.1 マニフェストフォーマット

このセクションは規定ではない。

デジタル出版物は、JSON-LD [json-ld] の特定の形（リンクトデータの JSON [ecma-404] のバリアント）を使用して表現されたプロパティのセットを提供するところのマニフェストで記述される。

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

表現的プロパティ: 表現的プロパティは、例えば、タイトル、著者、言語など、デジタル出版物の外見を説明する。
リソース分類プロパティ: リソース分類プロパティは、例えば、リソースのリストやデフォルトの読み上げ順序など、リソースの共通セットを記述又は識別する。これらのプロパティは、例えば、HTML ドキュメント、画像、スクリプト、及びメタデータレコードなど、複数のリソースを参照する。

マニフェストは、リンクリレーションを使用してデジタル出版物の主要なリソースもまた識別する。これらの関係は、（例えば、目次とリソースリストで見つかるリンクなど）LinkedResource オブジェクトの rel プロパティに適用される。

これらの関係が識別するリソースのタイプは、次のように分類される。

有益なリソース: 有益なリソースは、例えば、プライバシーポリシー、アクセシビリティレポート、又はプレビューなど、出版物に関する追加の情報を含むリソースである。
構造リソース: 構造リソースは、例えば、カバー画像、目次、ページリストなど、出版物の主要なメタ構造である。

Note

これらの分類は、この仕様以外には関係ない（つまり、プロパティは実質的にマニフェストでグループ化されていない）。

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

この仕様は、[json-ld] の特定の「形状」として出版物マニフェストを定義する。つまり、マニフェストは、JSON-LD 構文によって提示される全ての可能性とは対照的に、この仕様で定義されている構文構造のみを使用して表現するべきである（SHOULD）。

Note

この形状は、非公式に、この仕様で定義されている制約を表す JSON スキーマ [json-schema] を介しても定義されている。このスキーマは、https://github.com/w3c/pub-manifest/blob/master/schema/publication.schema.json で管理されている。

出版物マニフェストは、多数のオーサリングの柔軟性とコンパクトなオーサリング表現もある。例えば、オブジェクトタイプは、欠落しているときは正規化中に自動的に生成されるため、いつも明示的に作成する必要はない（詳細は、§ 2.7.1.4 明示的及び暗黙的なオブジェクトを見よ）。マニフェストデータの正規の表現は、個別に定義される。詳細は、§ 2.3 Web IDL を見よ。

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

2.1.3 Schema.org との関係

マニフェストプロパティ、特に、表現的プロパティとして分類されるプロパティは、主に schema.org とそのホストされた拡張機能 [schema.org] から取得される。結果として、これらのプロパティは、schema.org から構文とセマンティクスを継承し、マニフェストのオーサリングが schema.org のオーサリングと互換性を持つ。

マニフェスト項目が schema.org プロパティに対応するとき、そのプロパティ定義はマッピングを識別し、（例えば、CreativeWork や Book など）括弧内に定義タイプを包含する。

さらに、schema.org は、発行に関連するけれども、この仕様では言及されていない多数のプロパティを包含している。これらのプロパティは、このドキュメントが、マニフェストアイテムの最小限のセットのみを定義しているので、マニフェストで使用してもよい（MAY）。

追加の schema.org プロパティを使用するとき、マニフェストで指定された出版物のタイプに対して有効であることを確保されたい。語彙で使用される継承モデルの結果として、プロパティはしばしば多くの schema.org タイプを利用可能だが、全てのプロパティが全てのタイプに利用可能ではない。どのタイプがどのプロパティを受け入れるかの詳細は、[schema.org] を参照されたい。

追加の schema.org プロパティの使用に関する詳細は、§ 2.6 出版物タイプ及び § 2.7.4.2 追加のマニフェストプロパティも利用可能である。

2.2 要件

次のプロパティは、マニフェストに設定しなければならない（MUST）。

context
type

他の全てのプロパティとリソースの関係の優先順位はオプションだが（OPTIONAL）、マニフェストフォーマットの実装によって変更されてもよい（MAY）。

Note

一部のプロパティは、明示的にオーサリングされていないときは代替情報からコンパイルされるため、暗黙的に必要である。詳細は、§ 2.3 Web IDL を見よ。

2.3 Web IDL

デジタル出版物のマニフェストは [json-ld] として作成されるが、ユーザーエージェントはプロパティを利用するために、任意の言語にすることができるところの、正規の表現にあるこの情報を処理する。

開発者向けのマニフェストフォーマットを単純にするため、この仕様は、ウェブインタフェース記述言語（Web IDL） [webidl-1] — PublicationManifest 辞書を使用して、マニフェストで採用されたデータ構造の抽象表現を定義する。

この定義は、マニフェストの各要素に期待される名前、データ型、及び可能な制限を表している。しかしながら、一般的な Web IDL 定義とは異なり、ユーザーエージェントは、API としてマニフェストの情報を公開することは想定されていない。Web IDL 言語は、データモデルの抽象化を提供するためだけに選択される。

PublicationManifest 辞書の必須要素は、ユーザーエージェントが、（例えば、タイトルや読み上げ順序からなど）一部のプロパティの明示的な宣言がない場合、他のソースからの情報をコンパイルすることが予想されるため、マニフェストの必須要素と完全には一致しない。

Note

デジタル出版物を作成するために、Web IDL の定義を理解する必要はない。オーサリング要件は、次のセクションで定義される。

2.3.1 `PublicationManifest` 辞書

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

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

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

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

マニフェストは、指定された順序で、次の二つのコンポーネントを持つ JSON-LD コンテキスト [json-ld] を設定しなければならない（MUST）。

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

例 1：コンテキストの宣言。

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

出版物コンテキストのドキュメントは、（例えば、creator プロパティが順序を維持するための要件など）Schema.org で定義されたプロパティに機能を追加する。

Schema.org はしばしば、http URI スキームを使用して参照されるが、デフォルトとして安全な https スキームを使用するように語彙は移行されてる。マニフェストで Schema.org を参照するときに https を使用することは、この仕様において必須である（REQUIRED）。

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

（例えばタイトル、クリエイターなど）マニフェスト内の各自然言語プロパティ値は、デフォルトの自然言語があり、これは、（例えば、英語、フランス語、中国語など）表現される言語である。記述される自然なベース方向は、左から右かそれとも右から左の表示方向もまたある。

デジタル出版物のマニフェストは、ユーザーエージェントがメタデータの解釈及び提示するのを支援するために、これらの概念の両方を全体に（言語については個々の項目に）設定する機能を提供する。

2.5.1 グローバル宣言

自然言語マニフェストプロパティのためのデフォルト言語は、language キーワード [json-ld] を使用してコンテキストにグローバルの言語宣言を包含することによって設定される。これは、省略をするローカライズ可能な文字列に言語を提供するためだけでなく、マニフェストの処理中にローカライズ可能な文字列に単純な文字列値を展開するためにも使用する。

例 2 ：マニフェストのデフォルト言語としてフランス語を宣言する

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

language の値は、有効な言語タグ [bcp47] でなければならない（MUST）。

Editor's note

有効又は整形式の言語タグを要求する方が良いかどうかを判断するための未解決の問題がある。

グローバルの言語宣言は、存在するとき、出版物コンテキストに従わなければならない（MUST）。

デフォルトの言語とは異なり、デフォルトのテキスト方向は、現在、JSON-LD にこの機能が包含されていないため、コンテキストで指定できない。暫定措置として、この仕様は、グローバルのテキスト方向を定義するための direction プロパティを定義する。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`direction`	テキストのマニフェスト値のデフォルトの基本方向。	`ltr`、`rtl`、又は `auto` のいずれか。	リテラル	(None)

ベース言語の方向は、次の値のいずれかでなければならない（MUST）。

ltr：テキスト値が、明示的に方向に関して左から右のテキストに設定されていることを示す。
rtl：テキスト値が、明示的に方向に関して右から左のテキストに設定されていることを示す。
auto：Unicode 双方向アルゴリズム [bidi] の規則に従って、テキスト値が強い指向性を持つ最初の文字の方向に、明示的な指向性を設定されることを示す。

例 3 ：右から左に全体のテキスト方向を設定する

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

デフォルト値は、グローバルの言語及びベース方向の宣言に指定されていない。

2.5.2 項目固有の宣言

ローカライズ可能な文字列を使用して、マニフェスト内にある任意の自然言語値に対してローカルに言語を設定することができる。

例 4：ローカライズ可能な文字列を使用して著者名をフランス語に設定する

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"author" : {
"type"  : "Person",
"name" : {
"value"    : "Marcel Proust",
"language" : "fr"
        }
    }
}

language キーワード [json-ld] の値は、整形式の言語タグ [bcp47] でなければならない（MUST）。

そのような場合、ローカル宣言は、グローバル宣言より優先される。

Note

特定の値に方向を明示的に設定することはできない。詳細は、§ D.1 JSON-LD の項目固有の指向性を参照されたい。

2.6 出版物タイプ

デジタル出版物のマニフェストは、type キーワード [json-ld] を使用して出版物タイプを宣言する。タイプは任意の [schema.org] タイプにマッピングされてもよいが（MAY）、タイプが指定されていないとき、CreativeWork がデフォルトと見なされる。

例 5：CreativeWork に出版物タイプを設定する。

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

例えば、Article、Book、TechArticle、及び Course など、CreativeWork のより具体的なサブタイプを、CreativeWork の代わり又は追加して使用できる。

例 6：Book に出版物タイプを設定する。

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

各 schema.org タイプは、その使用に有効なプロパティのセットを定義する。マニフェストが、schema.org 対応プロセッサによって検証および処理できることを保証するために、マニフェストは、選択されたタイプに関連付けられたプロパティのみを含めるべきである（SHOULD）。

プロパティに複数のタイプが必要な場合、マニフェストに複数のタイプ宣言を包含してもよい（MAY）。

例 7：Book と VisualArtwork の両方のプロパティを組み合わせた出版物。

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

ユーザーエージェントは、宣言された schema.org タイプに対して有効でないマニフェストの処理を失敗するべきではない（SHOULD NOT）。

Note

完全な CreativeWork サブタイプのリストは、schema.org サイトを参照されたい。

2.7 プロパティ

2.7.1 値のカテゴリ

このセクションは、出版物マニフェストのプロパティに使用できる値のカテゴリを説明する。

2.7.1.1 リテラル

マニフェストプロパティがリテラルのテキスト文字列を値として想定しているとき、（例えば、コード値や日付など、言語に依存しないもの）、その値は、[json] 文字列として表現されなければならない（MUST）。

例えば、オブジェクトに変換されるかもしれない他の値とは異なり、リテラル値はマニフェストの処理中に変更されない。

2.7.1.2 数値

マニフェストプロパティが値として数値を想定しているとき、その値は、[json] 数値として表現されなければならない（MUST）。

2.7.1.3 ブール

マニフェストプロパティが値としてブールを想定しているとき、その値は、[ecmascript] ブール値（true 又は false）として表現されなければならない（MUST）。

2.7.1.4 明示的及び暗黙的なオブジェクト

様々なマニフェストプロパティは、[json] オブジェクトとして表現されることが想定される。通常、オブジェクトの使用が推奨されるが、次のセクションでは、コンテキストに応じてオブジェクトとして解釈される文字列値を使用することも許容される場合について説明する。オブジェクトへのテキスト値の正確なマッピングは、プロパティまたはオブジェクト定義の一部である。

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

マニフェストプロパティが、その値としてローカライズ可能なテキスト文字列を想定しているとき、これらの値は、次のいずれかで表さなければならない（MUST）。

[json] 文字列値、または、
[json] プロパティのテキストとテキストの言語を識別する language プロパティを含んでいる value プロパティを持つオブジェクト。

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

2.7.1.4.2 エンティティ

マニフェストプロパティがエンティティを想定しているとき（つまり、創作の様々な側面に対して責任を持つ個人又は組織）、その値は、次のいずれかで表現されなければならない（MUST）。

[json] 文字列値、又は、
CreatorInfo オブジェクト。

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

例 8：Person オブジェクトの代わりに文字列を使用する。

次の著者名は文字列として表現される。

{
"author" : "Edgar Allen Poe",
    …
}

しかし、クリエイターのコンテキストは、次と同等である。

{
"author" : {
"type" : "Person",
"name" : "Edgar Allen Poe"
    },
    …
}

（詳細は、§ 2.7.2.5 クリエイターを見よ。）

2.7.1.4.3 リンク

マニフェストプロパティが、ひとつ以上のリソースにリンクするとき、それは次のいずれかで表現しなければならない（MUST）。

[json] リソースの URL をエンコードする文字列として。または、
ターゲットリソースの URL、メディアタイプ、及びその他の特性を表現するために使用できる LinkedResource オブジェクトのインスタンスとして。

文字列値は、url プロパティが文字列値に設定されている暗黙の LinkedResource オブジェクトを表す。

例 9：相対 URL を使用し、文字列（'datatypes.svg'）としてひとつのリンクと、LinkedResource オブジェクトの様々なプロパティを表示する二つのリンクを包含するリソースのリスト

{
    …
"resources" : [
"datatypes.svg",
        {
"type"            : "LinkedResource",
"url"             : "test-utf8.csv",
"encodingFormat"  : "text/csv",
"name"            : "Test Results",
"description"     : "CSV file containing the full data set used."
        },
        {
"type"            : "LinkedResource",
"url"             : "terminology.html",
"encodingFormat"  : "text/html",
"rel"             : "glossary"
        }
    ]
}

2.7.1.5 URL

URL は、デジタル出版物に関連付けられたリソースを識別するために使用される。プロパティが URL 値を想定するとき、それは有効な URL 文字列 [url] でなければならない（MUST）。

マニフェスト URL は、http 及び https スキーマ [url] のみに制限される。ユーザーエージェントは、マニフェスト内の全ての URL を間接参照する必要はないが、URL はリソースを間接参照しなければならない（MUST）。

相対 URL 文字列の場合、これらは、ベース URL [url] を使用する絶対 URL 文字列に解決される。

相対 URL 文字列のベース URL は、次のように決定される。

埋め込まれたマニフェストの場合、それは埋め込みドキュメントのドキュメントベース URL [json-ld] である。
リンクされたマニフェストの場合、それは、マニフェストリソースの URL である。
マニフェストを発見する他の方法を使用するデジタル出版物フォーマットの場合、フォーマットによって定義される。

結果として、埋め込まれたマニフェストの相対 URL 文字列は、ドキュメントがベース URL（つまり、ヘッダーの <base> 要素）を宣言しない限り、マニフェストを参照するドキュメントの URL に対して解決される。

Note

URL は、[rfc3987] に従う Unicode 文字を使用できる。詳細は、HTML5 仕様の注を見よ。

2.7.1.6 識別子

識別子は、永続的及び明確な方法でウェブコンテンツを参照するために使用される。URL、URN、DOI、ISBN、及び PURL は、全て、出版物で頻繁に使用される永続的な識別子の例である。

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

2.7.1.7 配列

マニフェストプロパティが、それぞれのタイプ（例えば、リテラル、オブジェクト、又は URL）のひとつ以上の値を許可するとき、それらの値は、[json] 配列として表現される。しかしながら、プロパティ値が、単一要素のとき、配列構文は省略してもよい（MAY）。

例 10：配列の代わりにテキスト文字列を使用する

通常、デジタル出版物は、多くのリソースが含まれているため、単一のリソースの宣言は次のとおりであり、

{
"resources" : "datatypes.svg",
    …
}

配列と同等である。

{
"resources" : ["datatypes.svg"],
    …
}

2.7.2 表現的プロパティ

2.7.2.1 縮約

縮約のプロパティは、デジタル出版物が元のフォーマットから短くされているかどうかに関する情報を提供する。

Term	Description	Required Value	Value Type	[schema.org] Mapping
`abridged`	本が縮約版かどうかを示す。	`true` かそれとも `false`。	ブール	`abridged` (Book)

2.7.2.2 アクセシビリティ

アクセシビリティプロパティは、さまざまな好みの読書様式を持つユーザーによって消費されるデジタル出版物の適合性に関する情報を提供する。通常、これらのプロパティは、例えば、[wcag21] が提供しているような、確立されたアクセシビリティ基準に対する評価を補完する。

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

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`accessMode`	個人が情報を処理又は知覚するための人間の感覚知覚システムまたは認知機能。	複数のテキスト	リテラルの配列	`accessMode` (CreativeWork)
`accessModeSufficient`	リソースにある全ての知的コンテンツを理解するのに十分な単一または結合されたアクセスモードのリスト。	複数の ItemList	リテラルの配列	`accessModeSufficient` (CreativeWork)
`accessibilityFeature`	例えば、アクセシブルなメディア、代替手段、サポートされているアクセシビリティの強化など、リソースのコンテンツ機能。	複数のテキスト	リテラルの配列	`accessibilityFeature` (CreativeWork)
`accessibilityHazard`	一部のユーザーにとって生理学的に危険であると称されるリソースの特性。	複数のテキスト	リテラルの配列	`accessibilityHazard` (CreativeWork)
`accessibilitySummary`	他のアクセシビリティメタデータと一貫性のある特定のアクセシビリティ機能又は欠陥についての人間が読める要約。	テキスト	ローカライズ可能な文字列	`accessibilitySummary` (CreativeWork)

Note

それらのプロパティで使用する予定の値を包含する、これらのプロパティの詳細な説明は、[webschemas-a11y] が利用できる。

Note

これらのプロパティで表現できる以上の情報が必要な場合、詳細なアクセシビリティレポートへの参照も提供できる。

例 11：テキストと画像を含むドキュメントのアクセシビリティメタデータの例。出版物は、各画像に適した代替テキストと長い説明を提供するため、純粋なテキスト形式で読むこともできる。

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "CreativeWork",
    …
"accessMode"            : ["textual", "visual"],
"accessibilityFeature"  : ["alternativeText", "longDescription"]
"accessModeSufficient"  : [
        {
"type"           : "ItemList",
"itemListElement": ["textual", "visual"]
        },
        {
"type"           : "ItemList",
"itemListElement": ["textual"]
        }
    ],
    …
}

2.7.2.3 アドレス

アドレスは、デジタル出版物のソースの場所を識別する URL である。それは、url プロパティを使用して表現される。

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

デジタル出版物は、ひとつ以上のアドレスを持ってもよいが（MAY）、全てのアドレスは、同じドキュメントで解決されなければならない（MUST）。

Note

出版物のアドレスは、識別子のリンク関係 [link-relation] の値としても使用できる。

例 12 ：出版物のアドレスの設定

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"url"      : "https://publisher.example.org/frankenstein",
    …
}

2.7.2.4 正規の識別子

デジタル出版物の正規の識別子プロパティは、デジタル出版物の一意の識別子を提供する。それは、id プロパティを使用して表現される。

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

Note

正規識別子の一意性を保証することは、この仕様のスコープ外である。実際に達成可能な一意性は、使用される識別子スキームの規則や識別子の割り当ての制御の程度などの要因に依存する。

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

正規の識別子の仕様は、identifier プロパティ [schema.org] 及び/又はそのサブタイプを使用して、追加の識別子のタイプを包含することで補完してもよい（MAY）。

例 13：URL として正規の識別子とアドレスを設定する例

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "TechArticle",
    …
"id"       : "http://www.w3.org/TR/tabular-data-model/",
"url"      : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
    …
}

例 14：正規識別子の URN の例

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"id"       : "urn:isbn:9780123456789",
"url"      : "https://publisher.example.org/wuthering-heights",
    …
}

2.7.2.5 クリエイター

クリエイターは、デジタル出版物の作成を担当する個人又は組織である。

次のプロパティは、クリエイターとして分類される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`artist`	鉛筆又はデジタル線画以外の媒体における出版物の主要なアーティスト。	複数の `Person`	エンティティの配列	`artist` (VisualArtwork)
`author`	出版物の著者。	複数の `Person` 及び/又は `Organization`	エンティティの配列	`author` (CreativeWork)
`colorist`	インクの描画に色を追加する人。	複数の `Person`	エンティティの配列	`colorist` (VisualArtwork)
`contributor`	役割がこの表の他の役割のいずれにも適合しない貢献者。	複数の `Person` 及び/又は `Organization`	エンティティの配列	`contributor` (CreativeWork)
`creator`	出版物の作成者。	複数の `Person` 及び/又は `Organization`	エンティティの配列	`creator` (CreativeWork)
`editor`	出版物の編集者。	複数の `Person`	エンティティの配列	`editor` (CreativeWork)
`illustrator`	出版物のイラストレーター。	複数の `Person`	エンティティの配列	`illustrator` (Book)
`inker`	インクで鉛筆画をトレースする人。	複数の `Person`	エンティティの配列	`inker` (VisualArtwork)
`letterer`	アートワークに吹き出しや効果音などのレタリングを追加する人。	複数の `Person`	エンティティの配列	`letterer` (VisualArtwork)
`penciler`	主要な物語のアートワークを描く人。	複数の `Person`	エンティティの配列	`penciler` (VisualArtwork)
`publisher`	出版物の出版社。	複数の `Person` 及び/又は `Organization`	エンティティの配列	`publisher` (CreativeWork)
`readBy`	（オーディオブック用の）出版物を読む（演じる）人。	複数の `Person`	エンティティの配列	`readBy` (Audiobook)
`translator`	出版物の翻訳者。	複数の `Person` 及び/又は `Organization`	エンティティの配列	`translator` (CreativeWork)

クリエイターは、次のいずれかで表現しなければならない（MUST）。

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

単一の文字列値は、name プロパティがその文字列値に設定されている [schema.org] Person の省略形である。（§ 2.7.1.4.2 エンティティもまた見よ。）

[schema.org] Person 又は Organization タイプからクリエイター情報の各セットをコンパイルするとき、ユーザーエージェントは、利用可能なとき、CreatorInfo type で定義されているプロパティを保持しなければならない（MUST）。

マニフェストは、各タイプのクリエイターが複数含まれてもよい（MAY）。

例 15：本の著者

{
"type"     : "Book",
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
    …
"url"      : "https://publisher.example.org/alice-in-wonderland",
"author"   : {
"type"  : "Person",
"name"  : "Lewis Carroll"
    }
}

例 16 ：単純な文字列として一部の人が表現されている、編集者、著者、出版社の個別のリスト。

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "TechArticle",
    …
"id"         : "http://www.w3.org/TR/tabular-data-model/",
"url"        : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
"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/"
    }
    …
}

2.7.2.6 継続時間

グローバルの継続時間は、（例えば、オーディオブック又は一連のビデオクリップで構成される本など）時間ベースのデジタル出版物の全体の長さを示す。それは、duration プロパティを使用して表される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`duration`	時間ベースの出版物の全体的な継続時間。	[iso8601] で定義された継続時間値。	リテラル	`duration` (Property)

例 17：マニフェストで提供されるグローバルの継続時間（秒単位）

{
"@context"       : ["https://schema.org", "https://www.w3.org/ns/pub-context"],
"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",
    …
}

Note

関連する Wikiepedia ページには、ISO 継続時間構文の簡潔な説明がある。

2.7.2.7 最終変更日

最終変更日は、デジタル出版物が最後に更新されたときの日付である（つまり、マニフェストを包含する出版物のリソースに最後に変更が加えられたとき）。dateModified プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`dateModified`	出版物の最終変更日。	それぞれ、ISO 8601 日付又は日付時刻形式 [iso8601] の両方で表される `Date` や `DateTime` の値 [schema.org]。	リテラル	`dateModified` (CreativeWork)

最終変更日は、（例えば、デジタル出版物で、サードパーティのコンテンツの参照ができる場合など）出版物に対する全ての変更を必ずしも反映するわけではない。ユーザーエージェントは、変更があるか、更新が必要かどうかを判断するために、個々のリソースの最終変更日をチェックするべきである（SHOULD）。

例 18：出版物の最終変更日

{
"@context"     : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"         : "TechArticle",
    …
"id"           : "http://www.w3.org/TR/tabular-data-model/",
"url"          : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
"dateModified" : "2015-12-17",
    …
}

2.7.2.8 発行日

発行日は、デジタル出版物が最初に発行された日付である。出版物のライフサイクルにおける静的なイベントを表し、後に続く版の識別及び比較ができる。datePublished プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`datePublished`	出版物の作成日。	それぞれ、ISO 8601 日付又は日付時刻形式 [iso8601] の両方で表される `Date` や `DateTime` の値。	リテラル	`datePublished` (CreativeWork)

出版の正確な時期は、意図的な解釈の余地がある。それは、出版物が最初に利用可能になったとき、又は出版物が最終版と見なされる出版前の時点である可能性がある。

例 19 ：出版物の発行日と変更日

{
"@context"      : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"          : "TechArticle",
    …
"id"            : "http://www.w3.org/TR/tabular-data-model/",
"url"           : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
"datePublished" : "2015-12-17",
"dateModified"  : "2016-01-30",
    …
}

2.7.2.9 出版物の言語

デジタル出版物は、少なくともひとつの自然言語を持ち、つまり、（例えば、英語、フランス語、中国語など）コンテンツが表現される言語である。マニフェストは、このコンセプトを設定するために次のプロパティを包含し、例えば、（辞書又はテキスト読み上げエンジンをプリロードするなど）ユーザーエージェントの動作に影響を与える可能性がある。

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

自然言語は整形式の言語タグ [bcp47] でなければならない（MUST）。

ユーザーエージェントが、出版物の言語を必要とし、マニフェストで使用できない、又は取得された値が整形式 [bcp47] でない場合、ユーザーエージェントは、正規の表現を生成するときに出版物の言語を決定してもよい（MAY）。この仕様は、そのような言語タグの作成方法を強制しない。ユーザーエージェントは次のことを行う。

空ではないマニフェストの言語の宣言を使用し、
デフォルトの読み上げ順序で、リソースにある最初の空でない言語宣言を使用し、
独自のアルゴリズムを使用して言語を計算する。

ユーザーエージェントが、プライマリーの言語を要求し、複数の言語が指定されている場合、inLanguage 配列の最初のエントリーは、プライマリーとして認識されなければならない（MUST）。

Note

それを構成する個々のリソースの言語から、出版物の言語を区別することは重要である。例えば、そのようなリソースが HTML にある場合、言語はこれらのリソースに設定する必要がある。出版物の言語は継承されない。

2.7.2.10 組み方向

組み方向は、デジタル出版物内のあるリソースから次のリソースへの読書方向を確立する。メニュー位置、タッチジェスチャー、方向の切り替え、前後ページのタップゾーンなど、出版物レベルのインタラクションを調整するために使用される。組方向は、readingDirection プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`readingProgression`	あるリソースから他のリソースへの組み方向。	`ltr` 又は `rtl` のひとつ。	リテラル	(None)

このプロパティの値は、次のいずれかでなければならない（MUST）。

ltr：左から右
rtl：右から左

デフォルト値は、ltr である。readingProgression が設定されていない場合、ユーザーエージェントは、正規の表現を生成するとき、デフォルト値を使用しなければならない（MUST）。

このプロパティは、個々のプライマリリソースのレンダリングに影響しない。あるリソースから別のリソースへの進行方向にのみ関係する。

例 20：組み方向が明確に ltr に設定

{
"@context"           : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"               : "Book",
    …
"url"                : "https://publisher.example.org/leviathan",
"readingProgression" : "ltr"
}

2.7.2.11 タイトル

タイトルは、デジタル出版物の人間が可読可能な名前を提供する。name プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`name`	出版物の人間が可読可能なタイトル。	タイトルのための複数の項目。	ローカライズ可能な文字列の配列	`name` (Thing)

タイトルが、マニフェストに含まれておらず、デジタル出版物がタイトルを取得するための代替ルールを定義していない場合、ユーザーエージェントはタイトルを作成しなければならない（MUST）。この仕様は、このようなタイトルを生成するために使用するヒューリスティックを指定しない。

Note

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

例 21：明示的に設定された本のタイトル

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"url"      : "https://publisher.example.org/heart-of-darkness",
"name"     : "Heart of Darkness"
}

2.7.3 リソース分類プロパティ

出版物のリソースは、このセクションで定義されているデフォルトの読み上げ順序、リソースのリスト、及びリンクを介して指定される。これらの一覧は、プライバシーポリシーなどの情報リソースへの参照、及び目次などの構造リソースへの参照が含まれる。

特定のリソースの URL がこれらの一覧に複数現れてはならず（MUST NOT）、URL は、リスト内で繰り返してはならない（MUST NOT）ことに注意されたい。

マニフェストは、これらのリスト内に自体の参照を包含してはならない（MUST NOT）。

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

デフォルトの読み上げ順序は、デジタル出版物リソースのセットを経由する特定の進行順序である。ユーザーは、コンテンツを通る経由する代わりの経路を辿る場合があるが、そのようなインスタンスが欠如している場合、デフォルトの読み上げ順序は、あるリソースから次のリソースへの予想される進行順序を定義する。

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

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`readingOrder`	デジタル出版物のリソースを介した進行の順序。	ひとつ以上の `LinkedResource`。	リンクの配列	(None)

readingOrder プロパティの各要素は、次のいずれかで表現されなければならない（MUST）。

リソースの URL を表現する [json] 文字列、または、
LinkedResource オブジェクトのインスタンス。

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

項目の順序は、意味がある。

読み上げ順序を表現する URL は、フラグメント識別子に包含してはならない（MUST NOT）。非 HTML リソースは、encodingFormat 値が設定された LinkedResource として表現されるべきである（SHOULD）。

デフォルトの読み上げ順序は、最低でもひとつのリソースを包含しなければならない（MUST）。

例 22：読み上げ順序いは、URL の単純なリストとして表現される

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"url"      : "https://publisher.example.org/pride-prejudice",
"name"     : "Pride and Prejudice",
"readingOrder" : [
"html/title.html",
"html/copyright.html",
"html/introduction.html",
"html/epigraph.html",
"html/c001.html",
        …
    ]
}

例 23 ：読み上げ順序は、項目に関する詳細情報を提供するオブジェクトとして表現される

{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"     : "Book",
    …
"url"      : "https://publisher.example.org/pride-prejudice",
"name"     : "Pride and Prejudice",
"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"
    },{
        …
    }]
}

2.7.3.2 リソースリスト

リソースリストは、デフォルトの読み上げ順序に掲載されていないデジタル出版物の処理又はレンダリングに使用される追加リソースを列挙する。resources プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`resources`	出版物の処理又はレンダリングとして使用される追加の出版物リソースのリスト。	ひとつ以上の `LinkedResource`。	リンクの配列	(None)

resources プロパティの各要素は、次のいずれかで表現されなければならない（MUST）。

リソースの URL を表現する [json] 文字列、または、
LinkedResource オブジェクトのインスタンス。

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

項目の順序は、意味がない。

URL は、フラグメント識別子を包含してはならない（MUST NOT）。encodingFormat 値が設定された LinkedResource オブジェクトを使用することを推奨する（RECOMMENDED）。

リソースリストの完全性は、（例えば、オフラインで読む機能など）特定の読書状況におけるデジタル出版物のユーザビリティに影響する可能性がある。このため、デフォルトの読み上げ順序に掲載されているリソース以外の、パブリケーション内にある全ての構成リソースの包括的なリストを提供することを強く推奨する（RECOMMENDED）。

場合によっては、（例えば、ソースの深部からリソースを参照するサードパーティのスクリプトなど）これらのリソースの包括的なリストを簡単に得ることができない場合があるが、ユーザーエージェントは、（例えば、それらなしでオフラインになった場合など）これらのリソースの一部が出版物に属していると識別されない場合でも、出版物をレンダリングできるべきである（SHOULD）。

例 24 ：単純な URL を介したり、詳細を持つリソースを掲載する

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "TechArticle",
    …
"id"         : "http://www.w3.org/TR/tabular-data-model/",
"url"        : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
    …
"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"
        },{
            …
        }
    ],
    …
}

2.7.3.3 リンク

リンクリストは、デジタル出版物の処理とレンダリングに必要ないリソースのリストを提供するために使用される（つまり、これらのリソースが利用できない場合でも、出版物の内容は影響を受けない）。リンクは、links プロパティを使用して表現される。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`links`	出版物に関連付けられているが、処理又はレンダリングに必要ではないリソースのリスト。	ひとつ以上の `LinkedResource`。	リンクの配列	(None)

links プロパティの各要素は、次のいずれかで表現されなければならない（MUST）。

リソースの URL を表現する [json] 文字列、または、
LinkedResource オブジェクトのインスタンス。

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

項目の順序は、意味がない。

encodingFormat と rel 値が設定された LinkedResource オブジェクトの使用を推奨する（RECOMMENDED）。

通常、リンクされたリソースは、処理又はレンダリングを補強又は強化するためにユーザーエージェントを利用可能にする。例えば、

ユーザーエージェントが、シェルフからリンクを提示できるプライバシーポリシー又はライセンス、
ユーザーエージェントが、出版物に関する詳細情報を発見及び表示するために使用できるメタデータレコード、
ユーザーエージェントが、拡張された言語のヘルプを提供するために処理ができる用語の辞書。

リンクは、出版物のオンラインレンダリングで使用されるリソースを識別することもできるが、（例えば、サイズを最小化するなど）出版物がオフラインやパッケージ化されたときに包含する必要はない。これらは以下が含まれる。

出版物の見た目を強化するが、表示には不可欠ではない巨大なフォントファイル（つまり、代替フォントで十分だろう）、
出版物がオフライン又はパッケージ化されたときに使用することを意図していない（例えば、トラッキングスクリプトなど）サードパーティのスクリプト。

links のリストは、（例えば、スクリプト、画像、スタイルシートなど）リンクされたリソースをレンダリングに必要なリソースを包含するべきである（SHOULD）。

links に掲載されたリソースは、デフォルトの読み上げ順序又はリソースリストに掲載してはならない（MUST NOT）。

ユーザーエージェントは、リンクされたリソースを無視してもよく（MAY）、出版物でそれらをオフラインにする必要はない。これらのリソースは、出版物をパッケージングするときに包含するべきではない（SHOULD NOT）。

2.7.4 拡張性

マニフェストは、デジタル出版物の表示とレンダリングにおいてユーザーエージェントによって使用されるための基本的なプロパティのセットを提供するように設計されていますが、次の方法で拡張してもよい（MAY）。

リンクされたメタデータレコードの提供によって
マニフェストに追加プロパティの包含を介して

どちらの方法も有効だが、リンクされたレコードの使用を推奨する（RECOMMENDED）。

この仕様は、追加プロパティがマニフェストの正規の表現においてユーザーエージェントによるコンパイル、保存、公開する方法を定義しない。ユーザーエージェントは、一部又は全ての拡張プロパティを無視してもよい（MAY）。

2.7.4.1 リンクされたレコード

例えば、ONIX [onix] 又は BibTeX [bibtex] ファイルなど、レコードへのリンクを介してマニフェストを拡張するには、LinkedResource オブジェクトを使用して表現しなければならない（MUST）。

LinkedResource の rel 値は、IANA 又は他の組織によって定義された関連する識別子を包含するべきであり（SHOULD）、リンクレコードに記述的なメタデータが含まれる場合、describedby（IANA）識別子を包含しなければならない（MUST）。
リンク内の encodingFormat 値は、該当する場合、その特定のタイプのレコードに対して定義された MIME メディアタイプ [rfc2046] を使用しなければならない（MUST）。

リンクされたレコードが、出版物の一部である場合、リソースリストに包含しなければならない（MUST）（つまり、明示的なマニフェスト以上のものに必要である）。それ以外の場合、リンクリストに包含しなければならない（MUST）。

例 25 ：本のメタデータファイルのための外部 ONIX へのリンク

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
…
"url"        : "https://publisher.example.org/time-machine",
"name"       : "The Time Machine",
"links"  : [{
"type"            : "LinkedResource",
"url"             : "https://www.publisher.example.org/time-machine/onix.xml",
"encodingFormat"  : "application/onix+xml",
"rel"             : "describedby"
},{
	…
}],
…
}

Editor's note

application/onix+xml MIME タイプは、このドキュメントの執筆時点ではまだ IANA によって登録されておらず、説明だけを目的として例に包含されている。

2.7.4.2 追加のマニフェストプロパティ

追加のプロパティは、マニフェストに直接包含してもよい（MAY）。これらのプロパティは、[schema.org] や [dcterms] のようなパブリックスキームから取得し、可能な限りコントロールされた語彙から値を使用することを推奨する（RECOMMENDED）。プロプライエタリの用語を使用してもよいが（MAY）、コンテキストの一部として定義されたプレフィックスと伴に、そのような用語を、コンパクト IRI [json-ld] を使用して包含することを推奨する（RECOMMENDED）。

Note

[dcterms] のプレフィックス定義 dc は、[schema.org] のコンテキストファイルに包含されている。これは、プレフィックスを明示的に追加する必要がないという意味である。同じことが他に多くある公の語彙にも当てはまる。詳細は、schema.org context file を見よ。

例 26 ：基本データの拡張として、schema.org「copyrightYear」及び「copyrightHolder」用語の使用例

{
"@context"        : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"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",
…
}

例 27 ：基本データの拡張として、2012 ACM Classification 用語を持つダブリンコア「subject」の使用例

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "CreativeWork",
…
"id"         : "http://www.w3.org/TR/tabular-data-model/",
"url"        : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
"dc:subject" : ["Web data description languages","Data integration","Data Exchange"],
…
}

2.8 リソースの関係

2.8.1 有益なリソース

2.8.1.1 アクセシビリティレポート

アクセシビリティレポートは、様々な好みの読書方法を持つユーザーが消費するためのデジタル出版物の適合性に関する情報を提供する。通常、これらのレポートは、例えば、[wcag21] で提供されているものなど、確立されたアクセシビリティ基準に対する評価の結果を識別し、出版物のユーザビリティを決定する重要な情報源である。

アクセシビリティレポートは、accessibility-report リンクリレーションを使用して識別する。

Editor's note

現在、accessibility-report 用語は、IANA のリンクリレーションに登録されていないが、ワーキンググループはそれを追加する予定である。

マニフェストは、出版物が利用できるとき、アクセシビリティレポートへのリンクを包含するべきである（SHOULD）。レポートを、出版物のリソースとして包含することが推奨される（RECOMMENDED）。

アクセシビリティレポートは、例えば、HTML [html] など、人間が可読可能なフォーマットで提供されることも推奨される（RECOMMENDED）。例えば、schema.org [schema.org] で提供するなど、機械処理可能なメタデータでこれらのレポートを増補することも、推奨される（RECOMMENDED）。

例 28：アクセシビリティレポートへのリンク

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
    …
"url"        : "https://publisher.example.org/sherlock-holmes",
"name"       : "The Adventures of Sherlock Holmes",
"links"  : [{
"type"        : "LinkedResource",
"url"         : "https://www.publisher.example.org/sherlock-holmes-accessibility.html",
"rel"         : "accessibility-report"
    },{
        …
    }],
    …
}

2.8.1.2 プレビュー

全てのデジタル出版物を、（例えば、サイトの登録ユーザーに制限される場合など）全てのユーザーが利用できるわけではない。このような場合、出版社は、完全版へのアクセスをユーザーへ促すために、コンテンツのプレビューを提供することがある。

プレビューは、preview リンクリレーション [iana-link-relations] を使用して識別される。

プレビューは、外部に配置又はデジタル出版物のリソースとして包含してもよい（MAY）。

例 29 ：プレビューは、デジタル出版物の音声リソースとして識別される

"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
…
"url"        : "https://publisher.example.org/jekyll-hyde",
"name"       : "The Strange Case of Dr. Jekyll and Mr. Hyde",
"links"  : [{
"type"            : "LinkedResource",
"url"             : "preview.mp3",
"encodingFormat"  : "audio/mpeg",
"rel"             : "preview"
},{
	…
}],
…
}

例 30 ：プレビューは、外部リンクとして表現される

"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
…
"url"        : "https://publisher.example.org/jekyll-hyde",
"name"       : "The Strange Case of Dr. Jekyll and Mr. Hyde",
"links"  : [{
"type"            : "LinkedResource",
"url"             : "https://publisher.example.org/jekyll-hyde-preview.html",
"encodingFormat"  : "text/html",
"rel"             : "preview"
},{
	…
}],
…
}

2.8.1.3 プライバシーポリシー

多くの場合、ユーザーは、自分について収集される情報、その情報の保存方法や保存期間、個人を特定可能か、及び消去方法を、知り、制御する法的権利を持つ。従って、このようなプライバシーに対する懸念に対処する声明を包含することは、デジタル出版物の出版の重要な部分である。情報が収集されない場合でも、このような宣言は、ユーザーがコンテンツに対する信頼が高まる。

プライバシーポリシーへのリンクは、この目的のために、マニフェストへ包含できる。プライバシーポリシーは、出版物のリソースとして包含することを推奨する（RECOMMENDED）。

プライバシーポリシーは、privacy-policy リンクリレーション [iana-link-relations] を使用して識別される。

例 31 ：プライバシーポリシーは、外部リンクとして表現される

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "TechArticle",
    …
"id"         : "http://www.w3.org/TR/tabular-data-model/",
"url"        : "http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/",
    …
"links"  : [{
"type"           : "LinkedResource",
"url"            : "https://www.w3.org/Consortium/Legal/privacy-statement-20140324",
"encodingFormat" : "text/html",
"rel"            : "privacy-policy"
    },{
            …
    }],
    …
}

2.8.2 構造リソース

2.8.2.1 カバー

カバーは、ユーザーエージェントが、（例えば、図書館や本棚で、又は最初に出版物を読み込むときになど）デジタル出版物を提示するために使用できるリソースである。

カバーは、cover リンクリレーションによって識別される。url 用語で表現される URL は、フラグメント識別子を包含してはならない（MUST NOT）。

Editor's note

現在、cover 用語は、IANA リンクリレーションに登録されていないが、ワーキンググループは、それを追加する予定である。

カバーが画像フォーマットの場合、title と description が提供されるべきである（SHOULD）。ユーザーエージェントは、アクセシビリティが必要なとき、代替テキストと説明を提供するためにこれらのプロパティを使用できる。

複数のカバーを、（例えば、様々なデバイスの画面のための代替フォーマットとサイズを提供するためなど）マニフェストから参照してもよい（MAY）。複数のカバーが指定されている場合、各インスタンスは、（例えば、異なるフォーマット、高さ、幅、又は関係など）ユーザビリティを判断することがユーザーエージェントができるように、少なくともひとつの一意のプロパティを定義しなければならない（MUST）。

例 32：カバーは HTML ページ

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
    …
"url"        : "https://publisher.example.org/adam-bede",
"name"       : "Adam Bede",
"resources"  : [{
"type"           : "LinkedResource",
"url"            : "cover.html",
"encodingFormat" : "text/html",
"rel"            : "cover"
    },{
        …
    }],
    …
}

例 33：タイトルと説明を持つカバー画像

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
    …
"url"        : "https://publisher.example.org/mobydick",
"name"       : "Moby Dick",
"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"
    },{
        …
    }],
    …
}

例 34 ：JPEG 及び SVG フォーマットのカバー画像

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
    …
"url"        : "https://publisher.example.org/gullivers-travels",
"name"       : "Gulliver's Travels",
"resources"  : [{
"type"           : "LinkedResource",
"url"            : "lilliput.jpg",
"encodingFormat" : "image/jpeg",
"rel"            : "cover"
    },{
"type"           : "LinkedResource",
"url"            : "lilliput.svg",
"encodingFormat" : "image/svg+xml",
"rel"            : "cover"
    },{
        …
    }],
    …
}

2.8.2.2 ページリスト

ページリストは、デジタル出版物内の静的なページ分割の位置のリストを含むナビゲーション支援である。

ページリストは、pagelist リンクリレーションによって識別される。ページリストを識別するリソースの url 用語で表現された URL は、フラグメント識別子を包含してはならない（MUST NOT）。

Editor's note

現在、pagelist 用語は、IANA リンクリレーションに登録されていないが、ワーキンググループは、それを追加する予定である。

ページリストへのリンクは、リンクリストに指定してはならない（MUST NOT）。

例 35 ：出版物の別のリソース内で指定されたページリスト

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
…
"url"        : "https://publisher.example.org/metamorphosis",
"name"       : "Metamorphosis",
"resources"  : [{
"type"       : "LinkedResource",
"url"        : "toc_file.html",
"rel"        : "pagelist"
},{
	…
}],
…
}

2.8.2.3 目次

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

目次は、contents リンクリレーション [iana-link-relations] よって識別される。目次を識別するリソースの url 用語で表現される URL は、フラグメント識別子を包含してはならない（MUST NOT）。

目次へのリンクは、リンクリストに指定してはならない（MUST NOT）。

目次の推奨される（RECOMMENDED）構造と処理モデルは、§ B. 機械処理可能な目次で定義される。

例 36 ：rel 属性値で識別される目次を含むリソース

{
"@context"   : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"type"       : "Book",
    …
"url"        : "https://publisher.example.org/ilprincipe",
"name"       : "Il Principe",
"resources"  : [{
"type"       : "LinkedResource",
"url"        : "toc_file.html",
"rel"        : "contents"
    },{
        …
    }],
    …
}

2.8.3 拡張

この仕様で定義されている以上の追加の関係を表現する必要がある場合、rel プロパティは、次のいずれかで拡張できる。

[iana-relations] で定義された関係の使用を介して、又は、
拡張関連型 [rfc8288] の使用を介して。

[iana-relations] からの関連の使用を、推奨する（RECOMMENDED）。

5. マニフェストの処理

正規の表現におけるマニフェストの処理に対する手順は、次のアルゴリズムによって与えられる。早期にアルゴリズムが終了する場合、マニフェストは有効ではない。

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

text：マニフェストに含まれている UTF-8 文字列、
base：マニフェストのベース URL を表す URL 文字列。
document：利用できるとき、マニフェストを参照するドキュメントの HTML ドキュメント（DOM）ノード [html]。

Note

このアルゴリズムは、マニフェストの発見及び取得方法を定義しない。そのための手順は、各デジタル出版物フォーマットによって定義される。

Note

理解を助ける目的のために、このセクションの例は、JavaScript オブジェクトとして内部表現の構造を示す。ユーザーエージェントは、適切な言語と形式で結果の構造を処理及び内部化できる。

マニフェストの正規の表現を含むオブジェクトを処理する。
manifest は JSON [ecmascript] として text をパースした結果とする。パースがエラーを投げた場合、このアルゴリズムを終了する。
typeof（manifest）が Object [ecmascript] でない場合、このアルゴリズムを終了する。
（§ 2.4 マニフェストのコンテキスト）manifest["@context"] が、値「https://schema.org」及び「https://www.w3.org/ns/pub-context」を（この順序で）含んでいない場合、エラーを発行し、このアルゴリズムを終了する。
manifest 内の各プロパティ term を反復し、必要に応じて次のようにその値を拡張する。複数の手順を適用してもよい（MAY）。

Note

以下の手順は、term の想定された値のカテゴリによって異なる。値のカテゴリは、用語の名前だけでなく、使用されるオブジェクトにも依存する可能性があることに注意されたい。例えば、用語 url の値カテゴリは、PublicationManifest オブジェクトに使用されるときは（URLs の）配列だが、それ以外のときは単一の URL リテラルである。

このステップでは、変数 current は manifest[term] の値に設定され、適用可能な各変換によって更新される。
1. （§ 2.7.1.7 配列）term は配列を想定しているが、current に文字列又はオブジェクト value が含まれている場合、current を配列に変換し、それに value をプッシュする。
  説明
  
  多くの用語は配列にこれらの値が必要であるが、便宜上、著者はひとつの要素配列の代わりに単一の値を使用できる。例えば、次の場合、
  例 41
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"name"      : "Et dukkehjem",
"author"    : "Henrik Ibsen",
    …
}
```
  以下の結果が得られる。
  例 42
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"name"      : ["Et dukkehjem"],
"author"    : ["Henrik Ibsen"],
    …
}
```
2. （§ 2.7.1.4.2 エンティティ）term がエンティティを想定しているが、current の値が文字列 str の場合、次のプロパティを持つオブジェクトに current を変換する。
  - type – 値「Person」の配列に設定する。
  - name – str に設定する。
  typeof（current）が Array [ecmascript] の場合、配列の各要素でこの手順を実行する。
  説明
  
  著者、編集者などは、タイプ Person のオブジェクトとして明示的に設計されることが想定されるが、便宜上、名前のみを指定する必要がある。例えば、次の場合、
  例 43
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"author"    : ["Ralph Ellison"],
    …
}
```
  このルールは、オブジェクトに文字列値を変換し、前の例は以下の結果を得られる。
  例 44
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"author"    : [{
"type" : ["Person"],
"name" : "Ralph Ellison"
    }],
    …
}
```
  Note
  
  簡単にするために、ローカライズ可能な文字列への name の変換は、後の手順で説明される。
3. （§ 2.7.1.4.1 ローカライズ可能な文字列）term がローカライズ可能な文字列を想定し、current が文字列 str を含む場合、次のプロパティ持つオブジェクトに current を変換する。
  - value – str に設定する。そして、
  - language – 指定されているときは、manifest["@context"] の言語宣言の値に設定する。それ以外は省略される。
  typeof（current）が Array [ecmascript] の場合、配列の各要素でこの手順を実行する。
  
  typeof（current）が Object [ecmascript] の場合、オブジェクトの各プロパティでこの手順を実行する。
  説明
  
  自然言語のテキスト値は、ローカライズ可能な文字列のオブジェクトとして明示的に設計されることが意図されているが、便宜上、単純な文字列にすることができる。例えば、言語情報がグローバル言語宣言を介して提供されていない場合、
  例 45
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"name"      : ["La Comédie humaine"],
    …
}
```
  以下の結果が得られる。
  例 46
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"name"      : [{
"value" : "La Comédie humaine"
    }],
    …
}
```
  しかしながら、明示的な言語がマニフェストで提供されている場合、その言語はローカライズ可能な文字列オブジェクトに追加される。例えば、次の場合、
  例 47
```
{
"@context"  : [
"https://schema.org",
"https://www.w3.org/ns/pub-context",
                     {"language": "fr"}
                  ],
"name"       : ["La Comédie humaine"],
    …
}
```
  以下の結果が得られる。
  例 48
```
{
"@context"  : [
"https://schema.org",
"https://www.w3.org/ns/pub-context",
                     {"language": "fr"}
                  ],
"name"      : [{
"value"    : "La Comédie humaine",
"language" : "fr"
    }],
    …
}
```
4. （§ 2.7.1.4.3 リンク）term がリソース分類プロパティ又は alternate プロパティであり、current の配列における値の場合、次のプロパティを持つオブジェクトへ各文字列 str を変換する。
  - type – 値「LinkedResource」の配列に設定し、そして、
  - url – str に設定する。
  説明
  
  リソースリンクは、タイプ LinkedResource として明示的に設計されることを想定しているが、便宜上、絶対 URL 又は相対 URL のみを指定する必要がある。例えば、次の場合、
  例 49
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
    …
"resources" : [
"css/book.css",
        …
    ],
    …
}
```
  この手順においては、オブジェクトに文字列値を変換し、前の例では以下の結果が得られる。
  例 50
```
{
"@context"  : ["https://schema.org","https://www.w3.org/ns/pub-context"],
    …
"resources" : [{
"type" : ["LinkedResource"],
"url"  : "css/book.css"
    },
        …
    ],
    …
}
```
  Note
  
  簡単にするために、相対パスから絶対パスへの変換は、後の手順で説明する。
5. （§ 2.7.1.5 URL）term が URL を想定し、current の値が絶対 URL 文字列ではない文字列である場合、base [rfc1808] の値を使用して値を解決する。
  
  typeof（current）が、Array [ecmascript] の場合、配列の各要素でこの手順を実行する。
  
  typeof（current）が、Object [ecmascript] の場合、オブジェクトの各プロパティでこの手順を実行する。
  
  説明
  
  出版物マニフェスト内における全ての相対 URL は、絶対 URL を生成するためにベース値に対して解決する必要がある。
6. （§ 4.2 互換性の要件、拡張ポイント）プロファイルがプロファイル固有の用語の処理ステップを定義している場合、それらのステップはこの時点で実行される。
current の値に processed[term] を設定する。
必要に応じて、次のプロパティの document からデフォルトを追加する。
1. （§ 2.7.2.11 タイトル）processed["name"] が設定されていない、又はその値が空の文字列の場合、
  - 新しいオブジェクト title を作成する。
    - document の title 要素 [html] が設定され、そのコンテンツが空ではない場合、title 要素のテキストコンテツに title["value"] を設定し、そして、該当する場合、language [html] に title["language"] を設定する。
    - そうでなければ、title["value"] の値を生成し（詳細は別注を見よ）、ワーニングを発行する。
  - 空の配列に processed["name"] を設定し、それに title を追加する。
  説明
  
  この手順は、マニフェストに name プロパティが指定されていないときに、document の title 要素のコンテンツを追加する。例えば、次の場合、
  例 51
```
<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>
```
  以下の結果が得られる。
  例 52
```
{
"@context" : ["https://schema.org","https://www.w3.org/ns/pub-context"],
"name"     : [{
"value" : "The Golden Bough",
"language" : "en"
    }],
    …
}
```
2. （§ 2.7.3.1 デフォルトの読み上げ順序）processed["readingOrder"] が設定されていない、又はその値が空の文字列か配列の場合、
  - document.URL が設定されていない場合、エラーを発行してこのアルゴリズムを終了する。
  - そうでなければ、オブジェクトを作成して document.URL の値にその url プロパティを設定する。空の配列に processed["readingOrder"] を設定してオブジェクトを追加する。
  説明
  
  デジタル出版物が参照するドキュメントのみで構成されている場合、デフォルトの読み取り順序は省略でき、自動的に、その単一のリソースで構成される。
3. プロファイルがドキュメントのフォールバックを指定する場合、それらの手順はこの時点で実行される。
processed の次のプロパティでデータの整合性チェックを実行する。
1. エンティティの配列に想定される processed 内の各プロパティ term について、processed[term] の各値 entry に、name プロパティが設定されているかどうかをチェックする。設定されていない場合、processed[term] から entry を削除し、ワーニングを発行する。
  
  ひとつ以上のプロパティがエンティティを想定しているオブジェクトを想定する current の全てのプロパティについて、再帰的にこのステップを繰り返す。
2. （§ 2.5.1 グローバルの宣言及び § 2.5.2 項目固有の宣言）processed の全ての language プロパティが整形式 [bcp47] であることを再帰的にチェックし、検出された整形式でない値に対してワーニングを発行する。
3. （§ 2.5.1 グローバルの宣言）processed["direction"] が設定され、その値が必要な方向の値のいずれでもない場合、ワーニングを発行する。
4. （§ 2.6 出版物タイプ）processed["type"] 設定されていない又は空の値が含まれている場合、値「CreativeWork」の配列にその値を設定し、ワーニングを発行する。
5. （§ 2.7.2.1 縮約）processed["abridged"] が設定されており、ブール値でない場合、ワーニングを発行する。
6. （§ 2.7.2.6 継続時間）processed["duration"] が設定されており、その値が [iso8601] に従う有効な継続時間の値でない場合、ワーニングを発行する。
7. （§ 2.7.2.7 最終変更日）processed["dateModified"] が設定されており、その値が [iso8601] に従う有効な日付又は日時でない場合、ワーニングを発行する。
8. （§ 2.7.2.8 発行日）processed["datePublished"] が設定されており、その値が [iso8601] に従う有効な日付又は日時でない場合、ワーニングを発行する。
9. （§ 2.7.2.9 出版物の言語）processed["inLanguage"] が設定されている場合、その配列における各値が整形式 [bcp47] であることをチェックし、検出された整形式でない値に対してワーニングを発行する。
10. （§ 2.7.2.10 組み方向）次のように processed["readingProgression"] を検証する。
  - プロパティが設定されていない場合、「ltr」にその値を設定する。
  - そうでない場合、プロパティが設定されているが、必要な方向の値のいずれでもない場合、ワーニングを発行する。
  - そうでない場合、何もしない。
11. （§ 2.7.3 リソース分類プロパティ）processed の各リソース分類プロパティ term について、processed[term] の各オブジェクト P に P["url"] が設定されているかどうかを確認する。
  - 設定されていない場合、processed[term] 配列から P を削除し、ワーニングを発行する。
  - そうでない場合、P["url"] が有効な URL [url] かどうかをチェックし、もし有効でない場合、ワーニングを発行する。
12. （§ A.1 LinkedResource の定義）タイプ LinkedResource 想定している processed の各プロパティ term に対して、term["length"] が設定されており有効な数値でない場合はワーニングを発行する。
13. プロファイルがデータ検証チェックを指定している場合、これらの手順はこの時点で実行される。

Note

エラー及びワーニングメッセージを報告する方法は、ユーザーエージェントに依存する。

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`type`	リソースのタイプ。任意	ひとつ以上のテキスト。シーケンスは「`LinkedResource`」を包含しなければならない（MUST）。	リテラルの配列	(None)
`url`	リソースの位置。必須。	有効な URL 文字列 [url]。追加の制限は、このタイプを受け入れるプロパティの定義を参照されたい。	URL	`url`
`encodingFormat`	（例えば、`text/html` など）リソースのメディアタイプ。任意。	MIME メディアタイプ [rfc2046].	リテラル	`encodingFormat`
`name`	項目の名前。任意。	ひとつ以上のテキスト項目。	ローカライズ可能な文字列の配列。	`name`
`description`	項目の説明。任意。	テキスト。	ローカライズ可能な文字列	`description`
`rel`	リソースと出版物の関連性。任意。	ひとつ以上の関連性。値は、IANA リンクレジストリ [iana-link-relations] 関連性のある関連用語かそれとも、適切なリンクレジスト項目が存在しない場合は特別に定義された URL。	リテラルの配列	(None)
`integrity`	整合性の検証を可能にするリソースの暗号化ハッシュ。任意。	ひとつ以上の空白で区切られた整合性メタデータ [sri] のセット。値は、メタデータの定義 [sri] に準拠しなければならない（MUST）。ユーザーエージェントがサポートすることを期待している暗号化ハッシュ関数のリストは、[sri] を参照されたい。	リテラル	(None)
`length`	（おそらく分数）秒における時間ベースのメディアリソースの合計長。任意。	数字	数字	(None)
`alternate`	代替フォーマットでのリソースのひとつ以上の再形成への参照。指定されたとき、`encodingFormat` は再形成のフォーマットを示す。順序は重要ではない。任意ひとつ以上の、代替フォーマットのリソース再形成の URL を表現する文字列、又は、 `LinkedResource` オブジェクトのインスタンス。項目の順序は、重要ではない。非 HTML リソースは、`encodingFormat` 値が設定された `LinkedResource` オブジェクトとして表現されるべきである（SHOULD）。	`LinkedResource` オブジェクトのひとつ以上のインスタンス。	リンクの配列	(None)

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`type`	クリエイターのタイプ。任意。	ひとつ以上のテキスト。シーケンスは、「`Person`」又は「`Organization`」を包含しなければならない（MUST）。	リテラルの配列	(None)
`name`	クリエイターの名前。必須。	ひとつ以上のテキスト。	ローカライズ可能な文字列の配列	`name`
`id`	クリエイターに関連付けられた正規の識別子。任意。	URL レコーダー [url]。	識別子	(None)
`url`	クリエイターに関連付けられたアドレス。任意。	有効な URL 文字列 [url]。	URL	`url`
`identifier`	（例えば、ORCID など）クリエイターに関連付けられた識別子。任意。	ひとつ以上のテキスト。	リテラルの配列	`identifier`

用語	概要	必須の値	値のカテゴリ	[schema.org] マッピング
`type`	文字列のタイプ。任意。	ひとつ以上のテキスト。シーケンスは、「`LocalizableString`」を包含しなければならない（MUST）。	リテラルの配列	(None)
`value`	ローカライズ可能な文字列の値。必須。	テキスト。	リテラル	(None)
`language`	値の言語。任意。	整形式の言語タグ [bcp47]。	リテラル	(None)

B. 機械処理可能な目次

B.1 導入

このセクションは規定ではない。

ページ内及びサイト間のナビゲーションを容易にするために、HTML は、リンクのリストを表現するために nav 要素 [html] を使用する。デフォルトでは本質的に汎用ではあるが、nav 要素の目的は、role 属性 [html] の使用によって、より明確に識別することである。特に、[dpub-aria-1.0] 語彙の doc-toc ロールは、デジタル出版物の目次として nav 要素を識別する。

識別可能な目次を包含することは、任意のデジタル出版物を生成するためのアクセシブルな方法だが、HTML マークアップの柔軟性のために、（例えば、任意のページから利用可能なカスタムビューを提供するためなど）リンクの意味のある階層を抽出しようとするユーザーエージェントにとっての課題を提示する。様々な用途の目次が重複するのを避けるために、このセクションは、ユーザーエージェントの抽出に十分な構造を提供しながら、ヒューマンフレンドリーかつ一般的な用途の構文を定義する。

著者は、目次を構築するためのリスト（順序付きまたは順序なし）を選択できる。これらのリスト内の各リンクをアンカータグ（a 要素）でタグ付けすることにより、ユーザーエージェントは、必要な情報を周囲のコンテンツ（補助）又は追加されているスタイル的なタグとを容易に区別できる。目次は、アクティブなリンク（href 属性を含む）と非アクティブなリンク（href 属性を除く）の両方で構成でき、（例えば、特定の見出しへのリンクを省略したり、プレビュー内の特定のコンテンツへのリンクなど）目次の構成方法にさらなる柔軟性を提供できる。

B.2 HTML 構造

目次は、[html] 要素（通常は nav 要素）を介して表現される。この要素は、role 属性 [html] の値「doc-toc」 [dpub-aria-1.0] によって識別されなければならず（MUST）、その role 値を持つドキュメントツリー順序 [dom] におけるドキュメントの最初の要素でなければならない（MUST）。

マニフェストは、目次を含むリソースを識別するべきである（SHOULD）。

nav 要素のコンテンツモデルは、制限がないけれども、ユーザーエージェントは、次のマークアップガイドラインに従うときのみ、使用可能な目次を抽出できるだろう。

目次のタイトル

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

リンクのリスト

nav 要素内で遭遇した最初の [html] ol 又は ul リスト要素は、コンテンツへのリンクを定義するリストが含まれていると想定される。例えば、このリストは、アルゴリズムがその処理に関係のない無視する要素のため、たとえ div 要素にネストされていて発見されるだろう。しかしながら、内部コンテンツは評価されないため、リストはスキップする要素の内部に発生することはできない。

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

ブランチ

目次がリンクのツリーと見なされる場合、リンクのリスト内における各リスト項目（li 要素）は、ひとつのブランチを表現する。これらの各ブランチは、ユーザーに提示するために名前とオプションの目的地を持つ必要があり、この情報は、ネストされていれば、リスト項目内で発見された最初 a 要素から取得される（繰り返しになるが、スキップする要素内の全ての a 要素は除外される。）

ブランチのリンクの目的地は、指定されているとき、a 要素の href 属性から取得される。この属性は、リンクが利用できない（例えば、プレビューなど）又は関連性がない（例えば、グループ化したヘッダーなど）場合、省略できる。コンテンツへのリンクを提供するとき、（rel 属性で）リンクされたドキュメントの関係及び（type 属性で）リンクされたリソースのメディアタイプを指定することも可能である。

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

スキップする要素

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

隠された要素はユーザーによって直接アクセスされることを目的としていないため、hidden 属性が設定されている要素もスキップされる。

これらの要素は nav 要素に包含できるけれど、（たとえば、コンテンツへの全てのリンクを含むリストアイテムの周りを section 要素をラップしないようにするなど）それらの中に重要なコンテンツを埋め込まないように注意する必要がある。

無視する要素

目次の抽出に関連せず、スキップされない全ての要素は、無視される。スキップする要素とは異なり、無視することは、ユーザーエージェントが関連コンテンツを検索し続けることを意味し、使用できるタグ付けに関して柔軟性が向上する。

B.2.1 例

このセクションは規定ではない。

例 55 ：基本的なマルチレベルの目次。

異なるリストタイプは、レベルごとに使用できることに注意されたい。

<nav role="doc-toc">
<h2>Contents</h2>

<ol>
<li>
<a href="discourses.html">ZARATHUSTRA'S DISCOURSES.</a>
<ul>
<li><a href="discourses.html#s01">THE THREE METAMORPHOSES.</a></li>
<li><a href="discourses.html#s02">THE ACADEMIC CHAIRS OF VIRTUE.</a></li>
<li><a href="discourses.html#s03">BACKWORLDSMEN.</a></li>
            …
</ul>
</li>
      …
</ol>
</nav>

例 56 ：無視するコンテンツ内の目次。

補足説明の情報は、ユーザーエージェントによって無視される。

<nav role="doc-toc">
<h2>Contents</h2>

<ol>
<li>
<div class="title"><a href="c01.html">CHAPTER I</a></div>
<div class="description">Biographical and Introductory.</div>
</li>
<li>
<div class="title"><a href="c02.html">CHAPTER II</a></div>
<div class="description">A New System of Alternating Current Motors and Transformers.</div>
</li>
      …
</ol>
</nav>

例 57 ：プレビュー用の目次。

ユーザーがアクセスできないコンテンツへリンクする a 要素は、href 属性を包含していない。

<nav role="doc-toc">
<h2>Contents</h2>

<ol>
<li><a href="xmas_carol.html">Marley's Ghost</a></li>
<li><a>The First of Three Spirits</a></li>
<li><a>The Second of Three Spirits</a></li>
<li><a>The Last of the Spirits</a></li>
<li><a>The End of It</a></li>
</ol>

   …
</nav>

例 58 リンクしていない見出しのある目次。

この例では、著者名は関連するリンクロケーションではないため、href 属性は囲んでいる a 要素に包含されていない。

<nav role="doc-toc">
<h2>Contents</h2>

<ol>
<li>
<a>Faraday, Michael</a>
<ol>
<li><a href="faraday.html#s01">Experimental Researches in Electricity</a></li>
<li><a href="faraday.html#s02">The Chemical History of a Candle</a></li>
</ol>
</li>
<li>
<a>Forel, Auguste</a>
<ol>
<li><a href="forel.html">The Senses of Insects</a></li>
</ol>
</li>
      …
</ol>
</nav>

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

このセクションは、nav 要素から目次を抽出するアルゴリズムを定義する。これは、DOM ツリーのノードを、ツリー順に walk することに関して定義されており、各ノードは、ウォーク中にそのノードが入ったとき及び出たときにアクセスされる。ノードがアクセスされるたびに、それは入力又は終了イベントをトリガーしていると見なすことができる。いくつかの手順では、ユーザーエージェントにコンテンツの処理方法の選択及び様々なプレゼンテーションモデルに柔軟性を提供する。

Note

理解を助ける目的のために、このセクションの例は、JavaScript オブジェクトとして目次の構造を示す。ユーザーエージェントは、適切な言語と形式で結果の構造を処理及び内部化できる。

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

次のアルゴリズムは、role 属性値 doc-toc を使用して、ドキュメント順に最初の nav 要素をルートとする DOM サブツリーの walk のために適用しなければならない（MUST）。全ての説明は有益である。

toc は目次を表現するオブジェクトとし、次のように初期化する。
1. 目次のタイトルを表現する toc の name プロパティを作成し、空の文字列を設定する。
2. 目次の全てのブランチを表現する toc の entries プロパティを作成し、空の配列を設定する。
説明

この手順は、目次のタイトルとブランチを保存する toc オブジェクトを初期化する。
例 59 ：デフォルトの toc オブジェクトの視覚化
```
{
"name": '',
"entries": []
}
```
スタックの初期化。

説明

スタックは、まだ完了していないブランチを保持するために使用される。新しいサブブランチに遭遇すると、親を後で取得できるようにスタックへプッシュする。
現在の toc ブランチを null を設定した変数にする。

説明

現在の toc は、現在処理されている目次のブランチを表現するオブジェクトを保持するために使用される。
目次の構築元である nav 要素から始め、ツリー順で DOM 上を walk し、walk の入力及び終了するときに、各要素に対して次の最初の関連手順をトリガーする。
1. 見出しコンテンツ要素を入力するとき。
  
  次の手順を実行する。
  1. スタックが空で、toc の name プロパティが空の文字列である場合、次のいずれかのように name プロパティを設定する。
    - （HTML タグを保持するための）要素の子孫コンテンツ。
    - （例えば、要素のアクセシブルな名前 [accname-1.1] を計算することによってなど）子孫コンテンツから取得されたテキスト文字列。
    （例えば、プレゼンテーション要素を削除し、全ての先頭と末尾の空白をトリミングした後など）name の結果の値が空の文字列である場合、name プロパティをプレースホルダー値かそれとも null に設定する。
  2. 要素を終了し、次の要素で処理を続行する。
  説明
  
  この手順は、目次の見出しを識別する。見出しは、toc name プロパティの値が空の文字列の場合にのみ処理される（つまり、見出しはまだ検出されていない）。
  
  ユーザーエージェントが見出し要素の子孫コンテンツに name を設定するかそれとも、そこからテキスト文字列を生成するかは、（例えば、画像、MathML、ルビ、及び簡単にテキストへ変換できない他のコンテンツを保持するためなど）プレゼンテーションで子孫タグを再利用するかどうかによって異なる。
  例 60：見出しのある toc オブジェクトの視覚化
```
{
"name": "Contents",
"entries": []
}
```
  name が空の文字列ではない、または null の場合、すでに前の見出しと遭遇しているか、（例えば、見出しはリンクのリストをたどらないため、リストは既に処理されているなど）nav 要素に見出しがないことを示すコンテンツと遭遇している。
  例 61 見出しのない toc オブジェクトの視覚化
```
{
"name": null,
"entries": []
}
```
  見出しが識別されてない場合、ユーザーエージェントは、後で使用するために独自の見出しを提供できる。
2. リスト要素を入力するとき
  
  次の手順を実行する。
  1. toc の name プロパティが空の文字列の場合、name を null に設定する。
  2. 現在の toc ブランチが null でない場合。
    1. 現在の toc ブランチの entries プロパティが null 又は空でない配列の場合、要素を終了し、次の要素で処理を続行する。
    2. そうでなければ、スタックに現在の toc ブランチのオブジェクトをプッシュし、現在の toc ブランチを null に設定する。
  3. そうでなければ、スタックが空の場合。
    1. toc の entries プロパティが null 又は空でない配列の場合、要素を終了し、次の要素で処理を続行する。
    2. そうでなければ。何もしない。
  説明
  
  このアルゴリズムは、単一のブランチ又は nav 要素のルートで複数のリストを処理せず、そのため、リストと既に遭遇している場合（entries プロパティにひとつ以上のブランチが含まれているか、null に設定されている）、このリストはスキップされる。
  
  リストと遭遇し、目次（toc）にまだ名前がない場合（つまり、見出し要素と遭遇していない）、目次は見出しがないと想定される（つまり、目次の見出しはエントリの最初のリストの後に表示できない）。name プロパティの値は、これ以上は見出しが適用されないため、空の文字列から null に変更される。
3. リスト要素を終了するとき
  
  スタックが空でない場合、スタックからオブジェクトを取り、それに現在の toc ブランチを設定する。
  
  説明
  
  これは、全ての子ブランチが処理された後、現在の toc ブランチが親オブジェクトにリセットされる。
4. リスト項目要素を入力するとき場合
  
  次の手順を実行する。
  1. 新しいオブジェクトに現在の目次オブジェクトを設定する
  2. オブジェクトの name、url、type、及び rel プロパティを作成し、空の文字列を設定する。
  3. オブジェクトに entries プロパティを作成し、空の配列を設定する。
  説明
  
  各リスト項目は目次の新しいブランチの候補を表現しているため、新しいブランチに遭遇すると、新しい空のオブジェクトが現在の toc ブランチに作成される。
  例 62 ：新しいブランチオブジェクトの視覚化
```
{
"name": '',
"url": '',
"type": '',
"rel": '',
"entries": []
}
```
  このオブジェクトは、子孫の a 要素として情報が投入され、リストに遭遇する。
5. リスト項目要素を終了するとき
  
  次の手順を実行する。
  1. 現在の toc ブランチの entries プロパティが空の配列を含む場合、値を null に設定する。
  2. スタックがひとつ以上のエントリを含む場合。
    1. 現在の toc ブランチの entries プロパティに空でない配列が含まれ、その name プロパティが空の文字列である場合、その name をプレースホルダ値又は null に設定する。
    2. 現在の toc ブランチの entries プロパティが空の配列が含まれ、その name プロパティが空の文字列の場合、現在の toc ブランチを null に設定し、この処理手順を終了する。
    スタックの一番上にあるオブジェクトの entries プロパティの配列に現在の toc ブランチを追加する。
  3. そうでなければ、toc の entries 配列に現在の toc ブランチ内のオブジェクトを追加する。
  4. 現在の toc ブランチに null を設定する。
  説明
  
  リスト項目を終了すると、現在のブランチの処理が完了したことを示す。親の entries 配列にこのブランチを追加する前に、ブランチに名前及び/又はサブブランチがあるかどうかをテストする必要がある。名前はないがサブブランチがある場合、ブランチは保持される。ユーザーエージェントは、独自に作成のプレースホルダー値を提供するか、値を null に設定できる。名前またはブランチがない場合、無効になり破棄される。
  
  ブランチをマージする場所を決定するために、スタックがチェックされる。スタックにオブジェクトがない場合、ルートの toc オブジェクトの entries プロパティに追加される（つまり、最上位ブランチである）。そうでなければ、スタック内にある直前のオブジェクトの entries プロパティに追加される。
  
  最終の手順として、現在の toc ブランチは null に戻されてリセットされる。
  例 63：ブランチマージの視覚化
  
  次の二つのオブジェクトが、現在の toc ブランチにある場合
```
{
"name": "Section 1",
"url": "http://example.com/contents.html#s1",
"type": "text/html",
"rel": null,
"entries": []
},
{
"name": "Section 1.1",
"url": "http://example.com/contents.html#s1.1",
"type": "text/html",
"rel": null,
"entries": null
}
```
  マージ後、次の単一オブジェクトのみが残る。
```
{
"name": "Section 1",
"url": "http://example.com/contents.html#s1",
"type": "text/html",
"rel": null,
"entries": [
      {
"name": "Section 1.1",
"url": "http://example.com/contents.html#s1.1",
"type": "text/html",
"rel": null,
"entries": null
      }
   ]
}
```
6. アンカー要素を入力し、現在の toc ブランチが null でない場合。
  
  次の手順を実行する。
  1. 現在の toc ブランチの name プロパティが、空の文字列でない場合、何もしない。
  2. そうでなければ
    1. 次のいずれかに現在の toc ブランチの name プロパティを設定する。
      - （HTML タグを保持するための）アンカー要素の子孫コンテンツ。
      - （例えば、要素のアクセシブルな名前 [accname-1.1] を計算することによってなど）子孫コンテツから抽出したテキスト文字列。
      （例えば、プレゼンテーション要素を削除し、先頭と末尾の空白を全てトリミングした後など）name の結果の値が空の文字列の場合、name プロパティを null に設定する。
    2. 要素に href 属性があり、属性の URL がデフォルトの読み上げ順序又はリソースリストのリソースで解決される場合、現在の toc ブランチの url プロパティを値に設定する。そうでなければ、プロパティを null に設定する。
    3. 要素に type 属性があり、先頭と末尾の空白をトリミングした後の属性の値が空の文字列でない場合、現在の toc ブランチの type プロパティをその値に設定する。そうでなければ、プロパティを null に設定する。
    4. 要素に rel 属性があり、先頭と末尾の空白をトリミングした後の属性の値が空の文字列でない場合、現在の toc ブランチの rel プロパティをその値に設定する。そうでなければ、プロパティを null に設定する。
    要素を終了し、次の要素で処理を続行する。
  説明
  
  この手順は、ブランチの name と url プロパティの値を取得するためにアンカータグを処理する。
  
  現在のブランチの名前がすでに定義されている場合、この要素の処理は終了する（つまり、単一のブランチにおける複数のリンクの処理を回避するため）。
  
  ユーザーエージェントが a 要素の子孫コンテンツにエントリの name を設定するかそれとも、そこからテキスト文字列を生成するかは、（例えば、画像、MathML、ルビ、及び簡単にテキストへ変換できない他のコンテンツを保持するためなど）プレゼンテーションで子孫タグを再利用するかどうかによって決まる。
  
  href 属性を識別することに加え、この仕様の要件を満たすために、デジタル出版物に属するリソースを解決する必要がある。そうでない場合、ブランチは保持されるが、エントリはリンクできない。
  
  リンクのターゲットに関する追加情報（リソースのタイプとその関係）も保持される。
  例 64 ：SVG 画像へのリンクの視覚化
```
{
"name": "In the Beginning",
"url": "http://example.com/page1.svg",
"type": "image/svg",
"rel": null,
"entries": []
},
```
7. セクショニングコンテンツ要素、セクショニングルート要素、又は隠された属性を持つ要素を入力するとき。
  
  要素を終了し、次の要素で処理を続行する。
  
  説明
  
  セクショニング要素とセクショニングルート要素は独自のアウトラインを定義できるため、それらに由来すると目次の生成に問題が生じる（つまり、直接関連しないコンテンツが含まれる場合がある）。結果として、子コンテンツが処理されることを防ぐために遭遇したとき、スキップされる。
8. そうでない場合：何もしない。
  
  説明
  
  他の全ての要素について、この手順は、子孫要素の処理を継続できる。
DOM walk の完了後、toc の entries プロパティに空でない配列が含まれている場合、toc は機械処理された目次を表現する。

そうでなければ、デジタル出版物は、機械でレンダリングする目的で使用できる目次を持たない。

説明

ルート toc オブジェクトの entries 配列にブランチが含まれていない場合（リストが、nav 要素で発見されないかそれともリストに、適合するリスト項目が含まれていないため）、アルゴリズムは利用可能な目次を作成しない。

メモリー内の文字の順序：	`HTML היא שפת סימון.`
誤った表示を伝える：	HTML היא שפת סימון.
フォーマット文字のあるソースコード：	`"\u200FHTML היא שפת סימון."`
期待する表示を伝える：	HTML היא שפת סימון.

メモリー内の文字の順序：	`'سلام' is hello in Persian.`
誤った表示を伝える：	'سلام' is hello in Persian.
フォーマット文字のあるソースコード：	`"\u200E'سلام' is hello in Persian."`
期待する表示を伝える：	'سلام' is hello in Persian.

名前	出版物マニフェスト
`accessMode`	§ 2.7.2.2 アクセシビリティ
`accessModeSufficient`	§ 2.7.2.2 アクセシビリティ
`accessibilityFeature`	§ 2.7.2.2 アクセシビリティ
`accessibilityHazard`	§ 2.7.2.2 アクセシビリティ
`accessibilitySummary`	§ 2.7.2.2 アクセシビリティ
`artist`	§ 2.7.2.5 クリエイター
`author`	§ 2.7.2.5 クリエイター
`contributor`	§ 2.7.2.5 クリエイター
`creator`	§ 2.7.2.5 クリエイター
`dateModified`	§ 2.7.2.7 最終変更日
`datePublished`	§ 2.7.2.8 発行日
`duration`	§ 2.7.2.6 継続時間
`editor`	§ 2.7.2.5 クリエイター
`id`	§ 2.7.2.4 正規の識別子
`illustrator`	§ 2.7.2.5 クリエイター
`inker`	§ 2.7.2.5 クリエイター
`inLanguage`	§ 2.7.2.9 出版物の言語
`letterer`	§ 2.7.2.5 クリエイター
`link`	§ 2.7.3.3 リンク
`name`	§ 2.7.2.11 タイトル
`penciler`	§ 2.7.2.5 クリエイター
`publisher`	§ 2.7.2.5 クリエイター
`readBy`	§ 2.7.2.5 クリエイター
`readingOrder`	§ 2.7.3.11 デフォルトの読み上げ順序
`readingProgression`	§ 2.7.2.10 組み方向
`resources`	§ 2.7.3.2 リソースリスト
`translator`	§ 2.7.2.5 クリエイター
`url`	§ 2.7.2.3 アドレス

名前	出版物マニフェスト
`accessibility-report`	§ 2.8.1.1 アクセシビリティレポート
`contents`	§ 2.8.2.3 目次
`cover`	§ 2.8.2.1 カバー
`pagelist`	§ 2.8.2.2 ページリスト
`privacy-policy`	§ 2.8.1.3 プライバシーポリシー
`preview`	§ 2.8.1.2 プレビュー

Publication Manifest

W3C Working Draft 2019年9月11日

要約

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

1. 導入

1.1 スコープ

1.2 用語

1.3 適合性

2. 出版物のマニフェスト

2.1 導入

2.1.1 マニフェスト フォーマット

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

2.1.3 Schema.org との関係

2.2 要件

2.3 Web IDL

2.3.1 PublicationManifest 辞書

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

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

2.5.1 グローバル宣言

2.5.2 項目固有の宣言

2.6 出版物タイプ

2.7 プロパティ

2.7.1 値のカテゴリ

2.7.1.1 リテラル

2.7.1.2 数値

2.7.1.3 ブール

2.7.1.4 明示的及び暗黙的なオブジェクト

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

2.7.1.4.2 エンティティ

2.7.1.4.3 リンク

2.7.1.5 URL

2.7.1.6 識別子

2.7.1.7 配列

2.7.2 表現的プロパティ

2.7.2.1 縮約

2.7.2.2 アクセシビリティ

2.7.2.3 アドレス

2.7.2.4 正規の識別子

2.7.2.5 クリエイター

2.7.2.6 継続時間

2.7.2.7 最終変更日

2.7.2.8 発行日

2.7.2.9 出版物の言語

2.7.2.10 組み方向

2.7.2.11 タイトル

2.7.3 リソース分類プロパティ

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

2.7.3.2 リソース リスト

2.7.3.3 リンク

2.7.4 拡張性

2.7.4.1 リンクされたレコード

2.7.4.2 追加のマニフェスト プロパティ

2.8 リソースの関係

2.8.1 有益なリソース

2.8.1.1 アクセシビリティ レポート

2.8.1.2 プレビュー

2.8.1.3 プライバシー ポリシー

2.8.2 構造リソース

2.8.2.1 カバー

2.8.2.2 ページ リスト

2.8.2.3 目次

2.8.3 拡張

3. マニフェストの発見

3.1 リンク

3.2 埋め込み

3.3 その他の発見方法

4. モジュール拡張

4.1 導入

4.2 互換性の要件

5. マニフェストの処理

6. セキュリティとプライバシーの考慮事項

A. カスタム タイプの定義

A.1 LinkedResource の定義

A.2 CreatorInfo の定義

A.3 LocalizableString の定義

B. 機械処理可能な目次

B.1 導入

B.2 HTML 構造

B.2.1 例

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

2.1.1 マニフェストフォーマット

2.3.1 `PublicationManifest` 辞書

2.7.3.2 リソースリスト

2.7.4.2 追加のマニフェストプロパティ

2.8.1.1 アクセシビリティレポート

2.8.1.3 プライバシーポリシー

2.8.2.2 ページリスト

A. カスタムタイプの定義

A.1 `LinkedResource` の定義

A.2 `CreatorInfo` の定義

A.3 `LocalizableString` の定義

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