Digitization Lifecycle Telco 2012-05-21

Digitization Lifecycle,MPDL

Allgemeine Infos

 * Termin: Montag, 21.05.2012
 * Uhrzeit: 10:00-11:30 Uhr

Einwahldaten:
 * Zugangstelefonnummer: 069 27113800
 * Für alle Teilnehmer gilt der Code: 54175#
 * 0 Operatorhilfe: Bei Problemen bzw. Fragen zum Handling der Telefonkonferenz können alle Teilnehmer mit dieser Tastenfolge Operatorhilfe anfordern.
 * 6 Nur zuhören: Teilnehmer Können so selbst ihr Telefon in den reinen Hörmodus versetzen. Erneute Eingabe von *6 deaktiviert den Hörmodus.

Teilnehmer: Bitte melden Sie sich an, indem Sie Ihren Namen hier eintragen.
 * Andrea Kulas
 * Ingo Caesar
 * Lisa Pegelow
 * Klaus Werner
 * Anna Klug

Agenda:


 * Kurzbericht Entwickler
 * Kurzbericht und Austausch Arbeitsgruppen / Projektmitarbeiter
 * Bericht Projektkoordination

Protokoll
Hinweis: Diese Projektmitarbeitertelefonkonferenz hat am 21.05.12 im direkten Vorfeld des  Frankfurter Digitization-Lifecycle-Treffens (29.-31. Mai 2012)  stattgefunden.

Yuma als Annotationstool in DigiLib?
erster Klick vom 60%-Bild weg -> Vollansicht, in der die Yuma-Annotation möglich wäre ''' Frage an die Entwickler: Wird/ Wurde die neueste DigiLib-Version integriert? '''
 * Yuma funktioniert derzeit nur mit einer statischen Adresse
 * Deswegen ist Yuma im Moment noch nicht in DigiLib integrierbar.
 * Langfristig soll Yuma in DigiLib integriert werden und für DLC im DigiLib-Viewer genutzt werden.
 * Problematik, die gegen eine sofortige Implementierung spricht: Derzeit sind sowohl Yuma als auch DigiLib noch in der Entwicklung begriffen.
 * Evtl. könnte man sich folgende Übergangslösung vorstellen:

Batch-Ingest
 Die Frankfurter Vorlage "Batch update 08.05.12" (s. E-Mail von Ingo vom 08.05.12) sieht vor: 
 * Workspace-Ordner des jeweiligen Instituts bei der GWDG, der vor dem Ingest befüllt wird
 * Mindestens: Images und mab.xml
 * Automatische Prüfung der Datenkonsistenz: Beim Zugriff auf einen Ordner wird geprüft, ob die notwendigen Dateien darin lagern.

 Folgende Fragen/Probleme zum Thema "Batch-Ingest" traten in der Diskussion auf:  ''' Von der MPDL wird erwartet, dass sie auf die bestehenden Fragen in Frankfurt Antworten und Lösungsvorschläge bereit hat.   Die Ordnerstruktur an den Instituten divergiert. Eine nachträgliche Anpassung kann möglicherweise nur dann erfolgen, wenn sowieso Image-Kopien für den Upload in einem Workspace-Ordner erstellt werden müssten und ist allemal mit Aufwand verbunden. '''
 * Muss der Workspace-Ordner vom Institut zwischendrin geleert werden?
 * Müssen Updates immer manuell ausgelöst werden?
 * Was passiert, wenn für den Ingest notwendige Dateien fehlen? -> Fehlermeldung notwendig!
 * Können verschiedene Dateien von verschiedenen Orten aus hochgeladen werden? Z.B. à la manière: alle mab.xml-Dateien direkt vom Bibliotheksserver, alle Images vom GWDG-Server
 * Wie funktioniert der Upload bei großem Datenumfang? - auch: Thema "Sicherheit" beachten!
 * Was ist aus dem ursprünglich im Zuge des Batch-Ingest diskutierten Anliegen geworden, einen automatischen Reload für DLC zu implementieren? - [Das Anliegen bleibt generell bestehen. Wenn es nicht jetzt gelöst wird, dann in DLC2?]
 * Problematik bei Anlage eines Instituts-Workspace-Ordners: Manuelles Kopieren von A nach B wird bereits vor dem Ingest erwartet! Arbeitsaufwand!
 * Besser: Verzicht auf den Workspace-Ordner von seiten der Institute - Für den Ingest in DLC werden lediglich die Dateipfade zu den Masterdateien angegeben, von wo aus sich DLC die Dateien dann auch holt.
 * Was passiert aber dann in dem Fall, wo der Zugriff auf die Langzeitarchivierungsdateien stattfinden würde? Performanzproblem?
 * Frankfurt hat eine formatorientierte Ordnerstruktur: z.B. alle TEI-Dateien in einem Ordner, alle MAB-Dateien in einem Ordner, alle Images in einem Ordner
 * Berlin, Rom und Florenz arbeiten mit einer objektorientierten Ordnerstruktur: Jedes digitalisierte Buch besitzt einen eigenen Ordner, in dem die Images in einem Ordner, sowie die mab.xml und die tei.xml liegen. [Achtung: Die Struktur der Langzeitarchivierung kann schon wieder anders aussehen und beinhaltet derzeit nicht alle Dateiarten.]

 Derzeitiger provisorischer Vorschlag für einen Batch-Ingest à la Rom/Florenz: 
 * Anstelle einer genauen Dateipfadangabe pro Datei (tei.xml, mab.xml, etc.) wird nur der Ordner zum Buch angegeben, in dem sich alle notwendigen Dateien i.d.R. befinden. DLC holt sich die Einzeldateien dann selbständig.

 My Items-Konzept 
 * Als "My Items" wird in DLC derzeit das Userinterface bezeichnet, in dem alles erscheint, was beim Upload geklappt hat: Hochgeladene Dateien und ihr Status: "pending" oder "veröffentlicht"
 * Für den gemeinsamen DLC-Workspaceserver gibt es ein weiteres einsehbares Userinterface: Hier erscheinen dann möglicherweise zusätzliche Dateien, bei denen der vollständige Upload fehlgeschlagen ist.

