1. Was ich eigentlich vorhatte
Ich war nicht auf der Suche nach einer Produktidee. Ich war dabei, eine Arbeit fertigzustellen, sechsundsiebzig Referenzen tief in der Literatur zu KI-Kompetenz in der Bildung, und wollte vor der Abgabe genau eine Sache wissen: die Gewissheit, dass keines meiner Zitate eine tote DOI hatte, oder schlimmer, die falsche DOI, die still auf die Arbeit einer anderen Person zeigt. Also tat ich das Naheliegende — exportierte meine gesamte Bibliothek aus Zotero nach BibTeX, dem Werkzeug, das ich für jede Arbeit benutze, die ich schreibe, demselben Werkzeug, zu dem die meisten Menschen in dieser Lage greifen. Ich öffnete die Datei in der Erwartung, die DOIs eine nach der anderen durchzugehen.
So weit kam ich nicht. Die Datei selbst war das Problem.
2. Ein Titel mit den Attributen eines Tags als Klartext
Der Eintrag armstrong_when_2014 in meiner eigenen Bibliothek ist eine kurze, viel zitierte Methodenarbeit darüber, wann man für multiple statistische Vergleiche korrigieren sollte.[1] Sein Titelfeld, in der Datei, die Zotero mir ausgehändigt hat, lautete vollständig:
Der echte Titel lautet „When to use the Bonferroni correction“. Irgendwo vor Zotero — von Verlagen hinterlegte Metadaten machen das routinemäßig, um den ersten Buchstaben eines Namens in Kapitälchen darzustellen — war der Titel als HTML gespeichert worden: <span style="font-variant:small-caps;">B</span>onferroni. Zotero kann kein wörtliches < oder > in ein BibTeX-Feld schreiben — beides würde LaTeX zum Absturz bringen —, also hat der Exporter nur die spitzen Klammern maskiert, zu {\textless} und {\textgreater}, und alles, was im Tag stand, als reinen Text im Feld belassen. Das Tag war weg. Sein Inhalt — span, style="font-variant:small-caps;", das schließende /span — nicht. Als Fließtext gelesen, war aus dem Titel einer echten, korrekt veröffentlichten Arbeit in meinem eigenen Literaturverzeichnis geworden:
Diesen Fehler von Hand bis auf die einzelne geschweifte Klammer zurückzuverfolgen, um genau zu bestimmen, wo das Tag steckengeblieben ist, ist wahrscheinlich der deutscheste Absatz in diesem ganzen Artikel.
Zoteros eigenes, automatisch erzeugtes shorttitle-Feld für denselben Eintrag zeigt den Fehler mitten im Zusammenbruch erwischt, und das hat mir gezeigt, dass es kein einmaliger Anzeigefehler war: Was auch immer für Zoteros internen Gebrauch einen Titel kürzt, arbeitete mit derselben verstümmelten Zeichenkette und wusste ebenso wenig, dass es mitten in einem Tag stand, wie der Export selbst.
Das ist genau die Art von Fehler, die ein Werkzeug zur Zitationsprüfung durchschauen können muss, statt darüber zu stolpern. Vergleicht man diese Zeichenkette, so wie geschrieben, mit dem sauberen Titel, den Crossref für die DOI 10.1111/opo.12131 führt, gibt es keine nennenswerte Übereinstimmung — ein Fehlalarm gegen ein Zitat, das tatsächlich exakt richtig ist. Deshalb löst der Ingest, den StrictCite bei jedem Upload durchführt, die maskierten Klammern wieder in ein echtes Tag auf, erkennt es als Markup statt als Teil des Titels, und entfernt es — wobei die Lücke geschlossen wird, die genau dieser Tag-Stil am ersten Buchstaben eines Wortes hinterlässt, sodass der Vergleich „Bonferroni“ liest, nicht „B onferroni“. Das gilt unabhängig davon, ob das Markup als echtes <span> direkt aus dem JSON einer Registry kommt — Crossref und OpenAlex tun das beide —, oder, wie in meiner eigenen Datei, LaTeX-maskiert von einem Exportwerkzeug, das keine Möglichkeit hatte zu wissen, dass es mitten in einem stand.
3. Derselbe Mechanismus, ein Feld weiter
Ein Konferenzbeitrag weiter unten in meiner eigenen Bibliothek trägt denselben Fehler im Kleinen. Das booktitle-Feld für eine CSEE&T-Arbeit von 2024[2] lautete:
Dieser Fall ist doppelt kodiert statt nur halb entblättert: Die Quellmetadaten hatten das Et-Zeichen bereits als HTML-Entität & ausgeschrieben — selbst ein Zeichen dafür, dass irgendwo vorher jemand einen Wert nicht dekodiert hat, den er hätte dekodieren sollen —, und Zoteros Exporter hat, als er ein wörtliches &-Zeichen innerhalb dieser Entität fand, es zusätzlich für LaTeX mit einem Backslash maskiert. Sechs Zeichen erledigten jetzt die Arbeit eines einzigen. Wörtlich gelesen zitierte mein eigenes Literaturverzeichnis eine Konferenz namens „CSEE&T“, nicht „CSEE&T“. StrictCite dekodiert eine HTML-Entität, bevor irgendeine LaTeX-spezifische Behandlung greift, sodass ein Wert, der bereits eine solche trug — ganz gleich, welche Seite sie eingeführt hat —, zu genau dem Zeichen aufgelöst wird, das er immer meinte, und nicht zu einer der beiden Hälften der Doppelkodierung.
4. Eine Seitenzahl, die eine Dateigröße ist
Der dritte Fehler in meiner eigenen Datei war überhaupt kein Markup-Problem. Ein Melbourne/KPMG-Bericht von 2025 zum öffentlichen Vertrauen in KI, hinterlegt auf Figshare,[3] trug Folgendes:
Diese Zahl ist keine Seitenzahl. Es ist die Größe, in Bytes, der PDF-Datei, die Figshare für diesen Datensatz ausliefert — eine Zahl, die Figshares eigene Metadaten neben der DOI führen, und die Zoteros Übersetzer für Figshare-Einträge direkt in das Feld für Seitenzahlen übertragen hat. Auf den ersten Blick sah nichts daran offensichtlich falsch aus; es ist eine plausibel aussehende Ganzzahl, die genau dort steht, wo eine Seitenzahl hingehört — weshalb ich es beim Durchlesen der Datei mit bloßem Auge vermutlich übersehen hätte. Ein Locator, der sich nicht als Seitenzahl oder Seitenbereich parsen lässt, wird von StrictCites Engine auch nicht als einer behauptet: Es gibt auf Seiten der Registry nichts in der Form „S. 4.974.511“, womit man ihn vergleichen könnte, und ein Berichtsdatensatz ganz ohne Seitenbereich ist kein Widerspruch, also wird nichts gemeldet, als hätten sich beide Seiten tatsächlich über unterschiedliche Zahlen geäußert.
5. Warum ich Ihnen das erzähle, selbst wenn Sie StrictCite nie benutzen
Ich möchte präzise sein, was das nicht ist: Es ist kein Grund, Zotero speziell zu misstrauen, und kein Argument dafür, dass handgetipptes BibTeX besser abschneidet — das tut es nicht, und es bringt seine eigene Klasse von Fehlern mit, die diese hier nicht betreffen. Zotero ist nach wie vor das, was ich für jede Arbeit benutze, die ich schreibe. Was sich geändert hat, ist, dass ich aufgehört habe, exportiert von dem Werkzeug, dem ich vertraue und bereit zur Einreichung als dieselbe Aussage zu behandeln. Ein Export erbt alles, was die eigene Seite eines Verlags in die Metadaten geschrieben hat, alles, was die Deposit-Pipeline einer Registry dekodiert hat oder eben nicht, und alles, was ein Übersetzer unterwegs in das falsche Feld einsortiert hat — und er tut das alles lautlos, weil an keiner Stelle der Kette zwischen dem Verlag und meinem Literaturverzeichnis je jemand in der Position war, es zu bemerken.
Der Ratschlag hier ist also nicht wirklich ein Verkaufsargument. Dass ich das jetzt automatisch prüfen kann, liegt daran, dass ich StrictCite gebaut habe, aber der eigentliche Punkt gilt unabhängig davon, welches Werkzeug Sie benutzen: Nehmen Sie einen Export aus Zotero, Mendeley, EndNote oder sonst etwas nicht als sauberen, druckfertigen Text hin, nur weil eine Software, der Sie vertrauen, ihn erzeugt hat. Ein einzelnes Feld wie dieses, unbemerkt aus einem ersten Entwurf mitgeschleppt, übersteht jede folgende Überarbeitung aus demselben Grund, aus dem ich es beinahe übersehen hätte — nichts daran sieht falsch aus, bis etwas es tatsächlich liest. Es kann Monate an Überarbeitungen unbeschadet überstehen und landet dann, unangetastet, im Literaturverzeichnis einer druckfertigen Arbeit mit dem eigenen Namen darauf.
Wer sehen möchte, was der Export der eigenen Bibliothek tatsächlich enthält, Feld für Feld: strictcite.com. Der kostenlose Tarif erfordert keine Kreditkarte.