Digitization Lifecycle Meeting 2012-01-16/17

Digitization Lifecycle,MPDL

Projekttreffen des DLC-Lenkungskreises am KHI in Florenz
 Zeitplan: 
 * Montag, 16.01.12:	12.00 bis 18.45 Uhr
 * Dienstag, 17.01.12:	09.30 bis 17.40 Uhr

 Teilnehmer/-innen: 
 * Amedick, Sigrid (MPeR; Frankfurt)
 * Dreyer, Malte (MPDL; München)
 * Flitner, Ursula (MPIB; Berlin)
 * Simane, Jan (KHI; Florenz)

 Entschuldigt: 
 * Thielemann, Andreas (Bibliotheca Hertziana; Rom)

 Zusätzliche Teilnehmerin am Dienstag, 17.01.12 
 * Creutzburg, Anette (KHI; Florenz)

 Protokoll: 
 * Klug, Anna (KHI; Florenz)

Sammlung an Themen für die Tagesordnung
Im Folgenden genannt sind die Topics, die gemeinsam durchgesprochen werden sollten. Die finale Tagesordnung ergab sich im Anschluss spontan.
 * Spezifikationspapier zu den bibliographischen Metadaten
 * Maschineller Ingest von Daten: MAB-Export und Masseningest von Bildmaterial und TEIs
 * Export (CoLab und Rom-ppt von Ingo Caesar)
 * Prioritätenliste
 * Arbeitsplan
 * Projektorganisation und Kommunikation
 * Technische eSciDoc-Begrenzungen
 * Viewing: Besprechung zum Thema Farbgebung und grundsätzliche Anmutung der künftigen DLC-Webseite
 * Workshop
 * Virtuelle Forschungsumgebung
 * Folgeantrag: Überlegungen zum Thema Nachhaltigkeit, Verstetigung, Community

Maschineller Ingest von Daten: MAB-Export und Masseningest von Bildmaterial und TEIs
 Status quo: 


 * Der Wunsch nach einem Batch-Ingest von Daten in die DLC-Infrastruktur wurde bereits sehr früh innerhalb der Projektlaufzeit geäußert. (vgl. erstes Spezifikationspapier des Frankfurter MPeR)
 * Der technische DLC-Prototyp wird einen manuellen Ingest von Einzeldateien gewährleisten. Ein Batch-Ingest ist noch nicht implementiert.
 * Die für DLC verwendeten Scans werden künftig auf einem eigenen Image-Server liegen und sind daher innerhalb von DLC von den MAB-Dateien physisch separiert.
 * Für den Masseningest müssen drei unterschiedliche Dateitypen zueinander in eindeutigen Bezug gesetzt werden: Images, MAB-Dateien und TEI-Dateien

 Die MPDL wird prüfen, ob das Masseningest-Procedere künftig nach folgendem Schema erfolgen kann: 


 * Pro Sammlung muss angegeben werden, welches MAB-Feld die eindeutige Verknüpfungs-ID enthält.
 * In MODS wird diese ID in  umgewandelt.
 * Mögliche Identifikationsnummern sind: Normnummer (z.B. VD 16), Verbund-ID, Systemnummer oder Signatur
 * Verzeichnisse und ihre Benamung vor dem Ingest:
 * Pro Buch gibt ein Verzeichnis, das nach der ID benannt ist und die Images enthält.
 * Für den Masseningest muss dieses Verzeichnis zwingend so heißen, wie die ID.
 * Diese ID muss in der betreffenden MAB-Datei auch ausgelesen werden können. Welches MAB-Feld als ID für die Verknüpfung verwendet wird, wird beim Anlegen einer Sammlung festgelegt.
 * Erste Version: Eine MAB-Datei pro Satz liegt im entsprechenden Ordner, in dem sich auch die zugehörigen Scans befinden.
 * Zweite Version: x MAB-Dateien für x Sätze liegen woanders.
 * Das TEI liegt entweder im Verzeichnis der Images oder trägt die ID-Nr. (Verknüpfungs-ID) als Namen.

 Sonderfall, für den nur der manuelle Ingest funktioniert:   Zeitschriften und Mehrbandwerke ohne Untersätze mit vorhandenem Hauptsatz 

