信息速览
jPOSTdb 不是又一个质谱原始数据仓库。它是日本 jPOST 环境里的再分析层：把 jPOSTrepo 以及 ProteomeXchange 其他成员仓库的原始谱图取回来，用同一套协议重搜索、重打分、重推断蛋白，再把结果按数据集、肽段、PSM、蛋白四层存起来。它的卖点从来不是"数据最多"，而是"这些数据被同一个人用同一把尺子量过"。
也正因为如此，它和 PRIDE 的关系必须一开始就说清：jPOSTdb 的结果是派生的，不是独立的原始观测。它的规模远小于 PRIDE，覆盖的是经过元数据与谱图质量筛选的一小批数据集。真正让它在库内站得住的，是统一重算之后才可能出现的跨数据集可比性，以及蛋白页上的修饰位点共现、肽段共享和数据集页上的染色体覆盖直方图。
需要先纠正一个流传很广的说法：jPOSTdb 的"染色体中心视图"不是把 PSM 按基因组坐标聚合、再生成"基因位点→proteoform→肽段证据"的层级。官方把它叫作 Chromosome Info，是一张按染色体统计"检出蛋白数 vs 注释蛋白总数"的直方图。这个差别决定了它能不能替代 proteoform 数据库。一屏速览见下表。
| 项目 | 官方口径（核查日 2026-10-29） |
|---|---|
| 全称 | Japan ProteOme STandard DataBase（jPOSTdb） |
| 归属 | jPOST 环境的两大组件之一，另一组件为原始仓库 jPOSTrepo |
| 门户 | globe.jpostdb.org（数据库）；jpostdb.org（项目门户/新闻） |
| 上游 | jPOSTrepo 及 ProteomeXchange 其他仓库的公开原始数据 |
| 再分析规模 | 2024 年论文口径 600 余个数据集；正文另称约 600 个 |
| 上游仓库规模 | 近三千个注册项目、2,143 个公开项目、逾 160,000 个文件、超过 100 TB |
| 内容层级 | 项目 → 数据集 → PSM/肽段 → 推断蛋白 |
| 存储隐喻 | 一个样本一个 Cube；全部 Cube 并集为 Globe；用户筛选子集为 Slice |
| 统一协议 | UniScore 重打分 + 目标-诱饵 FDR + 统一蛋白推断 |
| 染色体视图 | 每条染色体上"检出 leading protein 数 / 注释蛋白总数"直方图，含线粒体、质粒、unplaced |
| 标识符 | JPST 项目号、PXD 来源号、RPXD 再分析号、内部 psm_id/protein_id、UniProt accession |
| 许可 | 数据 CC0 1.0；RDF Portal 数据集页标 CC BY 4.0；论文 CC BY 4.0 |
| 取数 | Web 交互 + TSV zip + RDF/SPARQL；无公开 REST API |
| 版本 | 无对外版本号；RDF 数据集版本 202509（2025-09-04）；归档站 2021-08-12 开放 |
| 存活状态 | 在线；门户最新消息 2026-08-04 |
§1 速览：它到底是什么
§1.1 一句话定义
jPOSTdb 是日本 jPOST 项目维护的蛋白质组再分析数据库。它接收的不是用户新提交的谱图，而是已经进入 jPOSTrepo 或 ProteomeXchange 的公开原始文件；它产出的不是另一份 RAW，而是统一流程下的 PSM、肽段、蛋白、修饰与可视化视图。用一句话概括：它把"别人做的蛋白质组实验"重新算了一遍，让不同实验室的结果第一次可以用同一套阈值放在一起看。
这个定义里有两个关键词。第一个是"再分析"，决定了它的数据是二阶的，任何一个结果都能追到上游登录号。第二个是"统一"，决定了它的价值不在单数据集内部，而在数据集之间。单看一篇论文的蛋白列表，PRIDE 已经够用；要把二十篇论文放在一张表里比较，才需要 jPOSTdb 这种把搜索工具、FDR 口径、蛋白推断规则都固定下来的层。
它也不是"日本版 PRIDE"。PRIDE 保存的是提交者给出的结果与原始文件，原则上不替提交者重算；jPOSTdb 保存的恰恰是重算后的结果，原始文件仍留在上游。两者的角色是仓库与加工厂，不是同类竞品。
§1.2 它解决的不是"有没有数据"，而是"能不能比"
公共蛋白质组学的核心矛盾早就不是数据量。PRIDE 的数据集以万计，ProteomeXchange 每年新增的 RAW 以 TB 计，真正卡住二次利用的是三件事：不同搜索引擎给出的肽段分数不可比；不同实验室的 FDR 控制口径不同；蛋白推断规则不透明，导致"这个蛋白到底算不算检出"无法复现。
jPOSTdb 对这三点各给了一个固定答案。分数层面，它用 UniScore 把不同搜索引擎的输出折算到同一尺度；FDR 层面，它用基于 UniScore 的目标-诱饵策略统一控制；蛋白推断层面，它明确采用 Nesvizhskii 与 Aebersold 2005 年的规则，并把蛋白分成 leading、same-set、sub-set、subsumable 四类。使用者不需要认同这套规则，但至少知道规则是什么，也能按同一规则复现。
这就是"可比性"的具体含义：不是把数据放在同一个网页上，而是把判断标准写成一套可执行的流程。代价是覆盖面。统一重算要花算力、要人工核对元数据、要过质量闸门，所以它只能处理几百个数据集，不可能追上 PRIDE 的万个量级。
§1.3 决策卡：你的处境决定它有没有用
| 你的处境 | jPOSTdb 能帮你什么 |
|---|---|
| 手上有十几篇不同实验室的组织蛋白组，想合并看趋势 | 这些数据集若已被再分析，PSM 与蛋白口径已统一，省去自己重跑搜索 |
| 想查某个蛋白在哪些实验里被检出、有哪些磷酸化位点 | 蛋白页给出肽段覆盖、PTM 位点计数、位点共现与跨蛋白共享肽 |
| 想按物种、器官、疾病、细胞系筛一批数据做差异表达 | Globe 分面筛选生成 Slice，两个 Slice 可直接做经验贝叶斯或 Wilcoxon 比较 |
| 关心某条染色体上还有多少蛋白缺乏质谱证据 | Chromosome Info 直方图配合 Protein Existence 饼图，正对 C-HPP 的 missing protein 议题 |
| 想下载 RAW 用自己的流程重跑 | 它不给 RAW，去 jPOSTrepo 或 PRIDE 取原始文件 |
| 想要上万样本、统一强度的定量矩阵 | 它只有几百个数据集，定量基础是谱图计数，不给绝对丰度 |
这张表的左列是处境，不是功能。同一个功能对不同处境的价值完全不同：染色体直方图对做 missing protein 的人是入口，对做药物靶点筛选的人只是一个背景图。
§1.4 不适合谁：三条硬边界
第一，不适合把 RAW 当作输入的人。 jPOSTdb 的结果表里没有谱图，只有 PSM 级别的肽段序列、荷质比、电荷、分数与修饰。要做 de novo 测序、谱图库检索、仪器参数复现，必须回到 jPOSTrepo 或 PRIDE 下载原始文件。这一点没有折中方案。
第二，不适合把"600 个数据集"当成"公共蛋白质组全库"的人。 它是筛选后的再分析集合，不是 ProteomeXchange 的完整镜像。你要找的数据集大概率不在里面，尤其当它来自欧洲实验室、元数据不全、或谱图质量没过闸门时。
第三，不适合把染色体直方图当成 proteoform 地图的人。 这张图不按基因组坐标聚合 PSM，也不生成"基因位点→proteoform"的层级。它只回答"这条染色体上有多少注释蛋白被检出"，不回答"这个位点上存在哪些剪接异构体、各自带什么修饰"。后者要去蛋白页看 isoform 级肽段共享，或者去 neXtProt、UniProt 查注释。
如果你的需求是"给我一份能直接训练模型的蛋白定量矩阵"，jPOSTdb 给不了你；它能给的是"这些数据集在统一口径下检出了哪些蛋白、哪些位点、哪些共享肽"，剩下的矩阵化与归一化要自己做。
§1.5 三个名字别混：jPOST、jPOSTrepo、jPOSTdb
| 名字 | 是什么 | 是否保存原始谱图 | 典型标识符 |
|---|---|---|---|
| jPOST | 整个环境/项目的总称 | 不适用 | 无 |
| jPOSTrepo | 原始数据仓库，PX 成员 | 是 | JPST、PXD |
| jPOSTdb | 再分析数据库 | 否（只存结果） | 内部 dataset/psm/protein id |
很多介绍把三者写成同义词，导致两个后果：一是以为 jPOSTdb 能下载 RAW，二是以为 jPOSTrepo 的数据都已被再分析。实际是反过来的：仓库里有近三千个项目，数据库只覆盖几百个数据集；数据库的每一条结果都能追到仓库，但仓库的绝大多数项目在数据库里没有对应记录。
§2 数据构成与规格
§2.1 官方口径的规模：先把数字分层
规模必须分三层看，混在一起就会得出"六千万条 PSM、四万份样本"这类无法核对的结论。
| 层级 | 官方数字 | 口径与日期 |
|---|---|---|
| 原始仓库项目 | 2,876 个注册项目，其中 2,143 个公开 | 2024 年论文，截止 8 月 30 日 |
| 原始数据体量 | 逾 160,000 个文件，超过 100 TB | 同上 |
| 再分析数据集 | 600 余个（摘要），正文称约 600 个 | 2024 年论文 |
| 归档 PSM 表 | 4,936,877 行 | 2021-07-29 快照，LSDB 归档 |
| 归档蛋白表 | 530,455 行 | 同上，按内部 protein_id 计，不能当作不同蛋白数 |
| 物种 | 仓库注册超过 300 个物种；再分析当前以人、小鼠、大鼠、细菌为主 | 2024 年论文与 2019 年论文 |
这张表最重要的信息不是任何一个数字，而是两个口径的落差：仓库有近三千个项目，数据库只有六百余个数据集；仓库有上百 TB 原始文件，数据库的归档结果表压缩后只有几十 MB。这个落差就是"再分析"这件事的成本，也是它必须做筛选的证据。
截至核查日，门户没有公布实时的数据集总数与 PSM 总数。2024 年论文的"600 余"是最新可引用的官方口径；2026 年的实际数量应高于此值，但没有官方数字可引，任何更大的数都只能算推测。
§2.2 四层内容结构：项目、数据集、PSM/肽段、蛋白
官方文档把信息按四层组织，但真正好用的读法是"三层内容 + 一层存储隐喻"。
| 层 | 一条记录代表什么 | 关键字段/概念 | 常见误读 |
|---|---|---|---|
| 项目 project | 一次再分析任务，对应一个 JPST 项目 | JPST 号、来源 PXD、物种、仪器 | 以为一个项目等于一篇论文 |
| 数据集 dataset | 一组生物学重复，是筛选与统计的基本单位 | dataset id、样本元数据、PSM/肽段/蛋白统计 | 以为一个数据集等于一个样本 |
| PSM/肽段 | 一张谱图与一条肽段的匹配 | psm_id、sequence、charge、exp_mz、calc_mz、jpost_score | 以为肽段表已去重 |
| 蛋白 | 由肽段证据推断出的蛋白 | protein_id、accession、protein_type、pep_count、psm_count、uniq_pep_count | 以为一行等于一个基因 |
存储隐喻是另一条轴：一个样本重算后生成一个 Cube；所有 Cube 的并集叫 Globe；用户按元数据筛出的子集叫 Slice。Cube 是构建单位，Globe 是全库视图，Slice 是会话级的工作副本。Slice 存在浏览器的 WebStorage 里，不上传服务器，换浏览器要导出再导入。这一点常被误解为"云端保存了我的筛选"，实际并没有。
§2.3 字段字典：三张表撑起整个数据库
归档站点提供三张核心表，字段不多，但每一张都对应一个分析层次。
| 表 | 字段 | 说明 |
|---|---|---|
| 蛋白表 | protein_id、accession、symbol、name、protein_type、pep_count、psm_count、uniq_pep_count | protein_type 取 leading、same-set、sub-set、subsumable 四值之一 |
| PSM 表 | psm_id、sequence、accession、exp_mz、calc_mz、charge、jpost_score | 一行一张谱图匹配，同一肽段可有多行 |
| 修饰表 | psm_id、modification、site、position | 通过 psm_id 与 PSM 表连接，position 是肽段内位置而非蛋白位置 |
蛋白表的 psm_count 是"支持该蛋白的 PSM 总数"，uniq_pep_count 是"只映射到该蛋白的肽段数"。这两个数常被直接当成丰度用，但它们是谱图计数，受蛋白长度、酶切效率、仪器占空比影响，跨蛋白比较需要归一化。官方在 Slice 比较里确实做了按数据集总谱图数的归一化，但那是相对比较，不是绝对定量。
§2.4 一条 PSM 长什么样
下面是一条按官方字段名构造的示意记录，数值仅用于说明字段关系。
#-- 字段顺序取自 LSDB README；数值为示意，不代表任何真实谱图
psm_id sequence accession exp_mz calc_mz charge jpost_score
18492031 LSEPEDTVK P12345 487.2611 487.2598 2 0.913
读法是这样：实验测到的前体荷质比是 487.2611，理论计算值是 487.2598，相差 0.0013，电荷为 2，jpost_score 为 0.913。分数越高表示谱峰与序列的对应越好，但具体阈值要看数据集层面的 FDR 控制，不能拿单条分数直接判断真假。accession 指向 UniProt 记录，说明这条肽段被归到了哪个蛋白记录下；如果一条肽段能映射到多个蛋白，蛋白表里会出现多条共享关系，这正是 Peptide Sharing 视图要处理的问题。
修饰表通过 psm_id 挂在这条记录上。假设这条肽段的第 3 位丝氨酸带磷酸化，修饰表会多一行：psm_id 相同，modification 为 Phospho，site 为 S，position 为 3。position 是肽段内的序号，不是蛋白序列上的绝对位置；要换算成蛋白坐标，必须先用 sequence 在蛋白序列里定位。这是二次分析时最常见的一个错位。
§2.5 贯穿案例：Q10471 的蛋白页
用一个具体的蛋白页说明这些字段最终如何呈现。打开 https://globe.jpostdb.org/protein?id=Q10471，页面不是一张表，而是五个联动的面板：肽段比对、PTM 位点、P 位点连锁、UniProt 注释、肽段共享。
肽段比对面板把检出的肽段画在蛋白序列上，条带颜色从灰到红表示 PSM 数由低到高。PTM 位点面板在每个修饰位点上画竖条，竖条长度有两种口径：count 是实际计数，norm 是按包含该位点的谱图总数归一化后的长度。P 位点连锁面板显示同一条肽段上多个磷酸化位点的共现关系，这是官方论文明确称为"据我们所知独有"的功能。UniProt 注释面板把 UniProt 记录的修饰位点与单氨基酸变异叠加上去，方便判断检出位点是否落在已知注释上。肽段共享面板则把同一序列映射到多个 isoform 或多个蛋白记录，同色条带表示同一条肽段。
这个案例的价值在于它展示了 jPOSTdb 的"最小可用单元"：不是全库矩阵，而是一个蛋白的、跨数据集的证据汇总。它同时也暴露了边界：页面上的数字是聚合后的谱图计数，不含原始谱图，也不含样本级定量；想看某个数据集里的原始证据，还要回到数据集页。
§2.6 物种与样本构成：人占大头，模式生物是补充
官方 2019 年论文的说法需要分两半读：后端架构支持人、模型动物、植物、酵母与细菌；但当时数据库实际收录的再分析数据来自人、小鼠、大鼠与细菌。2024 年论文补充说，仓库提交中人类占一半以上，另有 300 多个物种被注册。
这两个数字不矛盾，但含义不同。"支持"是流程能力，“收录"是内容现状。把酵母、拟南芥写进 jPOSTdb 的覆盖物种并没有官方依据；它们可能出现在仓库的注册物种里，也可能被流程处理，但当前再分析集合的主体仍是人与常见模式动物。写论文时如果把"仓库注册物种数"当成"数据库覆盖物种数”，审稿人一问就会露馅。
样本类型同样如此。门户的元数据分面包括物种、样本类型、细胞系、器官、疾病、修饰、仪器，这些分面来自人工整理的受控词表，不是原始提交的自由文本。整理过的代价是覆盖不全，好处是筛选可靠。想做"所有肝组织"这类检索，用分面比用关键词稳。
§2.7 与同类资源的规格对比
| 资源 | 核心内容 | 规模量级 | 与 jPOSTdb 的关键差异 |
|---|---|---|---|
| PRIDE | 原始谱图 + 提交者结果 | 数万数据集 | 保存原始状态，不统一重算；覆盖面远大于 jPOSTdb |
| ProteomeXchange | 联盟级索引 | 跨仓库 | 只做发现与跳转，不产生再分析结果 |
| MassIVE | 原始谱图 + 部分再分析 | 数千数据集 | 再分析非全库统一，工具链与 jPOSTdb 不同 |
| PaxDb | 绝对丰度（ppm）整合 | 多物种 | 给的是丰度值，不是 PSM/位点证据 |
| Expression Atlas | 统一重算的转录组/蛋白组 | 数千实验 | 侧重表达矩阵与差异分析，蛋白位点粒度较粗 |
| jPOSTdb | 统一再分析的 PSM/肽段/蛋白/修饰 | 600 余数据集 | 唯一同时给染色体覆盖、P 位点连锁与跨蛋白共享肽的再分析层 |
这张表要说明的不是"谁更好"，而是"谁回答哪类问题"。丰度去哪找、原始谱图去哪找、位点共现去哪找，各有各的入口。jPOSTdb 的位置很窄：它是那少数几个把"再分析结果"本身当成产品来维护的库。
§3 分层一：项目与数据集，归档层怎么组织
§3.1 项目不等于数据集，数据集不等于样本
这是使用 jPOSTdb 时第一个必须建立的区分。官方在 2024 年论文里写得很明确：只有元数据内容一致的原始文件才归入同一个再分析项目；生物学重复，例如不同患者的样本，在同一项目内被登记为不同数据集；技术重复（同一样本的多次进样）则在 PSM 层面合并结果。
三层关系可以这样记：项目是"一次实验设计"，数据集是"一个可比较的生物学单位"，样本是"一次进样"。一个项目可以有多个数据集，一个数据集通常对应一个样本或一组技术重复。做差异表达时，比较的单位是数据集，不是项目；做元数据检索时，筛的也是数据集，不是项目。
这个区分直接影响统计。把同一项目的多个数据集当成独立样本，会低估组内方差；把技术重复当成生物学重复，会把仪器噪声当成生物信号。jPOSTdb 已经在构建时做了合并，使用者不需要再猜，但必须知道它合并的是哪一层。
§3.2 JPST 与 PXD：双轨标识符
jPOSTrepo 作为 ProteomeXchange 成员，会给符合条件的数据集发 PXD 号；同时它自己发 JPST 号。两者不是替代关系，而是"联盟通行证"与"本地户口"的关系。非质谱类数据，例如凝胶电泳或抗体类蛋白质组数据，拿不到 PXD，只能有 JPST。
再分析结果还有第三种标识：RPXD。ProteomeXchange 用 RPXD 前缀标识"对已有数据集的再分析结果"，jPOST 的再分析提交正是以 RPXD 形式进入 PX 索引的。于是在一条完整链条上，可能同时出现 JPST（原始项目）、PXD（联盟原始数据集）、RPXD（再分析结果）三个号。写方法学部分时把三者混用，会让读者无法判断你用的是原始数据还是再分析结果。
内部表还有 psm_id 与 protein_id。这两个是数据库自增/内部编号，不是全局标识，跨版本可能变化。可引用的稳定标识是 UniProt accession 加肽段序列，而不是内部 id。
§3.3 一个样本一个 Cube，全部 Cube 并成 Globe
Cube 是 jPOSTdb 的构建单位：一个样本的再分析结果封装成一个 Cube 数据库。所有 Cube 合并成 Globe，也就是门户里"全库"的概念。用户在 Globe 上按元数据筛选，选中的数据集组成 Slice。
这个设计的好处是增量更新。新增一个样本，只需要生成一个 Cube 再并入 Globe，不必重算全库。坏处是跨 Cube 的统计必须在查询层做，蛋白在不同 Cube 里的记录是独立的，同一 UniProt accession 会在多个 Cube 中重复出现。蛋白表的 530,455 行不能直接当成 53 万个不同蛋白，原因就在这里。
Slice 则是会话级对象。它不落库，存在浏览器里，因此没有服务端版本、没有共享链接、没有权限控制。官方明确说不同浏览器不共享 WebStorage，要复用必须导出再导入。把 Slice 当成"可引用数据集"是另一个常见误解。
§3.4 三道质量闸门
不是所有提交都会被再分析。官方列出三条原始数据质量检查：肽段-谱图匹配率应大于 10%；液相色谱图不应出现异常峰形；前体离子的质量偏差分布应接近高斯。三条都过，才进入重算。
这三条闸门解释了为什么数据库只有几百个数据集。匹配率低于 10% 通常意味着采样不足、样品降解或仪器状态异常；色谱峰形异常往往指向柱效问题或梯度问题；质量偏差分布偏离高斯，可能是校准失败或污染。任何一条不过，重算出来的结果都不可信，不如不做。
除了谱图质量，元数据也要过人工整理。样本来源、样品制备方法、质谱采集条件三项是必需信息；整理时使用 NCBI Taxonomy、Cell Line Ontology、BRENDA 组织本体、Human Disease Ontology、NCI Thesaurus 与 PSI-MS 受控词表。这套本体映射是 jPOSTdb 相比"直接重跑一遍"最容易被低估的工程。
§3.5 这一层给不了什么
归档层能给你项目、数据集、物种、仪器、疾病、细胞系这些检索维度，但给不了样本级的临床变量。它没有年龄、性别、分期、用药、随访这类字段，因为上游提交本身就不要求。想做临床关联，必须回到原始论文或受控访问队列，jPOSTdb 不是入口。
它也给不了完整的文件清单与校验和。归档结果表是分析产物，不是提交流水；要追某个数据集的原始文件，得用 JPST/PXD 号回仓库查。把 jPOSTdb 当成"带元数据的下载站"会反复碰壁。
§4 分层二：再分析层，PSM 如何变成蛋白与视图
§4.1 UniScore：把不同搜索引擎的分数折算到一把尺子
UniScore 是 jPOST 再分析协议的核心。官方描述很克制：它只用匹配上的 b 离子与 y 离子数量，以及这些离子所界定、可唯一确定的氨基酸标签数量，来评估谱峰与候选序列的对应程度。因为它不依赖某个搜索引擎的专有分数，所以可以把 Mascot、X!Tandem、MS-GF+ 等不同工具的结果放到同一尺度上比较，选最佳匹配肽段。
这个设计的聪明之处在于"少即是多"。绝大多数肽段分数依赖大量参数与训练数据，跨工具不可比；b/y 离子与氨基酸标签是谱图的物理证据，任何工具都能输出。代价是它不区分某些精细的强度模式，对低丰度、低信噪比的谱图不如专用打分器敏感。官方用基于 UniScore 的目标-诱饵策略控制 FDR，正是为了弥补这一点：分数只负责排序，真假由诱饵分布决定。
对使用者来说，UniScore 的实际意义是"跨数据集可比"，不是"更准"。同一个蛋白在两个数据集里的 jpost_score 不能直接比大小，但两个数据集的 FDR 口径是一致的，检出与否的判断可以放在一起看。
§4.2 蛋白推断：一条肽段归给谁
蛋白推断采用 Nesvizhskii 与 Aebersold 2005 年的规则：用鉴定到的肽段反推最可能的蛋白集合，并处理共享肽。结果被分成四类：leading protein 是证据最强的代表；same-set protein 是拥有完全相同肽段证据的蛋白；sub-set protein 的证据是 leading 的子集；subsumable protein 的肽段能被其他蛋白完全解释。
这四类的存在说明一件事：质谱不能唯一确定蛋白身份。一条肽段可能来自多个同源蛋白、多个 isoform，甚至多个基因产物。jPOSTdb 不掩盖这一点，而是把歧义显式建模，再在蛋白页用 Peptide Sharing 展示。做定量时如果直接把所有 protein_type 的行相加，会把同一份证据重复计数；正确做法是只用 leading protein，或者按需要合并 same-set。
§4.3 修饰：从位点计数到 P 位点连锁
修饰表记录每个 PSM 上的修饰类型、位点与肽段内位置。由此可以算出每个蛋白位点被检出的次数，也可以按包含该位点的谱图总数做归一化。官方在蛋白页把两种口径并列：count 是实际计数，norm 是归一化长度。前者适合看绝对证据量，后者适合跨位点比较。
真正独特的是 P 位点连锁（P-site linkage）：它显示同一条肽段上多个磷酸化位点的共现关系。常规数据库通常只记录"某位点被磷酸化"，不记录"这两个位点是否同时出现在同一条肽段上"。共现信息对理解激酶级联、位点开关、抗体设计都很关键，但它依赖肽段长度与酶切覆盖，不是每个位点都能看到。使用时要注意：看不到共现，不等于体内不共现，可能只是没有覆盖两个位点的肽段。
§4.4 肽段共享：isoform 与蛋白之间的证据重叠
Peptide Sharing 面板把同一氨基酸序列在不同 isoform、不同 UniProt 记录上的映射画成同色条带，条带上的数字是 PSM 数。它回答的是一个非常具体的问题：这条肽段到底能不能区分这两个蛋白？
不能区分的肽段叫共享肽。共享肽越多，蛋白推断的歧义越大，定量越不可靠。面板还显示肽段两端是否有胰蛋白酶切位点，未完全酶切的肽段会被标灰，提示它可能是漏切产物。这个细节对判断样本制备质量很有用，也常被忽略。
对做靶点验证的人，这个面板的实际用法是反向的：先找到能唯一区分目标 isoform 的肽段，再看它在哪些数据集里被检出。如果所有可用肽段都是共享的，说明这个 isoform 在该数据集中无法被质谱单独证实。§2.5 的案例里，Q10471 的共享肽面板展示的正是这种"同色条带跨多个蛋白"的情形。
§4.5 染色体视图到底长什么样
这是最容易被写错的部分，必须把官方定义与常见想象分开。
官方把数据集页与 Slice 页上的这个模块叫作 Chromosome Info。它是一张直方图：横轴是染色体，另加线粒体、质粒与 unplaced（无染色体注释）类别；每根柱子有两个系列，蓝色是检出的 leading protein 数，灰色是该染色体上注释的蛋白总数。计数单位是 UniProt 记录；人类数据集改用 neXtProt 记录。官方特别提醒，灰色柱不等于该染色体的编码基因数，因为一个基因可能对应多个记录，注释也会随版本变化。
它回答的问题是：这条染色体上，注释的蛋白里有多少在本次实验中被检出。配合旁边的 Protein Existence 饼图，就能看出缺口落在哪一类证据上。人类数据中，PE2 到 PE4 的蛋白被称为 missing protein，正是染色体中心人类蛋白质组计划（C-HPP）长期追踪的对象。jPOSTdb 的这张图，本质上是一个覆盖度仪表盘。
它不是什么，同样要说清：
| 常见想象 | 官方实际 |
|---|---|
| 把 PSM 按基因组坐标聚合 | 不聚合坐标，只按染色体统计蛋白个数 |
| 生成"基因位点→proteoform→肽段"层级 | 没有这个层级；proteoform 信息在蛋白页的 isoform 共享肽里 |
| 每条柱子是蛋白丰度 | 柱子是蛋白计数，不是表达量 |
| 灰色柱是编码基因数 | 是 UniProt/neXtProt 记录数，官方明确说不等于基因数 |
| 可以跨染色体比较表达强弱 | 不同染色体蛋白数、长度、可检测性不同，不能当表达量比 |
| 是一个独立的染色体浏览器 | 是数据集页/Slice 页上的一个模块，没有独立入口 |
因此，“染色体中心视图"这个说法如果指"按基因位点聚合 proteoform”，在 jPOSTdb 里是查无实据的。它真实存在的是"按染色体统计检出覆盖"，价值在于快速定位 missing protein 的分布，而不是重建 proteoform。把这一点写准，比把它写得宏大更重要。
§4.6 Protein Existence 与 missing protein
Protein Existence 饼图把检出蛋白按 UniProt 的存在证据分成五类：PE1 是蛋白水平有实验证据；PE2 是转录水平有证据；PE3 是同源推断；PE4 是预测；PE5 是不确定。人类数据用 neXtProt 的分类，其他物种用 UniProt。
这个饼图与染色体直方图是一对。直方图告诉你"哪条染色体缺口大"，饼图告诉你"缺口里有多少是本来就难检出的预测蛋白"。如果一条染色体上灰色柱很高、蓝色柱很低，但饼图里 PE1 占比很高，说明不是注释问题，而是实验覆盖不足；反之，如果缺口主要集中在 PE2 到 PE4，那是 missing protein 的经典议题，需要更深的组分、更长的梯度或更敏感的仪器。
使用时要避免一个推论：PE1 比例高不代表数据集质量好。PE1 是注释属性，不是实验质量指标；一个低质量数据集也可能因为只检出高丰度、注释充分的蛋白而显示高 PE1 比例。
§4.7 Slice 与比较：把筛选变成统计
Slice 是 Globe 的子集，按元数据筛选而来。选中若干数据集后，可以创建 Slice，并在 Slice 页看到与数据集页相同的染色体、蛋白存在、KEGG 映射视图。两个 Slice 可以比较，方法包括经验贝叶斯估计、Wilcoxon 秩和检验与均值倍数变化，定量基础是按数据集总谱图数归一化的谱图计数。
这里有两个限制常被忽略。第一，前两种统计方法要求每个 Slice 至少有两个数据集，单数据集无法估计组内方差。第二，富集分析只覆盖 KEGG 通路与 GO 三大类，且依赖 KO 注释，未注释蛋白会被排除。把 Slice 比较当成全能差异分析会失望；它更像一个快速探索工具，用来在下载数据前判断"这批数据集值不值得深入"。
§5 分层三：怎么把数据取出来
§5.1 三条取数路，各有各的适用面
| 路径 | 入口 | 适合什么 | 限制 |
|---|---|---|---|
| Web 交互 | globe.jpostdb.org | 探索、筛选、看蛋白页、做 Slice 比较 | 不能批量，结果需手动导出 |
| TSV 归档 | dbarchive.biosciencedbc.jp | 批量分析、建本地库 | 2021 年快照，落后于在线门户 |
| RDF/SPARQL | rdfportal.org/dataset/jpostdb | 语义查询、与其他本体连接 | 需 SPARQL 基础；许可为 CC BY 4.0，与 TSV 不同 |
没有公开 REST API。门户前端确实会调用内部接口，但官方没有把它们列为对外 API，也没有文档、版本号或速率承诺。把内部接口当生产依赖，随时可能断。稳定的编程入口只有文件与 SPARQL。
§5.2 Web 端：从筛选到导出
典型路径是：在 Search 页用分面筛物种、样本类型、细胞系、器官、疾病、修饰、仪器；勾选数据集加入 Slice；在 Slice 页查看统计与图表；在数据集页下载该数据集的 PSM 与蛋白表。蛋白页可以按 accession 直接访问，例如 https://globe.jpostdb.org/protein?id=Q10471。
Slice 的导出是浏览器本地行为，导出的文件只含数据集清单，不含分析结果。换机器后要重新导入清单，再让服务端重新取数。这一点在协作场景里很容易出错：同事以为你发过去的是数据，实际只是一张名单。
§5.3 TSV 归档：字段清楚，但版本很旧
归档提供三个压缩包：蛋白表 11.8 MB、PSM 表 64.6 MB、修饰表约 3 MB。文件日期是 2021-07-29，README 最后更新是 2024-06-12（只是补 DOI）。PSM 表 4,936,877 行，蛋白表 530,455 行，这两个数就是那一版快照的规模。
这意味着一个必须写进方法学的事实：如果你用归档 TSV 做分析，你分析的是 2021 年的 jPOSTdb，不是 2026 年的在线库。两者之间的增量没有以同样格式发布。要最新结果，只能走在线门户或 RDF 快照；要做可复现的批量分析，归档 TSV 反而是唯一稳定的选择，但必须标注快照日期。
§5.4 RDF 与 SPARQL：语义层的入口
jPOST 数据库的 RDF 版本发布在 DBCLS 的 RDF Portal（rdfportal.org），版本号 202509，2025-09-04 发布，SPARQL 端点为 https://rdfportal.org/primary/sparql。旧的 NBDC RDF Portal（integbio.jp/rdf）已于 2023 年 9 月底停止，旧链接会跳转到迁移公告，不能再用。
这个 RDF 数据集标注的许可是 CC BY 4.0，与 LSDB 归档数据的 CC0 不同，引用时要分开写。它的规模是 5.77 亿余三元组、1.67 亿余主体，适合做语义连接，不适合整库拉回本地。要做"蛋白—疾病—通路"的跨库连接，RDF 更合适；要读进 pandas，TSV 更直接。两者是同一数据库的两种投影，不是替代关系。
§5.5 可运行的最小取数流程
第一步，取归档表并校验。
#-- 下载三个归档包；先建目录，避免解压污染当前工作区
mkdir -p jpostdb_raw && cd jpostdb_raw
base="https://dbarchive.biosciencedbc.jp/data/jpostdb/LATEST"
curl -fLO "$base/jpostdb_protein.zip"
curl -fLO "$base/jpostdb_psm.zip"
curl -fLO "$base/jpostdb_psm_modification.zip"
#-- 记录快照日期，写进分析日志；归档文件不带版本号，日期就是版本
curl -sI "$base/jpostdb_protein.zip" | grep -i last-modified
#-- 解压并查看表头；字段分隔符为制表符
unzip -o jpostdb_protein.zip
head -n 2 jpostdb_protein.tsv
第二步，读蛋白表并做最基本的质量过滤。
#-- 依赖：pandas；文件来自上一步解压
import pandas as pd
prot = pd.read_csv("jpostdb_protein.tsv", sep="\t", dtype={"accession": "string"})
#-- 只保留 leading protein，避免共享肽导致的重复计数
lead = prot[prot["protein_type"] == "Leading protein"].copy()
#-- 至少两条唯一肽段，降低单肽段假阳性
lead = lead[lead["uniq_pep_count"] >= 2]
#-- 按蛋白覆盖的 PSM 数排序，看证据最强的蛋白
ranked = lead.sort_values("psm_count", ascending=False)
print(ranked[["accession", "symbol", "pep_count", "uniq_pep_count", "psm_count"]].head(10))
第三步，把 PSM 表按 accession 聚合，核对蛋白表的计数。
#-- PSM 表可能较大，分块读取；这里只演示聚合口径
import pandas as pd
counts = {}
for chunk in pd.read_csv("jpostdb_psm.tsv", sep="\t", chunksize=500000,
usecols=["accession", "psm_id"]):
g = chunk.groupby("accession")["psm_id"].nunique()
for acc, n in g.items():
counts[acc] = counts.get(acc, 0) + int(n)
#-- 与蛋白表的 psm_count 对不上是正常的：蛋白表按数据集汇总，
#-- PSM 表跨数据集，同一个 psm_id 在不同数据集里可能重复使用
print(len(counts), sum(counts.values()))
第四步，用 SPARQL 查某个蛋白在各数据集中的出现情况。
#-- 端点与图名以 RDF Portal 页面为准；先用 LIMIT 试查，避免全量扫描
curl -sG "https://rdfportal.org/primary/sparql" \
--data-urlencode "query=PREFIX jpost: <http://rdf.jpostdb.org/ontology/jpost.owl#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?sequence (COUNT(?psm) AS ?psm_count)
FROM <http://jpost.org/graph/database>
WHERE {
VALUES ?uniprot { <http://purl.uniprot.org/uniprot/Q10471> }
?protein jpost:hasDatabaseSequence ?uniprot ;
jpost:hasPeptideEvidence/jpost:hasPeptide ?peptide .
?peptide jpost:hasSequence [ rdf:value ?sequence ] ;
jpost:hasPsm ?psm .
} GROUP BY ?sequence ORDER BY DESC(?psm_count) LIMIT 20" \
-H "Accept: application/sparql-results+json"
这四段代码的共同点是都显式标注了数据版本。没有版本标注的 jPOSTdb 分析，过半年就无法复现，因为在线库在变、归档不更新、RDF 版本会更新。
§5.6 体积与读取策略
归档压缩包只有几十 MB，解压后的 PSM 表会膨胀到数 GB 量级，行数接近五百万。单机 pandas 可以处理，但要分块；直接全量读入再 merge，很容易把内存打满。推荐策略是先用蛋白表做筛选，拿到目标 accession 列表，再分块扫 PSM 表，只保留命中的行。这样内存占用与目标蛋白数成正比，而不是与全表成正比。
RDF 的体积更分散，按数据集拆文件，适合只取需要的子图。SPARQL 端点适合聚合查询，不适合把全库拉回本地；后者应该用文件。
§6 边界：它是 PRIDE 的派生视图，不是独立原始数据源
§6.0 一句话结论
jPOSTdb 的数据血缘是单向的：原始谱图在 jPOSTrepo 与 ProteomeXchange 其他仓库，jPOSTdb 只保存重算后的结果。它不是 PRIDE 的镜像，因为镜像会逐条复制原始内容；它是 PRIDE 生态之上的一层派生再分析视图，覆盖面是 PRIDE 的子集，价值来自统一的加工口径与几个特有视图。
这个定位有两个直接推论。第一，任何声称"jPOSTdb 有独立原始数据"的说法都不成立。第二，任何声称"jPOSTdb 只是 PRIDE 换皮"的说法也不成立，因为它确实做了 PRIDE 不做的事：统一重算、质量闸门、蛋白推断、修饰聚合、跨数据集比较。
§6.1 数据流向：从 RAW 到视图
#-- 数据血缘示意：箭头方向即数据流向，不是调用关系
提交实验室
└─ RAW / 峰值表 / 搜索结果
├─→ jPOSTrepo（JPST，PX 成员，发 PXD）
└─→ PRIDE / MassIVE / iProX（PXD）
│
▼
jPOST 再分析协议
（元数据整理 → 质量闸门 → 重搜索 → UniScore → FDR → 蛋白推断）
│
▼
Cube（一个样本一个库）→ Globe（全库并集）
│
├─→ 数据集页：Chromosome Info / Protein Existence / KEGG
├─→ 蛋白页：肽段比对 / PTM / P 位点连锁 / 共享肽
├─→ Slice：用户筛选子集 + 比较统计
├─→ TSV 归档（2021 快照）
└─→ RDF / SPARQL（202509 快照）
图里最关键的一步是"再分析协议"。它把上游的异构结果全部丢弃，只保留原始谱图与元数据，然后用自己的流程重新生成结果。所以 jPOSTdb 与上游的关系不是"复制"，而是"重做"。也正因为重做，它才能保证跨数据集的分数与 FDR 口径一致。
§6.2 三条证据，证明它是派生的
证据一，官方定义。 门户原文写的是"a database containing re-analysis results with unified criteria for proteome data from jPOSTrepo"，以及"raw data from jPOSTrepo and other ProteomeXchange (PX) repositories"。两个句子都明确 upstream 是仓库，不是实验。
证据二，产物回流 PX 的形态。 jPOST 的再分析结果以 RPXD 前缀进入 ProteomeXchange 索引，例如 RPXD018476 这类记录，提交者标为 jPOST reanalysis，联系邮箱是 reanalysis@jpostdb.org。RPXD 的定义就是"对已有数据集的再分析"，这在制度上锁死了它的派生身份。
证据三，覆盖面。 上游仓库有 2,876 个注册项目，数据库只有 600 余个数据集。如果它是镜像，两者数量应该接近；实际差了一个数量级，说明它做的是筛选后的再分析，不是全量复制。
三条证据指向同一个结论：jPOSTdb 是二阶资源。它的权威性来自流程，不来自原始观测。引用它时必须同时引用上游登录号，否则读者无法追到 RAW。
§6.3 与 PRIDE 的重叠矩阵
| 维度 | PRIDE | jPOSTdb | 关系 |
|---|---|---|---|
| 原始谱图 | 有 | 无 | 不重叠，jPOSTdb 必须回上游取 |
| 提交者结果 | 有 | 不采用 | jPOSTdb 丢弃原结果，自己重算 |
| 统一 FDR 口径 | 无 | 有 | jPOSTdb 增量 |
| 统一蛋白推断 | 无 | 有 | jPOSTdb 增量 |
| 跨数据集比较 | 需自建 | Slice + 统计 | jPOSTdb 增量 |
| 修饰位点共现 | 无 | P-site linkage | jPOSTdb 增量 |
| 跨蛋白共享肽视图 | 无 | Peptide Sharing | jPOSTdb 增量 |
| 染色体覆盖直方图 | 无 | Chromosome Info | jPOSTdb 增量，但只是计数 |
| 数据集数量 | 数万 | 600 余 | jPOSTdb 是小子集 |
| 物种覆盖 | 极广 | 以人/鼠/大鼠/细菌为主 | jPOSTdb 窄 |
这张表说明"重叠"发生在哪：同一个上游数据集可能同时出现在两边，但两边保存的东西不同。PRIDE 保存原始与提交者结果，jPOSTdb 保存重算结果。把两边当成"同一数据的两个入口"会重复下载；把它们当成"原料与成品"才是正确用法。
§6.4 为什么不是镜像：五个不可替代的加工步骤
第一，元数据重整。原始提交的样本描述是自由文本，jPOSTdb 用受控本体重新映射，才有了可用的分面筛选。镜像不会做这件事。
第二，质量闸门。匹配率、色谱峰形、质量偏差三道检查会淘汰不合格数据。镜像不会淘汰任何东西。
第三，重搜索与 UniScore。丢弃提交者结果，用统一流程重算，跨搜索引擎可比。镜像是原样保留。
第四，蛋白推断与歧义建模。leading/same-set/sub-set/subsumable 四类，加上共享肽视图，把"这条肽段属于谁"的歧义显式化。镜像通常只存提交者的蛋白列表。
第五，派生视图。染色体覆盖、蛋白存在证据、KEGG 映射、P 位点连锁、Slice 比较，都是在重算结果之上再加工出来的。镜像是平的，这些视图是立体的。
这五步里，任何一步都不是"复制"能完成的。所以"jPOSTdb 是 PRIDE 镜像"这个说法，只在"数据上游相同"这一点上部分成立，在"数据内容"上完全不成立。
§6.5 它的独立价值排序：染色体视图排不到第一
§2.5 的案例已经展示了这个库的日常用法：先看一个蛋白的证据，再判断要不要深入。如果只能保留一个功能，很多人会选染色体视图，因为"染色体中心"听起来最宏大。但按官方证据，排序应该是这样：
| 排名 | 功能 | 为什么 |
|---|---|---|
| 1 | P 位点连锁 + 全库 PTM 计数 | 官方论文明确称为"据我们所知独有"，PRIDE 与 PX 都没有 |
| 2 | 跨蛋白/isoform 的肽段共享视图 | 直接服务蛋白推断歧义，其他再分析库少见 |
| 3 | 统一协议带来的跨数据集可比性 | 这是整个库的存在理由，但属于"过程价值" |
| 4 | 染色体覆盖直方图 + Protein Existence | 对 C-HPP 有用，但只是计数，且依赖注释 |
| 5 | Slice 比较与富集 | 方便探索，统计方法常规，非独有 |
这个排序不是贬低染色体视图，而是把它放回正确位置：它是一个好的覆盖度仪表盘，不是 proteoform 重建引擎。把它吹成后者，反而会让真正需要 proteoform 的人误用。
§6.6 什么时候必须回上游
以下五种情况，jPOSTdb 给不了，必须去 jPOSTrepo 或 PRIDE：
- 要原始 RAW、mzML、MGF，做自己的搜索或 de novo 测序；
- 要 SDRF 等样本-文件对应表，做严格的实验设计还原；
- 要找的数据集不在 600 余个再分析集合里；
- 要提交者原始蛋白列表与 q 值，做方法学对比；
- 要完整的数据集版本历史与文件校验和。
反过来，以下情况留在 jPOSTdb 更省事：跨数据集看某个蛋白的检出、看磷酸化位点共现、看共享肽、按元数据快速筛一批可比数据、做染色体覆盖概览。
§6.7 库内落点：和谁最像，和谁最不像
| 库内资源 | 关系 | 使用建议 |
|---|---|---|
| PRIDE（rid 379） | 上游原料库，覆盖广 | 先在这里找原始数据，再来 jPOSTdb 看是否已重算 |
| ProteomeXchange（rid 389） | 联盟索引，跨仓库发现 | 用 PXD/JPST 号做跳转，不在索引层做分析 |
| UniProt（rid 37） | 蛋白注释与 accession 权威 | 把 jPOSTdb 的 accession 映射到序列、结构域、变异 |
| MassIVE（rid 1406） | 同类原始仓库，部分再分析 | 若 jPOSTdb 未覆盖，去 MassIVE 找同源数据 |
| PaxDb（rid 1395） | 绝对丰度整合 | 要 ppm 级丰度去 PaxDb，要位点证据留在这里 |
| Expression Atlas（rid 1367） | 统一重算的表达图谱 | 要表达矩阵与差异结果去 Atlas，要 PSM 级证据留在这里 |
| Human Protein Atlas（rid 404） | 抗体/组织表达图谱 | 用 HPA 做蛋白存在性交叉验证，不用它替代质谱证据 |
| METLIN（rid 1644） | 小分子二级谱库 | 代谢组与蛋白组的分工，不在一个层面 |
这张表是"落点"，不是"导航"。它的用法是：当你不确定该用哪个库时，先看你要的是原料、索引、注释、丰度还是位点证据，再对号入座。jPOSTdb 的位置固定在"统一重算后的位点与肽段证据"这一格。
§6.8 如果只剩 PRIDE，会缺什么
做一次思想实验：假设 jPOSTdb 明天消失，只留 PRIDE。你会失去三样东西。
第一，跨数据集的统一判断。你仍然能下载每个数据集的蛋白表，但每个表的 FDR 口径、搜索工具、蛋白推断规则都不同，合并前必须自己重跑一遍，成本以周计。
第二，位点共现与共享肽的现成视图。PRIDE 的 mzTab 里有修饰位点，但没有"同一条肽段上两个磷酸化是否共现"的聚合，也没有"这条肽段在哪些 isoform 间共享"的可视化。要自己从 PSM 表重建，工程量不小。
第三，染色体覆盖的快速概览。你可以自己把蛋白映射到染色体再画图，但 jPOSTdb 已经把 UniProt/neXtProt 注释、unplaced 处理、线粒体与质粒分类都做好了。
反过来说，如果只剩 jPOSTdb，你会失去原始谱图、完整覆盖面与提交者结果。两者缺一不可，但角色不同：PRIDE 是原料市场，jPOSTdb 是加工中心。把加工中心当原料市场，是这个库最常被误用的方式。
§7 常见误读、质量评估与局限
| 常见说法 | 实际情况 | 证据 |
|---|---|---|
| “jPOSTdb 有六千万条 PSM、四万份样本” | 官方未公布这两个数；2021 归档快照为 4,936,877 行 PSM，数据集为 600 余个 | LSDB README 行数；2024 年 NAR 论文 |
| “它是 PRIDE 的镜像” | 它丢弃提交者结果、用统一协议重算，覆盖面是 PRIDE 子集 | 门户定义；RPXD 再分析记录 |
| “染色体视图按基因位点聚合 proteoform” | 它是按染色体统计检出蛋白数与注释蛋白总数的直方图 | 官方 Help 的 Chromosome Info 段 |
| “灰色柱就是编码基因数” | 灰色柱是 UniProt/neXtProt 记录数，官方明确说不等于基因数 | 同上 |
| “有 REST API 可以直接批量拉” | 没有公开 REST API；编程入口是 TSV 归档与 RDF/SPARQL | Integbio 目录 API 栏为空；门户文档 |
| “数据是 CC BY 4.0” | 数据是 CC0 1.0；CC BY 4.0 是论文许可，RDF Portal 页面另标 CC BY 4.0 | LSDB README；NAR 2024 版权页 |
| “2021 年发布了 v2” | 没有对外版本号；2021-08-12 是归档站开放日，V2 属于 jPOST repository 记录 | LSDB 两条记录；RDF Portal |
| “归档 TSV 就是当前全库” | 归档是 2021-07-29 快照，在线门户与 RDF 202509 更新 | 归档文件日期；RDF 版本号 |
| “Slice 会保存在云端，可分享链接” | Slice 存浏览器 WebStorage，换浏览器需导出导入 | 官方 Help |
| “蛋白表一行就是一个基因” | 一行是一个数据集内的推断蛋白，同一 accession 可跨数据集重复 | 表结构与 Cube 设计 |
这张表里每一条都能在官方页面找到对应句子，没有一条是推测。写作时如果必须引用一个数字，优先引"600 余个数据集"与"注册项目数"，因为它们有明确出处；六千万、四万这类数没有出处，不该出现。
§7.0 先拆掉三个错误的评价框架
在评价 jPOSTdb 之前，必须先放弃三个框架，否则所有结论都会错位。
框架一：把它当原始数据库评价。 用"有多少 RAW、覆盖多少物种、文件多大"来衡量它，必然失望。它的产品是结果表，不是文件柜。正确的指标是"重算了多少数据集、口径是否统一、视图是否可用"。
框架二：把它当 PRIDE 镜像评价。 用"是否收录了某个 PRIDE 数据集"来判断它完整与否，也必然失望。它是筛选后的子集，不追求完整。正确的问法是"我要的数据集是否在再分析集合里，若不在，我是否愿意自己重跑"。
框架三：把它当 proteoform 坐标库评价。 用"能否按基因位点查异构体"来衡量染色体视图，同样错位。它给的是染色体级覆盖计数，不是位点级聚合。正确的问法是"我要的是覆盖概览，还是位点级 proteoform 重建"；后者应去 neXtProt 或专门的 proteoform 数据库。
三个框架拆掉之后，才能谈它真正做得好不好：重算流程是否透明、质量闸门是否合理、视图是否独特、取数是否方便、版本是否可复现。
§7.2 已知偏倚：五个方向
物种偏倚。 人类样本占提交量一半以上，再分析集合也以人为主。小鼠、大鼠、细菌是补充，植物与酵母在架构上支持但当前内容有限。做跨物种比较时，非人数据的选择面会窄很多。
元数据偏倚。 再分析的前提是元数据可整理。标注规范、使用受控词表、有数据描述论文（JPDM）的数据集更容易进入，反之则被挡在门外。这会让数据库偏向"作者愿意花时间写元数据"的实验室，而不是"数据本身最有价值"的研究。
质量偏倚。 三道闸门淘汰低匹配率、异常色谱、非高斯质量偏差的数据。好处是干净，坏处是低质量但生物学上罕见的数据集永远不会出现，做阴性对照或方法学比较时会缺样本。
仪器偏倚。 提交数据集的仪器构成跟随社区，Orbitrap 系占优，新型 TimsTOF、Astral 等平台的早期数据较少。跨仪器比较时要注意覆盖率差异。
发表偏倚。 被再分析的数据集往往已有论文，热门细胞系、常见疾病、知名实验室更容易被选中。罕见病、非模式生物、负结果研究的代表性不足。
§7.3 DAIMS 24 项检查表
DAIMS 是一套针对"数据是否可直接用于建模"的检查框架。下面按 24 项逐条评估 jPOSTdb，结论只代表本库的再分析层，不代表上游仓库。
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 宽格式 | ✅ | 蛋白表与 PSM 表是规整的长表，列名稳定，可直接读入 |
| 2 | 唯一标识 | ✅ | JPST/PXD/RPXD + 内部 psm_id/protein_id + UniProt accession，层级清晰 |
| 3 | 特殊字符 | ✅ | TSV 转义规范，肽段序列限定在 20 种氨基酸字母 |
| 4 | 重复行 | ⚠️ | 技术重复在 PSM 层合并，但同一 accession 跨数据集重复；共享肽导致蛋白层重复计数 |
| 5 | 缺失编码 | ⚠️ | 元数据缺失多为空白，无统一缺失码；修饰表只含有修饰的 PSM |
| 6 | 标签标识 | ✅ | UniScore + 目标-诱饵 FDR，蛋白类型四分类明确 |
| 7 | 罕见类分组 | ❌ | 无罕见病/罕见物种的专门分层，需自行按本体字段聚类 |
| 8 | 偏倚评估 | ⚠️ | 官方论文有物种与提交量统计，无逐数据集偏倚报告 |
| 9 | 数据字典 | ✅ | LSDB README 列全三张表字段；Help 页解释视图口径 |
| 10 | 信息性缺失解释 | ⚠️ | 未检出与未注释的区别可推断，但页面未逐条标注 |
| 11 | 设备记录 | ✅ | 仪器是元数据分面之一，可筛选 |
| 12 | 共线性 | ❌ | 无特征共线性审查，跨数据集合并后的共表达结构需自检 |
| 13 | 编码映射 | ✅ | UniProt accession、PSI-MOD/UniMod、NCBI Taxonomy、KEGG KO |
| 14 | 时间戳处理 | ✅ | 项目、数据集、归档、RDF 均有日期；但缺对外版本号 |
| 15 | 划分建议 | ❌ | 无官方 train/val/test 划分，也不适合直接当监督学习数据集 |
| 16 | 泄漏讨论 | ❌ | 跨数据集样本重叠风险存在，官方未系统讨论 |
| 17 | 标签分布 | ⚠️ | 物种、仪器、疾病可分面统计，但无现成分布报告 |
| 18 | 测量偏倚 | ⚠️ | 论文级描述存在，无逐数据集量化 |
| 19 | 外部验证建议 | ⚠️ | 可与 PRIDE、UniProt、neXtProt 交叉核对，但无官方验证套件 |
| 20 | 版本记录 | ⚠️ | 归档有日期，RDF 有快照号，数据库本体无版本号 |
| 21 | 预处理脚本 | ⚠️ | 协议有论文描述，未发布完整可执行流程；UniScore 细节需自行实现 |
| 22 | 合规要求 | ✅ | CC0 1.0，允许商用与再分发，无 DUA |
| 23 | 多模态对齐 | ⚠️ | 蛋白组与转录组、疾病本体可连接，但非样本级行对齐 |
| 24 | 去标识化 | ⚠️ | 无患者级记录；原始文件残留元数据的责任在提交方 |
DAIMS 评分：13 / 24。
评分解读： 得分集中在标识、字典、编码、合规这些"工程底座"，失分集中在划分、泄漏、共线性、罕见类分组这些"建模前治理"。这符合它的定位：它是一个加工良好、口径统一的再分析库，不是一个开箱即用的机器学习数据集。把它当后者用，缺口不在数据质量，而在任务定义。
§7.4 外部验证矩阵
| 验证对象 | 交叉来源 | 验证什么 | 预期结果 |
|---|---|---|---|
| 数据集是否存在 | jPOSTrepo / ProteomeXchange | JPST 与 PXD 的对应关系 | 每条 jPOSTdb 结果都能追到上游登录号 |
| 蛋白身份 | UniProt | accession 与序列、名称、物种 | 一致；版本差异可能导致名称变化 |
| 人类蛋白存在证据 | neXtProt | PE 分类与 missing protein 列表 | 分类口径一致，版本更新会影响计数 |
| 修饰位点 | UniProt 注释 | 已知磷酸化位点是否被检出 | 部分重合；实验证据可补充注释 |
| 再分析结果 | ProteomeXchange 的 RPXD 记录 | 是否作为再分析提交 | 存在对应 RPXD 记录 |
| 语义结构 | RDF Portal / jPOST ontology | 类与属性定义 | 与 TSV 字段可映射，但粒度更细 |
验证矩阵的用法不是"逐条打勾"，而是"知道哪一层可能出错"。蛋白身份与修饰位点最容易受版本影响，数据集对应关系最稳定，语义层最需要读文档。
§7.5 版本与快照风险
jPOSTdb 没有对外版本号，这是它作为数据源最大的工程缺陷。LSDB 里的 V2 属于 jPOST repository 记录（nbdc01594-000.V002），不属于 jPOSTdb（nbdc01594-02-000）；2021-08-12 是归档站开放日，不是 v2 发布日；RDF 的 202509 是 RDF 数据集版本，不是全库版本。三个"版本"混在一起，很容易在论文里写错。
§2.5 的案例里，蛋白页的聚合数字看起来稳定，但它背后的快照可能已经换了版本。更实际的风险是快照滞后。TSV 归档停在 2021-07-29，在线门户与 RDF 在更新，两者之间的差异没有 changelog。用归档做分析，必须在方法学里写明"2021-07-29 快照"；用在线门户做分析，必须写明检索日期。没有日期标注的 jPOSTdb 结果，半年后无法复现。
§7.6 伦理与合规
数据本身是 CC0，没有使用门槛。但"许可开放"不等于"没有风险"。原始文件来自人类样本时，残余的元数据可能包含机构、地区、稀有疾病等可重识别线索；jPOSTdb 不做额外去标识，责任在提交方。做聚合分析时，如果按极窄的疾病+地区+机构组合筛选，仍有可能定位到个别研究。
另一个合规点是再分发。CC0 允许再分发，但学术惯例要求保留出处与快照日期。把 jPOSTdb 的表重新打包成商业产品，法律上可行，信誉上需要标注来源；把上游原始文件一起打包，则要遵守上游仓库的条款，不能拿 jPOSTdb 的 CC0 覆盖一切。
§8 版本、生态与可持续性
§8.1 版本号真相：没有 v2，只有日期
先把四个常被当成"版本"的标记分开：
| 标记 | 实际含义 | 能不能当数据库版本 |
|---|---|---|
| 202509（RDF Portal） | RDF 数据集版本，2025-09-04 发布 | 可以，但只覆盖 RDF 投影 |
| 2021-08-12 | LSDB 归档站开放日 | 不能，是站点上线日 |
| 2018-03-26 | 数据库开始运行（LSDB 记录） | 不能，是运行起始日 |
| jp03（页面标记） | 前端构建标记 | 不能，与数据无关 |
所以"jPOSTdb v2 于 2021 年发布"这个说法不成立。LSDB 里确实有一个 V2，但查记录可知它属于 jPOST repository（nbdc01594-000.V002），不属于 jPOSTdb（nbdc01594-02-000）。2021 年发生的是归档站开放；数据库本身 2018 年 3 月已开始运行，2019 年论文首次系统描述。2024 年发生的是 DOI 分配与 NAR 更新论文发表，2025 年 9 月 RDF 202509 发布。没有一个官方事件叫"v2 发布"。
这个事实对引用很重要。写"jPOSTdb v2"会被审稿人要求给出处，而官方没有这个说法；写"jPOSTdb，2021-07-29 归档快照"或"jPOSTdb，RDF 202509 快照"才是可核对的。
§8.2 时间线：从资助计划到十周年
| 时间 | 事件 |
|---|---|
| 2011 | 日本政府启动数据库整合协调计划，推动生命科学数据共享 |
| 2015 | jPOST 加入该计划，开始建设蛋白质组数据库 |
| 2016-05 | jPOSTrepo 上线；同年 7 月加入 ProteomeXchange |
| 2017 | jPOSTrepo 论文发表于 Nucleic Acids Research |
| 2019 | jPOST 环境论文发表，jPOSTdb 首次系统描述 |
| 2018-03-26 | jPOSTdb 开始运行（LSDB 记录） |
| 2021-08-12 | LSDB 归档站开放，TSV 批量下载可用 |
| 2023-09 | NBDC RDF Portal 停止，RDF 迁往 DBCLS 的 rdfportal.org |
| 2025-09-04 | RDF 数据集 202509 发布，许可为 CC BY 4.0 |
| 2024-06-12 | 归档数据分配 DOI |
| 2024 末 | NAR 更新论文发表，给出 600 余数据集与 2,876 项目的新口径 |
| 2025-07 | 十周年研讨会消息发布 |
| 2026-06 | 门户发布 EdgeProt 开发伙伴招募 |
| 2026-08 | 门户仍有 JCompMS 工作坊消息，站点活跃 |
这条时间线说明两件事。第一，jPOSTdb 不是一次性项目，它跨了三个资助周期，有论文、有归档、有社区活动。第二，它的节奏很慢：从 2019 年首次描述到 2024 年更新论文，中间五年没有大的版本发布，只有归档与 RDF 的滚动更新。
§8.3 生态位：PX 联盟里的日本节点
ProteomeXchange 联盟的成员包括 PRIDE（欧洲）、MassIVE（美国）、jPOST（日本）、iProX（中国）等。jPOSTrepo 是日本节点，jPOSTdb 是这个节点上的再分析层。这个位置带来两个好处：一是能拿到联盟内的元数据与标识体系，二是能用 JPST/PXD 双轨号与上下游对接。
在国内生态里，jPOST 又与 NBDC、DBCLS、LSDB Archive、RDF Portal 相连。数据归档走 LSDB，语义发布走 RDF Portal，资助来自 JST 与 NBDC。这条链路决定了它的取数形态：既有传统的 zip 下载，也有语义网的 SPARQL，两者并行但不完全同步。
§8.4 为何能持续：三个支点
支点一，制度性的数据整合计划。 日本的数据库整合协调计划从 2011 年持续至今，jPOST 2015 年加入，经历了 FY2015–FY2017 与 FY2018–FY2023 两个阶段。这类计划给的是长期运营经费，不是一次性项目经费，这是它能活过十年的基础。
支点二，数据期刊解决元数据瓶颈。 再分析最大的成本不是算力，是元数据。日本蛋白质组学会创办了 Journal of Proteome Data and Methods（JPDM），专门发表数据描述论文，把"可重分析的元数据"变成可发表的成果。没有这个激励，作者不会花时间写清楚样本与文件对应关系，再分析就无从谈起。
支点三，社区与仪式。 十周年研讨会、JCompMS 工作坊、hackathon，这些活动不直接产生数据，但维持了一个使用者与贡献者社区。2026 年的 EdgeProt 招募说明它还在找新的方向与伙伴，而不是准备关站。
§8.5 风险信号：三个不能忽视的脆弱点
第一，归档滞后。 TSV 快照停在 2021 年，与在线库的差距越来越大。对于强调可复现的批量分析，这是一个硬伤；对于只想探索的人，影响不大。
第二，资助周期结束。 FY2018–FY2023 的计划已经结束，后续资助安排没有公开细节。门户仍在更新，但"能访问"不等于"有长期经费"。日本多个生物数据库近年经历过整合、迁移或停服，这个风险不能假装不存在。
第三，团队规模小。 从论文作者与维护记录看，核心团队人数有限，同时维护仓库、数据库、RDF、归档四条线。任何一条线出问题，恢复速度都会受影响。
这三个信号不构成"即将停服"的判断。核查日站点在线、新闻更新到 2026 年 8 月，没有任何停服公告。但它们足以支持一个使用建议：不要把 jPOSTdb 当成唯一副本，重要结果要落地保存并标注快照日期。
§8.6 关键论文与引用
| 论文 | 年份 | 贡献 |
|---|---|---|
| jPOSTrepo: an international standard data repository for proteomes | 2017 | 仓库的设计与 PX 成员身份 |
| The jPOST environment: an integrated proteomics data repository and database | 2019 | jPOSTdb 的首次系统描述，含视图与流程 |
| jPOST environment accelerates the reuse and reanalysis of public proteome mass spectrometry data | 2024 | UniScore、JPDM、600 余数据集的新口径 |
引用时优先用 2024 年论文，因为它给出最新规模与流程；引用具体视图（染色体、P 位点连锁、共享肽）时用 2019 年论文，因为那里有完整定义。两篇都是 CC BY 4.0，但这是论文许可，不是数据许可，别混。
§9 使用指引：三类角色怎么用
§9.1 三类角色的路径
| 角色 | 目标 | 建议路径 |
|---|---|---|
| 生物学研究者 | 看某个蛋白/位点在多数据集中的证据 | 直接进蛋白页，用 accession 查；再看肽段覆盖与 P 位点连锁 |
| 数据工程师 | 批量取数、建本地索引 | 下载 TSV 归档，按 accession 分块聚合；需要语义连接时走 SPARQL |
| 方法学研究者 | 比较再分析口径、做基准 | 读 2019/2024 论文，取同一数据集的上游结果做对照 |
三类角色的共同动作是"先确认数据集在不在"。研究者容易直接搜蛋白，工程师容易直接下全表，方法学者容易直接比分数；三种做法都可能白费功夫，如果目标数据集根本没被再分析。
§9.2 最小工作流：五步
第一步，定问题。是"某蛋白在哪些数据集被检出"，还是"某批数据集的差异表达"，还是"某条染色体的覆盖缺口"。问题不同，入口不同。
第二步，定数据集。用 Globe 分面筛选，或直接用 JPST/PXD 号查。确认数据集在再分析集合里，记下 dataset id 与快照日期。
第三步，取证据。蛋白层面看蛋白页；PSM 层面下 TSV；跨数据集比较做 Slice。不要在蛋白页上做统计，那里的数字是聚合展示，不是分析接口。
第四步，做校验。用 UniProt 核对 accession，用上游仓库核对数据集，用 neXtProt 核对人类 PE 分类。三步里至少做一步，否则版本差异会被当成生物信号。
第五步，写方法。注明数据来源、快照日期、蛋白类型过滤规则、FDR 口径、是否只取 leading protein。这五项写完，别人才能复现。
§9.3 质量核查清单
- 数据集是否在 600 余个再分析集合内，还是你假设它在？
- 你用的是 2021 归档、在线门户，还是 RDF 202509？三者不可混用。
- 蛋白计数是否只取了 leading protein？有没有重复计算共享肽？
- PSM 数是谱图计数还是肽段数？两者不能互换。
- 修饰位点的 position 是肽段内位置还是蛋白坐标？换算了吗？
- 染色体直方图你看的是检出数还是注释总数？灰色柱不是基因数。
- 人类蛋白的 PE 分类用的是 neXtProt 哪个版本？
- 引用时是否同时给了上游 JPST/PXD 号？
§9.4 引用格式建议
数据引用应包含：数据库名、访问日期、快照/版本标识、上游登录号、许可。示例：
#-- 建议的数据引用格式（非 BibTeX，便于直接放进方法学段落）
jPOSTdb (Japan ProteOme STandard DataBase), accessed 2026-10-29,
RDF snapshot 202509 / TSV archive 2021-07-29,
source dataset JPSTxxxxxx (PXDxxxxxx), CC0 1.0.
论文引用用 2024 年 NAR 文章；具体视图定义可加引 2019 年文章。不要把论文的 CC BY 4.0 写成数据许可，也不要把 RDF Portal 页面的 CC BY 4.0 当成全库许可。
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 性质 | 本页是面向 AI 工程与数据选型的中文说明页，不是官方文档译本 |
| 用途 | 帮助判断 jPOSTdb 是否适合作为再分析证据源，以及如何正确取数 |
| 不建议用途 | 不建议作为临床决策依据；不建议把染色体直方图当 proteoform 地图 |
| 事实来源 | jpostdb.org、globe.jpostdb.org、LSDB Archive README、NAR 2019/2024 论文、Integbio 目录 |
| 核验日期 | 2026-10-29 |
| 未覆盖内容 | 未逐数据集核验 PSM 数；未验证在线门户的实时总数；未测试所有 SPARQL 查询 |
| 许可提示 | 数据 CC0 1.0；论文与 RDF Portal 页面为 CC BY 4.0，三者不可混用 |
| 更新策略 | 若官方发布新版本或停服公告，以官方为准，本页不追更 |
附录 A 四层结构对照：预设与官方实际
| 维度 | 常见预设 | 官方实际 | 影响 |
|---|---|---|---|
| 第一层 | project（染色体中心 / PXD 映射） | 项目 project，对应 JPST，可带 PXD | 染色体不是层级，是视图；PXD 是外部号 |
| 第二层 | dataset | 数据集，按生物学重复划分 | 统计单位是数据集，不是项目 |
| 第三层 | PSM/peptide | PSM 与肽段，一行一张谱图匹配 | 同一肽段可多行，需去重 |
| 第四层 | protein（染色体中心视图） | 推断蛋白，四类 protein_type | 蛋白层有歧义，需选 leading |
| 横切一 | 无 | Cube → Globe → Slice | 存储与筛选的实际结构 |
| 横切二 | REST + TSV | Web + TSV + RDF/SPARQL | 无公开 REST，批量靠文件 |
| 主键 | jPOST ID + PXD | JPST + PXD + RPXD + 内部 id + UniProt | 五种号各有用途，不能互替 |
这张表是全篇的压缩版。如果只记一件事：jPOSTdb 的结构是"内容四层 + 存储三隐喻 + 标识五件套"，不是一个四层金字塔。
附录 B 标识符与主键速查
| 标识符 | 形态 | 标识什么 | 稳定性 | 用法 |
|---|---|---|---|---|
| JPST | JPST + 6 位数字 | jPOSTrepo 项目 | 稳定 | 追原始项目、找文件 |
| PXD | PXD + 6 位数字 | ProteomeXchange 数据集 | 稳定 | 跨仓库检索、引用 |
| RPXD | RPXD + 数字 | 再分析结果 | 稳定 | 证明结果是派生 |
| psm_id | 内部数字 | 一条 PSM | 版本间可能变 | 表内连接，不作外部引用 |
| protein_id | 内部数字 | 一个数据集内的推断蛋白 | 版本间可能变 | 表内连接 |
| UniProt accession | 字母数字 | 蛋白序列记录 | 稳定但有合并/撤销 | 跨库映射、去重 |
| dataset id | 门户内部 | 一个数据集 | 随门户 | Web 浏览，不作论文主键 |
引用优先级：论文里写 JPST/PXD，分析里用 UniProt accession，表内连接用内部 id。把内部 id 写进论文，等于把数据库实现细节当科学标识，既不稳也没必要。
附录 C 术语表
| 术语 | 解释 |
|---|---|
| PSM | 肽段-谱图匹配，一张二级谱与一条肽段序列的匹配记录 |
| 肽段 peptide | 酶切后的短氨基酸序列，是质谱直接观测的对象 |
| 蛋白推断 | 由肽段证据反推蛋白集合的过程，存在共享肽歧义 |
| leading protein | 一组共享肽证据中最具代表性的蛋白 |
| same-set protein | 与 leading protein 拥有完全相同肽段证据的蛋白 |
| sub-set protein | 肽段证据是 leading 子集的蛋白 |
| subsumable protein | 肽段能被其他蛋白完全解释的蛋白 |
| proteoform | 同一基因产物在剪接、修饰、切割上的具体形式 |
| PTM | 翻译后修饰，如磷酸化、乙酰化、糖基化 |
| P-site linkage | 同一条肽段上多个磷酸化位点的共现关系 |
| UniScore | jPOST 的谱图-序列对应分数，基于 b/y 离子与唯一氨基酸标签 |
| FDR | 错误发现率，用目标-诱饵策略估计 |
| 目标-诱饵 | 在真实序列外加入诱饵序列，用命中比例估计假阳性 |
| 谱图计数 | 用支持某蛋白的谱图数作为相对丰度 proxy |
| Cube | 一个样本的再分析结果库 |
| Globe | 全部 Cube 的并集，即全库视图 |
| Slice | 用户按元数据筛选出的数据集子集，存浏览器本地 |
| neXtProt | 人类蛋白知识库，提供 PE 分类与 missing protein 列表 |
| PE1–PE5 | UniProt/neXtProt 的蛋白存在证据等级 |
| missing protein | 人类中 PE2–PE4、尚无蛋白水平证据的蛋白 |
| C-HPP | 染色体中心人类蛋白质组计划 |
| RPXD | ProteomeXchange 中对再分析结果的标识前缀 |
| JPDM | Journal of Proteome Data and Methods，数据描述期刊 |
| LSDB Archive | 日本生命科学数据库归档平台，提供 jPOSTdb 的 TSV 下载 |
附录 D 操作常见问题
Q1：为什么我在门户搜不到某个 PRIDE 数据集？
因为它不在 600 余个再分析集合里。jPOSTdb 不是全量镜像，只收录通过元数据整理与质量闸门的数据集。先用 PXD 号在 jPOSTrepo 或 PRIDE 确认原始数据存在，再判断是否值得自己重跑。
Q2：蛋白页上的 psm_count 能当丰度用吗？
只能当相对证据量，且要归一化。谱图计数受蛋白长度、酶切效率、仪器占空比影响，跨蛋白直接比会系统性高估长蛋白、高丰度蛋白。
Q3：为什么同一 accession 在蛋白表里出现多次？
因为一个 Cube 对应一个样本，同一蛋白在不同数据集里各有记录。蛋白表的行是"数据集内蛋白记录"，不是"全局蛋白"。去重按 accession，计数按数据集。
Q4：染色体直方图的灰色柱为什么对不上基因数？
因为计数单位是 UniProt/neXtProt 记录，一个基因可能对应多个记录，注释版本也会变。官方明确说灰色柱不等于编码基因数。
Q5：P 位点连锁看不到共现，是不是说明两个位点不同时磷酸化？
不能这么推。看不到可能只是因为没有一个肽段同时覆盖两个位点。共现视图依赖酶切覆盖，覆盖不到就无观测，不等于生物学上不共现。
Q6：Slice 能分享给同事吗？
能导出清单再导入，但清单不含分析结果，对方需要重新取数。Slice 存在浏览器本地，不上传服务器。
Q7：有 Python 客户端吗？
官方没有。批量分析走 TSV 归档，语义查询走 SPARQL。社区可能有非官方封装，但不应作为生产依赖。
Q8：为什么归档表和在线门户的数字对不上？
归档是 2021-07-29 快照，在线库持续更新。两者不是同一版本，数字对不上是正常的。分析方法里必须写明用的是哪一个。
Q9：能商用吗？
数据是 CC0 1.0，可以商用与再分发。但要注意上游原始文件的条款、论文许可与数据许可的区别，以及再分发时的出处标注。
Q10：这个库会停服吗？
核查日没有停服公告，站点活跃到 2026 年 8 月。但资助周期结束、归档滞后、团队规模小是真实风险。重要结果请本地留存并标注快照日期。
附录 E 许可与再分发注意事项
| 对象 | 许可 | 能不能再分发 | 注意 |
|---|---|---|---|
| jPOSTdb 数据表 | CC0 1.0 | 可以，无需授权 | 建议标注来源与快照日期 |
| jPOSTrepo 原始文件 | CC0（官方 FAQ） | 可以 | 原始文件可能含残余元数据，责任在提交方 |
| RDF Portal 数据集页 | 标注 CC BY 4.0 | 可以，需署名 | 与数据本身的 CC0 不一致，引用时说明 |
| NAR 2019/2024 论文 | CC BY 4.0 | 可以，需署名 | 论文许可不覆盖数据 |
| UniProt 注释 | CC BY 4.0 | 可以，需署名 | 派生注释需遵守 UniProt 条款 |
| neXtProt 注释 | 学术使用条款 | 视条款 | 商用前查最新条款 |
再分发的三条实操建议。第一，永远把"数据许可"与"论文许可"分开写，前者是 CC0，后者是 CC BY 4.0。第二，再分发时保留快照日期与上游 JPST/PXD 号，这既是学术规范，也是别人复核的唯一线索。第三，如果重新打包成衍生数据库，明确标注"基于 jPOSTdb 2021-07-29 快照"或"基于 RDF 202509 快照"，不要用"最新版"这种无法核对的表述。
最后一条边界：CC0 放弃的是著作权层面的权利，不免除数据保护、隐私、出口管制等其他法律义务。人类样本的残余元数据、罕见病的小样本组合、特定机构的可识别信息，仍可能构成风险。许可是使用的前提，不是伦理的替代。
编辑说明
核验时间：2026-10-29。核验方式：jpostdb.org 与 globe.jpostdb.org 门户、LSDB Archive README、Integbio 目录、NAR 2019 与 2024 论文、ProteomeXchange RPXD 记录交叉比对。未覆盖内容：未逐数据集核对 PSM 计数，未验证门户实时数据集总数，未执行全部 SPARQL 查询。与常见预设不符之处，一律以官方页面为准。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- pfam — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释 / 生物医学文献
- varsite — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- eggnog — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- sequence-ontology — 共享标签：基因组学与多组学 / 变异与注释 / 生物医学文献
- imgt — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- vdjdb — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- dbcan-hgm — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- proteingym — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- interpro — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
- cath — 共享标签：基因组学与多组学 / 蛋白质组学 / 变异与注释
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
