Digitization Lifecycle Meeting 2011-02-23

Digitization Lifecycle,MPDL

=Allgemeine Angaben= Datum & Uhrzeit: 23.-24.2.2011 Ort: Max-Planck-Institut für Europäische Rechtsgeschichte Hotel Hotel Ibis Frankfurt City West Breitenbachstrasse 7 60487 FRANKFURT 069 247070 Bei der Buchung bitte gegenüber dem Hotel angeben, dass MPG Preise angewandt werden (79 € Einzelzimmer-preis inkl. Frstk. außerhalb von Messe- und Eventzeiten).

Alle relevanten Locations in Google maps!

Teilnehmer

 * Andrea Kulas (MPDL)
 * Markus Haarländer (MPDL)
 * Lu Yu (MPDL)
 * Kristina Koller (MPDL)
 * Monika Fritz (MPIeR)
 * Ingo Caesar (MPIeR)
 * Anna Klug (KHI)
 * Anette Creutzburg (KHI)
 * Lisa Pegelow (MPIB)
 * Klaus Werner (Bibliotheca Hertziana)
 * Martin Raspe (Bibliotheca Hertziana)

Agenda
Moderator: Andrea Kulas

23.02.2011

 * 13:00 - 15:00: Vorstellungsrunde in Form von Kurzpräsentationen (eine Person pro Institut/MPDL)
 * Personen + deren Aufgaben / Verantwortlichkeiten (auch von Personen, die nicht an diesem Meeting teilnehmen)
 * Digitalisate
 * Teilprojekte (wer möchte, kann hierfür die „Lifecycle Matrix Teilprojekte“ vom MPIRG verwenden)


 * 15:00 - 15:30: Pause
 * 15:30 - 18:00: Organisatorisches
 * Dokumentation: Colab-Wiki (Einführung in die Benutzung + Verwendungszweck z.B. Sammeln von Anforderungen)
 * Kommunikation zwischen MPDL und den Instituten (Hauptansprechpartner an den Instituten?)
 * Dokumentenverwaltung/File Sharing: e.g. Dropbox, "file upload" im Wiki oder anderes Tool
 * Ziele des Projektes definieren, siehe Projektantrag (Andrea Kulas)


 * 19:15: Gemeinsames Abendessen im Bistro Arche Nova (bitte geben Sie Herrn Caesar Bescheid, falls Sie am Abendessen nicht teilnehmen können)

24.02.2011

 * 09:30 - 11:00: Editor
 * Vorstellung ViRR Editor (Frau Fritz und Herr Caesar)
 * 11:00 - 11:15: Pause
 * 11:15 - 13:00: Erste Arbeitsschritte
 * Entwicklung der Szenarien, konkrete Anforderungen (siehe Digitization Lifecycle Anforderungen) und Arbeitsplan
 * Diverses

=Protokoll=

Vorstellung der Projektpartner

 * Die Verantwortlichkeiten der einzelnen Projektmitarbeiter sind unter Digitization Lifecycle Contacts zu finden.

MPDL

 * Hauptansprechpartner: Andrea Kulas
 * Aufgaben der Projektkoordination:
 * Verantwortlich für die Organisation von Veranstaltungen, Meetings, Workshops, etc.
 * Erstellung des Arbeitsplans
 * Projektmonitoring
 * Kommunikationsschnittstelle/Vermittlung zwischen Instituten
 * Einhaltung einer neutralen Position

MPIeR

 * Hauptansprechpartner: Ingo Caeser
 * Die Bibliothek hat bereits mehrere DFG Projekte durchgeführt --> das Ergebnis von Digi Lifecycle muss den DFG-Praxisregeln entsprechen.
 * Die Daten des Instituts liegen bei der GWDG
 * Erwartungen an Digi Lifecycle
 * Unterteilung in zwei Stufen:
 * Erstellung einer digitalen Bibliothek
 * Auseinandersetzung mit dem Thema einer Virtuelle Forschungsumgebung
 * Digi Lifecycle baut auf ViRR auf
 * Wunsch: Import/Export soll möglichst schnell von den Instituten selbst ausgeführt werden
 * Zeitschriftenprojekt:
 * Aktuell arbeitet die MPDL (Wilhelm Frank) an dem Ingest von Zeitschriften in ViRR
 * langfristig soll dieses (Teil-) Projekt in Digi Lifecycle überführt werden
 * Ist ein DFG Projekt, daher sollten erste Ergebnisse im April sichtbar sein