Die Untersätze müssen dann entweder im Katalogsystem nachgetragen werden oder in DLC direkt manuell erstellt werden.

 Ergänzung:  Für die übergeordneten Sätze von mehrbändigen Werken (oder auch Sätze für Serien) existieren eigene MAB-Dateien, denen keine Images zugeordnet sind. Untersätze=Bandsätze sind durch die ID des übergeordneten Satzes mit diesem verknüpft, der übergeordnete Datensatz weiss nicht, welche Untersätze an ihm hängen. Nach derzeitigem technischen Stand kann dies zu Performanzproblemen bei der Suche führen.

 To do: Projektmitarbeiter 

Die Projektmitarbeiter stellen Beispiele auf CoLab: TEI, MAB-Dateien, wie heißen die Images, wie ist die Verzeichnisstruktur (1 Beispiel Monographie ohne Verknüpfung, 1 Beispiel mehrbändiges Werk mit ca. 2 Bänden)

Export
''' Fall 1 der pdf-Ausgabe ist die Minimalanforderung! ''' vgl. Digitization Lifecycle Export Zusätzlich wird bei jeder pdf-Seite die Zitierangabe mit ausgegeben.
 * Nice to have:

Priorität:
 * 1) Pdf-Export
 * 2) OAI

Gewünscht ist eine gute Auffindbarkeit in google.

 To do: Projektmitarbeiter 

Sammeln, welche Metadaten zvdd und Europeana benötigen.

Prioritätenliste
 Problempunkt mit oberster Priorität: Performanz von DigiLib 
 * Wilhelm Frank wird an DigiLib arbeiten, um eine Lösung herbeizuführen.

 Grundsätzliches zur Verbesserung der Prioritätenliste: 

  To do:  Von Seiten der MPDL wird gewünscht, dass neben die Szenarien die Use-Cases auflistet werden. (z.B. Suche im Volltext – Use Case: Anzeige des Buches -> Treffer Buch -> Treffer Seite -> Treffer Context.)

''' Nach Klärung dieser grundsätzlichen Punkte wurde die Prioritätenliste Punkt für Punkt durchgegangen, wobei nur die problematischen Punkte gesondert besprochen wurden. Hier die Ergebnisse: '''

17.	Suche in den Strukturdaten:
 * Ein separater Index für die Suche in den Struktur-TEIs muss aufgebaut werden.
 * Markus Haarländer arbeitet an einer Lösung. Wie diese aussehen kann, ist nicht klar; es gibt verschiedene Ansätze.

24.	Download als Pdf:
 * Das MPDL-Feedback ist missverständlich ausgedrückt. Bibliographische Metadaten werden zwar nicht separat, aber innerhalb des Deckblattes der generellen pdfs exportiert. Nice to have (s.o.): Zusätzliche bibliographische Angabe in der Fußzeile jeder pdf-Seite.

28.	„Nicht frunktionelle Anforderungen“ [sic]
 * Bitte an Andrea Kulas um Korrektur: Es muss heißen: „Nicht funktionale Anforderungen“

29.	Persistente IDs
 * Pro Ressource eine PID
 * D. h.: Pro Scan und pro Datei (z.B. eine PID pro TEI-Datei)

30.	Generische + nachnutzbare Lösungen  To Do Projektleiter  (wird auch beim Thema Folgeantrag nochmals angesprochen): (auch im Hinblick auf mögliche weitere Förderanträge) DTA als möglicher Projektpartner für alle DLC-Institutspartner Zeitplan für DLC:
 *  Neue Kooperationen, v.a. auf dem Februar-Workshop, anregen / bilden. 
 * Grundsätzliches Credo: Je mehr potentielle Nachnutzer über Mitentwickler einbezogen werden können, desto besser – auch für die Nachnutzbarkeit.
 * Vgl.: Derzeit kooperiert das Berliner MPIB mit dem DTA
 * Wünschenswert: Bis November muss die Version/Installation stehen.
 * Die Zeit ab November muss von der MPDL für die Stabilisierung und Bereitstellung des Open-Source-Pakets verwendet werden.

