パブリッシャーガイド
製品を公開する
prodid への公開は、Web に 2 つのファイルを置き、DNS に 1 つのレコードを追加することです。自分のドメインなら、登録も保管すべき鍵もありません。ドメインそのものが資格情報であり、ファイルを変えれば公開した内容を変更・撤回できます。
どの方法で公開しますか?
ID とホスティングは別物です。ID はあなたが管理するドメインで、文書が実際にどこにあるかは後から変えられる詳細にすぎず、変えても ID も、prodid が製品に割り当てた識別子も変わりません。3 つの方法、まったく同じレコード。
方法 1
自分のドメインでファイルを配信できる。
ドメインでディスカバリー文書を配信し、ドメイン自身を指す TXT レコードを公開します。
- ID
- ドメイン
- 信頼
- verified
方法 2
ドメインはあるが、そこでファイルを配信できない。
ホスト型の slug で公開し、自分のドメインの TXT レコードでそのホストを指します。
- ID
- DNS で証明されたドメイン
- 信頼
- verified
方法 3
ドメインをまったく持っていない。
ホスト型の slug で公開します。後からドメインを追加しても、何も失いません。
- ID
- slug ホスト
- 信頼
- unverified
方法 2 と 3 では <slug>.prodid.org のホスト型パブリッシャーを使います。メールで届くリンクで publish.prodid.org にサインインし、サイトを作り、ファイルをアップロードし、ドメインがあれば接続します。いつでもそこからすべてをエクスポートしたり、サイトを削除したりできます。
方法 1
自分のドメインで公開する
2 つのファイルと 1 つの DNS レコード。加盟店に代わって公開するプラットフォームは、加盟店ドメインごとに同じことを行うので、各加盟店が自分の ID と信頼レベルを保ちます。
ディスカバリー文書を配信する
製品フィードの場所を列挙する、固定パスの 1 つのファイル:
https://acme.example/.well-known/prodid.json.well-known/prodid.jsonapplication/json{ "$type": "org.prodid.feed", "version": 1, "publisher": { "name": "Acme Tekstil", "contact": "data@acme.example" }, "license": "CC0-1.0", "feeds": ["https://acme.example/prodid/items.ndjson"] }spec/fixtures/v1/examples/prodid.json の例。そのファイルからそのまま描画しています。 $type必須: はい- 常に org.prodid.feed。
version必須: はい- 1。値 0 の文書は 2027-01-26 00:00 UTC より前に始まった取得では受け付け、それ以降は明確な否定として拒否します。
publisher.name必須: はい- あなたのクレームの横に表示されるべき名前。
publisher.contact必須: いいえ- 実際に読まれているメールアドレス。ソースが lapse に入ったとき、インデックスはここに連絡します。届く通知はこれだけです。
license必須: はい- フィード内の情報に適用される SPDX 識別子。例: CC0-1.0。
feeds必須: はい- 最大 100 個の https URL。すべてこの文書と同じホスト上にあること。
domain必須: 委任時- この文書が代表するドメイン。別のホストを指す TXT レコードを通じて文書が見つかる場合は必須で、そのドメインと一致しなければなりません。ドメイン自身が配信する場合は任意ですが、書くなら一致が必要です。
HTTPS のデフォルトポートで有効な証明書を使い、
application/jsonまたは任意のapplication/…+jsonで配信します。別のホストへリダイレクトしないでください。クローラーが追うリダイレクトはacme.exampleからwww.acme.exampleへの 1 種類だけです。フィードを配信する
フィードは NDJSON です。1 行に 1 つの完全な JSON オブジェクト、UTF-8、改行区切り。外側に配列はなく、行の間にカンマもありません。こうすることで 200 万製品のフィードも 1 行ずつストリーム処理でき、壊れた行は残りではなくその行だけを失います。
prodid/items.ndjsonapplication/x-ndjson{"$type":"org.prodid.item","key":"TJ-2041-NVY-M","brand":"Acme","name":"Trail Jacket","lang":"en","group":"TJ-2041","variant":{"color":"navy","size":"M"},"identifiers":[{"scheme":"gtin","value":"09506000134352"},{"scheme":"mpn","value":"TJ-2041-NVY-M"}],"markets":["TR","DE"],"properties":{"material":"100% recycled polyester","madeIn":"TR","weight":{"value":480,"unit":"g"}},"media":[{"url":"https://acme.example/img/tj2041-navy.webp","license":"CC-BY-4.0","kind":"image"}]} {"$type":"org.prodid.item","key":"TJ-2041-NVY-L","brand":"Acme","name":"Trail Jacket","lang":"en","group":"TJ-2041","variant":{"color":"navy","size":"L"},"identifiers":[{"scheme":"gtin","value":"09506000134406"},{"scheme":"mpn","value":"TJ-2041-NVY-L"}],"markets":["TR","DE"],"properties":{"material":"100% recycled polyester","madeIn":"TR","weight":{"value":505,"unit":"g"}},"media":[{"url":"https://acme.example/img/tj2041-navy.webp","license":"CC-BY-4.0","kind":"image"}]} {"$type":"org.prodid.item","key":"TJ-2041-OLV-M","brand":"Acme","name":"Trail Jacket","lang":"en","group":"TJ-2041","variant":{"color":"olive","size":"M"},"identifiers":[{"scheme":"gtin","value":"09506000134413"},{"scheme":"mpn","value":"TJ-2041-OLV-M"}],"markets":["TR"],"properties":{"material":"100% recycled polyester","madeIn":"TR","weight":{"value":480,"unit":"g"}},"media":[{"url":"https://acme.example/img/tj2041-olive.webp","license":"CC-BY-4.0","kind":"image"}]}spec/fixtures/v1/examples/items.ndjson にある同じ製品の 3 つのバリアント。group を共有しているので、インデックスはそれをもとに 3 つのバリアントを持つ 1 つのファミリーを作ります。 フィードは、それを列挙する文書と同じホストになければなりません。 別のホストのフィードを列挙するディスカバリー文書は、一部ではなく全体が拒否されます。失うのはフィード 1 つではなくソース全体で、明確な否定として扱われ、下で説明する lapse の時計が動き出します。JSON は自分のサイトから、NDJSON は別の CDN ホスト名から配信したいというのはよくある要望ですが、v1 ではサポートしていません。両方を同じホストに置いてください。
その 1 行目を、読みやすく整形したもの:
1 つの org.prodid.item レコード{ "$type": "org.prodid.item", "key": "TJ-2041-NVY-M", "brand": "Acme", "name": "Trail Jacket", "lang": "en", "group": "TJ-2041", "variant": { "color": "navy", "size": "M" }, "identifiers": [ { "scheme": "gtin", "value": "09506000134352" }, { "scheme": "mpn", "value": "TJ-2041-NVY-M" } ], "markets": ["TR", "DE"], "properties": { "material": "100% recycled polyester", "madeIn": "TR", "weight": { "value": 480, "unit": "g" } }, "media": [{ "url": "https://acme.example/img/tj2041-navy.webp", "license": "CC-BY-4.0", "kind": "image" }] }$type必須: はい- 常に org.prodid.item。
key必須: はい- フィード内でのこのレコードの安定した名前。同じ key を再び公開すると置き換わります。
brand必須: はい- 製品に表示されているブランド。mpn の範囲を決める前に正規化されるので、ARÇELİK と Arçelik は 2 つではなく 1 つのブランドです。
name必須: はい- バリアントの次元を含まない製品名。
identifiers必須: はい- 少なくとも 1 つの { scheme, value } で、少なくとも 1 つはインデックスが保存できるもの。値の前後に空白はなく、空でもないこと。gtin は 8、12、13、14 桁の数字で、チェックディジットが正しく、すべてゼロでないこと。mpn はその範囲でしか一意でないため、正規化して何かが残る brand が必要です。流通が限定された gtin は保存されますが、あなた自身の rcn としてのみです。保存できるものが 1 つもないレコードは何も識別しないので、スキップされます。
lang必須: いいえ- このレコード内の人が読むテキストの BCP 47 タグ。
group必須: いいえ- あなた自身のグループキー。同じ値を共有するアイテムは、1 つのファミリーのバリアントです。
variant必須: いいえ- グループ内でこのアイテムを区別する次元。色、サイズ、容量。
category必須: いいえ- GS1 GPC ブリックコード。gpc: に続く 8 桁。
markets必須: いいえ- このアイテムが販売される市場の ISO 3166-1 alpha-2 コード。
properties必須: いいえ- 文字列、数値、真偽値、リスト、または測定値の { value, unit }。
media必須: いいえ- 最大 20 個の https URL。それぞれに kind と、受け入れ可能なリストの SPDX ライセンスを付けます。フィードと違い、どのホストにあってもかまいません。
フラットなアイテムを送ってください。ファミリーやバリアントを自分で組み立てることも、
opidを送ることもありません。前者はインデックスがgroupから導き、後者はインデックスが割り当てます。すでに Google Merchant フィードを生成しているなら、groupはあなたのitem_group_idです。エクスポートの前に、バーコードについて知っておくべきことが 2 つあります。すべてゼロの
gtinはバーコードではなくカタログのプレースホルダーで、それを持つレコードはチェックディジットの誤りと同様に拒否されます。流通限定コード、つまり店内用の番号帯は保存されてあなたに帰属しますが、世界的には何も識別しないので、あなたの製品が他の誰かの製品とまとめられることはなく、/01/で解決されることもありません。DNS で ID を確保する
ファイルが公開されたら、自分のドメインをホストとするレコードを公開します。
_prodid.acme.example TXT_prodid.acme.example. IN TXT "v=prodid0; host=acme.example"これはディスカバリーがいずれにせよ見つける場所を指すので、データは何も変わりません。変わるのは、DNS にレコードを追加できるだけの人ができることです。レコードがなければ、その人が追加した 1 つのレコードが、DNS がファイルより優先されるために、黙ってあなたの ID を奪います。あなたのレコードがすでにあれば、2 つ目のレコードはディスカバリーを「レコードが複数」で失敗させます。それは lapse であり、見え、通知され、回復できます。
_prodidをベンダーに委任しないでください。_prodid.<domain>への書き込み権限は、DKIM や ACME DNS-01 の検証とまったく同じく、あなたの ID の管理権です。DNS を共有するドメインは、ID も共有します。代理店に渡すのはフィードで、レコードではありません。先にファイルを公開し、次にレコードを追加します。逆にしないでください。まだ存在しない文書を指すレコードは、失敗したディスカバリーです。値は大文字小文字を区別せず、末尾のドットがあってもかまわないので、
ACME.Example.とacme.exampleは同じホストです。変更をインデックスに知らせる
任意です。既知のドメインはすべて定期的に再取得され、ping は次の取得を早めるだけです。
インデックスに今すぐディスカバリーを実行するよう依頼するcurl -X POST https://prodid.org/ping \ -H 'content-type: application/json' \ -d '{"domain": "acme.example"}' HTTP/1.1 202 Accepted Content-Type: application/json {"status":"accepted"}{"domains": [...]}は一度に最大 1000 件を受け付け、プラットフォームはこれでホストするすべての加盟店を知らせます。送る秘密はありません。ping は呼び出し元に内容への影響力を何も与えず、202しか返さないからです。そのドメインが既知か、何か見つかったか、1 分前に誰かが ping したかは教えてくれません。429はあなたが自分のリクエスト上限を超えたことだけを意味し、エラーはapplication/problem+jsonで返ります。あなたのドメインで何が起きたかは、ping の応答ではなくソースのステータスに表示されます。
方法 2
ホスティングを委任し、ID は保つ
ドメインは持っていても、そこにファイルを置けないメーカーは多くあります。フィードは別の場所にホストされ、ドメインは DNS で証明されるので、ソースの ID はドメインのまま、信頼は verified のままです。publish.prodid.org でサイトを作ってドメインを入力すると、追加すべき正確なレコードが表示され、確認もしてくれます。
実際の形
ホスト型 slug のディレクトリにアップロード
します。例えば
acme.prodid.orgで、ディスカバリー文書とフィードの両方を配信します。自分が所有するドメインの TXT レコード
で、そのホストを指します。URL ではなくホストなので、レコードがクローラーを任意のアドレスに向けることはできません。
_prodid.acme.example TXT_prodid.acme.example. IN TXT "v=prodid0; host=acme.prodid.org"あなたのドメインを指し返す文書。
DNS は「私の文書はあそこにある」と言い、文書は「私はそのドメインを代表している」と言います。
domainのない委任文書は拒否されます。欠落が同意とみなされることは決してなく、それこそが他人のフィードにレコードを向けることを防いでいます。acme.prodid.org/.well-known/prodid.jsonapplication/json{ "$type": "org.prodid.feed", "version": 1, "domain": "acme.example", "publisher": { "name": "Acme Tekstil", "contact": "data@acme.example" }, "license": "CC0-1.0", "feeds": ["https://acme.prodid.org/feeds/items.ndjson"] }spec/fixtures/v1/examples/prodid.delegated.json より。方法 1 との違いは domain フィールドだけで、ここでは必須です。 サイトを作成する
ホスト型パブリッシャーは、あなたの TXT レコードを自分で確認してから初めて
domainを文書に書き込むので、求めていないドメインを文書が主張する時間帯は存在しません。
方法 3
ドメインなしで公開する
サイトを作成する
ドメインをまったく持たない生産者は、ホスト型 slug
<slug>.prodid.orgで自分の名前で公開します。publish.prodid.org で申し込んでください。ソースの ID は slug ホストで、ドメインについて何も証明されていないため信頼はunverifiedです。レコードは本物のレコードで、識別子も解決も出典の帰属もすべてそろっています。この状況のパブリッシャーの多くは、すでに Google Merchant の製品ファイルを持っています。そのため仕様では、そのファイルから
org.prodid.itemレコードへの対応を列ごとに定め、意図的に捨てるもの(価格、在庫、配送、状態は、製品ではなく、ある日のある売り手のものです)も明記しています。エクスポートの前にMerchant フィードの取り込みを読んでおく価値があります。publish.prodid.org は、まさにこの対応に従ってアップロードされた CSV や TSV を変換します。シートの形を決めるのは次の 4 点です:- 4 つの列がバリアントの次元になります:
color、size、material、pattern。同じitem_group_idの中で買い手が選ぶものです。gender、age_group、size_type、size_systemは普通の属性のままです。これらはグループ全体を説明するもので、次元にすると、誰かが 1 つを 2 通りに書いただけで 1 つの製品が複数に分かれてしまいます。 - 繰り返し属性をカンマで区切るか、見出しを繰り返すかは、セルごとではなくファイルごとに決まります。 セルがカンマで分割されるのは、その列の見出しがファイル内に 1 回だけ現れる場合のみで、見出しを繰り返すと、その下のセルはそれぞれ丸ごと読まれます。カンマを含む値を運ぶ方法はこれだけで、この決定はファイル全体で 1 回だけです。対象は
additional_image_link、product_type、product_highlight、product_detail、certificationで、それ以外はカンマだらけのdescriptionも含め、どちらの場合も丸ごと読まれます。 product_detailは何も上書きしません。 中間の副属性が属性キーになり、セクション名は捨てられ、キーごとに最初の値が優先されます。同じキーの後続の detail や、対応付けがすでに作ったキーに当たる detail は、その行とともに報告されて捨てられるので、detail 列が行の他の部分の内容を黙って書き換えることはできません。- メディアのライセンスを宣言する必要があります。 Merchant 形式にはそのための列がなく、ライセンスなしでは何も取り込まれないため、取り込みではファイル内のすべての画像と文書に適用される、受け入れ可能な SPDX 識別子を 1 つ宣言します。あなた自身の
license列は行ごとにそれを上書きします。宣言したライセンスが受け入れられないファイルは、失敗したレコードではなく、メディアのないレコードになります。
レコードにできない行(使える識別子がない、GTIN のチェックディジットが誤り)はスキップされ、見出しを 1 行目としたシートの行番号で報告されるので、壊れた行は取り込み全体ではなくその行だけを失います。/spec/fixtures/merchant に比較用の完全な例があります。CSV、それが生成すべきレコード、そしてスキップされるべき 1 行です。
今日の判断にとって大事なのは、後で何が起きるかです。後から取得したドメインに同じホストを指す TXT レコードを追加すると、次の取得で slug はそのドメインになります。同じソース、同じレコード、すべての
opidが保たれ、信頼はunverifiedからverifiedに上がります。sku識別子はソースの名前ではなくソース自体に結び付いているので、移行後も有効です。publish.prodid.org では、方法 2 と同じドメインフィールドを使います。- 4 つの列がバリアントの次元になります:
ドメインを確認する
公開は終わりましたか。ドメインを入力してください。インデックスにいま確認を依頼し、そのライブのステータスページへ移動します。
公開前のチェック
ping の前にファイルを確認する
prodid-batch check は、ディスカバリー文書とすべてのフィードをインデックスとまったく同じ方法で検証します。トークンは不要で、インデックスには何も問い合わせません。リポジトリのクローンで Bun 1.4.4 を使って実行します。ファイルそのものを渡してください。.json で終わるパスは 1 つの文書として、それ以外は NDJSON フィードとして読まれます。
git clone https://github.com/productdevbook/prodid
cd prodid
bun install --frozen-lockfile
curl -fsSo prodid.json https://acme.example/.well-known/prodid.json
curl -fsSo items.ndjson https://acme.example/prodid/items.ndjson
bun apps/batch/src/cli.ts check prodid.json items.ndjson
prodid.json: ok, 1 record
items.ndjson: ok, 3 records問題のないファイルでは ok と、インデックスがそこから取り込むレコード数が表示されます。そうでなければ、問題ごとに items.ndjson:12: message の形でフィードの行番号付きの 1 行が表示され、0 以外の終了コードで終わります。読むのはファイルであり、DNS やサーバーではないので、上のチェックリストの TXT レコード、コンテンツタイプ、キャッシュヘッダーは自分で確認してください。
レコードを検証する規則は仕様にあり、スキーマは /spec/schemas/v1 に、誰かが取得する前にエクスポーターを試せる機械可読なテストベクトルは /spec/fixtures/v1 にあります。
仕様は英語でのみ公開されており、英語の本文が規範となります。
現状: Spec v1。インデックスとホスト型パブリッシャーは prodid.org で稼働しています。誰でも、自分のドメインからでもホスト型でも公開できます。 ここで説明しているファイル形式は、ping したときにインデックスが読む形式です。
リファレンス
下の 3 つの方法のどれが合うかはこれで決まるので、最初に知っておく価値があります。ディスカバリーは取得のたびに DNS から始まり、取得と取得の間にデータへの経路を覚えておくことはありません。
まず
_prodid.acme.exampleの DNS TXT レコードそこに
v=prodid0レコードがあれば、たとえ自分のドメインを指していても、それだけが使われます。レコードが示すのは host で、文書は常にhttps://<host>/.well-known/prodid.jsonにあります。そのようなレコードがない場合のみ
https://acme.example/.well-known/prodid.jsonドメイン自身にある文書。HTTPS でドメインを配信している者が、そのドメインとして発言します。
DNS が優先されるのは、より強い証明だからです。あるホストにファイルを置けることは、そのドメインの所有を意味せず、所有者はそれを覆せなければなりません。だからこそ、ファイルを自分で配信していてもレコードを書くべきです。方法 1 の手順 3 で、それが何をもたらすかを説明しています。
レコードは 1 つだけ、その背後に何もない。 同じ名前に複数の v=prodid0 レコードがあるとエラーで、どれかが選ばれることはありません。形式が不正なものや長すぎるものも、1 つだけでもエラーです。フォールバックはありません。レコードがあれば、壊れたレコードはディスカバリーをそこで終わらせ、クローラーがドメインを見に行くことはありません。ホストを移るときはレコードを置き換え、2 つ目を追加しないでください。構文とテストベクトルは仕様にあります。
有効な応答とみなされるもの。 リダイレクト 1 回以内での HTTP 200、JSON のコンテンツタイプ、フィードスキーマで検証できる本文、そして発見されたドメインを示す domain。不明なパスに 200 で HTML を返すサイトは応答とみなされず、text/html で配信された文書も同様です。
信頼はクレームではなくソースの性質です。誰が話しているかについて何が証明されたかを示しますが、ある情報が正しいかどうかは示しません。どう扱うかは、データを使う側が決めます。
| レベル | 意味 |
|---|---|
| authoritative | ドメインの管理を証明し、ブランドの所有を確認済み。 |
| verified | TXT レコード、またはドメインが文書を配信することで、ドメインの管理を証明済み。 |
| unverified | ドメインのないホスト型 slug、データセットの取り込み、またはコミュニティの投稿。 |
unverified より上になれるのは、ID がドメインであるソースだけです。verified は取得によって得られます。authoritative はそうではありません。ブランドが誰のものかはどんな取得でも証明できないからで、インデックスの運営者が、証拠に基づいてのみ付与します。
証拠はあなたの GS1 事業者コードです。
あなたのソースがそのブランドで公開する GTIN は、GS1 の公開検索「Verified by GS1」が示すとおり、あなたのドメインを管理する組織にライセンスされた GS1 事業者コードを持っていなければなりません。その検索の URL が、付与とともに証拠として記録されます。
付与はブランドごとに 1 つで、それぞれ取り消せます。
ブランドは正規化された形で記録されます。1 つのソースが複数のブランドの付与を持つことができ、運営者はそれぞれを個別に取り消します。
付与は、それが依拠する証明より長くは続きません。
ドメインの管理が証明され、lapsed でなく、取り消されていない付与を少なくとも 1 つ持つ間、あなたのソースは
authoritativeです。ドメインの証明を失うか lapse に入ると、残っている証明が支える水準に直ちに下がります。lapse 中はverified、ドメインの証明も失えばさらに下で、誰の操作も要りません。3 つがそろえば、直ちにauthoritativeに戻ります。対象はブランドではなくソースです。
信頼は常にソースの性質です。1 つのブランドへの付与で、付与されていないブランドについてのものも含め、あなたのソースのすべてのクレームが
authoritativeになります。
申請するには、まず自分のドメインで公開し、ドメイン、ブランド、そのブランドの GTIN 1 つについての Verified by GS1 の結果を添えて申請フォームから依頼してください。運営者は、あなたのソースがそのブランドで公開する GTIN を Verified by GS1 で確認します。申請は公開されます。
既存の key でレコードを公開すると、前のものが置き換わります。更新用の API はありません。フィードそのものが状態です。
クローラーが完全に取得したフィードから key が消えると、それについてのあなたのクレームは撤回済みとして印が付きます。エンティティとその識別子は残ります。他の人からのリンクは有効なまま、他のソースのクレームも同様です。
取得で読んだ文書があなたのフィード URL の 1 つをもう列挙していないとき、そのフィードが運んでいた有効なレコードはすべて、key がすべて消えたかのように直ちに撤回され、その URL はもう取得されません。下の 7 日間の猶予はここには当てはまりません。URL を外すことはファイルがなくなったと言うことであり、インデックスはそのとおりに受け取ります。後で再び列挙すれば戻り、最初から読み直されます。できれば文書に ETag を付けてください。304 はリストが変わっていないことを意味するので、何も引退しません。
64 KiB を超える行、解析できない行、無効な行はスキップされ、数えられます。スキップされた行の key はわからないので、スキップのあるフィードは 7 日間何も撤回しません。その後、消えた key は通常どおり撤回されます。件数は公開されているので、黙って行を落としているフィードも黙ってはいられません。
取得が成功するのは、文書が列挙するすべてが読めたときだけです。受け入れ可能な文書と、そのすべてのフィードが 200 か 304 を返すこと。1 つのフィードのタイムアウトで他のフィードを失うことはありません(応答したフィードは取り込まれ、失敗した取得は何も撤回しません)が、その取得は転送失敗として数えられ、ステータスの feeds_failed がそう示します。そのため、恒久的に壊れたフィード URL を 1 つ抱えた、それ以外は健全な文書は、まったく応答しなくなったドメインと同じ 7 日の時計で lapse に入り、その 30 日後にカタログ全体を失います。もう配信していないフィード URL は放置せず、文書から削除してください。
明確な否定、つまり受け入れ可能な文書なしにディスカバリーが終わること(レコードも文書もない。レコードが不正、長すぎる、重複している。文書が 200 でない、JSON でない、無効、domain がもう一致しない、自分のホスト外のフィードを列挙している)は、ソースを直ちに lapse に入れます。転送失敗(DNS のタイムアウト、5xx、429、上限到達。文書でもどのフィードでも)はそれ自体では何も変えませんが、7 日間のすべての試行がそれで終われば lapse に入るので、エラーを返し続けてもクレームをその場に凍結することはできません。
この「疑わしきは罰せず」はホストのもので、あなたのものではありません。 これが当てはまるのは、あなたのソースがすでに検証されたホストだけです。一度も検証されていないホスト(新しい slug、_prodid を向けたばかりのホスト、方法 2 と 3 のすべて)では、タイムアウトや 5xx も含め、どんな失敗も明確な否定で、直ちに lapse に入ります。これは意図的です。そうでなければ、検証済みのソースが管理していないホストにレコードを向け、lapse が今日始まるか 1 週間後に始まるかで、そのホストが稼働しているかを知ることができてしまいます。ホストを移ってもこのために失うものはありません。新しいホストでの最初の成功した取得ですべてが解消され、何かが撤回されるまでの 30 日間、lapse は常に回復できます。
lapse に入ったソースは新しいクレームを受け付けず、読者には lapsed と表示され、その publisher.contact に通知が届きます。lapse 中のソースへの取得は、完全に成功するまで何も書き込まず、成功して初めて lapse が解除されます。30 日連続で lapse すると、レコードとその有効なクレームはまとめて撤回され、履歴として残ります。この 30 日が回復の猶予なので、連絡先は誰かが読むアドレスでなければなりません。
戻るのに変更は要りません。同じ文書と同じフィードをいつもどおり配信すれば、ディスカバリーが成功した瞬間に、1 バイトも変えていなくても、公開したすべてが再確認されます。あなたの有効な内容を何も保持していない間、インデックスは条件付きリクエストをやめるので、変わっていないファイルが撤回されたままの理由になることはありません。
読者が目にするすべてのクレームには seen_at が付いています。その情報が最初にどこで公開されたかではなく、このソースがその値を途切れずに主張し続けている起点です。再取得で同じ値が見つかるたびに保たれ、それこそが意味のあるところです。撤回をまたいでは残りません。ソースが 30 日を超えて lapse すると、公開したすべての情報の日付は戻った日から始まり直します。空白の期間に、それに責任を持つ検証可能な誰かがいなかったからです。撤回された行は残るので、?history=1 は空白を隠さずに示します。読者に見えるものは仕様にあります。
/source/acme.example は問題を見つける場所です。最後の取得の結果、ディスカバリーがたどった経路、変更されたレコードの数、スキップされた行の数、読めなかったフィードの数、そして lapse しているか、いつからか。報告するのは、あなたのドメインが何を公開し、インデックスがいつ見たかだけで、誰が取得を依頼したかは決して報告しません。
{
"$type": "org.prodid.source",
"version": 1,
"name": "acme.example",
"kind": "domain",
"trust": "verified",
"verified_by": "dns-txt",
"verified_at": "2026-09-14T09:12:03Z",
"lapsed": false,
"license": "CC0-1.0",
"last_crawl": {
"at": "2026-09-19T06:00:11Z",
"via": "dns-txt",
"document_url": "https://acme.prodid.org/.well-known/prodid.json",
"outcome": "success",
"http_status": 200,
"records_seen": 3,
"records_changed": 1,
"lines_skipped": 0,
"feeds_failed": 0,
"media_failed": 0
}
}種類はバイトを読んで判定され、あなたの Content-Type はヒントにすぎません。保存されるのは 6 種類だけで、他にはありません。image として JPEG、PNG、GIF、WebP、AVIF、document として PDF。SVG、HTML、アーカイブ、Office ファイルは受け付けません。仕様書は PDF で公開してください。判定された種類はエントリの kind と一致しなければならず、一致しなければそのエントリはスキップされます。
| 項目 | 上限 |
|---|---|
| 画像 1 枚 | 20 MiB |
| 文書 1 件 | 50 MiB |
| メディア取得 1 回 | 60 s |
| 1 レコード内のメディアエントリ | 20 |
何かを取得する前に、ライセンスは文字列として確認され、7 つの SPDX 識別子のいずれかと正確に一致しなければなりません。誰でもファイルをそのまま再配布できるものだけで、インデックスが行うのもまさにそれです:
CC0-1.0 CC-BY-4.0 CC-BY-SA-4.0 CC-BY-ND-4.0
CC-BY-3.0 CC-BY-SA-3.0 CC-BY-ND-3.0ここではすべてがエントリ単位です。拒否された、大きすぎる、到達できないエントリは自分だけを失います。メディアのためにレコードが無効になることはなく、他のクレームはそのまま有効で、どんなメディアの失敗でも lapse には入りません。media_failed に数えられ、次にそのレコードが取得されるときに再試行されます。フィードとちょうど逆の点が 1 つあります。同一ホストの規則はここには適用されないので、画像は CDN に置けます。理由は取り込まれるものとライセンスの一覧にあります。
小売業者、登録機関、オープンデータセット、貢献者は、他と同じソースです。彼らのクレームは彼らに帰属し、あなたのものを上書きすることはありません。意見が食い違えば、両方のクレームがそれぞれのソースとともに並んで表示されます。