Super! Das hört sich überschaubar an, sodass wir da realistisch gesehen zu einem ersten Ergebnis kommen können und von dort dann weiter. SQLite ist jetzt noch längst nicht das letzte Wort, aber als erstes Hilfsmittel für Queries vielleicht ganz brauchbar, zumal der Bibeltext darin bereits vorliegt. Sicher wird die Erarbeitung der Daten nicht direkt darin stattfinden, sondern entweder per Schnittstelle oder per Export/Import.
Wegen der Transkription Griechisch fällt mir spontan die ehemalige Mailingliste Bibelgriechisch, jetzt
linguascriptura.org, ein, Peter Streitenberger hatte dafür eine eigene Systematik entwickelt. Die kann ich aber im Moment nicht finden, werde mal nachfragen. Ob das jetzt normativ ist, weiß ich nicht, es gäbe auch noch andere Anlaufstellen. Auch die Aufschlüsselung der Fraktursatz-Buchstaben würde ich verschieben, bis die konkrete Arbeit am Text beginnt.
Diese Woche habe ich meine
Luther-Ausgabe erfasst, die als authentische Grundlage gelten kann, solange es mir nicht gelingt, ein NT von 1912 der Preußischen Haupt-Bibelgesellschaft zu finden. Daneben habe ich angefangen, einen Konverter von CSV nach XML zu programmieren (Parser mit Baumstruktur), und bin im ersten Anlauf erstmal gescheitert. Ich habe zwar schon einen Konverter mit Code von jemand anderem, der produziert aber eine fehlerhafte Ausgabe. Der andere Code (externes Projekt) wurde zwar in der Zwischenzeit aktualisiert, ich weiß aber nicht, ob es sich lohnt, diese Updates zu übernehmen, ob sie den Fehler beheben. Wichtig wäre diese Komponente, um vom digitalen Text wie von mybible.zone bereitgestellt in SQLite nach CSV exportieren zu können (es wäre auch denkbar, einen XML-Export in SQLite einzubauen...), von dort dann nach XML, und von XML via XSLT nach überallhin.
Update: Die neueste Version vom Konverter des anderen Entwicklers hat den Fehler nicht mehr, sodass ich augenscheinlich den CSV-Export aus SQLite erfolgreich nach XML (17 MB) konvertieren konnte. Auf der Basis dieser Datei kann die Korrekturlesung von 1. Chronik 1 demnächst beginnen, sobald ein Scan der Seite angefertigt ist. Ob ich meinen eigenen CSV-Parser zwecks XML-Generierung noch fertigstellen soll?
Update:
Scans von 1. Chronik 1 sind da.
Update: Ich habe jetzt doch
csv2xml2 auf den aktuellen Stand gebracht, und mit den Fehlerkorrekturen funktioniert es auch richtig. Ob ich immer noch meinen eigenen Parser schreiben oder den bisherigen Code dafür wegschmeißen soll? Jedenfalls habe ich die Textgrundlage von mybible.zone via SQLite Database Browser nach CSV exportiert und mithilfe der Konfigurations-/Jobdatei
- Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8"?>
<csv2xml2-config>
<delimiter>,</delimiter>
<ignore-first-line>true</ignore-first-line>
<root-tag-name>bible</root-tag-name>
<encapsulation-tag-name>verses</encapsulation-tag-name>
<row-tag-name>verse</row-tag-name>
<mapping>
<csv-column number="0" xml-tag-name="book-number"/>
<csv-column number="1" xml-tag-name="chapter-number"/>
<csv-column number="2" xml-tag-name="verse-number"/>
<csv-column number="3" xml-tag-name="text"/>
</mapping>
</csv2xml2-config>
erfolgreich in eine XML-Datei mit dem Aufbau
- Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bible>
<verses>
<verse>
<book-number>130</book-number>
<chapter-number>1</chapter-number>
<verse-number>1</verse-number>
<text>Adam<S>121</S>, Seth<S>8352</S>, Enos<S>583</S></text>
</verse>
</verses>
</bible>
konvertiert. Nötig war dabei lediglich, die in der CSV enthaltenen < und >, die von csv2xml2 natürlich nach < und > escaped werden mussten, wieder zurück nach < und > zu ersetzen, damit diese als <S>-XML-Elemente genutzt werden konnten, womit die Strong-Nummern der Quelle ausgezeichnet sind. Die Buchnummer ist in der Quelle um Faktor 10 erhöht. Ich werde 1. Chronik 1 einmal zuschicken und habe schon festgestellt, dass Unterschiede bestehen, eine Korrekturlesung also nötig ist und als nächster Schritt vorgesehen wäre: im Vers 1 fehlt am Ende das Komma, so auch in weiteren Versen der Aufzählung. Von mir aus kann auch gerne jetzt in eins der bekannten Formate oder auch SQL mithilfe von XSLT konvertiert werden, ich persönlich kann die Korrekturlesung aber auch gut am jetzigen Stand vornehmen.
Update: Ich habe ein kleines
Tool in C++ programmiert (auf Wunsch portiere ich das auch gerne nach Java, damit es zu den anderen Tools passt, aber eigentlich brauchen wir es nur einmalig kurz aufrufen und machen dann mit dem Ergebnis weiter), das die Strong-Nummern um ihr Wort herumwrappt, wie sich das in XML gehört. Der neue Aufbau ist
- Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8"?>
<bible>
<verses>
<verse>
<book-number>130</book-number>
<chapter-number>1</chapter-number>
<verse-number>1</verse-number>
<text><S number="121">Adam</S>, <S number="8352">Seth</S>, <S number="583">Enos</S></text>
</verse>
</verses>
</bible>
Strongs sind zwar nett, aber ich persönlich würde die in meinen eigenen Projektergebnissen eher ignorieren, da sie nicht im originalen Druck enthalten sind. Für die Verknüpfung mit Namen/Orten können sie sehr hilfreich sein, weshalb wir sie uns zu einem späteren Zeitpunkt nochmal anschauen werden. Bei der Anwendung meines kleinen Tools auf den gesamten Luther-1912-Text stellte sich heraus, dass csv2xml2 immer noch Fehler enthält, weshalb doch die Fertigstellung eines eigenen CSV-nach-XML-Konverters wieder notwendig wäre. 1. Chronik 1 scheint jedoch nicht davon betroffen zu sein, d.h. wir können auch ohne meine Neuentwicklung erstmal weiterarbeiten.