为假设策展数据
输入一个假设。输出一个经过实证支撑的Symposium社区记录语料库：每篇源文献对应一个ScientificPublication、支撑它的段落和表格，以及从中提取的Argument。
找到这些源文献是此技能的核心工作，也是本文档的大部分内容。将它们转化为工件则是Symposium的工作，第7步会将控制权移交过去。
术语
五份文档共享此词汇表。其定义在此处固定。
| 术语 | 含义 |
|---|---|
| 假设 | 形式为 If [原因], then [结果], because [理由] 的陈述 |
| 子句 | 假设的三个组成部分之一：原因、结果、理由 |
| 方面 | 从子句中提取的概念——实体、方法、群体或结果——以及一次运行用于搜索的词汇 |
| 索引 | 用于查询作品的服務：OpenAlex、Europe PMC、Crossref、PubMed、bioRxiv、Semantic Scholar |
| 存储库 | 存储已提交数据的服务：MassIVE、GNPS、MetaboLights、Metabolomics Workbench、PRIDE |
| 命中结果 | 索引返回的一个结果，在身份解析之前 |
| 作品 | 将一组命中结果解析到同一身份的结果——一篇预印本及其已发表版本被视为一个作品 |
| 起点 | 搜索保留下来作为假设直接答案的作品，也是遍历的起始点 |
| 源文献 | 属于语料库的作品 |
| 语料库 | 本次运行将发布的所有源文献 |
| 行 | 在审查表中显示的源文献 |
| 位置 | 文档存在的URL、DOI或入库号 |
| 地址 | Symposium工件引用，格式为 @名称 |
| 记录 | 正在发布到的Symposium社区记录 |
工作文件
一次运行保存的信息比对话能容纳的要多，并且审查表在每次操作后都会重绘。因此，一次运行会维护一个文件：
<用户主目录>/.symposium-curate-data/run.json— 此技能在用户主目录下的自有目录，路径按照宿主平台的拼写方式。- JSON格式，因为在长时间运行中需要逐个字段地更新。一个对象包含：假设、方面、规模、本次运行发布到的社区和句柄、每个源文献及其已知的所有信息，以及针对每个源文献记录的决策和发布状态。
从该文件渲染表格，而不是从内存中渲染。在重绘之前将每次操作写入该文件。因任何原因（审查循环、交接、会话丢失）停止的运行，通过读取该文件来恢复。
一旦确定社区和句柄，立即记录它们，并在每次恢复时重新建立该会话。 选定的会话属于选择它的代理会话，并且不会比该会话更持久，因此在新的会话中恢复的运行开始时没有会话——这是有意设计的，这样一台机器上的两个代理永远不会互相改变。运行必须跨会话携带的信息是它正在发布到哪个社区，因为恢复的运行如果继承了当前碰巧激活的任何会话，或者要求用户再次命名社区，可能会发布到错误的记录。该记录是只追加的，工件不能被撤回。因此：从工作文件中读取社区和句柄，选择该会话，确认它已被选中，然后才继续。如果恢复运行时无法选择记录中的社区，则停止并告知用户，而不是发布到其他地方。
一次只允许一个运行。如果已有正在进行的运行，在重新开始之前询问用户。
开始之前：确定发布位置
本次运行产生的所有内容都将进入一个Symposium社区记录 —— 只追加、通过会话访问、并由一个门控决定。因此，在搜索任何内容之前，需要确定两件事：
- 您正在工作的会话。
- 您是其成员并将发布到的社区。
如果还没有社区，则有一个完整的设置路径：启动数据服务器、使用community.json创建社区、并使用邀请文件加入。引导用户走完该路径，而不是绕开它。密钥和邀请以文件形式传输；密钥、密码或邀请应放在文件中，而聊天内容可能无法安全存放。
如果当前环境中没有任何可以操作Symposium社区记录的东西 —— 没有会话、没有社区、无法访问数据服务器 —— 则缺少Symposium技能，而它是必需的。请告知用户，并引导他们访问 https://github.com/ndexbio/symposium/releases 以将其与此技能一并安装。如果用户希望现在获得语料库而稍后再创建记录，搜索和策展功能仍然可以工作；第7步会等到Symposium技能就绪后再执行。
此次检查仅此而已。请求会话和社区是本次运行无论如何都需要做的工作，而返回的结果（或失败的原因）将表明记录是否可访问。
第 1 步 — 理解假设
一个假设陈述了所有三个子句：If [原因], then [结果], because [理由]。
如果缺少某个子句，请指出是哪一个，并与用户合作将其陈述清楚。理由是人们最容易遗漏的子句，并且它决定了三分之一的搜索内容。
然后将每个子句分解为方面——实体、方法、群体、结果。这些是本次运行的词汇：所有查询都基于它们构建，所有源文献都根据它们评分，并且限制遍历的阈值也以它们为度量。
在搜索任何内容之前，向用户展示这些方面。 错误的方面在此时修复成本很低，但在围绕它收集了四十个源文献之后修复成本很高。
第 2 步 — 确定规模
两个数字，这是用户唯一需要调整的旋钮。
在说出每个数字的名称之前，用用户自己的话说明每个数字计数的是什么。 起点和源文献是本文档的词汇，而规模问题正是用户首次遇到它们的时候。仅仅一个标签告诉他们这个数字叫什么，而不是它做什么；一个没人理解的数字是一个没人会去更改的数字。因此，先用简单的描述开头，并将术语放在括号内。
最大起点数 — 搜索保留下来作为假设最佳直接答案的作品，也是所有后续内容的起点。搜索会产生数百个候选结果；这个数字控制保留多少个最强的结果。更多的起点可以触及文献中那些没有共同引用关系的部分；更少的起点则围绕最强的作品形成一个更紧密、更深入的聚类。默认值 10。
最大源文献数 — 最终语料库的大小：进入审查表和记录的所有作品。它包括起点以及距其一跳引文距离内、在去重后得分足够高而被保留的作品。这是下游所有工作的预算，因为每个源文献都需要被获取、分类、显示为一行并发布。默认值 40。
同时说明两者的代价——大致需要多长时间，以及用户需要阅读多少行。类似于下面这样，并根据手头的假设进行调整：
两个数字决定了本次运行的规模。
起始论文（最大起点数） — 对您假设的最强直接答案。我将从这些论文向外搜索。默认值 10。
总论文数（最大源文献数） — 最终语料库的大小：这些起始论文加上它们的引文所指向的论文。每篇论文都会成为您审查的一行，并在记录中生成一组工件。默认值 40 — 大约需要阅读 40 行，并提交几百个工件。
一旦用户回答（无论是采用默认值还是指定了自己的值），就开始搜索。
第 3 步 — 搜索
四个基于三个子句的查询族，每个都在使用前经过校准。所有四个族中的最佳命中结果将成为起点。
第 4 步 — 扩展一跳
从起点向后、向前和侧向扩展，以起点阈值作为跳的定义。
第 5 步 — 解决访问权限
为每个源文献逐级尝试，对返回的结果进行分类，并为每个源文献记录状态和备注。
第 6 步 — 策展并与用户一起审查
身份、撤回状态、独立性和覆盖率。然后是审查循环：一张包含每个源文献及其状态的表格，用户逐行审阅，直到批准为止。
在他们批准之前，不发布任何内容。
第 7 步 — 将语料库移交给 Symposium
社区定义了一个源文献如何变成工件——完全在其自己的文档中。在此处命名其概念是为了使此步骤易于理解；它并不能替代实际阅读这些文档。因此：
1. 说明您正在做什么，并让社区的文档来回答。 您以此社区的成员身份，以导入者发布角色，将工件发布到其记录中：导入外部材料以便社区可以基于其进行论证，并提取源文献中的论点。
2. 在构建任何内容之前，请先阅读： 成员的操作说明；导入者发布角色的章程；关于可以从源文献中嵌入什么内容以及渲染在进入时可以更改什么的现行政策；以及提取论文论证的程序。遵循它们所做的所有后续引用。它们会相互链接，并且链条最末端的内容包含您最可能违反的规则。
3. 检查您是否已理解。 渐进式披露可能会悄无声息地失败：代理阅读了第一份文档，感觉已经了解，然后开始构建。因此，在构建之前，请用您自己的话说明：
| 您必须能够说出的内容 | 这意味着您已经阅读了 |
|---|---|
| 什么是工件、断言、支撑和假设，以及一个工件如何引用另一个工件 | 规范 |
导入者可以发布什么，import_method必须声明什么，以及当源文献抵抗保存时该角色应做什么 | 导入者的章程 |
| 为什么提取是两个行为，哪个先发生，以及两者之间发生了什么 | 提取程序 |
可以从源文献中嵌入什么，以及什么留在download后面 | 嵌入政策 |
| 渲染在进入时可以更改什么 | 保真度政策 |
如果您无法说出其中任何一项，则说明您阅读得不够：请返回并查找涵盖该主题的内容。此处不会重述任何内容，并且当此技能与社区自己的文档不一致时，社区的文档是正确的。
4. 首先同步并阅读已有记录。 它是只追加的，因此其中已有的任何内容都通过地址引用，而不是再次发布。
5. 为每个源文献构建： ScientificPublication、每个支撑所需的段落、Argument所依据的表格，以及从中提取的Argument。每个派生工件都通过其地址引用出版物，而不是重复其位置。所有这些都在--role importer下完成。
关于可以从源文献中获取什么，请参见 reference/TAKING.md：测量结果是对世界的观察，应如实记录；句子是作者的表达，应作为有界限、有归属的引用；所有派生内容都用您自己的话撰写。
6. 发布到记录中，该记录负责提交、排序和门控。
在每次提交之前确认会话。 不是只在开始时确认一次，也不是只在恢复时确认；而是在每次提交之前确认。会话是按代理进程选择的，并且在该进程中运行的任何内容都可以更改它——在提交之间运行业务逻辑门控是通常发生的情况，并且随后的发布将以执行业务逻辑门控的身份进行。下游没有任何东西能捕获到这一点。业务逻辑门控检查工件是否符合要求，而使用错误的句柄发布的工件可能完全符合要求；它携带的关于谁引入了材料的虚假陈述，而在一个无法撤回工件的记录中，这是一个永久性错误。
因此，请回读会话，将其与工作文件中的社区和句柄进行核对，如果会话已更改，则重新选择它。这是对永久性错误的一个低成本检查，而跳过它的代价只能在事后支付。
发布是耗时最长的部分
每个源文献会产生多个工件，并且派生工件在其引用的出版物被接受之前无法提交——因此提交是串行的，并且依赖的工件之间有业务逻辑门控。四十个源文献意味着几百次提交和大量的判断：段落选择、一个Argument、两个方法属性，每次都需要重新撰写。
风险不是失败，而是退化。代理在深入四十个源文献后会陷入模板化，而模板化的Argument正是此技能旨在避免的缺陷，但它会因疲惫而出现。
因此，逐步发布。 逐个源文献地进行。将每个已发布的源文献记录在工作文件中。停止的运行将从那里恢复。在批准停止时告知用户这是耗时最长的部分，可以分多次进行——每个源文献的质量才是关键；一次性完成列表不是目标。
纠正已发布的内容
如果本次运行已发布的某个工件被发现是错误的，则应由您进行纠正，遵循以下测试标准。记录期望成员纠正自己工作中的缺陷，而一次涉及四十个源文献的运行如果每次都停下来询问用户，将会把用户的注意力浪费在不需要思考的决策部分上。
需要纠正的情况是任何人都可以通过查看来确定的缺陷：文件中不支持的计数、源文献中不存在的引用、指向错误出版物的地址。不需要纠正的情况是改进——更好的理由、更清晰的断言、更早的源文献与后来源文献的形状保持一致。第二种情况是诱惑您的情况，并且它来得较晚：处理了三十个源文献后，前五个读起来像是学徒之作。它们是本次运行在那个时候发布的记录，保留它们才能使后来的那些作品有意义。
测试标准是，两个引用是否能解决问题。 将工件所陈述的内容与源文献中的内容以及工作文件中的记录进行对比。如果它们一致，则不是需要纠正的情况；继续前进。如果它们不一致，则进行纠正，重新提交受影响的工件，并记录您所做的更改。
结束语
构建一个经过实证支撑的语料库需要来源、判断和用户审查。此技能将三者联系起来，但它不能替代它们。源文献的质量取决于对它们的关注程度，Argument的严谨性取决于提取它们所付出的努力，而记录的价值取决于社区为其设定的标准。