Bibliometria: 產生錯誤數字的陷阱
此技能並非教授書目計量學。它教的是最常見的特定錯誤，所有這些錯誤都有一個共同特徵：一個看似正確但實質錯誤的數字。 這些錯誤在閱讀時都不會出現；只有在測量時才會顯現。
統整所有規則的原則是：
永遠不要在沒有測量存在的情況下斷言不存在。 「零」是一個強烈的陳述， 表示「我在正確的地方、用正確的方式找過了，而且沒有」。但通常它代表別的意思。
1. 「零」有六種原因，只有一種是真正不存在。
這些原因分為兩組，驗證方式不同。
四種可透過查詢消除
每種都有具體的測試方法。只需要一次 API 呼叫，結果是客觀的。
| 原因 | 測試 | 範例 |
|---|---|---|
| 資料庫錯誤 | 在不同覆蓋範圍的資料庫（OpenAlex, Crossref, DOAJ）中重複查詢 | "maçonaria"：在 PubMed 為 0，在 OpenAlex 為 1,529 |
| 欄位錯誤 | 在其他索引欄位中重複該詞彙：[Author], [Journal], topics.id | "amilton iatecola"[tw] = 0；"iatecola amilton"[Author] = 11 |
| 查詢失敗 | 讀取錯誤處理方式：是否存在某個路徑在 except 中回傳 0？ | OpenAlex 的 429 錯誤被轉換為零 |
| 算術錯誤 | 確認交集的所有因數都大於 0 | 交集為 0 是因為其中一個前端已經是 0 |
作者姓名： PubMed 索引格式為 姓 名；但人們通常寫成 名 姓。在斷言作者沒有發表文章之前，請測試這兩種順序。
兩種無法消除，只能聲明
對於這兩種原因，沒有通用的測試方法，假裝有辦法測試比承認沒有更糟。
- 語言錯誤，要證明需要搜尋所有語言。所能做的只是聲明：搜尋是在哪種語言下進行的，以及資料庫的控制詞彙是否屬於另一種語言。（MeSH 是英文；葡萄牙文的詞彙會落入自由文字，並失去索引的同義詞。）
- 策略不完整，要證明完整性需要知道完整的策略，而這正是未知的部分。所能做的只是聲明：使用了什麼策略（完整寫出），以便他人可以反駁它。
對允許使用的語句強度產生的影響
在消除了前四種原因並聲明了後兩種原因之後，可以寫：
"在此資料庫中，使用此策略，在此時間範圍內，沒有記錄。"
絕不能寫：
"關於這個主題沒有文獻。"
前者是可以維持的且可以被反駁的，其他人可以改變策略並顯示相反的結果，這才是正確的方式。後者是站不住腳的，因為它對所有未被查詢的事物做出了斷言。
關於 OpenAlex 的備註
它按請求收費（US$ 0.001），並有每日預算，在 UTC 午夜歸零。預算用盡後，它會回傳 429，並附帶 Insufficient budget (...) Resets at midnight UTC 和數小時的 Retry-After。因此，那裡的 429 有兩個需要相反回應的原因：太快（等待就能解決）和當日配額用完（無法解決）。在做出反應之前先讀取訊息內容；密集的 session 會耗盡配額。
2. 表面比對大部分正確，但錯誤的部份足以造成影響
所有基於字串的比對都需要完整包含，絕不能僅靠共享的單字。真實案例：
- MeSH 為 "retinopatia diabética" 回傳了
Hypoglycemia, Neonatal, Simulating Foetopathia Diabetica，這是合法的描述詞，但疾病是錯的，因為它包含了 "diabética"。 - Wikipedia 將
Escala de Equilíbrio de Berg作為 "teleconsulta" 的翻譯回傳，因為該文章提及了遠距醫療。前端變成了"teleconsulta" OR "Berg Balance Scale"：在一場關於遠距諮詢的搜尋中，出現了 2,456 筆關於平衡量表的記錄。 - 一篇文章因為標題中含有
SHIMMER（病歷索引的縮寫，並非聲學參數）而進入了語音搜尋的結果。
規則： 相關性搜尋 ≠ 概念等同。模糊搜尋的第一個結果不是翻譯、不是同義詞，也不是同一個實體。
3. 合併變體：錯誤在於合併，而不是保持分離
根據相似性建議合併，在一次測試中產生了十一條建議，幾乎全部錯誤：
Type 1 diabetes→Type 2 diabetes（不同的疾病；數字本身就是全部差異，而過濾器丟棄了 ≤2 個字符的 token）Diabetes mellitus→Type 2 Diabetes Mellitus（屬變成種）University of Baltimore→University of Maryland, Baltimore（兩個不同的機構）
規則： 數字絕不是短 token；「包含」適用於作者和機構，但絕對不適用於概念（在那裡子字串代表階層關係）；要求相等的區別性單詞，而不是子集。少合併的代價是一次點擊；過度合併會在圖表上產生一個看似正確但實際上是錯誤的合併。最終決定始終由人來做。
4. 透過兩種方式檢查總和
導入器將識別碼截斷為 24 個字符以生成鍵。來自同一出版社的 DOI 共享前綴，導致衝突，一個覆蓋了另一個，輸出顯示 "54 個新"，但語料庫實際上是 49。五篇文章悄悄消失了。
這個錯誤在沒有人核對時就會發生。務必：之前 + 新 == 之後 且 新 + 已存在 == 讀取總數。如果數字對不上，請說明對不上。
5. 腳本上限 ≠ 欄位大小
在一個導向搜尋腳本中，設定了 per_page=25 + rows=20。13 個查詢中沒有一個在報告中超過 45，因為 45 是上限。實際覆蓋率相差三個數量級：在 data literacy teacher education 中為 0.2%，在 DigCompEdu validation 中為 83%。
這並不否定導向搜尋的價值，它的存在是為了找到關鍵作品。但這個數字無法支持關於大小或覆蓋率的陳述。如果有截斷，請說明有多少被排除在外。
6. 始終聲明範圍
「整個語料庫」和「已納入」的指標無法比較。一個主題有 53 篇被收集，0 篇被篩選，結果回報「沒有記錄有 DOI」，從計數上看是正確的，但其含義是具有誤導性的。請在每個輸出中說明範圍。
7. 全文與補充資料：路徑取決於文章類型
在搜尋 Benke et al. (2025) 的寡核苷酸序列時：Claude Science 嘗試了 PMC 的 OA 服務和 FTP，在這三條路徑上都收到了 404，然後陷入循環。補充資料確實存在；只是路徑錯了。這裡的 404 是錯誤的路徑，而不是不存在（這是第 1 節中的「查詢失敗」）。
有效的順序：
- PMCID：
elink.fcgi?dbfrom=pubmed&db=pmc&id=<PMID>。沒有 PMCID，PMC 中就沒有開放的全文；請前往 DOI 查看出版社是否提供開放取用。 - 全文：
efetch.fcgi?db=pmc&id=<PMCID 編號>&retmode=xml。這對開放取用文章和 NIH 作者的手稿都有效。方法、表格和數字都來自這裡。 - 補充資料列表： 在同一個 XML 中，帶有
xlink:href的標籤<supplementary-material>提供了每個檔案的名稱。在下載之前，先確定你要找什麼。 - 文章類型： 如果 XML 中有
<article-id pub-id-type="manuscript-id">NIHMS...，這是作者手稿，步驟 5 的路徑不適用於其補充資料。 - 出版社開放取用文章的補充資料： Europe PMC，
https://www.ebi.ac.uk/europepmc/webservices/rest/<PMCID>/supplementaryFiles，回傳一個 zip 檔案（PMC12904924：4.5 MB 的 zip 檔）。 - NIHMS 手稿的補充資料： Europe PMC 回傳空回應（297 bytes，PMC11700762），PMC 的 OA 服務（
/utils/oa/oa.fcgi）和 FTP 都回傳 404，而連結pmc.ncbi.nlm.nih.gov/articles/instance/<id>/bin/<檔案>會開啟一個顯示「Preparing to download...」的頁面，這需要瀏覽器。這是反機器人機制：不要繞過它。 請停止，說明需要哪個檔案，並要求使用者透過瀏覽器下載，然後將其以你指定的名稱儲存到套件的資料夾中。 - 在要求使用者操作之前，先嘗試出版社。 NIHMS 手稿在出版社端也有對應的版本。在 Elsevier，Crossref 提供 PII（
alternative-id），補充資料通常位於公共 CDNhttps://ars.els-cdn.com/content/image/1-s2.0-<PII>-mmc1.pdf（如果回傳 404 請更換副檔名）。Benke 2025（PII S0956566324010595）就是透過這種方式在 13/10/2026 取得的：200，1.5 MB 的 PDF，沒有障礙。
絕對不要做的事： 因為補充資料沒打開，就憑記憶重建序列、目錄編號、體積或溫度。不是來自檔案的內容都保持「待定」，並附上缺少的檔案名稱。
在路徑之間循環之前： 如果兩個不同的路徑對同一個檔案都回傳了 404，請停止並檢查文章類型（步驟 4），而不是嘗試第三個路徑。
無法繞過的限制
- CAPES 法令 275/2023，第 50 條 禁止使用機器人或智慧型代理程式存取或下載受合約保護的內容，且此禁令涵蓋授權使用者。Scopus、Web of Science、CAPES 入口網站、Google Scholar：請建構查詢字串，在旁邊開啟資料庫，然後接收匯出結果。切勿自動化其介面。
- 絕對不要寫入
zotero.sqlite。 只能以mode=ro&immutable=1進行讀取。 - 絕對不要覆寫篩選決策。 元資料可以重建；但人類的判斷不行。
- 絕對不要在沒有透過 API 驗證的情況下引用識別碼。 偽造的 DOI 在閱讀時與真實的無法區分。
交付前檢查
- 每個「零」是否都已由六種原因之一解釋？
- 每個總和是否都透過兩種方式驗證？
- 每次截斷是否都說明了有多少被排除在外？
- 是否每個範圍都已聲明？
- 每個變異合併是否都經過了人為決定？