KHI

 * Hauptansprechpartner: Anna Klug
 * Rara Projekt:
 * Gesamtbestand von ca. 7.500 Bänden soll digitalisiert und mit Strukturdaten versehen werden
 * Ziel des Projekts: wissenschaftliche Erschließung, Konservierung und Digitalisierung des Gesamtbestandes
 * Aktuell liegen ca. 120 Dokumente als Digitalisate auf dem Instituts-Server
 * Digitalisierung und Nachbearbeitung der Images wird inhouse durchgeführt (Speicherung der Digitalisate als Raw, TIFF und jpg)
 * Das Institut verfügt über eine Access Datenbank, die Informationen zur wissenschaftlichen und formalen Beschreibung der Rara-Bände enthält
 * Die Struktur der Datenbank soll den anderen Projektpartnern zur Verfügung gestellt werden
 * Erwartungen an Digi Lifecycle
 * Für das Rara Projekt wird ein leistungsstarker, an die speziellen Anforderungen zur Strukturdateneingabe bei Rara-Bänden angepasster Struktureditor benötigt
 * Die Daten aus der Access Datenbank sollen in ein XML-Format transformiert werden wie z.B. TEI

Access Datenbank
 * Beinhaltet Informationen zur den Eigenschaften eines Buches
 * Wenig Freitextfelder, mehr kontrollierte Vokabularien (auswählbar durch Pull Down Menüs oder Checkboxen)
 * Der Aufbau ist hierarchisch: einem Oberelement sind mehrere Unterelemente zugeordnet
 * Es existiert eine Einbindung von Normdaten (PND und SWD)
 * Sofern Personen und Institutionen nicht in PND/SWD enthalten, wird ein eigener neuer Eintrag in der Datenbank erstellt
 * Des weiteren existieren Verlinkungen zu lokal gespeicherten Fotos und Textdateien (zur Dokumentation des Restaurierungsvorgangs)
 * Anforderung an Digi Lifecycle:
 * Alle Daten sollten in ein XML Format überführt werden
 * Evtl. könnte man hierfür in Zukunft TEI verwenden, da TEI viele dieser Elemente unterstützt (TEI Modul MsDesc (Manuskript Description))
 * Die komplette Datenbank (wahlweise einzelne Module daraus) soll den anderen Instituten zur Verfügung gestellt werden

Hertziana

 * Hauptansprechpartner: Martin Raspe
 * Alter Kernbestand der Bibliothek sind historische Rom-Guiden (15.-18. Jh.) und Stichwerke zur Topographie Roms
 * Digitalisierung wurde bisher inhouse und extern durchgeführt
 * Aktuell existieren ca. 80000 Scans (ca. 250 Bücher), davon 120 mit Strukturdaten, alle im Netz verfügbar []
 * Die entsprechenden Strukturdaten werden direkt im XML durch Praktikanten erfasst
 * Verwendung eines eigenen Formats, in Anlehnung an TEI
 * Zusätzlich verfügt das Institut über einen einen eigenen Viewer für dieses Format
 * Das Institut arbeitet eng mit dem MPI Wissenschaftsgeschichte zusammen; hat auch bei Digilib mitentwickelt
 * Erwartungen an Digi Lifecycle
 * Sehen sich in einer technischen Rolle
 * Hohes Interesse an einem virtuellen Arbeitsraum
 * Würden gerne die eigenen Daten in das Digi Lifecycle Projekt übertragen und ihr eigenes System ablösen. Dafür müsste das neue System auf jeden Fall folgende Funktionalitäten unterstützen:
 * Das Material in Digi Lifecycle soll problemlos mit Material von anderen Instituten /Datenbanken verlinkt werden können
 * Materialien aller Partnerdatenbanken sollen zusammen bearbeitet werden können
 * Digitalisate sollen generisch auf Seiten- bzw. Abschnitt-Ebene referenzierbar sein, bei Vorliegen des Volltextes auch wortgenau

