為假說策展數據
輸入一個假說。輸出一個 Symposium 社群記錄中具有根據的語料庫：每個來源一個 ScientificPublication，作為其根據的段落和表格，以及從每個來源提取的 Argument。
尋找這些來源是此技能的工作，也是本文件的主要內容。將它們轉化為成品是 Symposium 的工作，步驟 7 將負責交接。
術語
五份文件共享此詞彙表。在此確定。
| 術語 | 含義 |
|---|---|
| 假說 (hypothesis) | 一個 如果 [原因]，則 [結果]，因為 [理由] 格式的陳述 |
| 子句 (clause) | 其三部分之一：原因、結果、理由 |
| 面向 (facet) | 從子句中提取出的概念——實體、方法、族群或結果——以及一次運作所搜尋的詞彙 |
| 索引 (index) | 為作品提供查詢服務：OpenAlex、Europe PMC、Crossref、PubMed、bioRxiv、Semantic Scholar |
| 儲存庫 (repository) | 存放已提交資料的服務：MassIVE、GNPS、MetaboLights、Metabolomics Workbench、PRIDE |
| 命中 (hit) | 索引返回的一個結果，在身份解析之前 |
| 作品 (work) | 身份將一組命中解析成的對象——一篇預印本及其已發表版本視為同一作品 |
| 原始論文 (origin) | 搜尋保留作為假說直接答案的作品，以及遍歷的起點 |
| 來源 (source) | 語料庫中的一個作品 |
| 語料庫 (corpus) | 此次運作將發布的來源 |
| 列 (row) | 審查表格中顯示的來源 |
| 位置 (location) | 文件所在的 URL、DOI 或存取號 |
| 位址 (address) | Symposium 成品參考，寫作 @name |
| 記錄 (the record) | 正在發布到的 Symposium 社群記錄 |
工作檔案
一次運作所容納的內容超過對話所能承載，且審查表格在每次操作後都會重新繪製。因此，一次運作會保留一個檔案：
<使用者主目錄>/.symposium-curate-data/run.json— 此技能自身的目錄，位於使用者的主目錄中，並按照主機平台的路徑格式書寫。- JSON，因為它在長時間運作中每次只更新一個欄位。一個物件，包含假說、面向、規模、此運作發布的社群和代號、每個來源及其所有已知資訊，以及針對每個來源記錄的決定和發布。
從該檔案渲染表格，而不是從記憶體中。在重新繪製之前，將每個操作寫入該檔案。因任何原因（審查迴圈、交接、連線中斷）停止的運作，都會透過讀取該檔案來恢復。
在社群和代號確定後立即記錄下來，並在每次恢復時重新建立該工作階段。 一個已選擇的工作階段屬於選擇它的代理工作階段，並且不會比它更長久，因此在新會議中接續的運作開始時不會有任何工作階段——這是設計使然，以避免同一台機器上的兩個代理互相改變對方的運作。運作必須跨越間隙攜帶的是它正在發布到哪個社群，因為一個恢復的運作如果繼承了任何當前有效的工作階段，或者要求使用者再次指定社群，可能會發布到錯誤的記錄。該記錄是僅可追加的，且成品無法撤回。因此：從工作檔案中讀取社群和代號，選擇該工作階段，確認已選中它，然後才繼續。如果運作恢復時無法選擇記錄的社群，則停止並告知，而不是發布到其他地方。
一次只進行一個運作。如果已有運作正在進行，在覆蓋它之前先詢問使用者。
開始之前：確定發布位置
此運作產生的所有內容都將進入一個 Symposium 社群記錄——僅可追加，透過工作階段存取，並由一道閘門決定。因此，在搜尋任何內容之前，先確定兩件事：
- 您正在使用的工作階段。
- 您所屬且將發布到的社群。
如果尚無社群，則有解決途徑：啟動資料伺服器、使用 community.json 建立社群，並使用邀請檔案加入。引導使用者走過該途徑，而不是繞過它。金鑰和邀請以檔案形式傳遞；金鑰、密碼或邀請應存放在檔案中，而聊天可能不適合存放這些內容。
如果此環境中沒有任何東西可以操作 Symposium 社群記錄——沒有工作階段、沒有社群、無法連線到資料伺服器——則表示缺少 Symposium 技能，而這是必需的。請告知使用者，並引導他們前往 https://github.com/ndexbio/symposium/releases 將它與此技能一起安裝。如果使用者希望現在取得語料庫而稍後再建立記錄，搜尋和策展仍然有效；步驟 7 會等待直到該技能就緒。
該嘗試即是檢查的全部內容。無論如何，此運作都需要請求一個工作階段和一個社群；返回的結果（或失敗的結果）會告訴我們記錄是否可達。
步驟 1 — 讀取假說
一個假說應陳述所有三個子句：如果 [原因]，則 [結果]，因為 [理由]。
如果缺少某個子句，請指出是哪個，並與使用者合作將其陳述出來。理由是人們經常遺漏的子句，而它是決定三分之一搜尋目標的子句。
然後將每個子句分解成面向 (facets)——實體、方法、族群、結果。這些是運作的詞彙：每個查詢都由它們建構，每個來源都根據它們評分，而界定遍歷範圍的閾值也以它們為單位來衡量。
在搜尋任何內容之前，向使用者展示面向。 錯誤的面向現在修正的代價很低，但在收集了四十個來源之後則代價高昂。
步驟 2 — 同意規模
兩個數字，這是使用者唯一需要調整的控制項。
在命名數字之前，用使用者的語言說明每個數字計算的是什麼。 原始論文和來源是本文檔的詞彙，而規模問題是使用者第一次遇到它們的地方。單獨的標籤只告訴他們數字叫什麼，而不是它的作用；一個没人理解的數字就是一個没人會改變的數字。因此，先以平實的描述說明，並將術語保留在括號中。
最大原始論文數 (Max Origins) — 搜尋保留下來作為假說最佳直接答案的作品，以及所有其他內容從中發展出的起點。搜尋會產生數百個候選；這是它保留的最強者的數量。更多的原始論文可以觸及文獻中那些彼此不互相引用的部分；更少的原始論文則會圍繞最強的作品形成更緊密、更深入的集群。預設值 10。
最大來源數 (Max Sources) — 最終語料庫的大小：每個到達審查表格和記錄的作品。它是原始論文數加上一次引用跳轉範圍內、得分足夠高且已消除重複的作品總數。它是所有後續工作的預算，因為每個來源都需要被獲取、分類、顯示為一行，並發布。預設值 40。
將兩者與它們的成本一起提出——大約運作需要多長時間，以及使用者需要閱讀多少行。類似以下內容，並根據實際假說進行調整：
兩個數字設定此運作的範圍。
起始論文（最大原始論文數） — 對您假說最強的直接答案。我從這些論文向外搜尋。預設值 10。
總論文數（最大來源數） — 最終語料庫的大小：這些起始論文加上它們的引文所導向的論文。每一篇都會變成您審查的一行，以及記錄中的一系列成品。預設值 40 — 大約需要閱讀 40 行，以及提交數百個項目。
一旦他們回答（無論是接受預設值還是自行設定），就開始搜尋。
步驟 3 — 搜尋
基於三個子句產生的四個查詢系列，每個系列在使用前都經過校準。所有四個系列中的最佳命中將成為原始論文。
步驟 4 — 擴展一次跳轉
從原始論文向後、向前和側向擴展，以原始論文的閾值作為此次跳轉的定義。
步驟 5 — 解決存取權限
為每個來源依序嘗試存取方法，分類返回的結果，並為每個來源留下一個狀態和備註。
步驟 6 — 策展，並與使用者審查
身份、撤回狀態、獨立性和覆蓋率。然後是審查迴圈：一個包含每個來源及其狀態的表格，使用者逐行處理直到批准。
在使用者批准之前，不發布任何內容。
步驟 7 — 將語料庫交給 Symposium
社群定義了來源如何變成成品——完全在其自身文件中。在此命名其概念是為了讓此步驟易於理解；它不能替代實際去閱讀它們。因此：
1. 說明您正在做什麼，並讓社群的文件來回答。 您正在以此社群的成員身分，將成品發布到其記錄中，並擔任 importer 發布角色：匯入外部材料以便社群能以此為根據，並提取來源所提出的論證。
2. 在構建任何內容之前，請閱讀： 成員的操作說明；importer 發布角色的章程；關於可從來源嵌入哪些內容以及渲染在匯入時可以更改哪些內容的常規政策；以及提取論文論證的程序。遵循它們所做的每一個後續參考。它們會互相指向對方，而鏈條中最末端的文件承載著您最可能違反的規則。
3. 確認您已經理解。 漸進式揭露很容易失敗：代理閱讀了第一份文件，感覺有了方向，然後開始構建。因此，在您構建之前，請用您自己的話來說明：
| 您必須能夠說明的事項 | 這表示您已讀到 |
|---|---|
| 什麼是成品 (Artifact)、斷言 (Assertion)、根據 (Ground) 和假設 (Assumption)，以及一個成品如何指向另一個成品 | 規格說明 |
importer 可以發布什麼、import_method 必須說明什麼，以及當來源拒絕保存時該角色的作用 | importer 的章程 |
| 為什麼提取是兩個動作，哪一個在先，以及它們之間發生了什麼 | 提取程序 |
可以從來源嵌入什麼，以及什麼應保留在 download 之後 | 嵌入政策 |
| 渲染在匯入時可以更改什麼 | 忠實度政策 |
如果您無法說明其中一項，表示您讀得太少：回頭尋找涵蓋該主題的文件。此處不再重述，如果此技能與社群自身文件不一致，以社群文件為準。
4. 先同步並讀取記錄。 它是僅可追加的，因此其中已有的任何內容都將通過位址引用，而不是再次發布。
5. 為每個來源構建： ScientificPublication、每個 Ground 所需的段落、Argument 所依據的表格，以及從中提取的 Argument。每個衍生成品透過其位址來引用出版物，而不是重複其位置。所有操作均在 --role importer 下進行。
關於匯入時可以從來源獲取什麼，請參閱 reference/TAKING.md：測量值是對世界的觀察，應如實記錄；句子是作者的表述，應作為有界限、有歸屬的引文；所有衍生的內容都應用自己的話語撰寫。
6. 發布到記錄中，記錄擁有提交、排序和閘門的控制權。
在每次提交前確認工作階段。 不是只在開始時確認一次，也不是只在恢復時確認：而是在每次提交前確認。工作階段是按代理程序選擇的，且在該程序中執行的任何程式碼都可以更改它——在兩次提交之間執行閘門是常見的發生方式，而後續的發布將會以閘門所執行的身分發出。下游沒有任何機制可以捕捉到這個錯誤。閘門在檢查成品是否符合規範，而在錯誤代號下發布的成品會完美地符合規範——它所攜帶的是一個關於誰匯入了材料的虛假陳述，存在於一個無法撤回的記錄中。
因此，請讀回工作階段，根據工作檔案中的社群和代號進行檢查，並在工作階段已變更時重新選擇它。這是一個針對永久性錯誤的廉價檢查，而跳過它的代價只能在事後支付。
發布是最耗時的部分
每個來源會變成數個成品，而衍生成品必須在其引用的出版物被接受後才能提交——因此提交是序列化的，且依賴性之間的閘門必須執行。四十個來源意味著數百次提交和大量的判斷：段落選擇、一個 Argument、兩個方法屬性，每個都需要重新撰寫。
風險不是失敗，而是品質下降。進行到四十個來源深處的代理會陷入模板化的模式，而模板化的 Argument 正是此技能旨在避免的缺陷，它源於疲勞。
因此，請增量發布。 逐個來源進行。在每次提交來源時，檢查工作階段。將每個已發布的來源記錄在工作檔案中。一個停止的運作會從該處恢復。在批准停止時告知使用者，這是耗時的部分，可以分次進行——每個來源的品質才是重點，一口氣完成整個列表並非目標。
修正已發布的內容
如果此運作已發布的某個成品被發現是錯誤的，修正工作應由您根據以下測試來完成。記錄期望成員修正其自身作品的缺陷，而一個包含四十個來源的運作，如果對每個來源都停下來詢問，將會耗盡…
…[為翻譯而截斷]