32.	Einfache Zitierbarkeit:
 * Jede Sicht im Viewing, sprich auch jeder Scan, ist über eine PID (handle) direkt ansprechbar.

33.	Browser-Kompatibilität
 * Die MPDL hält sich an die unter folgendem Link festgeschriebenen Vorgaben: http://colab.mpdl.mpg.de/mediawiki/GUI_Constraints

35.	Punktgenaue URNs
 * DLC arbeitet mit Handles.
 * Eine punktgenaue URN sei damit hinfällig.

44.	Provenienz-MD  To do: Projektleiter und AG Viewing  ''' Zu klären bleibt, wie mit Digitalisierungsvorlagen allgemein umgegangen werden soll. ''' vgl.: Nach derzeitigem Stand ist das immer der Fall, d.h. die Images werden behandelt wie die von eigenen Büchern. Vgl.: Die Provenienz der Dig.vorlage steht in dem Metadaten der Sekundärausgabe. Wie das angezeigt wird, ist Gegenstand in der AG Viewing.
 * Werden sie auf unseren Server umbezogen?
 * Wo würde das Kennzeichen der digitalisierenden Institution erscheinen?

67.	Viewing – Seiten scrollen  To do: MPDL
 * Es muss geprüft werden, wieviel Aufwand das Einführen von scrollbaren Scans und Seiten bedeutet.

74.	Hilfefunktion
 * Soll eine Hilfefunktion kontextsensitiv implementiert werden oder lieber an einem bestimmten Punkt?
 * Anlage durch die Entwickler, Texte werden auf CoLab auf Englisch gesammelt.

To do: Aufnahme eines Desiderats in der Prioritätenliste: Descriptive Metadaten 
 * Abstimmung des Editing: Wo wird editiert?
 * Abstimmung fürs Viewing: Wo zeigen wir descriptive MD zum Digitalisat an?!

Februarworkshop
Alle Referenten haben zugesagt.

 To do – Projektkoordination:
 * Die Affiliated partners sollen eine eigene E-Mail-Einladung bekommen.
 * Die Referenten bekommen eine Mail für die Kostenabrechnung.

 Zum Programm: 

Erster Themenvorschlag für die Einleitungsworte: Konzeption einer Infrastruktur für Digitalisate
 * Aus der Sicht des Nutzers und des Bibliothekars (Jan Simane)
 * Herausforderungen für die Software-Entwicklung (Malte Dreyer)

Zweiter Themenvorschlag für die Anfangspräsentation:
 * Die Vorprojekte fließen zum gemeinsamen Projekt DLC zusammen.
 * + freundliche Erwähnung der Vorarbeiten durch andere MPIs / affiliated partners
 * Vgl. auch die dadurch gewonnenen Vorerfahrungen mit verschiedenen Datentypen und Datenformaten

Final Remarks von Andreas Thielemann:
 * Am Vorabend und beim gemeinsamen Mittagessen wird vorab nochmal gesammelt.

 Vorschläge für die Rollenverteilung während des Workshops:  To do: Projektleiter (Sigrid Amedick spricht die Personen an, die als Eröffnungsredner in Frage kommen.)
 * Für die Workshop-Einführung soll ein Wissenschaftler aus einem der beteiligten MPIs gewonnen werden.
 * Möglichkeiten: Thomas Duve, Karl Härter, Christiane Birr

To do: Alle für eine Aufgabe vorgeschlagenen Personen sollten Kenntnis davon erhalten.