Leitfaden
Im PM-Track: 20 min. zur Klärung des Prozederes verwenden! Differenzieren: Was kann geschrieben werden – was kann noch nicht geschrieben werden! Was ist machbar?
 * Vorschlag: auf dem Florenztreffen im Oktober sollte die erste Lesefassung stehen - sinnvoller Zeitpunkt?
 * Bis dahin müsste der Leitfaden als „Manuale“ sehr klein gehalten werden.
 * Evtl. in der Überwinterungsphase: Erweiterung durch weiterbeschäftigte Mitarbeiter

Viewing

 * Marco Schlender stellt in Frankfurt seine derzeitige Arbeit am Viewing vor.

Offline-Editing

 * Idee: Im Frankfurter PM-Track soll auch ein Blick auf die Gemeinsamkeiten und Unterschiede der TEIs geworfen werden. vgl. derzeitige Unterschiede:
 * Unklarheit über die Eingabe der Nummerierung in oder nur im n-Attribut
 * Gestaltung/ Verwendung des -Elements
 * Scanbezüge:
 * Über @xml-base im Header kann der Dateipfad einmalig für das ganze TEI-Dokument angegeben werden. Damit wird eine genaue Dateiangabe innerhalb der Attribute im TEI-Dokument selbst hinfällig.
 * Mitangabe der Dateiendung oder weglassen? Argumente, die dafür oder dagegen sprechen sammeln!

Protokolleinteilung beim Frankfurttreffen
Protokollanten:
 * Dienstag - Nachmittag: Lisa
 * Mittwoch – Vormittag: Klaus
 * Mittwoch – Nachmittag: PM-Track: Andrea protokolliert öffentlich (über Beamerprojektion); CoLab-Upload mit Unterstützung von Ingo
 * Donnerstag – Vormittag: Anna

OCR-Prozedere
 Florenz 
 * Überlegt, baldmöglichst die neueste Abbyy-Fine-Reader-Version nachzurüsten, um noch in der Projektlaufzeit inhouse Versuche durchführen zu können.

 Berlin zum derzeitigen Einsatz von Abbyy Fine Reader   Weitere Themen für den PM-Track auf dem Frankfurter Treffen: 
 * Abbyy Fine Reader – Arbeitsplatzlizenz Version 11 im Scannerraum
 * Die IMPACT-Entwicklungen wurden in der Abbyy-Fine-Reader-Version 11 integriert.
 * Nach dem Scannen direkt: Dirty OCR – pro Seite 10-30 Fehler (Bücherbeispiele von um 1800)
 * 24 bit, 300 dpi in Farbstufen; Umwandlung von TIFF Doppelseite in TIFF Einzelseiten und dann OCR direkt über TIFF
 * Abbyy 11 bietet die Möglichkeit, Seitentrennung u. Bildvorbearbeitung vor dem Start der OCR anzuhaken; für eine bessere Texterkennung sinnvoll, d. h., für das spätere Abspeichern in .doc sollten die Häkchen gesetzt sein; f. das Abspeichern in pdf u. pdf/a zwar auch sinnvoll wg. der besseren Durchsuchbarkeit weil bessere Ausgangslage, aber die Scans werden beschnitten und den Beschnitt sieht man dann auch im PDF u. das sieht wenigerschön aus
 * Möglich: Anlernen und Alphabetanreicherung um Sonderzeichen
 * Vgl. auch: Testbericht von Editura zu Abbyy 11
 * TEI-Generierung vom OCR-generierten Text
 * Offline-Editing (s.o.)
 * Digitalisierungsleitfaden (s.o.)