发布者指南
发布你的产品
向 prodid 发布,就是在网上放两个文件,在 DNS 里加一条记录。在你自己的域名上,无需注册,也无需保管任何密钥:域名本身就是凭证,修改文件就能修改或撤回你发布的内容。
你打算如何发布?
身份与托管是分开的。你的身份是一个你控制的域名;文档实际放在哪里,只是一个以后可以更改的细节,不会改变你的身份,也不会改变 prodid 分配给你产品的任何标识符。三种方式,产生的记录完全相同。
方式 1
你可以在自己的域名上提供文件。
在域名上提供发现文档,并发布一条指向域名本身的 TXT 记录。
- 身份
- 域名
- 可信度
- verified
方式 2
你有域名,但无法在上面提供文件。
在托管的 slug 上发布,并让你域名上的一条 TXT 记录指向那台主机。
- 身份
- 经 DNS 证明的域名
- 可信度
- verified
方式 3
你完全没有域名。
在托管的 slug 上发布。以后再添加域名,不会丢失任何东西。
- 身份
- slug 主机
- 可信度
- unverified
方式 2 和 3 使用位于 <slug>.prodid.org 的托管发布服务。用发送到你邮箱的链接登录 publish.prodid.org,创建站点、上传文件,有域名的话再连接域名。你可以随时在那里导出全部内容或删除站点。
方式 1
在自己的域名上发布
两个文件加一条 DNS 记录。代表商户发布的平台在每个商户域名上做同样的事,因此每个商户都保有自己的身份和可信度等级。
提供发现文档
一个位于固定路径的文件,列出你的产品 feed 在哪里:
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必填: 是- 涵盖你 feed 中信息的 SPDX 标识符,例如 CC0-1.0。
feeds必填: 是- 最多 100 个 https URL,全部与本文档位于同一主机。
domain必填: 委托时- 本文档代表的域名。只要是通过指向其他主机的 TXT 记录找到本文档,就必须填写,并且必须等于该域名。由域名自己提供文档时可选,但如果填写,仍须一致。
通过 HTTPS 在默认端口、使用有效证书,以
application/json或任何application/…+json提供。不要重定向到其他主机:抓取程序只跟随一种重定向,即从acme.example到www.acme.example。提供 feed
feed 是 NDJSON:每行一个完整的 JSON 对象,UTF-8,以换行分隔。外面不包数组,行与行之间没有逗号。这样,两百万件产品的 feed 也能逐行流式读取,一行出错只损失那一行,不影响其余部分。
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 的同一产品的三个变体。它们共享一个 group,因此索引据此构建一个包含三个变体的系列。 feed 必须与列出它们的文档位于同一主机。 发现文档若列出其他主机上的 feed,会被整体拒绝而非部分拒绝:你失去的是整个来源,而不只是一个 feed,并且这算作明确否定,会启动下文所述的 lapse 计时。从你的网站提供 JSON、从单独的 CDN 主机名提供 NDJSON 是很常见的需求,但 v1 不支持。请把两者放在同一主机上。
其中第一行,排版后便于阅读:
一条 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必填: 是- 这条记录在 feed 中的稳定名称。再次发布相同的 key 会替换它。
brand必填: 是- 产品上显示的品牌。它在限定 mpn 的范围之前会先被规范化,所以 ARÇELİK 和 Arçelik 是同一个品牌,而不是两个。
name必填: 是- 产品名称,不含变体维度。
identifiers必填: 是- 至少一个 { scheme, value },并且至少有一个是索引能保存的。值两端不能有空白,也不能为空。gtin 必须是 8、12、13 或 14 位数字,校验位正确,且不能全为零;mpn 需要一个能规范化出内容的 brand,因为它只在该范围内唯一;限定流通的 gtin 会被保留,但只作为你自己的 rcn。一条没有任何可保存内容的记录不标识任何东西,会被跳过。
lang必填: 否- 本记录中供人阅读的文本所用的 BCP 47 标签。
group必填: 否- 你自己的分组键。共享同一个值的单品是同一系列的变体。
variant必填: 否- 在组内区分这个单品的维度:颜色、尺码、容量。
category必填: 否- GS1 GPC 细分代码,写作 gpc: 加八位数字。
markets必填: 否- 该单品销售市场的 ISO 3166-1 alpha-2 代码。
properties必填: 否- 字符串、数字、布尔值、列表,或表示测量值的 { value, unit }。
media必填: 否- 最多 20 个 https URL,每个都带一个 kind 和一个来自可接收列表的 SPDX 许可。与 feed 不同,它们可以位于任何主机。
发送扁平的单品。你从不需要自己构建系列或变体,也从不发送
opid:前者由索引从group推导,后者由索引分配。如果你已经在生成 Google Merchant feed,group就是你的item_group_id。导出之前,关于条形码有两点值得了解。全为零的
gtin不是条形码,而是目录占位符,带有它的记录会像校验位错误一样被拒绝。限定流通编码,即店内使用的号段,会被保存并归属于你,但它在全球范围内不标识任何东西,因此永远不会把你的产品与别人的合并,/01/也不会解析它。在 DNS 中认领身份
文件上线后,发布一条把你自己的域名作为主机的记录。
_prodid.acme.example TXT_prodid.acme.example. IN TXT "v=prodid0; host=acme.example"它指向的正是发现过程本来就会找到的地方,所以你的数据不会有任何变化。变化的是:只拥有 DNS 添加权限的人能做什么。没有记录时,他们添加的一条记录会悄无声息地夺走你的身份,因为 DNS 优先于文件。而你的记录已经存在时,第二条记录会让发现以“多于一条记录”失败:这是一次 lapse,可见、会通知、可恢复。
绝不要把
_prodid委托给供应商。 对_prodid.<domain>的写权限就是对你身份的控制,和 DKIM 或 ACME DNS-01 验证完全一样。DNS 共享的域名,身份也是共享的。给代理商 feed,不要给记录。先上线文件,再添加记录,不要反过来:指向尚不存在的文档的记录就是一次失败的发现。值的读取不区分大小写,末尾多一个点也没关系,所以
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。它不会告诉你该域名是否已知、是否找到了内容,也不会告诉你一分钟前是否有别人 ping 过它。429只表示你超出了自己的请求配额,错误以application/problem+json返回。你的域名发生了什么,会显示在你的来源状态里,而不是在 ping 的响应中。
方式 2
委托托管,保留身份
很多制造商拥有域名,却无法在上面放文件。feed 托管在别处,域名用 DNS 证明,所以来源身份仍然是域名,可信度仍然是 verified。在 publish.prodid.org 创建站点并输入你的域名,它会显示需要添加的确切记录,并替你检查。
具体是什么样
上传到托管 slug 的目录
,例如
acme.prodid.org,它同时提供发现文档和 feed。你所拥有域名上的一条 TXT 记录
,指向那台主机。是主机而不是 URL,因此记录永远无法把抓取程序引向任意地址。
_prodid.acme.example TXT_prodid.acme.example. IN TXT "v=prodid0; host=acme.prodid.org"一份回指你域名的文档。
DNS 说“我的文档在那边”;文档说“我代表那个域名”。没有
domain的委托文档会被拒绝:缺失永远不会被当作同意,正是这一点阻止了任何人把记录指向别人的 feed。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 申请一个。来源身份是 slug 主机,可信度是unverified,因为没有证明任何关于域名的事情。这些记录是真正的记录:标识符、解析、来源归属一应俱全。处于这种情况的发布者大多已经有一份 Google Merchant 产品文件,所以规范中逐列写明了从这种文件到
org.prodid.item记录的映射,也写明了它有意舍弃的内容:价格、库存、配送和成色属于某一天的某个卖家,而不属于产品。导出之前值得先读一读导入 Merchant feed:publish.prodid.org 正是按照这个映射转换你上传的 CSV 或 TSV。其中有四点决定了你的表格应该是什么样子:- 四列会成为变体维度:
color、size、material和pattern,也就是买家在同一个item_group_id内挑选的那些。gender、age_group、size_type和size_system仍是普通属性:它们描述的是整个组,如果作为维度,只要有人把其中一个写成两种写法,一件产品就会被拆成好几件。 - 重复属性用逗号分隔还是用重复表头,按文件决定,而不是按单元格。 只有当某列的表头在整个文件中只出现一次时,单元格才会按逗号拆分;重复表头,则其下每个单元格都整体读取。这是携带含逗号值的唯一方式,而且这个决定对整个文件只做一次。它适用于
additional_image_link、product_type、product_highlight、product_detail和certification;其余一切,包括满是逗号的description,无论哪种情况都整体读取。 product_detail从不覆盖任何内容。 它中间的子属性成为属性键,节名被丢弃,同一个键以第一个值为准。之后出现的同键 detail,或落在映射已生成的键上的 detail,会被丢弃并连同所在行一起报告,所以 detail 列永远无法悄悄改写这一行其余部分说过的内容。- 必须声明媒体许可。 Merchant 格式没有对应的列,而且没有许可就不会接收任何内容,因此一次导入要声明一个可接收的 SPDX 标识符,涵盖文件中的所有图片和文档。你自己的
license列会逐行覆盖它;声明的许可不可接收的文件,会生成不带媒体的记录,而不是失败的记录。
无法成为记录的行(没有可用标识符、GTIN 校验位错误)会被跳过,并按表格行号报告,表头算第 1 行,所以一行出错只损失那一行,不影响整个导入。/spec/fixtures/merchant 中有一份可供对照的完整示例:一个 CSV、它必须生成的记录,以及必须被跳过的那一行。
对今天的决定而言,重要的是以后会发生什么。在你日后取得的域名上添加一条指向同一主机的 TXT 记录,下一次抓取时 slug 就会变成该域名:同一个来源,同一批记录,每个
opid都保留,可信度从unverified升到verified。你的sku标识符绑定的是来源本身而不是它的名称,所以迁移后依然有效。在 publish.prodid.org 上,用的就是方式 2 的那个域名字段。- 四列会成为变体维度:
检查你的域名
发布完成了吗?输入你的域名。索引会立即去查看它,然后你会进入它的实时状态页。
上线之前
ping 之前先检查文件
prodid-batch check 完全按照索引的方式校验你的发现文档和每个 feed,不需要 token,也不向索引询问任何东西。它在仓库的克隆中用 Bun 1.4.4 运行。把文件本身交给它:以 .json 结尾的路径按单个文档读取,其他路径按 NDJSON feed 读取。
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,带上所在的 feed 行号,并以非零状态退出。它读的是文件,而不是你的 DNS 或服务器,所以上面清单中的 TXT 记录、内容类型和缓存头仍需你自己检查。
记录校验所依据的规则在规范中,schema 位于 /spec/schemas/v1,/spec/fixtures/v1 中有机器可读的测试向量,可以在任何人抓取之前用来测试你的导出程序。
规范只以英文发布,以英文文本为准。
现状: Spec v1。索引和托管发布服务运行在 prodid.org 上。任何人都可以发布,可以用自己的域名,也可以使用托管。 本页的文件格式,就是你 ping 索引时它读取的格式。
参考
这一点要先了解,因为它决定了下面三种方式中哪一种适合你。每次抓取时,发现过程都会从头开始,先查 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 步解释了它能为你带来什么。
只能有一条记录,背后没有退路。 同一名称下有多条 v=prodid0 记录就是错误,而不是从中挑一条;单独一条格式错误或过长的记录也是错误。没有回退:一旦存在记录,失效的记录会直接终止发现,而不是让抓取程序转去查看你的域名。如果要更换主机,请替换记录,绝不要再加第二条。语法和测试向量见规范。
什么才算有效响应。 最多一次重定向后返回 HTTP 200、JSON 内容类型、能通过 feed schema 校验的正文,以及指明被发现域名的 domain。对未知路径返回 HTML 网页和 200 的网站不算响应,以 text/html 提供的文档也不算。
可信度是来源的属性,而不是某条声明的属性。它说明关于“谁在说话”已经证明了什么,却不说明某条信息是否正确。如何对待它,由数据的使用者决定。
| 等级 | 含义 |
|---|---|
| authoritative | 已证明域名控制权,并已确认品牌所有权。 |
| verified | 已通过 TXT 记录或由域名提供文档证明域名控制权。 |
| unverified | 没有域名的托管 slug、数据集导入或社区贡献。 |
只有身份是域名的来源,才可能高于 unverified。verified 来自抓取。authoritative 则不是,因为任何抓取都无法证明品牌归谁:它由索引的运营者授予,而且只凭证据授予。
证据是你的 GS1 厂商识别代码前缀。
你的来源以该品牌发布的 GTIN,其 GS1 厂商识别代码前缀必须授权给控制你域名的组织,以 GS1 公开的“Verified by GS1”查询结果为准。该查询的 URL 会作为证据与授权一起保存。
一项授权只对应一个品牌,每项都可以撤销。
品牌以其规范化后的形式记录。一个来源可以持有多个品牌的授权,运营者会分别撤销。
授权不会比它所依据的证明活得更久。
只要同时满足以下三点,你的来源就是
authoritative:其域名控制权已证明、它没有 lapsed、并且至少持有一项未被撤销的授权。失去域名证明或进入 lapse,它会立刻降到剩余证明所支持的等级:lapse 期间为verified,若域名证明也没了则更低,无需任何人操作。三点再次满足时,它立即恢复为authoritative。它覆盖的是来源,而不是品牌。
可信度始终是来源的属性:一个品牌的授权会让你的来源的每条声明都成为
authoritative,包括关于它没有授权的品牌的声明。
如需申请,请先在自己的域名上发布,然后通过申请表提出,写明你的域名、品牌,以及该品牌某个 GTIN 的 Verified by GS1 查询结果。运营者会在 Verified by GS1 中核对你的来源以该品牌发布的 GTIN。申请是公开的。
用已存在的 key 发布记录会替换之前的那条。没有更新接口,因为 feed 本身就是状态。
如果一个 key 从抓取程序完整获取的 feed 中消失,你关于它的声明会被标记为已撤回。实体及其标识符依然保留:别人指向它的链接继续有效,其他来源的声明也一样。
当抓取读到的文档不再列出你的某个 feed URL 时,该 feed 承载的每条有效记录都会立即撤回,就像它所有的 key 都消失了一样,而且该 URL 不会再被获取。下文的七天宽限期在这里不适用:移除 URL 就等于你说文件已经没了,索引会照你说的办。以后再列出它,它就会回来,并从头读取。如果可以,请为文档提供 ETag:304 表示列表没有变化,因此不会停用任何东西。
超过 64 KiB、无法解析或无效的行会被跳过并计数。由于被跳过行的 key 未知,含有跳过行的 feed 在七天内不会撤回任何内容。之后,缺失的 key 照常撤回。计数是公开的,所以一个悄悄丢行的 feed 并不会悄无声息。
只有当文档列出的一切都被读取时,抓取才算成功:一份可接受的文档,并且其中每个 feed 都返回 200 或 304。一个 feed 超时不会让你失去其他 feed(已响应的 feed 会被接收,失败的抓取不会撤回任何内容),但这次抓取会被算作传输失败,你的状态中的 feeds_failed 会如实显示。因此,一份完全健康的文档只要挂着一个永久失效的 feed URL,就会和一个彻底不再响应的域名一样,按同样的七天计时进入 lapse,并在此后三十天失去整个目录。不再提供的 feed URL 应当从文档中删除,而不是任其荒废。
明确否定,即发现过程结束时没有可接受的文档(既无记录也无文档;记录格式错误、过长或重复;或者文档不是 200、不是 JSON、无效、在 domain 上不再一致,或列出了其主机之外的 feed),会让来源立即进入 lapse。传输失败(DNS 超时、5xx、429、达到上限,无论发生在文档还是任何 feed 上)本身不会改变任何事,但如果连续七天每次尝试都以此告终,你也会进入 lapse,所以一直返回错误并不能把你的声明冻结在原处。
这种“疑罪从无”属于主机,而不属于你。 它只适用于你的来源已经在其上验证过的主机。在从未验证过的主机上(新的 slug、你刚把 _prodid 指过去的主机、方式 2 和 3 下的一切),任何失败,包括超时和 5xx,都是明确否定,会让你立即进入 lapse。这是有意的:否则,一个已验证的来源可以把记录指向一台它不控制的主机,再根据 lapse 是今天开始还是一周后开始,判断出那台主机是否在线。更换主机并不会因此让你付出任何代价。在新主机上的第一次成功抓取会清除一切,而在任何内容被撤回之前的 30 天里,lapse 始终可以恢复。
进入 lapse 的来源不再接受新的声明,会向读者显示为 lapsed,其 publisher.contact 会收到通知。对 lapse 来源的抓取在完全成功之前不会写入任何内容;只有那时 lapse 才会解除。连续 lapse 30 天后,你的记录及其有效声明会一并撤回,作为历史保留。这 30 天是你的恢复窗口,所以联系地址必须是有人会看的。
回来不需要做任何改动。像往常一样提供同样的文档和同样的 feed,在发现成功的那一刻,你发布的一切都会被重新确认,不管有没有改动一个字节:在没有保存你任何有效内容期间,索引会放弃条件请求,所以一个没变的文件永远不会成为继续处于撤回状态的理由。
读者看到的每条声明都带有 seen_at:不是这条信息最早在何处发布,而是这个来源从何时起不间断地断言这个值。每次重新抓取找到相同的值时,它都会保留下来,这正是它的意义。它不会在撤回后保留。如果你的来源 lapse 超过 30 天,你发布的每条信息的日期都会从你回来的那天重新开始,因为在空档期内没有任何可验证的人为它们负责。被撤回的行会保留,所以 ?history=1 会显示这段空档而不是掩盖它;读者会看到什么写在规范里。
/source/acme.example 是你发现问题的地方:上一次抓取的结果、发现走了哪条路径、多少条记录发生了变化、跳过了多少行、多少个 feed 无法读取,以及你是否处于 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 只是提示。只保存六种类型,别无其他:JPEG、PNG、GIF、WebP 和 AVIF 作为 image,PDF 作为 document。不接受 SVG、HTML、压缩包和 Office 文件:规格书请以 PDF 发布。检测到的类型必须与条目的 kind 一致,否则该条目会被跳过。
| 项目 | 上限 |
|---|---|
| 单张图片 | 20 MiB |
| 单个文档 | 50 MiB |
| 单次媒体获取 | 60 s |
| 一条记录中的媒体条目 | 20 |
在获取任何内容之前,许可会作为字符串进行检查,并且必须恰好是七个 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,并在下次抓取该记录时重试。有一点与 feed 正好相反:同主机规则在这里不适用,所以你的图片可以放在 CDN 上。接收哪些内容和许可列表给出了理由。
零售商、注册机构、开放数据集和贡献者都是和其他人一样的来源。他们的声明归属于他们自己,绝不会覆盖你的;你们意见不一时,两条声明都会连同各自来源并列显示。