data-availability

数据可用性

概述

使用此技能，将支持稿件的数据整理成可直接用于投稿的可用性资料包：声明文本、仓库计划、源数据映射，以及未解决风险标记。

此技能的适用范围比 submission-audit 更窄，比 scientific-writing 更偏重实际操作。当瓶颈不再是论文的叙事，而是数据共享资料包是否具体、持久且符合期刊投稿要求时，请使用此技能。

适用场景

在以下情况下使用此技能：

• 稿件需要 Data Availability 声明
• 登录号、DOI、仓库记录或源数据文件缺失或不稳定
• 论文同时包含生成的数据、重复使用的公共数据和受限数据
• 需要收紧或替换「应要求提供」的措辞
• 投稿或修订需要编辑能快速审核的数据共享文本

以下情况请勿使用此技能：

• 与数据共享无关的通用章节改写
• 全面重构稿件
• 不影响数据集可用性的参考文献清理

工作流程

1. 确定目标期刊和文章类型。
2. 清点支持主要结论和补充结论的数据集：
   • 原始数据
   • 处理后数据
   • 图表源数据
   • 重复使用的公共数据集
   • 检查结果所必需的代码相关输出
3. 为每个数据集指定唯一一种访问途径：
   • 公共仓库
   • 受控访问仓库
   • 收录于论文或补充材料中
   • 重复使用的公共来源
   • 第三方限制访问
   • 有正当理由的申请途径
4. 起草声明前，确定仓库和标识符方案。
5. 明确写出数据集与存放位置的对应关系。
6. 检查声明是否涵盖新生成的数据和重复使用的数据。
7. 标记未解决的字段，不要捏造仓库名称、登录 ID、DOI 或访问规则。

工作规则

• 尽可能优先选择公共的学科专用仓库。
• 除非确实存在法律、伦理、商业或第三方限制，否则应将 available upon request 视为较弱的表述。
• 如果数据无法公开，应说明：
  • 限制访问的原因
  • 由谁控制访问
  • 如何审核申请
  • 哪些元数据、源数据或衍生数据仍可公开
• 除非期刊明确要求，否则不要将数据、代码、方案和材料合并成一句含糊的可用性声明。
• 不要捏造登录号、DOI、仓库名称、审稿人链接或禁运条款。
• 只列出分析实际使用的资源，并明确说明其来源（「所有响应数据均来自 [collection]，[DOI]」）。不得列出研究未使用的资源；如果来源中没有记录某个标识符，应直接省略，而不是坦承其「未公开」或「无法识别」；应将此类缺漏标记给作者。
• 不作任何承诺：只说明当前实际存在的途径和文件。只有在确实存在相应途径或文件时，才提及「应要求提供」和「源数据文件」；不得提及未来发布或安排访问（「将发布」「计划在接收前发布」「可以安排」）。
• 写明科学内容，而非仓库布局：声明中不得出现文件夹路径（source_data/）、文件操作细节或工作簿使用说明。
• 写出实际使用的公共仓库名称，例如，用于处理后输入的 Hugging Face 数据集和用于代码的 GitHub 仓库；并确保代码可用性声明与已发布仓库的内容一致。
• 补充材料中的数据来源表每项已用资源占一行，不应包含每行内容都相同的列；引用的出版物应取自稿件自身的参考文献，以避免两者不一致。尽可能根据分析表生成此表。

相关文件

仅在需要时打开以下文件：

• references/statement-patterns.md 用于起草或修订实际声明文本。
• references/repository-routing.md 用于确定每个数据集应存放的位置，以及所需的标识符类型。
• references/source-data-checks.md 用于检查图表和补充材料是否提供了足够的底层数据。
• references/fair-metadata-checklist.md 当期刊要求提供符合 FAIR 或 DataCite 风格的数据集元数据或正式的数据集引用时使用。
• references/chinese-author-alignment.md 用于将中文数据可用性声明草稿与英文投稿措辞对齐。

输出标准

使用此技能时，返回：

• 可直接粘贴的 Data Availability 文本
• 仍需完成的存储库和标识符操作
• 缺失信息或阻碍风险
• 一则简短说明，指出当前材料属于以下哪种状态：
  • ready_to_submit
  • draft_with_placeholders
  • needs_author_input
  • blocked