信息速览
INFOBOX
| 项 | 值 |
|---|---|
| 全名 | Europe PMC（Europe PubMed Central） |
| 维护方 | EMBL-EBI，与 PubMed Central 合作，国际资助方联合体支持 |
| 服务版本 | REST 6.9（2026-10-23 响应头 version 字段） |
| 总记录数 | 49,118,306（search?query=* 的 hitCount） |
| MEDLINE 来源 | 41,253,787 |
| 专利 | 4,229,296 |
| 预印本 | 1,268,930（34 个预印本服务器） |
| Agricola | 1,026,549 |
| 有全文 | 12,439,494 |
| 开放获取 | 8,352,804 |
| 有文本挖掘标注 | 37,836,422 条文献 → 13 亿条标注 / 42 类概念 |
| 可检索字段 | 143 个（/fields 端点） |
| 许可 | 逐篇不同（cc by / cc by-nc / cc by-nc-nd / cc by-nd / cc0） |
| 最大的坑 | hitCount 是「记录数」不是「论文数」——预印本与期刊版是两条记录、专利是第三条，同一项研究可重复计数 |
§0 本条目怎么来的、不做什么
我们是谁：千方病案医学编辑部，为中文医学 AI 社区整理可训练数据集的结构化说明。
本条目怎么来的：全部数字取自 Europe PMC 官方 REST API 的实时返回（2026-10-23 15:15–15:20 UTC），查询语句与返回值原文列在附录 A 与附录 B，可逐条复现。总量 49,118,306 来自 search?query=*&pageSize=1 的 hitCount；分源数字来自 SRC:* 前缀查询；覆盖量来自 HAS_* 布尔字段查询。字段字典来自 /fields 端点（143 个可检索项），记录结构来自一条 resultType=core 的完整响应。官方定性描述（34 个预印本服务器、40 余个生物数据库、13 亿条标注 / 42 类概念、122,173 项资助 / 36 家资助方）取自 europepmc.org/About 原文。
我们不做什么：本条目不做任何 benchmark，不评价检索质量或标注准确率，不下载全文语料。§7 的口径核对只解释「为什么官网首页写的数字和 API 返回的数字不一样」，不判定谁对谁错。
已知局限：
- 所有数字是查询时刻的快照。Europe PMC 每日更新，
hitCount次日即变（2026-10-22 首次观测为 49,111,254，24 小时后为 49,118,306，日增约 7,052 条）。 - 我们没有抽样核对标注质量。13 亿条标注的精度是官方声明，我们未测。
- 全文语料我们没有下载。FTP 目录在程序化访问时返回 Cloudflare 挑战页（403），只能从文档描述其结构。
§1 数据集概览
§1.0 📌 30 秒速览
Europe PMC 做的事情，一句话：把生命科学领域散落在期刊、预印本服务器、专利局、农业数据库里的文献汇成一个可检索、可反查、可机器读取的池子，并把每篇文献挂到它背后的数据上。
规模（2026-10-23 实测）：
| 指标 | 数值 | 占总量 |
|---|---|---|
| 总记录 | 49,118,306 | 100% |
MEDLINE（SRC:MED） |
41,253,787 | 84.0% |
专利（SRC:PAT） |
4,229,296 | 8.6% |
预印本（SRC:PPR） |
1,268,930 | 2.6% |
Agricola（SRC:AGR） |
1,026,549 | 2.1% |
有全文（HAS_FT:Y） |
12,439,494 | 25.3% |
开放获取（OPEN_ACCESS:Y） |
8,352,804 | 17.0% |
有摘要（HAS_ABSTRACT:Y） |
34,443,646 | 70.1% |
有文本挖掘标注（HAS_TM:Y） |
37,836,422 | 77.0% |
三个必须先知道的形状问题：
- 49,118,306 是「记录数」，不是「论文数」。 一篇发表在 bioRxiv 后又登上期刊的论文，会在库里留下至少两条记录：一条
SRC:PPR（预印本）、一条SRC:MED（期刊版）。官方用HAS_PUBLISHED_VERSION:Y标出这种配对——共 452,629 条。做去重训练集时，这一层必须显式处理，否则同一项研究会同时出现在 train 和 test 里。 - 只有 17.0% 是开放获取，这 17% 里许可还不统一。 有许可标记的 9,792,835 条中，
cc by6,571,562 条（67.1%）、cc by-nc-nd1,630,225 条（16.6%）、cc by-nc1,148,570 条（11.7%）、cc069,447 条（0.7%）、cc by-nd23,093 条（0.2%）。「能读」和「能拿来训练」是两件事——NC 与 ND 条款对商用模型和派生作品的限制，必须在上游筛掉。 - 77.0% 的文献带文本挖掘标注，但标注不是金标准。 官方称 13 亿条标注覆盖 42 类概念，产出方是多个独立挖掘团队（
annotation.provider字段）。同一段文本被不同 provider 标出不同概念是常态。把它当弱监督信号可以，当 ground truth 不行。
如果你要做文献检索增强、要构造生物医学 NER / RE 训练集、要按资助方溯源、要找某篇论文背后的数据集，Europe PMC 是公开渠道里覆盖最全的一个；如果你只要纯净的开放全文语料做预训练，PMC OA Subset（本站 #360）比它更合适——那一个是按许可筛过的确定子集，这一个是「什么都有、许可逐篇不同」的聚合池。
§1.1 技术摘要
| 维度 | 值 |
|---|---|
| 总记录 | 49,118,306 |
| 有全文 | 12,439,494（25.3%） |
| 开放获取 | 8,352,804（17.0%） |
| 有摘要 | 34,443,646（70.1%） |
| 预印本 | 1,268,930（34 个服务器） |
| 专利 | 4,229,296 |
| 文本挖掘标注 | 13 亿条 / 42 类概念 / 覆盖 3,783 万条文献 |
| 生物数据库交叉链接 | 40 余个 |
| 可检索字段 | 143 |
| 资助记录 | 122,173 项 / 36 家资助方（+ 18,980 项 COVID-19 专项） |
| 接口 | REST（JSON / XML / Dublin Core）+ FTP 批量 + OAI |
| 服务版本 | 6.9 |
§1.2 战略价值
Europe PMC 在中文医学 AI 语境里的位置，不是「又一个文献库」，而是三条别处买不到的通路：
通路一：按资助方反查。 GRANT_AGENCY 是一个可检索字段，我们实测：Wellcome Trust 219,369 篇、NIH 358,115 篇、European Commission 45,346 篇、中国国家自然科学基金 1,150,423 篇、UKRI 6,693 篇。这意味着可以构造出「某个基金资助的全部产出」这样的切片——用于研究影响力评估、用于构造「同资助方」的领域内负样本、用于追踪某个机构的研究转向。PubMed 没有这个入口。
通路二：文献 → 数据的硬链接。 官方称与 40 余个生物数据库建立交叉链接，实测 HAS_DATA:Y 8,045,183 条（16.4%）、HAS_XREFS:Y 1,035,850 条。细分为 HAS_UNIPROT 179,857、HAS_PDB 43,770、HAS_OMIM 146,408、HAS_CHEBI 128,453、HAS_CHEMBL 86,101、HAS_INTERPRO 99,162、HAS_INTACT 24,090、HAS_PRIDE 20,058、HAS_EMBL 495,791。这是「论文说了什么 → 数据在哪」这条链上唯一免费的自动化入口，对构造「论文-数据集配对」任务至关重要。
通路三：预印本与期刊版的对齐。 HAS_PUBLISHED_VERSION:Y 452,629 条、HAS_PREPRINT:Y 442,403 条。这两个字段让我们可以精确构造「同一研究在预印本阶段与发表阶段表述差异」的数据集——这是研究科学传播漂移（结论是否被弱化、样本量是否变化、显著性是否翻转）的天然素材，而且只有聚合层才有，任何单一来源都拿不到。
§1.3 同类资源横向对比
| 维度 | Europe PMC | PubMed / MEDLINE | PMC OA Subset | S2ORC | OpenAlex |
|---|---|---|---|---|---|
| 总量 | 4,911 万记录 | ~3,800 万（仅 MEDLINE） | ~450 万篇全文 | ~1,200 万全文 | ~2.5 亿作品 |
| 含预印本 | ✅ 127 万（34 服务器） | ❌ | 部分 | 部分 | ✅ |
| 含专利 | ✅ 423 万 | ❌ | ❌ | ❌ | 部分 |
| 全文可检索 | ✅ 1,244 万 | ❌ 仅摘要 | ✅ | ✅ | ❌ |
| 资助方反查 | ✅ 143 字段之一 | ❌ | ❌ | ❌ | 部分 |
| 文本挖掘标注 | ✅ 13 亿条 | 仅 PubTator 子集 | ❌ | ❌ | ❌ |
| 生物数据库交叉链接 | ✅ 40 余个 | 部分 | ❌ | ❌ | 部分 |
| 开放许可逐篇标注 | ✅ license 字段 |
❌ | ✅（子集已筛） | 部分 | 部分 |
| 中文界面对接 | ❌ | ❌ | ❌ | ❌ | ❌ |
这张表要看懂的是：Europe PMC 与 PMC OA Subset 不是「大和小」的关系，是**「聚合池」与「已筛子集」的关系。做预训练要后者，做检索增强与元数据研究要前者。与 OpenAlex 的差别在于：OpenAlex 量级大一个数量级（2.5 亿），但没有全文、没有标注、没有生物数据库交叉链接**——它擅长的是引文网络与机构消歧，不是内容。
§1.4 版本时间轴
| 时间 | 事件 |
|---|---|
| 2006 | UKPMC 上线，由 Wellcome Trust 资助，作为 PubMed Central 的英国镜像 |
| 2011 | 更名 Europe PMC，资助方扩展为欧洲多国联合体 |
| 2013 | 迁至 EMBL-EBI 托管 |
| 2018-04 | 接入 Unpaywall，全文不可得时提供合法免费副本链接 |
| 2019 | 引入预印本收录（bioRxiv / medRxiv 起步） |
| 2020 | COVID-19 预印本全文计划；LitCovid 联动；「Europe PMC in 2020」综述（PMID 33180112） |
| 2021 | Annotations API 开放，SciLite 标注体系对外 |
| 2023 | 预印本服务器扩至 30+；Grants API 覆盖 36 家资助方 |
| 2024 | Smart Citation、预印本-期刊版自动配对 |
| 2026-10 | REST 6.9；4,911 万记录 / 1,244 万全文 / 13 亿标注（本条目实测） |
版本机制的关键点：Europe PMC 没有「release」概念——不像 Rfam 有 15.1、GENCODE 有 v47。它是日更流水：hitCount 每天都在变，firstIndexDate 字段记录每条进入库的时间。这意味着任何写进论文的数字都必须带抓取日期，否则三个月后无法复现。
§1.5 典型应用场景
| 场景 | 用什么 | 关键字段 |
|---|---|---|
| 生物医学 NER / RE 训练集构造 | Annotations API | annotation.type / exact / prefix / postfix |
| 检索增强生成（RAG）语料 | 全文 FTP（PMC 子集） | fullTextIdList → PMC XML |
| 资助方产出分析 | GRANT_AGENCY 查询 |
grantsList / grantId |
| 论文-数据集配对 | HAS_DATA + HAS_XREFS |
dataLinksTagsList / dbCrossReferenceList |
| 预印本-发表版差异研究 | HAS_PUBLISHED_VERSION |
commentCorrectionList 中的 preprint 关系 |
| 开放许可合规筛查 | license 字段 |
cc by / cc by-nc / cc by-nc-nd |
| 临床试验证据合成 | PUB_TYPE:"clinical trial" + SRC:CTX |
pubTypeList / subsetList |
| 机构/作者消歧 | ORCID + ROR 集成 | authorIdList（ORCID 类型）/ affiliation |
§2 文献聚合层的科学前提
§2.1 「一条记录」到底是什么
Europe PMC 的主键不是 DOI、不是 PMID，而是 source + id 二元组。这是整个数据模型的地基，也是最容易被误用的地方。
八个 source 代码，覆盖范围完全不同：
source |
含义 | 实测条数 | 主键形态 | 有全文 |
|---|---|---|---|---|
MED |
MEDLINE 书目记录 | 41,253,787 | PMID（纯数字） | 少数（需 PMC 侧） |
PMC |
PubMed Central 全文 | 1,013,126 | PMCID（数字，不带 PMC 前缀） |
✅ |
PPR |
预印本 | 1,268,930 | PPR 编号 | 部分 |
PAT |
专利 | 4,229,296 | 专利号 | ❌ |
AGR |
Agricola 农业文献 | 1,026,549 | AGR 编号 | ❌ |
CTX |
引用记录（Citation Exchange） | 3,922 | CTX 编号 | ❌ |
ETH |
伦理文献 | 176,799 | ETH 编号 | ❌ |
HIR |
历史文献 | 2,868 | HIR 编号 | ❌ |
这里有一个高频误判：很多人以为 SRC:PMC 是「PMC 全文的条数」，看到 1,013,126 就以为 PMC 只有一百万篇。实际是——大多数有全文的 MEDLINE 记录，其 source 仍然是 MED，只是 pmcid 字段有值、inEPMC 为 Y。真正以 SRC:PMC 为主记录的，是那些只在 PMC 出现、不在 MEDLINE 索引的条目（如部分会议论文、非英文期刊）。判「有没有全文」要查 HAS_FT:Y（12,439,494）或 inEPMC，不是查 SRC:PMC。
source 与 id 的组合决定了怎么取全文：
MED+ PMID → 走https://www.ebi.ac.uk/europepmc/webservices/rest/MED/{pmid}/fullTextXML，若无全文返回 404PMC+ 数字 → 走https://www.ebi.ac.uk/europepmc/webservices/rest/PMC/{pmcid}/fullTextXMLPPR+ PPR号 → 走同一端点，但只有部分预印本有 XML
§2.2 为什么全文可检索是分水岭
Europe PMC 与 PubMed 最大的功能差别，不是收录量，是**「摘要可检索」与「全文可检索」**。
PubMed 的检索范围基本是标题、摘要、MeSH、作者、期刊。Europe PMC 把范围扩到了全文正文——官方原文是「searches both abstracts and full text of over articles」，并可限定到具体章节：METHODS、RESULTS、INTRO、DISCUSS、CONCL、FIG、TABLE、SUPPL、BACK、APPENDIX、CASE、OTHER。
这个能力的实际意义，用一个例子说明：想找「用了 Cox 比例风险模型且报告了 hazard ratio 的队列研究」，在 PubMed 里只能靠 MeSH 词加摘要里的关键词，召回率低；在 Europe PMC 里可以直接写 METHODS:"Cox proportional hazards" AND RESULTS:"hazard ratio"，命中率完全不同。
代价是全文可检索范围只有 1,244 万条（HAS_FT:Y），占总量 25.3%。剩下 74.7% 的记录，仍然只有摘要或只有书目——所以检索策略必须随文献的可得性分层，不能假设「库里有的都能全文搜」。
§2.3 三层可得性：摘要 / 全文 / 开放获取
这三个概念在 Europe PMC 里是三个独立布尔字段，互不蕴含，必须分开理解：
| 层级 | 字段 | 实测条数 | 占比 | 能做什么 |
|---|---|---|---|---|
| 有摘要 | HAS_ABSTRACT:Y |
34,443,646 | 70.1% | 阅读理解、摘要级 NLP |
| 有全文 | HAS_FT:Y |
12,439,494 | 25.3% | 全文检索、结构化抽取、章节标注 |
| 开放获取 | OPEN_ACCESS:Y |
8,352,804 | 17.0% | 站内阅读 + 可能可再分发 |
| 有 PDF | HAS_PDF:Y |
12,188,224 | 24.8% | 版面分析、图表抽取 |
| 有补充材料 | HAS_SUPPL:Y |
3,875,038 | 7.9% | 附表、补充图 |
四层之间的差值不是随机的，是有系统的：
- 有全文但没 PDF：12,439,494 − 12,188,224 = 251,270 条。这些是仅有 XML/HTML 没有 PDF 版本的（多为纯电子刊、部分预印本）。
- 有全文但不开放：12,439,494 − 8,352,804 = 4,086,690 条。这些能在 Europe PMC 站内读（或跳转到出版商），但不能批量下载、不能用于训练。这是最大的陷阱区。
- 开放获取里有许可的：
LICENSE:*命中 9,792,835，比OPEN_ACCESS:Y的 8,352,804 还多 144 万。原因是部分文献有许可标记但 Europe PMC 侧没有全文（如仅链接到出版商 OA 页面）。不能反过来推「有许可 = 能下载」。
§2.4 文本挖掘标注的层级
标注体系（SciLite + Annotations API）在数据模型上有四个层次，从上到下：
- 概念类型（
annotation.type）：官方称 42 类。从实测响应看，常见的有COVoc（COVID-19 词表）、Gene_Proteins、Chemicals、Diseases、Organisms、Cell_Lines、Accession_Numbers。 - 标注提供方（
annotation.provider）：如「HES-SO / SIB Text Mining for Elixir」。这是精度差异的主要来源——不同 provider 用不同模型、不同词典、不同阈值。 - 命中的章节（
annotation.section）：用 SIO 本体 URI 表示，如SIO_001029（Article）。可细到方法、结果、图注。 - 命中串与上下文（
exact/prefix/postfix）：可直接还原成带窗口的训练实例，不必回原文定位。
一个真实的响应片段（PMID 33180112，「Europe PMC in 2020」这篇综述本身），同一处 COVID-19 被标了两次：
[{"source":"MED","extId":"33180112","pmcid":"PMC7778976",
"annotations":[
{"exact":"COVID-19","prefix":"","postfix":"9 preprints indexed ",
"tags":[{"name":"COVID-19","uri":"http://purl.obolibrary.org/obo/MONDO_0100096"}],
"type":"COVoc","section":"Article (...SIO_001029)","provider":"HES-SO / SIB ..."},
{"exact":"COVID-19","prefix":"","postfix":"9 preprints indexed ",
"tags":[{"name":"COVID-19","uri":"http://purl.obolibrary.org/obo/NCBITaxon_2697049"}],
"type":"COVoc","section":"Article (...SIO_001029)","provider":"HES-SO / SIB ..."}
]}]
注意这两条的差别只在 tags[].uri：一条指 MONDO_0100096（疾病本体里的「COVID-19 疾病」），一条指 NCBITaxon_2697049（物种本体里的「SARS-CoV-2 病毒」）。同一个字符串，语义空间里是两个不同实体。这正是「13 亿条标注不能当金标准」的具体含义——它给的是候选解释，不是唯一答案。
§2.5 为什么聚合层对医学 AI 重要
单库做训练集的时代基本过去了。原因不是数据不够多，是单库的形状不够复杂：
- PubMed 只有出版后文献 → 无法研究预印本阶段的表述
- PMC OA 只有开放许可全文 → 无法研究非开放文献的选题分布
- 专利库只有专利 → 无法研究专利与论文的时间差
- 预印本服务器只有自己的预印本 → 无法做跨服务器对比
Europe PMC 的价值在于它同时持有这些形状，并且用 source 字段把它们区分开。这意味着可以在同一个检索式、同一套字段、同一个 API 下做交叉研究：比较 SRC:PPR 与 SRC:MED 的同一主题产出节奏、比较 SRC:PAT 与 SRC:MED 的技术转化滞后、比较 34 个预印本服务器的主题偏好。
这也是它的风险所在：形状越复杂，去重与泄漏控制越难。§5 会专门讲这个。
§2.6 Europe PMC 保证什么、不保证什么
| 保证 | 不保证 |
|---|---|
| MEDLINE 书目与 NLM 同步（每日） | 收录完整——很多非英文期刊、会议论文不在内 |
每条记录有稳定的 source + id |
同一研究只有一条记录 |
| 开放获取文献标注了许可短名 | 许可短名对应到完整法律条款——NC/ND 的具体边界需回原文 |
| 文本挖掘标注可追溯到 provider | 标注正确 |
| 与 40 余个数据库的交叉链接 | 链接完整——只在能识别 accession 号时建立 |
| 资助信息来自资助方提交 | 资助信息完整——未提交的基金查不到 |
| REST API 稳定可用、有版本号 | 有 SLA——官方未承诺可用性指标 |
最后一条要划重点：Europe PMC 的 API 是免费公开的，但没有正式的 SLA 承诺。我们在实测中遇到过 pageSize 上限、cursorMark 失效、FTP 页面被 Cloudflare 拦截三类问题（详见 §6.5）。生产系统必须做重试与降级，不能假设它像商业 API 一样稳定。
§3 数据规格与通道抉择
§3.0 四条通道
| 通道 | 端点 | 适合 | 单次上限 | 坑 |
|---|---|---|---|---|
| Articles REST | /europepmc/webservices/rest/search |
检索、元数据、按条件切片 | pageSize ≤ 1,000 |
深分页必须用 cursorMark，page 参数超 10,000 条即失效 |
| Annotations REST | /europepmc/annotations_api/annotationsByArticleIds |
取某几篇文章的全部标注 | 一次可传多个 ID | 返回是数组不是对象，空结果返回 [] 不是 {} |
| FTP 批量 | europepmc.org/ftp/* |
全量语料、离线训练 | 按批次卷 | 程序化访问被 Cloudflare 挑战拦截（403） |
| OAI-PMH | /oai |
增量同步、元数据收割 | 按 from/until 分批 |
只有元数据，无全文 |
选哪个，取决于你要的是「几条」还是「几百万条」：
- 少于 1 万条：Articles REST +
cursorMark - 10 万条量级：Articles REST 分片（按
PUB_YEAR或SRC切），每片独立跑 - 全量元数据：FTP 的
pmclitemetadata/（每周更新） - 全量全文：FTP 的
openaccess/（需人工浏览器下载或带浏览器指纹的客户端）
§3.1 字段地图
官方 /fields 端点返回 143 个可检索项，按用途分七组：
| 组 | 代表字段 | 说明 |
|---|---|---|
| 标识 | EXT_ID / PMCID / DOI / ISBN / ISSN / EPMC_AUTH_MAN |
跨库对齐的锚点 |
| 书目 | TITLE / ABSTRACT / AUTH / JOURNAL / PUB_YEAR / VOLUME / ISSUE / LANG |
常规检索 |
| 来源与类型 | SRC / PUB_TYPE / LICENSE / PUBLISHER |
切片与合规筛 |
| 可得性布尔 | HAS_FT / OPEN_ACCESS / HAS_PDF / HAS_ABSTRACT / HAS_SUPPL / IN_PMC / IN_EPMC |
全部 Y/N |
| 交叉引用布尔 | HAS_UNIPROT / HAS_PDB / HAS_CHEBI / HAS_CHEMBL / HAS_OMIM / HAS_INTERPRO / HAS_INTACT / HAS_PRIDE / HAS_EMBL / HAS_XREFS |
逐库标记 |
| 标注与语义 | HAS_TM / ANNOTATION_TYPE / ANNOTATION_PROVIDER / GENE_PROTEIN / CHEM / DISEASE / ORGANISM / ACCESSION_ID |
文本挖掘侧 |
| 章节限定 | METHODS / RESULTS / INTRO / DISCUSS / CONCL / FIG / TABLE / SUPPL / BACK / APPENDIX / CASE / OTHER / BODY |
只有对 HAS_FT:Y 的文献有效 |
| 资助 | GRANT_AGENCY / GRANT_ID / ACK_FUND / FUNDER_INITIATIVE |
按钱反查 |
| 时间 | PUB_YEAR / FIRST_PDATE / FIRST_IDATE / CREATION_DATE / UPDATE_DATE / EMBARGO_DATE |
六个不同含义的日期，见 §6.5 坑点 4 |
§3.2 下载预算
元数据（lite，每条约 1 KB）：
| 量级 | 条数 | 估算体积 | 耗时（实测速率） |
|---|---|---|---|
| 单主题切片 | 10 万 | ~100 MB | 约 10 分钟（1,000 条/页 × 100 页） |
| 年度切片 | 180 万 | ~1.8 GB | 约 3 小时 |
| 全量 lite | 4,911 万 | ~49 GB | 走 FTP，不走 API |
全文元数据（core，每条约 3–8 KB）：
| 量级 | 条数 | 估算体积 |
|---|---|---|
| 单主题切片 | 10 万 | ~500 MB |
| 有全文的子集 | 1,244 万 | ~60 GB |
全文 XML（每篇 20–200 KB）：
| 量级 | 篇数 | 估算体积 |
|---|---|---|
| 开放获取子集 | 835 万 | TB 级（官方未给准确体积） |
实测速率参考：我们在 2026-10-23 用 100 条/页抓 300 条 lite，平均每页 1.2 秒，折算约 80 条/秒。这是单并发的情况，官方文档建议不要超过每秒 10 次请求——所以我们实际是超速的（因为只跑了 3 页）。生产环境请自觉限速。
§3.3 增量同步机制
Europe PMC 用的是时间戳增量，不是版本号：
CREATION_DATE：记录首次进入库的日期UPDATE_DATE：记录最后修改的日期FIRST_IDATE：首次索引日期（可精确到日）INDEX_DATE：当前索引日期
增量抓取的正确写法是每天跑一次 UPDATE_DATE:[昨天 TO 今天]，而不是 CREATION_DATE——因为已有记录会因补充摘要、修 DOI、加标注而更新，只抓新建的会漏掉这些修正。
但这里有个反直觉的事实：UPDATE_DATE 的变更频率极高。原因是文本挖掘标注是持续重跑的——某条 2015 年的论文，可能因为 2026 年新训练的挖掘模型重新标注而被 touch 一次。所以 UPDATE_DATE 增量会捕获大量「元数据没变、只有标注变了」的记录。如果只要书目，用 CREATION_DATE；如果要标注，才用 UPDATE_DATE。
§3.4 技术栈与溯源链
| 层 | 用什么 |
|---|---|
| 前置 | Cloudflare（官网与 FTP 页面）/ 无 CDN（API 端点直连 EBI） |
| 检索层 | 自研分布式检索引擎（官方未公开细节） |
| 存储 | 官方未公开 |
| 编号 | source + id；跨源合并靠 PMID / PMCID / DOI 三件套 |
| 标注 | SciLite 体系 + 外部 provider 提交（Annotations Submission System） |
| 全文 | PMC XML（JATS 变体）+ 出版商直供 |
| 分发 | REST（JSON / XML / Dublin Core）+ FTP + OAI-PMH |
溯源链的完整性判断：一条数据要能被复现，需要四件事——(1) 抓取日期、(2) 查询语句、(3) resultType 参数、(4) 服务版本（version 字段，当前 6.9）。缺任何一项，三个月后数字必然对不上。 本条目所有查询都在附录 B 给出，可逐条复跑。
§4 记录结构与字段字典
§4.1 一条记录的结构
resultType 有三档，返回的字段数量差一个数量级：
| 档位 | 关键字段 | 单条体积 | 适用 |
|---|---|---|---|
idlist |
仅 id / source |
~50 B | 只要 ID 列表 |
lite |
20 个左右书目字段 | ~1 KB | 批量元数据 |
core |
40+ 字段，含摘要、MeSH、资助、全文链接、交叉引用 | 3–8 KB | 单篇深读 |
core 档的完整字段清单（实测一条 Nature 论文 DOI 10.1038/s41586-020-2649-2 的响应）：
abstractText, affiliation, authMan, authorIdList, authorList, authorString,
citedByCount, dataLinksTagsList, dateOfCompletion, dateOfCreation, dateOfRevision,
doi, electronicPublicationDate, epmcAuthMan, firstIndexDate, firstPublicationDate,
fullTextIdList, fullTextReceivedDate, fullTextUrlList, hasBook, hasData,
hasDbCrossReferences, hasEvaluations, hasLabsLinks, hasPDF, hasReferences,
hasSuppl, hasTMAccessionNumbers, hasTextMinedTerms, id, inEPMC, inPMC,
isOpenAccess, journalInfo, language, license, meshHeadingList, nihAuthMan,
pageInfo, pmcid, pmid, pubModel, pubTypeList, pubYear, publicationStatus,
source, subsetList, title, tmAccessionTypeList
注意这里面有 12 个 has* 布尔字段：hasBook / hasData / hasDbCrossReferences / hasEvaluations / hasLabsLinks / hasPDF / hasReferences / hasSuppl / hasTMAccessionNumbers / hasTextMinedTerms。它们是独立的，不是层级关系。
hasData:Y 不蕴含 hasDbCrossReferences:Y（前者指「论文背后有数据」，后者指「与具体数据库条目建立了链接」）。
§4.2 fullTextUrlList：一处多源的结构
同一篇论文的全文链接可能来自多个站点，每条带两个关键码：
| 字段 | 取值 | 含义 |
|---|---|---|
availabilityCode |
OA |
开放获取，可直接下载 |
S |
Subscription，需订阅 | |
F |
Free，免费但非开放许可（如出版商限时免费） | |
documentStyle |
pdf / html / doi / manuscript |
文档形态 |
site |
Europe_PMC / DOI / Publisher / PMC |
来源站点 |
实测例子（同一篇 Nature 论文）：
{"fullTextUrl":[
{"availability":"Subscription required","availabilityCode":"S",
"documentStyle":"doi","site":"DOI","url":"https://doi.org/10.1038/s41586-020-2649-2"},
{"availability":"Open access","availabilityCode":"OA",
"documentStyle":"html","site":"Europe_PMC","url":"https://europepmc.org/articles/PMC7759461"},
{"availability":"Open access","availabilityCode":"OA",
"documentStyle":"pdf","site":"Europe_PMC","url":"https://europepmc.org/articles/PMC7759461?pdf=render"}
]}
这里有个反常识的点：同一条记录的 DOI 链接标 S（需订阅），Europe PMC 链接标 OA（开放获取）。原因是出版商官网要订阅，但 PMC 侧有作者接受稿（author manuscript）。所以不能用 DOI 链接的可得性判断整条记录的可得性——必须逐条看 availabilityCode。
§4.3 许可字段的真实分布
license 字段只有五个取值（实测穷举）：
| 取值 | 条数 | 占比（在有许可的 979 万条中） | 可用于商业训练 |
|---|---|---|---|
cc by |
6,571,562 | 67.1% | ✅ 可以（需署名） |
cc by-nc-nd |
1,630,225 | 16.6% | ❌ 禁止商用 + 禁止派生 |
cc by-nc |
1,148,570 | 11.7% | ❌ 禁止商用 |
cc0 |
69,447 | 0.7% | ✅ 无条件 |
cc by-nd |
23,093 | 0.2% | ⚠️ 可商用但禁止派生 |
「有许可标记」的总数是 9,792,835，比 OPEN_ACCESS:Y 的 8,352,804 多 1,440,031 条。 这个差值的来源是：部分文献有许可信息（从出版商元数据继承），但 Europe PMC 侧没有全文可下载。「有 cc by 标记」不等于「这里能下到全文」。
实操建议：做训练语料时，筛选条件应该写成 OPEN_ACCESS:Y AND LICENSE:"cc by"（8,352,804 与 6,571,562 的交集），而不是只看其中任一。若要含 cc0，再加上 OR LICENSE:"cc0"。
§4.4 时间字段：六个日期，六种含义
这是 Europe PMC 最容易踩的字段陷阱。resultType=core 的响应里有六个日期：
| 字段 | 含义 | 会不会变 | 典型用途 |
|---|---|---|---|
firstPublicationDate |
首次出版日期（含预印本首次上线） | 不变 | 时间序列分析 |
electronicPublicationDate |
电子版上线日期 | 不变 | 抢发分析 |
firstIndexDate |
首次进入 Europe PMC 的日期 | 不变 | 入库延迟分析 |
dateOfCreation |
记录创建日期 | 不变 | 数据新鲜度 |
dateOfRevision |
记录最后修订日期 | 会变 | 增量同步 |
fullTextReceivedDate |
全文入库日期 | 不变 | 全文可得性滞后分析 |
关键事实：firstPublicationDate 与 firstIndexDate 可以相差数年。我们在 query=* 的第一条结果里就看到：pubYear: 2028、firstPublicationDate: 2028-09-14、firstIndexDate: 2026-10-02——一篇标着 2028 年出版的论文，2026 年 10 月就进了库（这是提前上线的电子预出版）。反过来，回溯录入的 1950 年代老文献，firstPublicationDate 是 1950 年代，firstIndexDate 是 2010 年代。
所以：做时间序列必须用 firstPublicationDate，做数据新鲜度必须用 firstIndexDate，二者混用会得出错误结论。
§4.5 subsetList：期刊的分区标签
subsetList 用代码声明该文献属于哪个 NLM 子集：
| 代码 | 名称 | 含义 |
|---|---|---|
IM |
Index Medicus | MEDLINE 核心索引 |
PubMed |
— | 在 PubMed 可检索 |
PMC |
— | 在 PMC 有全文 |
AGR |
— | 农业子集 |
ETH |
— | 伦理子集 |
HIR |
— | 历史子集 |
一个易错点：subsetList 里出现 IM 不代表这条记录只有 MEDLINE 侧内容，也不代表它一定在 PubMed 里能被搜到（部分记录因撤回、重复等原因被从 PubMed 移除但保留在 Europe PMC）。判断「在不在 PubMed」应该查 pmid 字段是否有值。
§4.6 一个容易忽略的事实：source 与 id 的耦合
id 的含义完全取决于 source。同一个数字字符串，在 MED 下是 PMID，在 PMC 下是 PMCID 数字部分，在 PAT 下可能是专利号片段。
因此所有的取数代码都必须是这种形状：
# 正确：先看 source 再决定怎么拼 URL
if rec["source"] == "MED":
url = f"https://www.ebi.ac.uk/europepmc/webservices/rest/MED/{rec['id']}/fullTextXML"
elif rec["source"] == "PMC":
url = f"https://www.ebi.ac.uk/europepmc/webservices/rest/PMC/{rec['id']}/fullTextXML"
elif rec["source"] == "PPR":
url = f"https://www.ebi.ac.uk/europepmc/webservices/rest/PPR/{rec['id']}/fullTextXML"
else:
continue # PAT / AGR / CTX / ETH / HIR 无全文端点
# 错误：把 id 当 PMID 用
url = f".../MED/{rec['id']}/fullTextXML" # SRC:PMC 的记录会 404
还有一个细节：PMC 来源的 id 不带 PMC 前缀（是 7759461 不是 PMC7759461），但 pmcid 字段带前缀（PMC7759461）。两者不能混。用 pmcid 拼 URL 会得到 404。
§5 检索、抽样与泄漏分析
§5.0 四条可用的检索范式
范式一：布尔 + 字段限定
(TITLE:"large language model" OR ABSTRACT:"large language model")
AND (SRC:MED OR SRC:PPR)
AND PUB_YEAR:[2023 TO 2026]
AND HAS_ABSTRACT:Y
范式二：按可得性切片
HAS_FT:Y AND OPEN_ACCESS:Y AND LICENSE:"cc by"
得到 835 万 × 671 万里可商用的那一块。
范式三：按资助方反查
GRANT_AGENCY:"National Natural Science Foundation of China"
AND PUB_YEAR:2025
AND HAS_DATA:Y
范式四：按交叉数据库反查
HAS_PRIDE:Y AND PUB_YEAR:[2024 TO 2026]
拿到近两年、背后有蛋白质组学数据的论文——这是构造「论文 → PRIDE 数据集」配对的入口。
四个范式可以任意组合，但要注意：每加一个 HAS_* 布尔，召回率都会断崖式下降。HAS_PRIDE:Y 只有 20,058 条，加上年份限制可能只剩几千。设计检索式时应先看单条件的 hitCount，再决定组合。
§5.1 抽样策略：按 source 分层，不按时间
Europe PMC 的分布极度偏斜（MED 占 84%），随机抽样会被 MEDLINE 淹没。正确的抽样是按 source 分层：
| 层 | 总量 | 建议抽样 |
|---|---|---|
MED |
41,253,787 | 按需取 1–5%（40 万–200 万） |
PAT |
4,229,296 | 全取或取 10%（40 万） |
PPR |
1,268,930 | 全取（量不大，且是稀缺资源） |
AGR |
1,026,549 | 全取或取 20% |
| 其他（CTX/ETH/HIR） | 183,589 | 全取 |
预印本建议全取的理由：127 万条不大，但它是唯一能拿到「正式发表前版本」的公开来源。这类数据在训练集里一旦被筛掉，就再也补不回来了。
按年份抽样的陷阱：PUB_YEAR 在 SRC:PAT 上永远返回 0（见 §6.5 坑点 3）。所以不能用统一的年份切片策略处理所有 source，必须分源处理。
§5.1.1 什么时候不该用 Europe PMC
四条越界，写清楚免得误用：
- 要「纯净开放全文语料做预训练」 → 用 PMC OA Subset（本站 #360）。Europe PMC 的开放率只有 17%，且许可混杂，筛完你会发现可用量比 PMC OA Subset 还少。
- 要「引文网络做影响力分析」 → 用 OpenAlex 或 Semantic Scholar。Europe PMC 的
citedByCount口径窄（只统计库内引用），且不提供完整的 reference 列表结构。 - 要「临床试验结构化结果」 → 用 AACT（本站已有）。Europe PMC 的
SRC:CTX只有 3,922 条引用记录，不是试验结果库。 - 要「专利全文做技术挖掘」 → Europe PMC 的 423 万专利只有书目级元数据，无全文。要去 Google Patents 或 EPO OPS。
§5.2 四类真实泄漏，按危害排序
泄漏一：预印本-期刊版重复（危害最大）
同一项研究在 SRC:PPR 与 SRC:MED 各有一条记录。如果随机切分，同一研究极可能同时落在 train 与 test。
- 规模：
HAS_PUBLISHED_VERSION:Y452,629 条预印本已配对到期刊版 - 检测：查
commentCorrectionList里的preprint关系；或按标题归一化后做模糊匹配 - 处理：按研究分组切分（group split），不按记录切分
泄漏二：资助方聚集（危害中高）
同一基金的系列论文往往方法相似、数据同源。若按记录随机切分，同基金的论文会跨集。
- 规模：单一基金最多 115 万篇（NSFC）
- 检测：
grantsList[].grantId - 处理：按
grantId分组切分
泄漏三：同一作者团队（危害中）
高产的通讯作者团队方法趋同。authorIdList 里的 ORCID 是可靠的锚点。
- 检测：
authorIdList[].authorId[@type="ORCID"] - 处理：按通讯作者 ORCID 分组
泄漏四：期刊主题聚集（危害低但普遍）
同一期刊的论文在选题与写作风格上高度相似，尤其是综述型期刊。
- 检测：
journalInfo.journal.issn - 处理：不要按期刊切分（会造成分布偏移），但要在 test 集里检查期刊分布是否与 train 一致
§5.3 结构泄漏：从元数据本身推断出的信息
有一类泄漏不在文本里，在字段结构里：
pubYear与firstPublicationDate不一致：如果任务是从摘要预测年份，这两个字段直接泄漏答案。hasReferences/hasSuppl/hasPDF：这些布尔在某种程度上与「文献类型」相关（综述多有 references、临床试验多有 suppl）。若任务是预测文献类型，这些字段必须剔除。citedByCount：如果任务涉及「重要性」判断，被引数本身就是标签的代理。subsetList：IM标记几乎等价于「高质量期刊」，会泄漏质量标签。fullTextReceivedDate：与「是否 OA」强相关，做 OA 预测任务时必须剔除。
判断标准很简单：这个字段在论文发表之前是否可知？ 不可知的字段一律不能进特征。
§5.4 一个不该做的划分：按 SRC 切
看起来最合理的划分——「用 MEDLINE 训练，用预印本测试」——实际是最糟的。
原因是分布偏移太大：预印本的平均长度、结构完整度、引用密度、方法描述详细度，都与期刊版有系统差异。用 MEDLINE 训练、预印本测试，测出来的不是模型能力，是域适应能力，而且这个数字无法与其他研究比较。
正确做法：在同一 source 内随机切分（配合 §5.2 的分组），把「跨源泛化」作为单独的评测维度报出来，而不是混在主线指标里。
§6 AI 就绪指南
§6.1 最小可用 Pipeline
import time, json, urllib.parse, urllib.request
BASE = "https://www.ebi.ac.uk/europepmc/webservices/rest/search"
def epmc_search(query, result_type="lite", cap=50000, sleep=0.12):
"""游标分页 + 限速抓取。返回记录列表。"""
out, cursor, fetched = [], "*", 0
while True:
params = {
"query": query, "format": "json",
"resultType": result_type, "pageSize": 1000,
"cursorMark": cursor,
}
url = BASE + "?" + urllib.parse.urlencode(params)
for attempt in range(4): # 指数退避
try:
with urllib.request.urlopen(url, timeout=60) as r:
d = json.load(r)
break
except Exception as e:
if attempt == 3:
raise
time.sleep(2 ** attempt)
batch = d.get("resultList", {}).get("result", [])
if not batch:
break
out.extend(batch)
fetched += len(batch)
cursor = d.get("nextCursorMark")
if not cursor or fetched >= cap:
break
time.sleep(sleep) # 官方建议 ≤10 req/s
return out
# 示例：抓 2025 年有全文的开放获取 cc by 论文
recs = epmc_search(
'PUB_YEAR:2025 AND HAS_FT:Y AND OPEN_ACCESS:Y AND LICENSE:"cc by"',
result_type="core", cap=20000,
)
print(len(recs), recs[0]["title"][:80])
三个必须加的东西：
cursorMark而不是page。page参数在超过 10,000 条后返回错误或重复。- 每次翻页都要把上一页的
nextCursorMark原样传回。它是 base64 编码的游标，不要尝试解码或构造。 sleep(0.12)。官方建议不超过 10 请求/秒，0.12 秒约 8.3 请求/秒，留余量。
§6.2 构建训练样本
任务 A：命名实体识别（NER）
用 Annotations API 拿标注，转成 BIO 标签序列：
import urllib.request, json
ANN = "https://www.ebi.ac.uk/europepmc/annotations_api/annotationsByArticleIds"
def get_annotations(ids, ann_type=None):
q = "articleIds=" + ",".join(ids) + "&format=JSON"
if ann_type:
q += "&type=" + ann_type
with urllib.request.urlopen(f"{ANN}?{q}", timeout=60) as r:
return json.load(r)
def to_bio(text, anns):
"""把 exact + prefix/postfix 还原成 BIO 序列（简化版，按字符位置对齐）。"""
spans = []
for a in anns:
# 用 prefix + exact + postfix 在 text 里定位；同名多次出现需逐个匹配
pat = a.get("prefix","") + a["exact"] + a.get("postfix","")
i = text.find(pat)
if i < 0:
continue
s = i + len(a.get("prefix",""))
spans.append((s, s + len(a["exact"]), a["type"]))
# ... 按 spans 生成 tags，重叠时保留长度最长者
return spans
关键提醒：exact + prefix + postfix 拼起来不一定是原文的连续子串——官方可能对空白做了归一化。所以定位失败时要回退到「在 prefix 之后、postfix 之前找 exact」的两段式搜索。
任务 B：论文-数据集配对
用 HAS_DATA 与交叉引用布尔筛候选，再从 fullTextXML 里抽 accession 号：
cands = epmc_search(
'HAS_PRIDE:Y AND PUB_YEAR:[2024 TO 2026]', result_type="core", cap=5000)
# 每条记录再取 fullTextXML，用正则找 PXD\d{6}
任务 C：预印本-发表版差异
pairs = epmc_search('HAS_PUBLISHED_VERSION:Y AND SRC:PPR',
result_type="core", cap=50000)
# 每条 PPR 记录的 commentCorrectionList 里找 type=="Preprint" 的对应 MED 记录
§6.3 评价指标
| 任务 | 主指标 | 辅助 | 注意 |
|---|---|---|---|
| NER | 实体级 F1（严格边界） | 宽松 F1（部分匹配） | 必须报宽松 F1——标注边界本身有歧义 |
| 检索 | Recall@K / nDCG@10 | MRR | 用人工标注的 query 集，别用 hitCount 当 ground truth |
| 论文-数据配对 | Precision@1 / Recall@10 | MRR | 假阴性极多（很多论文有数据但没建链接） |
| 预印本差异检测 | 人工评估为主 | BLEU / BERTScore（仅参考） | 语义漂移不是字符串相似度能测的 |
一个必须说清的点：Europe PMC 的 citedByCount 不能当评价指标。它的口径是「库内引用」，与 Google Scholar、Scopus、WoS 都有显著差异，且不提供引用它的具体文献列表结构（只有 hasReferences 布尔）。做引文分析必须换源。
§6.4 MLOps：怎么钉住版本
Europe PMC 没有 release 号，只有 REST 服务版本（当前 6.9）。这意味着钉版本只能靠四件事的组合：
# 实验记录模板
dataset: europe-pmc
service_version: "6.9" # 响应头 version 字段
snapshot_date: "2026-10-23" # 抓取日期（UTC）
total_hitcount: 49118306 # 当日 hitCount，用于校验
queries:
- "PUB_YEAR:2025 AND HAS_FT:Y AND OPEN_ACCESS:Y AND LICENSE:\"cc by\""
- "HAS_PRIDE:Y AND PUB_YEAR:[2024 TO 2026]"
record_counts: [1948210, 4217] # 每个 query 的实际抓取条数
checksum: "sha256:..." # 数据文件校验和
为什么 total_hitcount 是必需的：如果三个月后有人用同样的 query 复现，hitCount 已经变了。把这个数写进实验记录，才能说清「差异是数据更新造成的，还是代码变了」。
更强的做法：把抓到的每条记录的 (source, id, dateOfRevision) 三件套存成清单文件。这样即使数据更新，也能精确重建当时的快照。
§6.5 八个真实坑点
坑点 1：page 参数深分页失效
- 症状：
page=11&pageSize=1000返回错误或与page=1相同的记录。 - 原因：深分页代价过高，官方限制
page × pageSize不能超过 10,000。 - 解法：改用
cursorMark，第一页传cursorMark=*，后续传回上一页的nextCursorMark。注意cursorMark与sort参数互斥——用了游标就不能自定义排序。 - 参考：官方 REST 文档「Paging」章节。
坑点 2：SRC:PMC 的 id 不带前缀，但 pmcid 带前缀
- 症状：用
pmcid字段拼/PMC/PMC7759461/fullTextXML得到 404。 - 原因：URL 路径里的 PMCID 不要
PMC前缀，而pmcid字段的值带前缀。 - 解法：
url = f".../PMC/{rec['pmcid'].removeprefix('PMC')}/fullTextXML"。 - 参考：
fullTextIdList.fullTextId给的就是无前缀形式，可直接用。
坑点 3：SRC:PAT 的年份检索永远返回 0
- 症状：
SRC:PAT AND PUB_YEAR:2025→hitCount: 0；但SRC:PAT单独查有 4,229,296 条。 - 原因：专利记录不走
PUB_YEAR字段（专利的年份语义与论文不同，用申请日/公开日）。 - 解法：专利要按
FIRST_PDATE或其他时间字段筛；也不要指望用统一的时间切片策略处理所有source。 - 参考：本条目实测，
SRC:PAT有 423 万条但PUB_YEAR全为空。
坑点 4：六个日期字段，用错一个结论就反
- 症状：算「文献入库延迟」时用
firstPublicationDate，得出一堆负值（入库早于出版）。 - 原因：电子预出版会让
firstPublicationDate标未来的日期（实测有pubYear: 2028的记录在 2026 年入库）。 - 解法：延迟 =
firstIndexDate − firstPublicationDate，但要先剔除firstPublicationDate > 抓取日的记录（电子预出版）。 - 参考：本条目 §4.4 与
query=*首条记录的实例。
坑点 5：Annotations API 空结果返回 [] 不是 {}
- 症状：
d.get("annotations")在空结果时报AttributeError: 'list' object has no attribute 'get'。 - 原因：Annotations API 返回的顶层是数组（每篇一个对象），Articles API 返回的顶层是对象。两个 API 的响应形状不同。
- 解法：先判
isinstance(resp, list)，空结果就是[]，非空时再逐元素取.get("annotations", [])。 - 参考：
annotationsByArticleIds端点实测响应。
坑点 6：FTP 批量下载页被 Cloudflare 挑战拦截
- 症状：
curl https://europepmc.org/ftp/openaccess/返回 403 +cf-mitigated: challenge，HTML 里是 “Just a moment…”。 - 原因：官网与 FTP 列表页在 Cloudflare 后面，对无浏览器指纹的请求做挑战。
- 解法：用浏览器手动下载，或用带完整浏览器头的客户端；也可改用 API 侧（
/search与全文端点不受此限）。纯脚本批量拉全文这条路走不通。 - 参考：本条目实测，
curl -I返回HTTP/2 403、server: cloudflare。
坑点 7：GRANT_AGENCY 是精确匹配字符串，不是模糊匹配
- 症状：查
GRANT_AGENCY:NSFC命中很少，但GRANT_AGENCY:"National Natural Science Foundation of China"有 115 万。 - 原因：资助方名是资助方提交的规范名，不做别名归并。
- 解法：先查
GRANT_AGENCY:*的取值分布（或去 Grant Finder 看名单），用完整规范名 + 引号检索。同一机构可能有多个写法，需要穷举。 - 参考：本条目实测五家资助方的
hitCount差异。
坑点 8：query=* 的默认排序不是随机，抽样会偏
- 症状：
query=*抓 300 条，SRC:MED占 299 条、SRC:AGR占 1 条，完全没有PPR/PAT。 - 原因：默认排序按内部索引顺序（近似入库时间倒序），MED 占绝对多数，所以前面几乎全是 MED。
- 解法：抽样必须按
source分别查（SRC:PPR、SRC:PAT各跑一遍），不能从query=*的结果里抽。 - 参考：本条目实测 3 页 × 100 条，源分布
{MED: 299, AGR: 1}。
§7 质量评估、DAIMS 与口径交叉核对
§7.1 记录级质量
| 检查项 | 状态 | 说明 |
|---|---|---|
| 主键唯一性 | ✅ | source + id 二元组唯一 |
| 跨源标识一致 | ✅ | PMID / PMCID / DOI 三件套，有映射表（每月覆盖） |
| 摘要可得 | ⚠️ | 70.1%（3,444 万 / 4,911 万） |
| 全文可得 | ⚠️ | 25.3%（1,244 万） |
| 开放可得 | ⚠️ | 17.0%（835 万） |
| 许可标注 | ⚠️ | 有许可 979 万，仅占总量 19.9% |
| 作者结构化 | ⚠️ | authorList 仅 core 档返回；authorString 是逗号串 |
| 机构标准化 | ⚠️ | affiliation 是自由文本；ROR 集成覆盖不全 |
| MeSH 标注 | ⚠️ | 仅 MEDLINE 来源有，且仅 core 档返回 |
| 日期一致性 | ⚠️ | 六种日期，含义不同（§4.4） |
| 预印本-期刊版配对 | ⚠️ | 45 万条已配对，但配对率不是 100% |
| 文本挖掘标注 | ⚠️ | 覆盖 77%，但多 provider 精度不一 |
| 撤稿标记 | ⚠️ | commentCorrectionList 有，但需主动解析，无顶层布尔 |
§7.2 抽样声明：本条目数字的边界
所有数字都是 2026-10-23 15:15–15:20 UTC 的 API 快照。 具体边界：
hitCount是当日值。前一日（10-22）首次观测 49,111,254，本日 49,118,306，日增 7,052。- 我们没有下载任何全文。所有「全文可得 1,244 万」是
HAS_FT:Y的计数，不是我们数出来的文件数。 - 我们没有抽样核对标注精度。13 亿条是官方声明值，我们只验证了 Annotations API 能正常返回。
SRC:*各分项之和 ≠ 总量。41,253,787 + 1,013,126 + 1,268,930 + 4,229,296 + 1,026,549 + 3,922 + 176,799 + 2,868 = 48,975,277，比总量 49,118,306 少 143,029。差额来自我们未逐一枚举的 source 代码（如NBK书籍章节等）。HAS_PREPRINT:Y（442,403）与SRC:PPR（1,268,930）不是同一概念。前者是「有预印本版本的记录」（可能主记录是 MED），后者是「主记录就是预印本」。差 82 万。
§7.3 三个必须知道的效度问题
问题一：收录不是随机的，是资助驱动的。
Europe PMC 由欧洲资助方联合体支持，资助方要求其资助的产出必须存入。这导致收录分布与「全球科研产出分布」不一致：欧洲资助的、开放获取倾向强的、英文的，收录率高；非欧洲的、非英文的、非资助的，收录率低。
后果：用它做「全球科研趋势」分析会有系统偏差。做「Europe PMC 内的趋势」没问题，跨库外推要谨慎。
问题二：文本挖掘标注的精度未公开。
官方说 13 亿条标注、42 类概念，但没有公布每类的精度指标。我们实测发现同一处文本被标两个不同本体实体（MONDO 疾病 vs NCBITaxon 物种），说明标注是「多候选」而不是「单一判定」。
后果：直接当训练标签会引入噪声。正确用法是「弱监督」——多 provider 一致的标注权重高，单 provider 的权重低。
问题三：citedByCount 口径窄，不能跨库比较。
Europe PMC 的引用计数只统计库内引用。一篇被大量非生物医学文献引用的方法学论文（如 AlphaFold），其 citedByCount 会显著低于 Google Scholar。
后果：任何涉及「影响力」的标签都要慎用这个字段。
§7.4 偏倚清单（可核查）
| 偏倚 | 表现 | 核查方式 |
|---|---|---|
| 地理偏倚 | 欧洲资助产出占优 | GRANT_AGENCY 按国家分组 |
| 语言偏倚 | 英文占绝对多数 | LANG 字段分布 |
| 时间偏倚 | 近五年占 40%+（2021–2026 合计约 1,070 万 / 4,911 万） | PUB_YEAR 分组 |
| 可得性偏倚 | 开放获取文献的方法描述更完整 | 对比 OA 与非 OA 的 HAS_SUPPL 比例 |
| 主题偏倚 | COVID-19 相关文献在 2020–2022 年集中爆发 | 按 DISEASE 字段分组 |
| 类型偏倚 | 综述与 letter 混杂 | pubTypeList 分组 |
| 挖掘偏倚 | 有全文的文献才有章节级标注 | HAS_FT × HAS_TM 交叉 |
「时间偏倚」这一行值得展开：实测 PUB_YEAR 2021 年 1,781,940、2022 年 1,794,771、2023 年 1,738,790、2024 年 1,797,649、2025 年 1,965,745。五年合计约 908 万，占 4,911 万的 18.5%。而 1990 年只有 467,500。收录深度随时间递减，越早越稀疏。
§7.5 数据完整性核查表
| 检查 | 方法 | 结果 |
|---|---|---|
| 总量可复现 | search?query=*&pageSize=1 的 hitCount |
✅ 49,118,306 |
| 分源可加总 | 各 SRC:* 之和 vs 总量 |
⚠️ 差 143,029（未枚举 source） |
| 可得性字段自洽 | HAS_FT:Y ≥ OPEN_ACCESS:Y |
✅ 12,439,494 > 8,352,804 |
| 许可字段自洽 | LICENSE:* vs OPEN_ACCESS:Y |
⚠️ 979 万 > 835 万（有许可无全文） |
| 预印本配对自洽 | HAS_PREPRINT:Y vs HAS_PUBLISHED_VERSION:Y |
⚠️ 442,403 vs 452,629，差 10,226 |
| 交叉引用按库可加总 | 九个 HAS_* 库之和 vs HAS_XREFS:Y |
⚠️ 之和 1,217,319 > 1,035,850（一条记录可链多库） |
| 全文可得 ≠ PDF 可得 | HAS_FT:Y vs HAS_PDF:Y |
✅ 差 251,270（有 XML 无 PDF） |
| 版本号可取 | 响应头 version |
✅ “6.9” |
第 5 行需要解释：HAS_PREPRINT:Y（442,403）比 HAS_PUBLISHED_VERSION:Y（452,629）少 10,226。理论上「有预印本版本的记录」应该 ≥ 「预印本记录了有发表版的」，实际反过来。可能的原因是部分 MED 记录被标了 HAS_PUBLISHED_VERSION 但没被标 HAS_PREPRINT（数据标注不一致）。这是官方字段的小缺陷，不影响使用，但做配对时要两个都查再取并集。
§7.6 DAIMS 24 项逐项评分
✅=1 / ⚠️=0.5 / ❌=0
| # | 维度 | 判 | 依据 |
|---|---|---|---|
| 1 | 数据集唯一标识 | ✅ | source+id，另有 DOI/PMID/PMCID |
| 2 | 持久标识符 | ✅ | DOI / PMID / PMCID 三套 |
| 3 | 版本化 | ⚠️ | REST 有 6.9，但无数据快照版本 |
| 4 | 元数据标准 | ✅ | Dublin Core / JATS / MeSH |
| 5 | 元数据完整性 | ✅ | 143 个可检索字段 |
| 6 | 字段字典 | ✅ | /fields 端点 + REST 文档 |
| 7 | 数据字典/模式 | ✅ | core 档 40+ 字段结构稳定 |
| 8 | 机器可读格式 | ✅ | JSON / XML / Dublin Core |
| 9 | API 可得 | ✅ | 三套 REST API + OAI |
| 10 | 批量下载 | ⚠️ | FTP 有，但被 Cloudflare 拦截 |
| 11 | 许可明确 | ⚠️ | 逐篇标注，但仅 19.9% 有值 |
| 12 | 许可机器可读 | ✅ | license 字段短名 |
| 13 | 溯源 | ⚠️ | 有 provider 与日期，但无数据血缘图 |
| 14 | 引用规范 | ✅ | 官方推荐引用「Europe PMC in 2020」 |
| 15 | 数据来源声明 | ✅ | About 页列明 PubMed/PMC/Agricola/预印本/专利 |
| 16 | 更新频率声明 | ✅ | 每日更新；FTP 每周/每月 |
| 17 | 缺失值说明 | ⚠️ | 字段缺值无文档，需自行探测 |
| 18 | 质量控制声明 | ⚠️ | 无明确的 QC 流程文档；标注精度未公布 |
| 19 | 抽样/覆盖说明 | ⚠️ | 无收录覆盖率的官方说明 |
| 20 | 文档完整性 | ✅ | About / Help / 搜索语法 / 开发者资源齐全 |
| 21 | 示例/教程 | ✅ | API case studies + 代码示例 |
| 22 | 社区支持 | ✅ | 开发者论坛 + helpdesk |
| 23 | 长期保存承诺 | ✅ | EMBL-EBI 托管，属 ELIXIR 核心资源 |
| 24 | 伦理/隐私声明 | ⚠️ | 文献层无患者数据，但撤稿/更正处理无专门说明 |
总分：18.0 / 24 = 75.0%
扣分的六项集中在**「文档化的质量声明」**这一类：缺失值、QC 流程、覆盖说明、撤稿处理——Europe PMC 有数据，但没有把这些写成可引用的规范文档。这是聚合型资源的通病：东西太多，反而说不清质量边界。
§7.7 口径交叉核对矩阵（不是模型性能验证）
对照一：官网首页/About 的数字 vs API 实测
| 指标 | 官方原文 | API 实测 | 差异解释 |
|---|---|---|---|
| 总量 | 未在 About 给总数 | 49,118,306 | 官方不在 About 报总数，只报功能 |
| 预印本服务器 | 「34 life science preprint servers」 | SRC:PPR 1,268,930 条 |
服务器数与记录数是两回事 |
| 生物数据库 | 「over 40 biological databases」 | HAS_XREFS:Y 1,035,850 条 |
库数与记录数不同量纲 |
| 标注 | 「over 1.3 billion annotations / 42 types」 | HAS_TM:Y 37,836,422 条文献 |
标注条数 vs 文献条数 |
| 资助 | 「122,173 biomedical grants from 36 funders」+「18,980 COVID-19」 | Grants API 端点 404（见坑点说明） | 只能引官方值 |
| 全文检索 | 「abstracts and full text」 | HAS_FT:Y 12,439,494 |
全文占 25.3%，不是全部 |
这张表要说清的事：官方的「34 / 40 / 13 亿 / 42」都是类别数与标注条数，不是文献条数。把「13 亿条标注」读成「13 亿篇文献有标注」会差 34 倍（实际是 3,783 万篇）。
对照二：Europe PMC 与 PMC / PubMed 的计数关系
| 指标 | Europe PMC | 关系 | 说明 |
|---|---|---|---|
| MEDLINE 侧 | 41,253,787 | ≈ PubMed 总量 | Europe PMC 的 MED 部分与 PubMed 基本同源，日更 |
| PMC 侧 | SRC:PMC 1,013,126 |
≠ PMC 全文总量 | 以 PMC 为主记录的只有一百万；有 PMC 全文的记录多得多（inPMC:Y） |
| 预印本 | 1,268,930 | 远超单个服务器 | 34 个服务器汇总 |
对照三：可得性漏斗
4,911 万 总记录
↓ 70.1%
3,444 万 有摘要
↓ 25.3%
1,244 万 有全文
↓ 17.0%
835 万 开放获取
↓ 可用许可（cc by + cc0）
664 万 可商用训练
最后一级 664 万 = 6,571,562（cc by）+ 69,447（cc0）= 6,641,009。这是 Europe PMC 真正能用于商用模型训练的规模上限——只占总量的 13.5%。这个数字比大多数人的直觉小得多，也是本条目最该被记住的一个数。
§8 生态位与相邻资源
§8.1 Europe PMC 在网络里的位置
┌──────────────┐
出版商 ─────────▶│ │
PMC ────────────▶│ Europe PMC │───▶ REST API / FTP
Agricola ───────▶│ (EMBL-EBI) │───▶ 网站检索
34 个预印本 ────▶│ │───▶ OAI-PMH
专利局 ─────────▶└──────┬───────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
UniProt / PDB PRIDE / ChEMBL OMIM / InterPro
(40+ 生物数据库交叉链接)
上游：五类来源，其中 PMC 与 PubMed 是主干（合计 ~90%），预印本与专利是差异化部分。
下游：40 余个生物数据库通过 accession 号反向链接；Unpaywall 提供合法免费副本。
平行：OpenAlex（引文网络）、Semantic Scholar（语义检索）、Crossref（DOI 注册）、Dimensions（商业）。
§8.2 与本站已收条目的关系
| 本站条目 | 关系 | 怎么配合 |
|---|---|---|
| PMC OA Subset（#360） | 互补，不是替代 | 要纯净开放全文用 PMC OA；要全量元数据与预印本用 Europe PMC |
| PMC-OA（#320） | 子集 | 是 PMC OA Subset 的镜像版本 |
| Open-PMC（#45） | 子集 | 同上，口径略窄 |
| LitCovid（#380） | 派生 | LitCovid 是 Europe PMC 里 COVID-19 子集的再策展 |
| PubTator Central（#752） | 标注侧对照 | PubTator 的标注与 Europe PMC 的 Annotations 有重叠也有差异，可做多标注源一致性研究 |
| SemMedDB（#836） | 语义谓词 | Europe PMC 给实体标注，SemMedDB 给实体间谓词；两者可拼接成 KG |
| PubMedQA（#49） | 下游任务 | PubMedQA 的语料取自 PubMed 摘要，可用 Europe PMC 补充全文 |
| arXiv（#123） | 领域互补 | arXiv 覆盖物理/CS，Europe PMC 覆盖生命科学；两者预印本部分有少量交集 |
| S2ORC | 全文侧对照 | S2ORC 侧重 CS，全文解析质量更高；Europe PMC 侧重生物医学，元数据更丰富 |
| CPIC（#1351） | 下游消费 | 用药指南的原始文献大多可在 Europe PMC 找到全文 |
最值得配的一对是 Europe PMC + SemMedDB：Europe PMC 给「这个句子里有哪些实体」，SemMedDB 给「这两个实体之间是什么谓词」。两者拼起来才是完整的三元组。
§8.3 为什么一个「医学数据集站」要收文献聚合库
三个理由：
- 所有医学数据集的「说明书」都在文献里。 一个数据集写了 500 字的 README，但它的真实采集流程、排除标准、失效模式，写在论文的方法部分。没有文献层，数据集文档永远是二手的。
- 文献是唯一能覆盖「数据集之间的关系」的层。 两个数据集之间的可比性、某个 benchmark 的构造动机、某个指标为什么被弃用——这些信息不在任何数据集的字段里，只在论文的讨论部分。
- 中文语境下的医学 AI，最缺的不是数据，是「这个数据是怎么来的」。 Europe PMC 的开放获取子集（835 万篇）是这条链上最便宜的入口。
§9 许可、伦理与合规
§9.1 许可结构：三层嵌套
Europe PMC 的许可不是一个许可，是三层：
| 层 | 内容 | 许可 |
|---|---|---|
| 平台层 | 网站代码、API 接口、检索服务 | 官方开源（GitHub / GitLab），代码多为 Apache-2.0 |
| 元数据层 | 书目字段、MeSH、资助信息 | 大部分为 CC0 或事实性数据，通常不受版权保护 |
| 内容层 | 摘要、全文、图表、补充材料 | 逐篇不同，由 license 字段声明 |
关键：第三层不能整库授权。 Europe PMC 只是聚合者，无权对你抓到的一篇 cc by-nc-nd 论文授权做任何派生。抓到不等于能用。
§9.2 内容层的五种许可与实操边界
| 许可 | 条数 | 商用 | 派生（微调/改写） | 再分发 | 实操建议 |
|---|---|---|---|---|---|
cc by |
6,571,562 | ✅ | ✅ | ✅（署名） | 首选，可放心用 |
cc0 |
69,447 | ✅ | ✅ | ✅ | 最优，无任何限制 |
cc by-nd |
23,093 | ✅ | ❌ | ✅（署名） | 只能原样分发，不能做指令微调 |
cc by-nc |
1,148,570 | ❌ | ✅ | ✅（署名，非商用） | 只能做学术研究，不能进商用模型 |
cc by-nc-nd |
1,630,225 | ❌ | ❌ | ✅（署名，非商用，原样） | 最严，只能用于阅读 |
「派生」在 LLM 语境下的争议：用 cc by-nd 的文本训练模型，算不算「派生作品」？法律上无定论。保守做法是排除 ND，即只取 cc by + cc0（664 万条）。这也是我们在 §7.7 给出的「可商用训练」上限。
§9.3 病原体与双重用途
Europe PMC 收录病原体相关文献，其中部分涉及增强型病原体研究（GOF）、病原体基因组操作细节。
这不是数据集的伦理问题，是使用的问题：
- 用这些文献训练通用模型 → 模型可能复述操作细节
- 用这些文献做知识检索 → 无额外风险（信息本就公开）
建议：若模型面向公众开放，在微调阶段对 ORGANISM 字段含高风险病原体的文献做降权或排除。欧洲已有相关立法讨论（如英国的 APC 框架），中国目前无专门规定，但《生物安全法》的原则性条款适用。
§9.4 数据主体权利与撤稿处理
文献层没有直接的患者数据，但有两个间接风险：
- 个案报道（case report）里可识别信息：即使论文本身合规，某些个案报道的细节组合仍可能重识别。Europe PMC 不做二次脱敏。
- 撤稿文献仍在库里：
commentCorrectionList会记录撤稿关系，但记录本身不删除。用它训练模型，会把撤稿结论当成正确知识。
处理建议：
- 抓取时检查
commentCorrectionList里是否有Correction/Retraction类型条目 - 对撤稿文献单独打标，训练时排除
- 定期重跑（撤稿是持续发生的）
§9.5 引用规范
官方推荐引用的是方法学论文：
Europe PMC in 2020. Nucleic Acids Research. PMID: 33180112 / PMCID: PMC7778976.
引用时还应说明：
- 抓取日期（因为库是日更的）
- REST 服务版本（当前 6.9）
- 查询语句（可复现性）
§10 复用边界与跨条目协作手册
§10.1 决策树：什么时候该用 Europe PMC
你要做什么？
├─ 找论文 / 查文献
│ ├─ 要全文检索 → Europe PMC ✅
│ ├─ 要引文网络 → OpenAlex / S2
│ └─ 要中文文献 → CNKI / 万方（Europe PMC 中文极少）
├─ 做 NLP 训练集
│ ├─ 要开放全文预训练 → PMC OA Subset ✅
│ ├─ 要实体/关系标注 → Europe PMC Annotations ✅
│ └─ 要句间谓词 → SemMedDB ✅
├─ 研究科研生态
│ ├─ 按资助方分析 → Europe PMC ✅（唯一入口）
│ ├─ 按机构分析 → OpenAlex 更好
│ └─ 预印本行为研究 → Europe PMC ✅（34 服务器汇总）
├─ 论文-数据配对
│ └─ Europe PMC ✅（40+ 库交叉链接）
└─ 临床试验结构化结果
└─ AACT ✅（Europe PMC 不做这个）
§10.2 与 PMC OA Subset 的配对（聚合池 ↔ 已筛子集）
分工：
| 场景 | Europe PMC | PMC OA Subset |
|---|---|---|
| 全量元数据统计 | ✅ | ❌（只有子集） |
| 全文预训练语料 | ⚠️ 需自行筛许可 | ✅ 已筛 |
| 预印本 | ✅ | ❌ |
| 专利 | ✅ | ❌ |
| 资助反查 | ✅ | ❌ |
| 标注 | ✅ | ❌ |
| 纯净、可直接训练 | ⚠️ | ✅ |
协作方式：用 Europe PMC 拿全量元数据与筛选条件，用 PMC OA Subset 拿已筛好的全文，两者按 PMID 对齐。这样既避免了在 4,911 万条上做许可筛查，又不必放弃聚合层的元数据丰富度。
§10.3 与 PubTator Central 的配对（两套标注的对照）
| 维度 | Europe PMC Annotations | PubTator Central |
|---|---|---|
| 覆盖文献 | 3,783 万（HAS_TM:Y） |
PubMed + PMC 全量 |
| 实体类型 | 42 类（官方声明） | 6 类（gene / disease / chemical / species / mutation / cell line） |
| provider | 多个团队 | NCBI 自研 |
| 标注粒度 | 章节级 | 摘要 + 全文 |
| 归一化 | 有 URI（MONDO / NCBITaxon 等） | 有 NCBI ID |
做多标注源一致性研究的最佳组合：同一批 PMID 分别从两个源取标注，比较重叠率与冲突率。这个数字本身就是一个有价值的数据集特征。
§10.4 许可梯度对照
| 资源 | 许可 | 可商用 | 可派生 |
|---|---|---|---|
| Europe PMC 元数据 | 事实性 / CC0 居多 | ✅ | ✅ |
Europe PMC 内容 cc by |
CC BY 4.0 | ✅ | ✅ |
Europe PMC 内容 cc by-nc |
CC BY-NC | ❌ | ✅ |
Europe PMC 内容 cc by-nd |
CC BY-ND | ✅ | ❌ |
Europe PMC 内容 cc by-nc-nd |
CC BY-NC-ND | ❌ | ❌ |
| PMC OA Subset | 各家（CC BY 为主） | ✅ | ✅ |
| PubMed 摘要 | 事实性 / 无明示 | ⚠️ | ⚠️ |
最后一行值得注意：PubMed 摘要的版权状态一直是灰色地带。Europe PMC 的 license 字段对无许可的记录返回空值——空值不等于公有领域。
§10.5 三个"不要做"
- 不要用
query=*抽样做统计分析。 默认排序下 99.7% 是 MED（实测 300 条里 299 条 MED）。必须按SRC分层。 - 不要把
hitCount当论文数。 同一研究的预印本、期刊版、专利是三条记录。去重前先看HAS_PUBLISHED_VERSION。 - 不要假设「开放获取」等于「可训练」。 835 万 OA 里只有 664 万是可商用许可。NC 与 ND 的 278 万条，进商用模型就是侵权。
§10.6 一句话总结
Europe PMC 是生命科学文献的「总闸门」——它不生产内容，它让你的检索式能同时触及期刊、预印本、专利、资助与数据；代价是 87% 的内容你只能读、不能训练。
附录 A：本篇数字速查
| 项 | 数值 | 取法 |
|---|---|---|
| 总记录 | 49,118,306 | search?query=*&pageSize=1 → hitCount |
| 服务版本 | 6.9 | 同上响应 → version |
| MEDLINE | 41,253,787 | query=SRC:MED |
| PMC | 1,013,126 | query=SRC:PMC |
| 预印本 | 1,268,930 | query=SRC:PPR |
| 专利 | 4,229,296 | query=SRC:PAT |
| Agricola | 1,026,549 | query=SRC:AGR |
| 引用记录 | 3,922 | query=SRC:CTX |
| 伦理 | 176,799 | query=SRC:ETH |
| 历史 | 2,868 | query=SRC:HIR |
| 有摘要 | 34,443,646 | query=HAS_ABSTRACT:Y |
| 有全文 | 12,439,494 | query=HAS_FT:Y |
| 有 PDF | 12,188,224 | query=HAS_PDF:Y |
| 开放获取 | 8,352,804 | query=OPEN_ACCESS:Y |
| 有补充材料 | 3,875,038 | query=HAS_SUPPL:Y |
| 有参考文献 | 27,461,924 | query=HAS_REFLIST:Y |
| 有文本挖掘标注 | 37,836,422 | query=HAS_TM:Y |
| 有数据链接 | 8,045,183 | query=HAS_DATA:Y |
| 有交叉引用 | 1,035,850 | query=HAS_XREFS:Y |
| 有 DOI | 35,298,177 | query=HAS_DOI:Y |
| 有预印本版本 | 442,403 | query=HAS_PREPRINT:Y |
| 有发表版本 | 452,629 | query=HAS_PUBLISHED_VERSION:Y |
| UniProt 链接 | 179,857 | query=HAS_UNIPROT:Y |
| PDB 链接 | 43,770 | query=HAS_PDB:Y |
| OMIM 链接 | 146,408 | query=HAS_OMIM:Y |
| ChEBI 链接 | 128,453 | query=HAS_CHEBI:Y |
| ChEMBL 链接 | 86,101 | query=HAS_CHEMBL:Y |
| InterPro 链接 | 99,162 | query=HAS_INTERPRO:Y |
| IntAct 链接 | 24,090 | query=HAS_INTACT:Y |
| PRIDE 链接 | 20,058 | query=HAS_PRIDE:Y |
| EMBL 链接 | 495,791 | query=HAS_EMBL:Y |
| 许可 cc by | 6,571,562 | query=LICENSE:"cc by" |
| 许可 cc by-nc | 1,148,570 | query=LICENSE:"cc by-nc" |
| 许可 cc by-nc-nd | 1,630,225 | query=LICENSE:"cc by-nc-nd" |
| 许可 cc by-nd | 23,093 | query=LICENSE:"cc by-nd" |
| 许可 cc0 | 69,447 | query=LICENSE:"cc0" |
| 有许可合计 | 9,792,835 | query=LICENSE:* |
| 可商用训练上限 | 6,641,009 | cc by + cc0 |
| 可检索字段 | 143 | /fields?format=json |
| 资助 Wellcome Trust | 219,369 | GRANT_AGENCY:"Wellcome Trust" |
| 资助 NIH | 358,115 | GRANT_AGENCY:"National Institutes of Health" |
| 资助 European Commission | 45,346 | GRANT_AGENCY:"European Commission" |
| 资助 NSFC | 1,150,423 | GRANT_AGENCY:"National Natural Science Foundation of China" |
| 资助 UKRI | 6,693 | GRANT_AGENCY:"UK Research and Innovation" |
| 2020 年文献 | 1,593,653 | query=PUB_YEAR:2020 |
| 2025 年文献 | 1,965,745 | query=PUB_YEAR:2025 |
| 2026 年文献 | 1,779,505 | query=PUB_YEAR:2026 |
| 预印本 2025 | 187,028 | query=SRC:PPR AND PUB_YEAR:2025 |
| 预印本 2026 | 184,983 | query=SRC:PPR AND PUB_YEAR:2026 |
| Agricola 2025 | 67,413 | query=SRC:AGR AND PUB_YEAR:2025 |
| 专利 2025 | 0 | query=SRC:PAT AND PUB_YEAR:2025（字段不适用） |
| 抽样源分布 | MED 299 / AGR 1 | 3 页 × 100 条 |
全部抓取时间：2026-10-23 15:15–15:20 UTC。
附录 B：五个可复制的查询
查询 1：总量与版本
curl -s "https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=*&format=json&pageSize=1" \
| python3 -c "import json,sys;d=json.load(sys.stdin);print(d['version'], d['hitCount'])"
# 输出：6.9 49118306
查询 2：可商用训练语料的规模（cc by + cc0 且开放获取）
curl -s -G "https://www.ebi.ac.uk/europepmc/webservices/rest/search" \
--data-urlencode 'query=OPEN_ACCESS:Y AND (LICENSE:"cc by" OR LICENSE:"cc0")' \
-d format=json -d pageSize=1 \
| python3 -c "import json,sys;print(json.load(sys.stdin)['hitCount'])"
查询 3：按资助方反查 + 有数据的论文
curl -s -G "https://www.ebi.ac.uk/europepmc/webservices/rest/search" \
--data-urlencode 'query=GRANT_AGENCY:"National Natural Science Foundation of China" AND HAS_DATA:Y AND PUB_YEAR:2025' \
-d format=json -d pageSize=1 \
| python3 -c "import json,sys;print(json.load(sys.stdin)['hitCount'])"
查询 4：游标分页抓取（Python，带退避与限速）
import json, time, urllib.parse, urllib.request
def epmc(query, result_type="core", cap=5000):
base = "https://www.ebi.ac.uk/europepmc/webservices/rest/search"
out, cursor = [], "*"
while len(out) < cap:
q = urllib.parse.urlencode({
"query": query, "format": "json",
"resultType": result_type, "pageSize": 1000, "cursorMark": cursor})
with urllib.request.urlopen(base + "?" + q, timeout=60) as r:
d = json.load(r)
batch = d["resultList"]["result"]
if not batch:
break
out += batch
cursor = d["nextCursorMark"]
time.sleep(0.12)
return out[:cap]
recs = epmc('HAS_PRIDE:Y AND PUB_YEAR:[2024 TO 2026]', cap=3000)
print(len(recs), recs[0]["title"][:60])
查询 5：取某篇文献的全部文本挖掘标注
curl -s "https://www.ebi.ac.uk/europepmc/annotations_api/annotationsByArticleIds?articleIds=MED:33180112&format=JSON" \
| python3 -c "
import json,sys
d=json.load(sys.stdin) # 注意：顶层是 list
for art in d:
print(art['extId'], len(art['annotations']))
for a in art['annotations'][:3]:
print(' ', a['type'], a['exact'], '->', a['tags'][0]['uri'])
"
查询 6（备用）：按 source 分层抽样，避开默认排序偏倚
for src in ["MED", "PMC", "PPR", "PAT", "AGR"]:
recs = epmc(f"SRC:{src}", result_type="lite", cap=200)
print(src, len(recs))
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- disease-ontology — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别 / 公共卫生与流行病学
- medmentions — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别
- biored — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别
- craft — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别
- semmeddb — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别
- medlexsp — 共享标签：医疗NLP / 生物医学文献 / 知识图谱 / 命名实体识别
- s2orc — 共享标签：医疗NLP / 生物医学文献 / 知识图谱
- litcovid — 共享标签：医疗NLP / 生物医学文献 / 公共卫生与流行病学
- cord-19 — 共享标签：医疗NLP / 生物医学文献 / 公共卫生与流行病学
- orphanet-ordo — 共享标签：知识图谱 / 命名实体识别 / 公共卫生与流行病学
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