Präsentation des aktuellen Arbeitsprozesses in Rom
 * 1) Digitalisate werden photographiert und nachbearbeitet (gespiegelt, gedreht, beschnitten, systematische Dateinamen)
 * 2) Automatische Erstellung der Strukturdaten (leeres XML Dokument mit Auflistung der Images), die zunächst bei den Scans liegen
 * 3) Einfügung der Struktur-/OPAC-Daten in eine XML-Datenbank (eXist), ab dann sind die Digitalisate konsultierbar
 * 4) Live-Abfragemöglichkeit, z. B. welche Bücher strukturiert sind und welche nicht, wie viele Scans, etc.
 * 5) Verwendung eines nativen XML-Struktureditors ("jEdit", erweitert durch Plugins und Macros)
 * 6) * Das verwendete Format wurde frei definiert, in Anlehnung an TEI
 * 7) * Beinhaltet eine automatische Kontrolle bei der XML Erstellung mit Hilfe einer DTD (Dokument Type Definition)
 * 8) * Die DTD bietet dem Nutzer auch Eingabehilfen an
 * 9) * Nach der Bearbeitung werden die XMLs in der Datenbank aktualisiert
 * 10) Eigener Viewer:
 * 11) * Anzeige doppelseitig oder einfach, kleine Vorschaubilder, Strukturbaum, Metadaten, Buchbeschreibung, Bearbeitungsstand
 * 12) * Einzeln ausgewählte Scans werden mit Hilfe von Digilib angezeigt (alle Funktionalitäten von Digilib stehen dem Nutzer zur Verfügung)
 * 13) * Digilib zeigt aber aktuell immer nur eine vom Nutzer ausgewählte Seite, die Strukturdaten werden nicht mit in Digilib übertrage
 * 14) * Verbesserte Version von Digilib ist bereits in Arbeit

Datenbank Zuccaro
 * Forschungsdatenbank
 * Beinhaltet zusätzliche Informationen zu den digitalisierten Büchern
 * Es existiert eine Verknüpfung zwischen den Digitalisaten und der Datenbank
 * Anforderung an Digi Lifecycle: offene Schnittstellen definieren, so dass unterschiedliche externe Datenbanken mit den Digitalisaten verknüpft werden können

MPIB

 * Hauptansprechpartner: Lisa Pegelow
 * Das Institut möchte aktuell Bücher anderer Bibliotheken digitalisieren, da diese den größten Mehrwert für die Wissenschaftler am Institut bieten
 * Im Moment wird ein externer Dienstleister zur Digitalisierung gesucht
 * 23 Titel sollen gescannt werden, Seitenumfang etwa 7.000 Seiten
 * Erwartungen an Digi Lifecycle
 * Entwicklung eines Strukturdateneditors
 * Guidelines für die Erstellung von Digitalisaten

Definition der Projektziele

 * Aus dem Projektantrag:
 * Technische Lösung zum Umgang mit Digitalisaten
 * Leitfaden zum Digitalisierungsprozess
 * Durchführung von 2 Workshops
 * Unterschiedliche Vorstellungen der Herangehensweise an das Projekt
 * Standpunkt MPIeR:
 * Sich mit dem auseinander setzen, was bereits da ist (ViRR) und anhand dessen weitere Szenarien erstellen
 * Hertziana:
 * Strukturdaten der Institute gegeneinander abgleichen
 * In einem ersten Schritt das Format (die Datenbasis) festlegen
 * Editor sollte nicht in den Mittelpunkt gestellt werden
 * Vorschlag zum weiteren Vorgehen:
 * Erstellung einer Analyse: Was kann ViRR, was kann das Hertziana-System, was überschneidet sich, was ist unterschiedlich
 * Die Schnittstellen zwischen den beiden Strukturen (ViRR und Rom) herausfinden
 * Weiterentwicklung von ViRR vs. Neuentwicklung eines Editors
 * Manchmal ist eine neue Entwicklung einfacher als etwas schon Vorhandenes total umzubauen
 * Die Entscheidung hierbei hängt von den Wünschen der Institute ab
 * Das gemeinsame Datenformat sollte vor der Entscheidung für eine Neu- bzw. eine Weiterentwicklung konzipiert und definiert werden unter Berücksichtigung einer möglichst generischen Einbindung vordefinierter Metadaten-Sets (bibliothekarisch/kodikologisch/usw.)
 * METS/MODS sollte auf jeden Fall als Exportformat angeboten werden
 * eSciDoc ist ein Repository, keine Datenbank
 * Wünsche an das Vorgehen von Seite der MPDL:
 * Arbeitsplan mit Arbeitspaketen kann erst erstellt werden, wenn alle Anforderungen bekannt sind
 * Deshalb sollten die Anwendungsszenarien möglichst bald erstellt werden

