Re: Literatur- und Medienverwaltung
Verfasst: 08.04.2012 15:58
Hallo zusammen und frohe Ostern,
Das wird notgezwungen wohl etwas ausführlicher, für eiligen, siehe fettgedrucktes. Ein kurzer Hintergrund zu diesem Post:
LS hat mir eine TXT-Datei mit einer Größe von 20 MB geschickt, generiert aus Einträgen in EndNote. Die Datei umfasst 564.774 Zeilen und ist völlig normalisiert, nur für die Felder wo auch Information vorhanden ist, ist ein Eintrag vorhanden. Das Format scheint sich komplett nach den Standards von bibliografischen Austauchformaten wie RIS zu richten. Hier mal kurz ein Beispiel aus einer anderen Datenbank:
TY - CHAP
ID - 1535
T1 - Traditionen in der Orientierung bandkeramischer Häuser in Mitteldeutschland und Brandenburg
T3 - Beiträge zur Ur- und Frühgeschichte Mitteleuropas
T2 - Varia neolithica VII. Dechsel, Axt, Beil & Co - Werkzeug, Waffe, Kultgegenstand? Aktuelles aus der Neolithforschung
CY - Langenweissbach
A1 - Einicke,Ralf
ED - Beier,Hans-Jürgen
ED - Einicke,Ralf
ED - Biermann,Eric
PB - Beier & Beran
PY - 2011///
KW - Bronzezeit
KW - Neolithikum
KW - Tagung
KW - Waffen
KW - Werkzeug
SP - 171
EP - 182
ER -
Das ist eigentlich selbsterklärend, mit TYpe (Chapter, Book, Journal article usw), ID des Eintrags in der Datenbank, T1 usw, die Titeldaten (Aufsatz, Buch und Reihe), Verlagsort (CY), Author1 (hier Alleinauthor), EDitors (des Bandes), Verlag (PuBlisher), Erscheinungsjahr (PY). KeyWords, StartPage, EndPage und ein Abschlusseintrag des Datensatzes (ER). Das ist beliebig erweiterbar mit CallNumber (Signatur), ISBN, Seitenzahl des Buches usw.
Beim Importieren wird die Datei Zeile für Zeile eingelesen und für den Eintrag auch nur wieder die Felder angelegt, die auch tatsächlich vorhanden sind, dies in Gegensatz zu z.B. Access, wo für jede Zeile auch alle Spalten angelegt werden, wodurch die Datenbank sehr viel umfangreicher wird, dafür jedoch für menschliche Lesern einfacher interpretierbar ist.
Das Importieren der Daten hat etwas gedauert, etwas über zwei Stunden, weil Zotero das nur auf einem Kern macht, dafür sind es dann auch 22.368 Einträge.
Es gibt beim Exportieren als TXT anscheinend ein sehr massives Problem: Ein Großteil der Sonderzeichen sind nicht richtig kodiert, sodass viele Datensätze völlig unbrauchbar sind. Ich weiß jedoch nicht, wie gut die Zeichen in der Originaldatenbank vorhanden waren, weil es Teilweise auch Probleme mit Umläute gab, die in TXT durchaus vorgesehen sind.
Als sehr dramatisches Beispiel:
al-**Am*±r/University of Pennsylvania. University Museum./Egypt. Ma*¹*la*¸Æat al-**th**r./Egypt. Wiz**rat al-Thaq**fah wa-al-I**l**m./Mat*¸Æaf al-Mi*¹*r*±. 1959: M.¹.¹. af al-**Am*±r/University of Pennsylvania. University Museum./Egypt. Ma*¹*la*¸Æat al-**th**r./Egypt. Wiz**rat al-Thaq**fah wa-al-I**l**m./Mat*¸Æaf al-Mi*¹*r*±., A family archive from Thebes : demotic papyri in the Philadelphia and Cairo Museums from the Ptolemaic period (Cairo 1959).
Ich vermute, dass bei einem Export als RIS, BibTex usw. mit erweiterten Kodierungen diese Probleme nicht auftreten, bislang habe ich mit Sonderzeichen (auch Tschechisch, Rumänisch und Polnisch) in Zotero keine Probleme gehabt. Da würde sich ein erneutes Experiment (mit etwas weniger Datensätzen) durchaus lohnen.
Weitere nachteile: Die Daten sind völlig unsortiert, es gibt keine Dateistruktur und dadurch müssen die einzelne Einträge Stück vor Stück angefasst werden und in einen Ordner verschoben werden. Das ist nicht nur zeitaufwändig, sondern wenn man die Aufsätze nicht kennt auch mit Fehlern verbunden.
In diesem speziellen Fall ist auch die Qualität der Daten ungenügend: So scheint bei der Bodlean Library ein Suchauftrag gelaufen zu sein nach 'flint' wobei das Ergebnis ohne Überprüfung in die Datenbank integriert worden ist. So sind auch Einträge vorhanden wo der Autor zwar 'Flint' heißt, die mit Archäologie jedoch nichts zu tun haben. In diesem Datenbereich sind auch die Call-Numbers (Signaturen) von der Bodlean vorhanden in der Datenbank, was mir in Dresden herzlich wenig nutzt.
Weiter gibt es einige Schwierigkeiten, weil es statt einzelne Schlagwörter Schlagwortketten gibt, die immer wieder Probleme verursachen.
Also formell wäre die Sache wohl überhaupt kein Problem, nur ist der Inhalt in diesem Fall etwas fehlerbehaftet und ist ein TXT-Format wohl nicht geeignet. Ein Export mittels eines anderen Formates hätte wohl die Sonderzeichen besser verwaltet und möglicherweise die Ordnerinformationen behalten, wodurch das Integrieren in bestehende Bibliotheken sehr viel einfacher gewesen wäre. Und wie immer gilt das ultimative Gesetz: 'Garbage in, garbage out', solche Datenbestände müssen immer wieder überprüft und gepflegt werden.
Ticker: Einlesen Datensätze, auch große Mengen, kein Problem. TXT wegen Sonderzeichen ungeignet, bibliografisches Austauschformat verwenden. Literaturdatenbank pflegen.
Das wird notgezwungen wohl etwas ausführlicher, für eiligen, siehe fettgedrucktes. Ein kurzer Hintergrund zu diesem Post:
LS hat mir eine TXT-Datei mit einer Größe von 20 MB geschickt, generiert aus Einträgen in EndNote. Die Datei umfasst 564.774 Zeilen und ist völlig normalisiert, nur für die Felder wo auch Information vorhanden ist, ist ein Eintrag vorhanden. Das Format scheint sich komplett nach den Standards von bibliografischen Austauchformaten wie RIS zu richten. Hier mal kurz ein Beispiel aus einer anderen Datenbank:
TY - CHAP
ID - 1535
T1 - Traditionen in der Orientierung bandkeramischer Häuser in Mitteldeutschland und Brandenburg
T3 - Beiträge zur Ur- und Frühgeschichte Mitteleuropas
T2 - Varia neolithica VII. Dechsel, Axt, Beil & Co - Werkzeug, Waffe, Kultgegenstand? Aktuelles aus der Neolithforschung
CY - Langenweissbach
A1 - Einicke,Ralf
ED - Beier,Hans-Jürgen
ED - Einicke,Ralf
ED - Biermann,Eric
PB - Beier & Beran
PY - 2011///
KW - Bronzezeit
KW - Neolithikum
KW - Tagung
KW - Waffen
KW - Werkzeug
SP - 171
EP - 182
ER -
Das ist eigentlich selbsterklärend, mit TYpe (Chapter, Book, Journal article usw), ID des Eintrags in der Datenbank, T1 usw, die Titeldaten (Aufsatz, Buch und Reihe), Verlagsort (CY), Author1 (hier Alleinauthor), EDitors (des Bandes), Verlag (PuBlisher), Erscheinungsjahr (PY). KeyWords, StartPage, EndPage und ein Abschlusseintrag des Datensatzes (ER). Das ist beliebig erweiterbar mit CallNumber (Signatur), ISBN, Seitenzahl des Buches usw.
Beim Importieren wird die Datei Zeile für Zeile eingelesen und für den Eintrag auch nur wieder die Felder angelegt, die auch tatsächlich vorhanden sind, dies in Gegensatz zu z.B. Access, wo für jede Zeile auch alle Spalten angelegt werden, wodurch die Datenbank sehr viel umfangreicher wird, dafür jedoch für menschliche Lesern einfacher interpretierbar ist.
Das Importieren der Daten hat etwas gedauert, etwas über zwei Stunden, weil Zotero das nur auf einem Kern macht, dafür sind es dann auch 22.368 Einträge.
Es gibt beim Exportieren als TXT anscheinend ein sehr massives Problem: Ein Großteil der Sonderzeichen sind nicht richtig kodiert, sodass viele Datensätze völlig unbrauchbar sind. Ich weiß jedoch nicht, wie gut die Zeichen in der Originaldatenbank vorhanden waren, weil es Teilweise auch Probleme mit Umläute gab, die in TXT durchaus vorgesehen sind.
Als sehr dramatisches Beispiel:
al-**Am*±r/University of Pennsylvania. University Museum./Egypt. Ma*¹*la*¸Æat al-**th**r./Egypt. Wiz**rat al-Thaq**fah wa-al-I**l**m./Mat*¸Æaf al-Mi*¹*r*±. 1959: M.¹.¹. af al-**Am*±r/University of Pennsylvania. University Museum./Egypt. Ma*¹*la*¸Æat al-**th**r./Egypt. Wiz**rat al-Thaq**fah wa-al-I**l**m./Mat*¸Æaf al-Mi*¹*r*±., A family archive from Thebes : demotic papyri in the Philadelphia and Cairo Museums from the Ptolemaic period (Cairo 1959).
Ich vermute, dass bei einem Export als RIS, BibTex usw. mit erweiterten Kodierungen diese Probleme nicht auftreten, bislang habe ich mit Sonderzeichen (auch Tschechisch, Rumänisch und Polnisch) in Zotero keine Probleme gehabt. Da würde sich ein erneutes Experiment (mit etwas weniger Datensätzen) durchaus lohnen.
Weitere nachteile: Die Daten sind völlig unsortiert, es gibt keine Dateistruktur und dadurch müssen die einzelne Einträge Stück vor Stück angefasst werden und in einen Ordner verschoben werden. Das ist nicht nur zeitaufwändig, sondern wenn man die Aufsätze nicht kennt auch mit Fehlern verbunden.
In diesem speziellen Fall ist auch die Qualität der Daten ungenügend: So scheint bei der Bodlean Library ein Suchauftrag gelaufen zu sein nach 'flint' wobei das Ergebnis ohne Überprüfung in die Datenbank integriert worden ist. So sind auch Einträge vorhanden wo der Autor zwar 'Flint' heißt, die mit Archäologie jedoch nichts zu tun haben. In diesem Datenbereich sind auch die Call-Numbers (Signaturen) von der Bodlean vorhanden in der Datenbank, was mir in Dresden herzlich wenig nutzt.
Weiter gibt es einige Schwierigkeiten, weil es statt einzelne Schlagwörter Schlagwortketten gibt, die immer wieder Probleme verursachen.
Also formell wäre die Sache wohl überhaupt kein Problem, nur ist der Inhalt in diesem Fall etwas fehlerbehaftet und ist ein TXT-Format wohl nicht geeignet. Ein Export mittels eines anderen Formates hätte wohl die Sonderzeichen besser verwaltet und möglicherweise die Ordnerinformationen behalten, wodurch das Integrieren in bestehende Bibliotheken sehr viel einfacher gewesen wäre. Und wie immer gilt das ultimative Gesetz: 'Garbage in, garbage out', solche Datenbestände müssen immer wieder überprüft und gepflegt werden.
Ticker: Einlesen Datensätze, auch große Mengen, kein Problem. TXT wegen Sonderzeichen ungeignet, bibliografisches Austauschformat verwenden. Literaturdatenbank pflegen.