''' Generelle Ablaufsorganisation, sog. "Housekeeping": Andrea Kulas '''

 Vorschläge für die Moderation der Sektionen: 


 * 1) Sektion: „Text in DLC – TEI”: Klaus Werner
 * 2) Sektion: „Images in DLC“: Anette Creutzburg
 * 3) Sektion: „Synthesis First Day, Text in DLC”: Ingo Caesar
 * 4) Sektion: Annotations in DLC: Malte Dreyer

 Aufforderung an die Sektionsleiter: 
 * Max. 10-minütige Einführung ins Thema
 * Kurzpräsentation der Redner: Aus welcher Fachrichtung kommt der Redner, wo ist er tätig.
 * Allgemeines Credo: Nicht überformalisieren!
 * Diskussionsmoderation

 Aufforderung an alle: Rege Diskussionsbeteiligung 

Folgeantrag (1. Teil)
Zentrales Thema (= großer nichttechnischer Anteil): Anbahnung von Kontakten zur Einbindung vorhandener Digitalisate in unseren Kontext Aber: Die Realisierung der Einbindung ist technisch nicht trivial! Vorteil für die MPG: Leitfrage: Wer sind unsere Nutzer? Frage: Wann hat die Durchführung des Arbeitsplans einen Punkt erreicht, an dem wir etwas zeigen können?
 * Verbesserung der Arbeitsbedingungen in den MPIs
 * Mehr Digitalisate im MPG-Kontext, (die evtl. als Bücher an MPGs gar nicht vorhanden sind), die mit den DLC-Werkzeugen bearbeitet werden können.
 * Verbessertes Erschließungsniveau
 * Der Zeitpunkt, an dem die Nutzer in die Fragen der Entwicklung miteinbezogen werden, darf nicht verpasst werden!

Projektbeschreibung
'' To do: Andrea Kulas  pflegt die Verbesserungen in der englischen Version ein und passt den deutschen Text an. Danach wird der endgültige Text verschickt.''

Viewing – Vorbesprechung zur farblichen Anmutung
 Präsentation von Anette Creutzburg 

Zwei verschiedene Ansätze für die GUI
 * Iteratives Entwerfen / Verwerfen / Ändern von Entwürfen
 * Mood Boards / Farbschema / Feedback / Komponenten / Detailarbeit

Vorgehensweise zur Findung der farblichen Anmutung: (Malte Dreyer: Kapazitätfrage; Die Bibliotheksleiter weisen darauf hin, dass dieses Ziel nur erreicht warden kann, wenn der erste Entwurf schon sehr gut ist.)
 * Die Bibliotheksleiter verständigen sich über den grundsätzlichen Tenor des Farbschemas.
 * Es wird eine Person als Ansprechpartner für die kommende Kommunikation mit Herrn Kiefl ernannt.
 * Es soll eine einzige Runde für die Detailanpassung zugelassen werden.
 * Bei der Auswahl der Farbgebung bleibt die bisherige Arbeit (Positionierung und Wahl der Komponenten) unangetastet.

 Diskussion anhand von Beispielen anderer Webseiten:  Feststellung: Die Botschaft im Sinne von Design / Label erfolgt über den Header. (vgl. z.B. die E-Rara-Eule) (vgl. z.B. der Pinguin des Prototyps: Wunsch auch nach der Übernahme des Logos in der Adressleiste)
 * DLC-Label sollte auch über den Header erfolgen
 * Vorab: endgültige Festlegung des Produktnamens
 * Ein gestalterisches Element sollte sich einprägen.
 * Grundsätzliches Credo für Logo und Gestaltung:
 * Klassisch-ruhig und schlicht
 * Explizit NICHT die Welt des Alten Buches, sondern: neutral
 * Hintergrundfarbe: kein Reinweiß, sondern gedimmt, Tendenz von der Farbe weiß ausgehend und in eine leichte dezente Hellgrau-Note übergehend (freundlich fürs Benutzerauge)
 * Schmuckfarbe (als klare Zusatzfarbe & für den Header): Blauton
 * Farbwahl und Gestaltung nicht MPG-lastig
 * Die MPDL prüft, dass die Farbkontraste für Farbenblinde und Sehbehinderte gerecht sind.
 * Bis ein neuer Name steht, bleibt es bei Name und Logo von DLC.
 * Das Logo muss mit der Schmuckfarbe korrespondieren.

 An Herrn Kiefl werden folgende Wünsche weitergegeben: 
 * Das gedämpfte Weiß darf nicht bis in das Grau der alten Windowsfarbe gehen.
 * Die klare Zusatzfarbe ist blau; darf ins Taubenblau gehen.
 * Zum Workshop werden Vorlagen von Herrn Kiefl erwartet.

  To do: Projektmitarbeiter und Lenkungskreis:  Suche nach einem pfiffigen Portalnamen

