Wiki
Clone wikiBibSonomy / development / Person Names
This page documents the process of the switch from the "First Last" format BibSonomy used until 2011 to store author and editor names of publications to the "Last, First" format.
ToDos
Nächste
- Posts aus der DB holen (über REST-API direkt von bibsonomy.org), Hashes neu berechnen und vergleichen
- herausfinden, ob wir schon Posts mit inkonsistenten Hashes haben
- im nächsten Schritt herausfinden, ob unsere neue Implementierung evtl. Hashes verändert
- Problem könnten Imports mit falsch getrennten Autoren-Namen machen (mit Komma statt mit " and "getrennt)
- JabrefModelConverter testen
REST-API
- Ein- und Ausgabe stets Last, First
- Problem: alte Daten aus der DB müssen umgewandelt werden
- Klappt das mit den Clients? JabRef?
Clients/Plugins
- Typo3?
- JabRef-Layout-Rendering klappt?
Export-Formate
- Welche müssen wir anpassen?
- JSON?
- BibTeX? - konfigurierbar?
weitere Probleme
- Sicherstellen, dass Hash-Berechnung nicht kaputtgeht!
- Autor-Batch-Skript anpassen
Hash-Berechnung
Hashes, die sich ändern
Bei folgendem Post ändern sich die Hashes:
log_date: 2011-07-26 17:55:24 date: 2010-09-07 12:03:02 change_date: 2010-09-07 12:03:02 simhash2: badb93cbb25b8fa5bcf5923f5a5e1d5e title: Wirtschaftsethische Perspektiven author: NULL editor: Arnold, {Volker} and Gaertner, {Wulf} year: 2000 entrytype: proceedings journal: NULL booktitle: NULL volume: NULL number: N.F., 228,5
das liegt daran, dass die Herausgeber schon falsch herum in der Datenbank stehen (mit Komma) - so wie es gar nicht sein sollte - der Hash aber ohne sie umzudrehen berechnet wurde. Bei der "neuen" Berechnung werden die Herausgeber umgedreht und dadurch ändert sich der Hash:
old normalized string = simhash2 = badb93cbb25b8fa5bcf5923f5a5e1d5e (Wirtschaftsethische Perspektiven Arnold Volker and Gaertner Wulf 2000 proceedings NF2285) new normalized string = simhash2 = d7bb4c97e871be24904f5d02ecaad0f0 (Wirtschaftsethische Perspektiven Volker Arnold and Wulf Gaertner 2000 proceedings NF2285)
Eigentlich ist die zweite Variante die richtige, aber so haben wir das bisher halt nicht gemacht. Da anzunehmen ist, dass noch weitere einträge in der Datenbank existieren, die schon ein Komma enthalten, dürfte das häufiger passieren. Leider ist dieser Fall nicht wirklich abzufangen, d.h., wir müssten für diese Einträge die Hashes neu berechnen und in der Datenbank aktualisieren - mit allen nicht so schönen Folgen:
- bibtex-Tabelle aktualisieren
- bibhash-Tabelle aktualisieren
- ggf. GoldStandardPost-Tabelle aktualisieren
- log_bibtex so lassen?
- externe Links laufen ggf. ins leere
Um mal ein Gefühl zu bekommen, wie viele Einträge das betrifft:
SELECT COUNT(*) FROM bibtex WHERE LOCATE(',', author) > 0;
----> 10121SELECT COUNT(*) FROM bibtex WHERE LOCATE(',', editor) > 0;
----> 948
Kaputte Einträge in der Datenbank
''siehe auch vorherigen Abschnitt''
Es gibt neben Einträgen, die bereits ein Komma enthalten (s.o.) auch Einträge, die ein Semikolon enthalten:
SELECT COUNT(*) FROM bibtex WHERE LOCATE(';', author) > 0;
----> 25057SELECT COUNT(*) FROM bibtex WHERE LOCATE(';', editor) > 0;
----> 173
Daher stellt sich generell die Frage, ob das Semikolon wie ein Komma behandelt werden sollte?
'''Achtung''': Beim Semikolon gibt es mehrere Fälle zu unterscheiden:
- "David Kempe and Jon Kleinberg and \Éva Tardos"
- "Kirsch KA; Schlemmer M; De Santo NG; Cirillo M; Perna A; Gunga HC"
Done
Zusammen mit dem 2.0.18 Release am 22.9.2011 wurde der SimHashCleaner angeworfen. Ergebnis:
observed posts: 2795609 changed hashes: 21015 printed hashes: 10307 updated hashes: 20215 changed person: 939 pnp exceptions: 127 loop-time in s: 1069.22
Die 127 Exceptions kommen von Personennamen in der Datenbank, die der
Parser nicht parsen kann. Zusätzlich gibt es noch 800 Posts, deren
Hash nicht geändert werden kann, weil der Besitzer schon einen anderen
Post mit dem gleichen Intrahash haben. Dadurch kann auf diese Posts
nur noch eingeschränkt zugegriffen werden. Diese Einträge kann man
mittels grep "^updating post" SimHashCleaner.log| wc -l
ermitteln.
Updated