Weiteres Vorgehen zur Einigung auf ein gemeinsames Datenformat
 * Erste Schritte: MPDL und Rom bilden eine Arbeitsgruppe zum Vergleich der beiden Standards (ViRR Editor und XML Editor aus Rom)
 * Beide schicken Beispieldaten an den jeweils anderen
 * Alle anderen Projektpartner werden über die Diskussion auf dem Laufenden gehalten werden

Wie kommen wir zu den genauen Anforderungen
Vorgehen:
 * 1) Erstellung von Szenarien diverser Art (incl. Beschreibung der Ist-Situation)
 * 2) * für den Editor (Sicht des Bibliothekars)
 * 3) * für die virtuelle Forschungsumgebung (Sicht des Wissenschaftlers)
 * 4) * Auch wenn das Thema virtuelle Forschungsumgebung im Projektrahmen erst zu einem späteren Zeitpunkt bearbeitet wird, so ist es doch jetzt schon wichtig, die Szenarien hierfür festzuhalten. Denn erst wenn bekannt ist, wie hinterher mit den Daten gearbeitet werden soll, kann der Editor entsprechend geformt werden.
 * 5) * Optimal wäre es, die Szenarien bereits zum März Meeting zu haben!
 * 6) Erstellung einer Anforderungsliste (basierend auf den Szenarien, Formulierung von Wünschen für die Zukunft)
 * 7) * Strukturiert nach : Datenmodel, Editor, Viewer, Institut, sowie den Punkten aus der Excel Liste vom MPIeR
 * 8) * Die MPDL erstellt eine entsprechend strukturierte CoLab Seite und verteilt sie an alle Projektpartner
 * 9) * Ziel: es soll klar erkennbar sein, was welches Institut erwartet
 * 10) * Wenn die Liste fertig ist, können die Punkte zusammengefasst und priorisiert werden (alle Institute müssen sich einigen)
 * 11) * Optimal wäre es, die Anforderungslisten der einzelnen Institute bereits zum März Meeting zu haben! Die fertige Anforderungsliste sollte dann Ende März fertig sein, so dass mit der Erstellung des Arbeitsplans im April begonnen werden kann.
 * 12) Erstellung der detaillierten Spezifikationen (basieren auf der Anforderungsliste)

Dokumentation und Kommunikation
CoLab
 * Dokumentation: wenn möglich alles in CoLab
 * Diskussionen wären sinnvoller in CoLab, da alle Meinungen nachverfolgt werden können
 * Wenn Seiten fertig sind und eingefroren werden sollen, dann sperren wir sie in CoLab (Andrea Kulas bekommt dafür Administratoren Rechte)

Filesharing
 * Dropbox ist nicht MPG konform
 * Wir werden versuchen, alles in CoLab zu dokumentieren und die Anzahl an zusätzlichen Dateien gering zu halten
 * Nur wenn langfristig Bedarf besteht, würden wir uns nach einer Filesharing Lösung umschauen

Telcos
 * Regelmäßige Telco alle drei Wochen
 * Die jeweiligen Agendas werden in CoLab erstellt
 * Jeweils Dienstag 10:00 - max. 11:00
 * Teilnehmer: max. 6 Personen (wenn möglich pro Institut jeweils nur eine Person)
 * Andrea Kulas lädt jeweils ein und verschickt einen Agendavorschlag (über CoLab)

Präsentation ViRR Editor

 * Testumgebung für das Projekt Digitization Lifecycle ist unter erreichbar
 * Auf dieser Testumgebung können Daten von jedem Institut eingespielt werden. Alle Infos hierzu sind in CoLab unter Digitization_Lifecycle_Sandbox zu finden
 * Export in den DFG viewer: nur das METS/MODS wird an den DFG Viewer übermittelt. Dadurch kann er die Scans mit den vorhandenen Informationen anzeigen, die Scans an sich bleiben aber auch dem original Server (hier den ViRR Server der MPDL) gespeichert.