Besprechung der nächsten DLC-Treffen
 Nächstes DLC-Treffen im Anschluss an den Februarworkshop 


 * Ort: MPIB
 * Zeit: Freitag, 24.02.12

Programm:
 * Nachbesprechung des Workshops: Was können wir für DLC verwerten / Was folgert sich für das weitere Programm in DLC daraus? / Reflexion über den Status quo des Projekts
 * Besprechung des technischen Prototyps:
 * Der technische Prototyp bietet bereits die Möglichkeit zum selbständigen Ingest ohne die Garantie, dass geladene Daten erhalten bleiben.

 To do – MPDL:  Schnelle Bereitstellung des technischen Prototyps, so dass er im Vorfeld von den Instituten getestet werden kann.

 To do – Institute: Vorbesprechung des technischen Prototyps  v. a. an KHI und Hertziana wg. Absenz von Andreas Thielemann und Jan Simane beim DLC-Treffen am Freitag, 24.02.12. Aber: Erkannte Fehler des Prototypen sollen im Vorfeld des Treffens nicht an die MPDL gemeldet werden, da klar ist, dass er noch viele Fehler haben wird.

''' Weitere Treffen dieses Jahr? '''

 Nächstes Treffen in Frankfurt; 1,5 Tage 
 * Evtl. KW: 18, 20, 22
 * --Anna.klug 17:48, 3 February 2012 (CET) Inzwischen wurde das Treffen für den 29. und 30. Mai 2012 fixiert.
 * Geblockt, wg. anderer Termine:
 * KW 16	16.-18. April Bibliothekstage (BT)
 * KW 21	22.-25. Mai: Bibliothekartag

Arbeitsplan
Meilensteine:
 * Der funktionale Prototyp wird wie gehabt im Februar und März getestet.
 * Prototyp Editing, wie gehabt
 * Problem: Bezüglich der wissenschaftlichen Nutzung hängen wir hinterher.

Virtuelle Forschungsumgebung
 Status quo:  Derzeit verfügbare Wissenschaftler, die sich für das Projekt „Virtuelle Forschungsumgebung“ interessieren und deren Meinung eingeholt werden sollte: (Präzise Vorstellungen: keine wirklich wissenschaftliche Edition, aber: Suche nach elaborierten Auszeichnungsformen für wiss. Texte; Abkürzungsauflösungen)
 * Die Sammlung der wissenschaftlichen Anforderungen durch die AG befindet sich auf der entsprechenden CoLab-Seite.
 * Die MPG hat Kooperationsvereinbarungen bezüglich e-Humanities mit Göttingen und DARIAH. // Achtung: Nicht an diesen Entwicklungen vorbeiarbeiten!
 * Lateinamerikanische Wissenschaftler des Wörterbuchprojektes am MPeR
 * Wissenschaftler aus dem Alhazen-Projekt der Bibliotheca Hertziana
 * Wissenschaftler, die sich mit Bildmaterial beschäftigen: vgl. z.B. der anstehende Vortrag von Ute Dercks zu Cenobium auf dem Februar-Workshop

''' Grundsätzliches Ziel: Implementation von Annotationstools für bestimmte Textstellen und bestimmte Stellen im Scan / Bild.   To do: Entwicklung ins Rollen bringen! ''' </i>
 * Die MPDL studiert die gesammelten wissenschaftlichen Anforderungen (Wilhelm und Andrea) und entwickelt daraus die APIS zur Einbindung von Annotationstools
 * d.h. u.a.: Verbindung mit Cone; Verweismöglichkeit auf externe Ressourcen; möglicherweise die Einbindung von: Voyant-Tools; HyperImage; Highlighter
 * Parallel werden die Wissenschaftler im Fokus der konkreten Projekte befragt und gebeten, ihre Anforderungen zusammenzustellen.
 * Malte Dreyer schickt die Szenarien für wissenschaftliches Arbeiten aus den e-Humanities zur Inspiration herum.

''' Ausstehende Problemanalyse: Wie wird bei der Einbindung externer Tools verfahren? ''' Die Institute wünschen sich, dass die Verwendung der zur Verfügung gestellten Annotationstools auf Dauer gesichert werden kann, was bei der Einbindung externer Tools problematisch werden könnte.

Folgeantrag und weitere Anträge (2. Teil)
 Ziele: 
 * Konsolidierung des Lebens / der weiteren Laufzeit des Projekts
 * Die besondere Innovativität muss herausgestellt werden.
 * Mehrwert entsteht durch neue Kooperationen und die Einbindung externer Ressourcen.
 * Gelder werden weiterhin für die derzeit beteiligten Institute beantragt.
 * Sinnvoll ist eine nahtlose Fortsetzung des Projektes.

 Derzeitige konkrete Vorschläge für Kooperationen: 
 * DTA (s.o.)
 * MPG-Archiv (Ansprechpersonen: Kronthaler / Beck; Strategie: nach den Anforderungen für die Digitalisierung des Archives befragen!)

 Die Option eines Verstärkungsmittelantrags wird zunächst ausgeschlossen: 
 * Verstärkungsmittel der MPG betreffen oftmals nur ein Jahr (aber: Frankfurt beantragte bereits erfolgreich Personalmittel für 2 Jahre)
 * Es wäre zu prüfen: Gehen Verstärkungsmittel nur an ein Institut oder können sie auch an unseren Institutsverbund gehen?
 * Grundsätzlich ist ein normaler Folgeantrag vorzuziehen, da nach der einmaligen Verstärkung eines Projektes i.d.R. kein weiterer Antrag mehr gestellt werden kann.

 Auch angesprochen wurde: 
 * Frage von Malte Dreyer: Macht es Sinn, DLC dafür vorzubereiten, dass es in DARIAH integriert werden kann?

''' To do – Projektleiter: Für DLC werben! ''' Die weiteren Institute sollen bis dahin eigenständig Digitalisate einstellen können. Die Projektmitarbeiter leisten erste Hilfestellung.
 * Zu klären ist, wer die Kollegen vom MPG-Archiv anspricht!
 * Zukünftige Kooperationspartner müssen auf dem Workshop und auch schon vorab angesprochen werden!
 * Die Werbung bei den anderen MPIs im Hinblick auf den nächsten Projektantrag soll maßgeblich auch auf der BT vorangetrieben werden.
 * Die affiliated partners werden auf der BT aufgefordert, Digitalisate zu liefern. Nach dem DLC-Vortrag werden auch weitere MPIs aufgefordert, Texte zu liefern. (Möglicherweise stellt Herr Beck auf dem BT das Archiv vor!)
 * Werbung innerhalb der einzelnen Institute
 * Werbung auf fachspezifischen Veranstaltungen (z.B. Kunsthistorikertag): Achtung: Für Anträge bei der MPG liegt der Fokus auf weiteren MPIs

''' To do: Projektleiter: Folgeantrag schreiben! '''

 Zeitplan für die Antragstellung: 
 * KW 21 (21.-25. Mai) ist von Malte Dreyer dafür reserviert, den Folgeantrag zu schreiben.
 * April / Mai	Das grobe Gerüst von Seiten der Institute muss vorab stehen.
 * Juni:	Deadline für den Folgeantrag