Feedback zur Oberfläche des Editors
 * Anzeige von Thumbnails wird gewünscht
 * Aktuell werden auf der ViRR Oberfläche zu wenig Informationen parallel angezeigt (Seitenweises Arbeiten: Paginierung, Erstellung der Strukturelement und Zuweisung der Seiten sollte in einem Arbeitsschritt machbar sein)
 * Anforderungen Rom: Es sollte klar sichtbar sein, welche Informationen direkt aus dem Buch entnommen wurden und welche Informationen Zusatzinformationen des Bearbeiters sind

Unterschiedliche Herangehensweise an die Strukturierung eines Digitalisats
 * 1) Digital Faksimile: Das Buch muss ganz genau abgebildet werden, eventuelle Fehler im Buch werden auch weiter als Fehler dargestellt (authentische Darstellung; Anforderung Hertziana)
 * 2) * In diesem Fall darf es nicht möglich sein, eine Seite zwei Strukturelementen (z. B. Kapiteln) zuzuordnen, auch wenn die Seite Content von beiden Kapiteln beinhaltet
 * 3) * Logische Struktur steht im Vordergrund
 * 4) Bisheriges Vorgehen MPIeR
 * 5) * Physische Struktur steht im Vordergrund und diese Struktur wird dann mit der logischen Struktur verknüpft
 * 6) * Eine Seite darf beliebig vielen Strukturelementen zugeordnet werden
 * 7) * Wichtig: Es soll der Ausdruck einzelner Kapitel angeboten werden, deshalb muss aus dem Datenformat klar ersichtlich sein, welche Seiten zu einem Kapitel gehören. Deshalb bislang Mehrfachzuweisung von Seiten.
 * 8) * (Bei falsch gebundenen Büchern findet das "virtuelle Umbinden" im Interesse der Nutzerfreundlichkeit durch entsprechende Vergabe der Dateinamen statt, nicht aber durch Manipulationen mit Hilfe des Editors)

Identifizierte Themen für den im Projekt zu entwickelnden Leitfaden
 * 1) Paginierung: Richtlinien, z. B. in welcher Sprache wird paginiert, erscheinen vom Nutzer abgeleitete Informationen in Klammern, etc.
 * 2) Benennung der Scans: Richtlinien für eine allgemeine Logik, Empfehlungen für zukünftige Scanvorhaben, Erfahrungsaustausch
 * 3) * Wäre sehr interessant für Florenz, da hier im Juni die Digitalisierung weiter geht und dann eventuell entwickelte Richtlinien bereits angewendet werden könnten.
 * 4) * Bereits benannte Scans sollten natürlich nicht mehr ungenannt werden.
 * 5) Abtippen von Informationen: Wie gehe ich damit um?
 * 6) * Beachte ich Groß und Kleinschreibung?
 * 7) * Wie gehe ich mit Rechtschreibfehlern um?

Zur Sammlung relevanter Informationen wird die MPDL mehrere CoLab Seiten erstellen für
 * 1) Anforderungen an die Paginierung
 * 2) Erfahrungen, bisheriges Vorgehen zur Benennung der Scans, Vorstellungen
 * 3) Sammlung einer Liste der Strukturtypen (siehe Strukturdaten)

Strukturtypen und Metadatenspezifikation
 * Diskussion: für welche Strukturtypen werden welche descriptiven Metadaten Elemente benötigt
 * Problem der aktuellen ViRR Liste: abstrakte Strukturelemente (z.B. Kapitel) sind vermischt mit Inhaltlichen Elementen (z. B. Gesetz)
 * Vokabular: Differenzierung zwischen buchnahen Erschließungsdaten (was im Buch steht) und hergeleiteten (vom Erschließer hinzugefügt)

Organisatorisches
Rolle der affiliated Partners
 * Sie können Ihre Erwartungen an uns formulieren
 * Und unseren Fortschtritt verfolgen
 * MPI Wissenschaftgeschichte wird behandelt wie ein affiliated Partner

Meeting im März
 * Am Montag sollte so früh wie möglich angefangen werden
 * Alle Partner senden Andrea eine kurze Info, ab wann Sie da sein könnten
 * Die Agenda sollte Ende KW9 (4. März) abgestimmt sein
 * Bitte alle relevanten Punkte für die Agenda bis 4. März in CoLab einstellen

Erste Telco
 * Dienstag 08. März 10:00 (die MPDL wird einladen)