''' To do: Antrag und Bericht zur Bewilligung der letzten 15 % der Projektmittel verfassen. '''
 * Die Institute schreiben ihre Hausberichte. Deadline: nach der Sommerpause
 * Andrea Kulas stellt die Berichte zusammen und verfasst den allgemeinen Teil.

''' To do: Projektkoordination / Projektmitarbeiter: Konzept zum Thema Rechtemanagement ausarbeiten! '''</i>

Spezifikationspapier „Bibliographische Metadaten“ und eSciDoc-Begrenzungen
''' Kommentar frank13: Suche nur in Strukturdaten funktioniert noch nicht. '''
 * Desiderat: Eine dezidierte Anzeige der Trefferseite und des Trefferpunktes funktioniert nicht. Dies ist ein generelles Architekturproblem.
 * Markus Haarländer prüft hier Möglichkeiten.

 Status quo: 
 * Die Architekturüberlegungen wurden zuletzt in Berlin (Stichwort: Berkeley xml) kommuniziert. Danach nicht mehr. (Kritikpunkt)
 * Für die Volltextsuche wurde für jede physische Seite eine Einzel-Volltextdatei generiert. Deswegen funktioniert die seitengenaue Anzeige in der Trefferausgabe der Volltextsuche.
 * Für die Suche in den Strukturdaten wurden bislang keine Einzeldateien pro Seite bzw. pro Strukturelement generiert und somit funktioniert das Prozedere nicht. Der große Aufwand der Einzeldateigenerierung behindert diesen Lösungsansatz.
 * Vgl. Die Facettierung ist auch je nach Strukturelement (z.B. Suche in allen Bildunterschriften, z.B. Suche nach Aufsätzen) gewünscht.

 Lösungsansätze: 
 * SolR ist ein Lucene-Aufsatz. Sobald SolR in eSciDoc integriert ist (Zeitpunkt derzeit unbekannt), kann die Suchmaschine auch Indices.
 * Kollegen von SolR zum Februar-Workshop einladen?
 * Kritik am Fehlen der xml-Datenbank

  To do: Malte Dreyer  klärt, wieviel Aufwand die nachträgliche Implementierung einer xml-Datenbank bedeutet. To do: Ende Januar wird der Prototyp veröffentlicht. To do: MPDL: Inspiration bei VD 18 zur Umsetzung der Suche in den Strukturdaten (zusätzlich: Erinnerung über die Viewing-AG) (s. bes. die Beispieldaten der Uni Halle) </i>

 Weitere Punkte fürs Spezifikationspapier „Bibliographische Metadaten“  (Achtung: Frankfurt hat dafür kein MAB-Feld)  To do: Sammlung der Publikationstypen aus dem OPAC  --Anna.klug 18:01, 3 February 2012 (CET)Die Aleph-.Kategorien EXP und AUC, die augenscheinlich für den kubikat als Filterfunktion dienen, werden nicht als MAB-Kategorie exportiert!
 * Der Nebentitel muss rein!
 * Publikationstypen sollen gefiltert werden können: Die Auswahl muss in der betreffenden DLC-Filtermaske angeboten werden.
 * Die Signatur muss eine Suchkategorie werden!
 * Wording:
 * „Collation“ nicht „Umfang“
 * In der Anzeige: „Autor / Sonstige Person“, nicht „Verfasser“
 * In der Suche: „Autor / Sonstige Person“
 * Filterfunktion „Ausstellung / Auktion aus dem kubikat übernehmen.

To do: KHI und Bibliotheca Hertziana: Vgl.:	Manuelle Ergänzungen dürfen beim Aktualisieren nicht überschrieben werden.
 * Die Keywords aus den Strukturdateien der beiden Institute sollen zentral gesammelt werden. Danach wird entschieden, wie innerhalb von DLC damit verfahren wird.
 * KHI und Hertziana ergänzen die Signaturen in den MAB-Dateien manuell.
 * KHI und Hertziana prüfen, wie die Kennzeichnung nach Ausstellung / Auktion exportiert werden kann.