Lieber Sebastian, [@Alle: Diese Antwort ist ziemlich umfänglich und detailliert. Die unmittelbare Erwiderung auf Sebastians Fragen könnte für alle interessant sein, unterhalb einer Abtrennung geht es in die (Un-)Tiefen der TEI.] Eine überarbeitete Fassung des Dokuments hängt an. (Ich habe begonnen, die Kapitelzählung zu "normalisieren", im Korrekturmodus habe ich dann den Überblick über die vielen Ebenen verloren und Word ließ mich das Inhaltsverzeichnis nur einmal aktualisieren.) es ist ein bisschen schade, dass Du dieses Dokument "im stillen Kämmerlein" so weit fortgeschrieben hast, so dass nun die Zeit knapp ist und Dich dabei auf einen längst veralteten Stand beziehst (MASTER-Projekt) ohne neuere Entwicklungen zu berücksichtigen. Nicht nur die TEI hat sich seit dem MASTER-Projekt fortentwickelt, sondern auch die Nutzungsszenarien: Schon das ENRICH-Projekt [1] hatte die neueren Entwicklungen in der TEI aufgegriffen und zuletzt haben wir (i.e. BSB und HAB als deutsche Partner) im Projekt Europeana Regia [2] die ENRICH-Entwicklungen in Hinblick auf die Datenlieferung an die Europeana fortgeschrieben. Unglücklicherweise habe ich im Projekt Europeana Regia bereits ein ähnliches Dokument erstellt, in dem die Verwendung der TEI für Handschriften ausführlich erläutert ist. (Das Dokument war zur Projektlaufzeit nur für den internen Gebrauch bestimmt, die abschließende Veröffentlichung müssen wir noch organisieren. Bei Bedarf kann ich das schon mal rumschicken.) Ausserdem hat es auch einige theoretische Klärungen in der Frage gegeben, was der Inhalt einer TEI-Datei eigentlich ist. Dazu gleich mehr. Zugegebenermaßen war auch ich im ersten Beispiel für den Demonstrator in dieser Frage einem Irrtum aufgesessen, den wir mittlerweile geklärt haben. tierung im DFG-Viewer bis Jahresende abzuschließen. Die theoretische Frage, was der Gegenstand eines TEI-Dokuments sei, ist wichtig für das Kapitel 2.1 des Anwendungsprofils. Wir (=HAB, analoge Lösungen, allerdings nicht auf TEI-Basis, bei ManuMed und e-codices) gehen davon aus, dass *die Handschrift* in einer TEI-Datei beschrieben werden kann, welche die Beschreibungsdaten im <teiHeader> enthält, per <facsimile> das Digitalisat repräsentiert und als <text> den Volltext der Handschrift bzw. wahlweise und als ersten Schritt die Strukturdaten aufnimmt. Die einzelnen Beschreibungen zur Handschrift, die ihrerseits in der Regel "historische" Dokumente und damit unveränderlich sind, werden am Besten in separaten TEI-Dokumenten gespeichert. In diesem zweiten Fall ist der Gegenstand der TEI-Datei nicht die Handschrift, sondern "der Katalog" wie er z.B. gedruckt vorliegt. Einmal sind also die Beschreibungen Metadaten (Fall 1: <msDesc> innerhalb von <sourceDesc>), das zweite Mal sind sie Daten (Volltext = <msDesc> innerhalb von <text>). *Keinesfalls* aber können die Angaben über die Handschriftenbeschreibungen wie von Dir vorgeschlagen in den Elementen 2.1.1 bis 2.1.5 untergebracht und die Handschrift *gleichzeitig* in <sourceDesc>/<msDesc> beschrieben werden. Dies wäre eine Verletzung des Paradigmas "entweder Handschrift oder Katalog". Da ich davon ausgehe, dass der DFG-Viewer eher dazu gedacht ist (sein sollte?), *die Handschrift selbst* zu (re)präsentieren, müssten die Felder genau entgegengesetzt definiert werden als von Dir vorgeschlagen, also z.B. der Autor der Handschrift und nicht des Katalogisats. [Sonst passiert dass, was im Demonstrator wie oben erwähnt falsch gelaufen ist: Die Handschrift hätte dann z.B. einen Autor Heinemann, nur weil der Katalog von ihn geschrieben worden ist. Das war natürlich falsch!] Der Autor des Katalogisats steht in msDesc/additional/adminInfo/recordHist/source. Wichtig allgemein zu diskutieren wäre mir noch Folgendes: Du erwähnst das Vorhandensein des METS/MODS-Profils, welches anstelle des vorliegenden verwendet werden könnte. Hier wäre es dem Material unbedingt angemessen, wenn wir auf diesen Hinweis verzichten würden, weil die Anwendung von MODS dazu verleiten mag, die Daten von vorneherein in nicht-sachdienlicher Form zu speichern und damit den Austausch erschweren. ========== Weitere Details, die noch nicht in das Dokument eingearbeitet wurden: - Die einzelnen Elemente werden nicht in "modularisierter" Form besprochen, d.h. die Aufzählung ist manchmal redundant (tei:p) und manchmal missverständlich (tei:summary). Könnte man nicht dem TEI-Vorbild folgen, die Elemente grundsätzlich in alphabetischer Reihenfolge aufzulisten und bei Oberelementen anzugeben, welche darin vorkommen können? - Ich finde auch den Sprachmix unglücklich. Zu allen TEI-Beschreibungen der genannten Elemente müsste es bei der TEI auch eine Übersetzung geben, wieso nicht diese verwenden, sondern das Englische? Würde nicht auch ein Link auf die TEI-Seite ausreichen bzw. nützlich sein? - Im Profil wird die Dokumentation der verwendeten Sprache nirgends erwähnt. In der TEI ist @xml:lang ein globales Attribut, wovon häufig Gebrauch gemacht wird. Insbesondere in internationalen Kontexten ist dies wichtig. Deshalb sollte grundsätzlich möglichst frühzeitig im XML-Dokument (=root), insbesondere aber auch an bestimmten definierten Stellen Gebrauch davon gemacht werden: bei <msDesc>, <title>, und bei allen Zitat-artigen Elementen. - Im Profil wird die Referenzierung auf Normdaten nicht thematisiert, vor allem bei Autoren, Texten, Orten etc. ist das aber von zentraler Bedeutung für die Interoperabilität der Daten. Das sollte unbedingt rein. - Das <publicationStmt> enthält bei Dir keinen Verweis auf die Rechtedeklaration. Den jüngsten Erfahrungen zufolge sind diese Angaben essentiell wichtig für den Datenaustausch und daher an dieser Stelle unabkömmlich, damit die Angaben in der Handschriftenbeschreibung verfügbar sind. Diese können nicht sinnvoll in die METS-Datei ausgelagert werden. (Vgl. dazu meine Kommentare im Dokument zum Element tei:availability) - Bei tei:date verzichtest Du auf @type, welches wir für die Differenzierung verwenden, wann das Dokument veröffentlicht bzw. wann die Handschrift digitalisiert worden ist. - Bei tei:idno (wir verwenden lokal <tei:ptr>) fehlt mir der type, mit dem man das anzuzeigende Thumbnail spezifizieren kann. Im Projekt Europeana Regia verwenden wir <ptr type="thumbnailForPresentations">. - Kann man nicht an fast allen Stellen auf die alternative Kodierung mittels tei:p verzichten? Wenn das nicht gewünscht ist, brauchen wir es nicht unbedingt zu erwähnen. - Ist bei tei:collection nicht auch noch @type angebracht, um gegebenenfalls die Art der Sammlungsbezeichnung zu dokumentieren? Man möchte ja gegebenenfalls nicht alle Angaben oder die vorhandenen n einer bestimmten Reihenfolge ausgeben? - Für tei:head siehst Du vor, dass "Die Angabe der nach DFG-Richtlinien gebildeten Schlagzeile im Unterelement tei:note[@type="caption"] [...] verpflichtend" sein soll. Wenn wir aber das Profil zugleich als Einführung und Richtlinie in die Katalogisierung bestimmter Basiskategorien (in Europeana Regia: "concise metadata") verstehen, dann zwingen wir den Katalogisierer, die Angaben doppelt zu machen, da z.B. die Angaben zu Entstehungsort und -zeit separat in recherchierbaren Felder angegeben werden *müssen*! Ich hatte hier bisher immer die Alternative Kodierung in Einzelfeldern vorgesehen und so arbeiten auch die Skripte. - In 2.2.2.2.9 gehört tei:textLang nach vorne, gemäß der Reihung in msContents! (2.2.2.2.9.3 statt 5) - In den Elementen handNote bzw. scriptNote sollte die Benutzung der Attribute scribe/scribeRef bzw. script/scriptRef anempfohlen werden. ========== Wichtig für die Etablierung des Anwendungsprofils wäre es ausserdem zu berücksichtigen, dass die Handschriftenzentren die Aufgabe haben, die Richtlinien Handschriftenkatalogisierung vor dem Hintergrund der Digitalisierung fortzuschreiben. Beste Grüße, Torsten [1] http://enrich.manuscriptorium.com, besonders: http://tei.oucs.ox.ac.uk/ENRICH/ODD/WP3_deliv_1.xml und http://projects.oucs.ox.ac.uk/ENRICH/Deliverables/referenceManual_en.html [2] http://www.europeanaregia.eu, Materialien zur Nutzung der TEI unter http://diglib.hab.de/rules/schema/ER/current/euroepana-regia.xml -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm <TEI-Anwendungsprofil 1.0.1_tsch.doc>

-----Ursprüngliche Nachricht----- Von: dv-technik-bounces(a)dfg-viewer.de [mailto:dv-technik-bounces@dfg- viewer.de] Im Auftrag von Torsten Schassan Gesendet: Montag, 8. Oktober 2012 14:59 An: Meyer, Sebastian Cc: Aurich, Frank; bettina.wagner(a)bsb-muenchen.de; 'Christoph Mackert'; technik(a)dfg-viewer.de; Haffner, Dr. Thomas Betreff: Re: [DFG-Viewer] TEI-Anwendungsprofil für Handschriften Lieber Sebastian, [@Alle: Diese Antwort ist ziemlich umfänglich und detailliert. Die unmittelbare Erwiderung auf Sebastians Fragen könnte für alle interessant sein, unterhalb einer Abtrennung geht es in die (Un-)Tiefen der TEI.] Eine überarbeitete Fassung des Dokuments hängt an. (Ich habe begonnen, die Kapitelzählung zu "normalisieren", im Korrekturmodus habe ich dann den Überblick über die vielen Ebenen verloren und Word ließ mich das Inhaltsverzeichnis nur einmal aktualisieren.) TEI-Anwendungsprofils für mittelalterliche Handschriften. Es stellt den Versuch dar, die aus dem MASTER-Projekt hervorgegangene Dokumentation zur Beschreibung von Handschriften in TEI-P5 mit METS zu verheiraten, um die Stärken beider Formate insbesondere in der Digitalisierung nutzen zu können. es ist ein bisschen schade, dass Du dieses Dokument "im stillen Kämmerlein" so weit fortgeschrieben hast, so dass nun die Zeit knapp ist und Dich dabei auf einen längst veralteten Stand beziehst (MASTER-Projekt) ohne neuere Entwicklungen zu berücksichtigen. Nicht nur die TEI hat sich seit dem MASTER-Projekt fortentwickelt, sondern auch die Nutzungsszenarien: Schon das ENRICH-Projekt [1] hatte die neueren Entwicklungen in der TEI aufgegriffen und zuletzt haben wir (i.e. BSB und HAB als deutsche Partner) im Projekt Europeana Regia [2] die ENRICH- Entwicklungen in Hinblick auf die Datenlieferung an die Europeana fortgeschrieben. Unglücklicherweise habe ich im Projekt Europeana Regia bereits ein ähnliches Dokument erstellt, in dem die Verwendung der TEI für Handschriften ausführlich erläutert ist. (Das Dokument war zur Projektlaufzeit nur für den internen Gebrauch bestimmt, die abschließende Veröffentlichung müssen wir noch organisieren. Bei Bedarf kann ich das schon mal rumschicken.) Ausserdem hat es auch einige theoretische Klärungen in der Frage gegeben, was der Inhalt einer TEI-Datei eigentlich ist. Dazu gleich mehr. Zugegebenermaßen war auch ich im ersten Beispiel für den Demonstrator in dieser Frage einem Irrtum aufgesessen, den wir mittlerweile geklärt haben. Handschriftenbeschreibung dann November tierung im DFG-Viewer bis Jahresende abzuschließen. Die theoretische Frage, was der Gegenstand eines TEI-Dokuments sei, ist wichtig für das Kapitel 2.1 des Anwendungsprofils. Wir (=HAB, analoge Lösungen, allerdings nicht auf TEI-Basis, bei ManuMed und e-codices) gehen davon aus, dass *die Handschrift* in einer TEI-Datei beschrieben werden kann, welche die Beschreibungsdaten im <teiHeader> enthält, per <facsimile> das Digitalisat repräsentiert und als <text> den Volltext der Handschrift bzw. wahlweise und als ersten Schritt die Strukturdaten aufnimmt. Die einzelnen Beschreibungen zur Handschrift, die ihrerseits in der Regel "historische" Dokumente und damit unveränderlich sind, werden am Besten in separaten TEI-Dokumenten gespeichert. In diesem zweiten Fall ist der Gegenstand der TEI-Datei nicht die Handschrift, sondern "der Katalog" wie er z.B. gedruckt vorliegt. Einmal sind also die Beschreibungen Metadaten (Fall 1: <msDesc> innerhalb von <sourceDesc>), das zweite Mal sind sie Daten (Volltext = <msDesc> innerhalb von <text>). *Keinesfalls* aber können die Angaben über die Handschriftenbeschreibungen wie von Dir vorgeschlagen in den Elementen 2.1.1 bis 2.1.5 untergebracht und die Handschrift *gleichzeitig* in <sourceDesc>/<msDesc> beschrieben werden. Dies wäre eine Verletzung des Paradigmas "entweder Handschrift oder Katalog". Da ich davon ausgehe, dass der DFG-Viewer eher dazu gedacht ist (sein sollte?), *die Handschrift selbst* zu (re)präsentieren, müssten die Felder genau entgegengesetzt definiert werden als von Dir vorgeschlagen, also

der Autor der Handschrift und nicht des Katalogisats. [Sonst passiert dass, was im Demonstrator wie oben erwähnt falsch gelaufen ist: Die Handschrift hätte dann z.B. einen Autor Heinemann, nur weil der Katalog von ihn geschrieben worden ist. Das war natürlich

Der Autor des Katalogisats steht in msDesc/additional/adminInfo/recordHist/source. Wichtig allgemein zu diskutieren wäre mir noch Folgendes: Du erwähnst das Vorhandensein des METS/MODS-Profils, welches anstelle des vorliegenden verwendet werden könnte. Hier wäre es dem Material unbedingt angemessen, wenn wir auf diesen Hinweis verzichten würden, weil die Anwendung von MODS dazu verleiten mag, die Daten von vorneherein in nicht-sachdienlicher Form zu speichern und damit den Austausch erschweren. ========== Weitere Details, die noch nicht in das Dokument eingearbeitet wurden: - Die einzelnen Elemente werden nicht in "modularisierter" Form besprochen, d.h. die Aufzählung ist manchmal redundant (tei:p) und manchmal missverständlich (tei:summary). Könnte man nicht dem TEI-Vorbild folgen, die Elemente grundsätzlich in alphabetischer Reihenfolge aufzulisten und bei Oberelementen anzugeben, welche darin vorkommen können? - Ich finde auch den Sprachmix unglücklich. Zu allen TEI-Beschreibungen der genannten Elemente müsste es bei der TEI auch eine Übersetzung geben, wieso nicht diese verwenden, sondern das Englische? Würde nicht auch ein Link auf die TEI-Seite ausreichen bzw. nützlich sein? - Im Profil wird die Dokumentation der verwendeten Sprache nirgends erwähnt. In der TEI ist @xml:lang ein globales Attribut, wovon häufig Gebrauch gemacht wird. Insbesondere in internationalen Kontexten ist dies wichtig. Deshalb sollte grundsätzlich möglichst frühzeitig im XML-Dokument (=root), insbesondere aber auch an bestimmten definierten Stellen Gebrauch davon gemacht werden: bei <msDesc>, <title>, und bei allen Zitat-artigen Elementen. - Im Profil wird die Referenzierung auf Normdaten nicht thematisiert, vor allem bei Autoren, Texten, Orten etc. ist das aber von zentraler Bedeutung für die Interoperabilität der Daten. Das sollte unbedingt rein. - Das <publicationStmt> enthält bei Dir keinen Verweis auf die Rechtedeklaration. Den jüngsten Erfahrungen zufolge sind diese Angaben essentiell wichtig für den Datenaustausch und daher an dieser Stelle unabkömmlich, damit die Angaben in der Handschriftenbeschreibung verfügbar sind. Diese können nicht sinnvoll in die METS-Datei ausgelagert werden. (Vgl. dazu meine Kommentare im Dokument zum Element tei:availability) - Bei tei:date verzichtest Du auf @type, welches wir für die Differenzierung verwenden, wann das Dokument veröffentlicht bzw. wann die Handschrift digitalisiert worden ist. - Bei tei:idno (wir verwenden lokal <tei:ptr>) fehlt mir der type, mit dem man das anzuzeigende Thumbnail spezifizieren kann. Im Projekt Europeana Regia verwenden wir <ptr type="thumbnailForPresentations">. - Kann man nicht an fast allen Stellen auf die alternative Kodierung mittels tei:p verzichten? Wenn das nicht gewünscht ist, brauchen wir es nicht unbedingt zu erwähnen. - Ist bei tei:collection nicht auch noch @type angebracht, um gegebenenfalls die Art der Sammlungsbezeichnung zu dokumentieren? Man möchte ja gegebenenfalls nicht alle Angaben oder die vorhandenen n einer bestimmten Reihenfolge ausgeben? - Für tei:head siehst Du vor, dass "Die Angabe der nach DFG-Richtlinien gebildeten Schlagzeile im Unterelement tei:note[@type="caption"] [...] verpflichtend" sein soll. Wenn wir aber das Profil zugleich als Einführung und Richtlinie in die Katalogisierung bestimmter Basiskategorien (in Europeana Regia: "concise metadata") verstehen, dann zwingen wir den Katalogisierer, die Angaben doppelt zu machen, da z.B. die Angaben zu Entstehungsort und -zeit separat in recherchierbaren Felder angegeben werden *müssen*! Ich hatte hier bisher immer die Alternative Kodierung in Einzelfeldern vorgesehen und so arbeiten auch die Skripte. - In 2.2.2.2.9 gehört tei:textLang nach vorne, gemäß der Reihung in msContents! (2.2.2.2.9.3 statt 5) - In den Elementen handNote bzw. scriptNote sollte die Benutzung der Attribute scribe/scribeRef bzw. script/scriptRef anempfohlen werden. ========== Wichtig für die Etablierung des Anwendungsprofils wäre es ausserdem zu berücksichtigen, dass die Handschriftenzentren die Aufgabe haben, die Richtlinien Handschriftenkatalogisierung vor dem Hintergrund der Digitalisierung fortzuschreiben. Beste Grüße, Torsten [1] http://enrich.manuscriptorium.com, besonders: http://tei.oucs.ox.ac.uk/ENRICH/ODD/WP3_deliv_1.xml und http://projects.oucs.ox.ac.uk/ENRICH/Deliverables/referenceManual_en.ht ml [2] http://www.europeanaregia.eu, Materialien zur Nutzung der TEI unter http://diglib.hab.de/rules/schema/ER/current/euroepana-regia.xml -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm

-----Ursprüngliche Nachricht----- Von: Torsten Schassan [mailto:schassan@hab.de] Gesendet: Mittwoch, 10. Oktober 2012 16:28 An: Claussnitzer, Ralf; &lt;technik(a)dfg-viewer.de&gt; Betreff: Re: [DFG-Viewer] TEI-Anwendungsprofil für Handschriften Lieber Herr Claussnitzer, (ODD) was genau meinen Sie mit "dem vorliegenden Dokument"? Die Word- Datei?

Da Sebastian Meyer dankenswerterweise eine sehr regelmäßige Form gewählt hat, gibt es Hoffnung, dies überhaupt hinzubekommen, ohne Nacharbeit wird es aber nicht gehen. Eine Elementdefinition aus einem ODD sähe z.B. so aus: <elementSpec ident="name" mode="change" module="core"> <desc>...</desc> <attList> <attDef ident="type" mode="change" usage="rec"> <defaultVal>unknown</defaultVal> <valList type="semi" mode="replace"> <valItem ident="person"> <desc>the name of a person</desc> </valItem> <valItem ident="place"> <desc>the name of a place</desc> </valItem> <valItem ident="project"> <desc>the name of a project</desc> </valItem> <valItem ident="org"> <desc>the name of an organisation</desc> </valItem> <valItem ident="unknown"> <desc>name of an unknown type</desc> </valItem> </valList> </attDef> </attList> </elementSpec>

Insbesondere im Feld "Wiederholbarkeit" gibt es aber Bezüge, die eigentlich in der Definition des "Elternfeldes" oder an noch anderen

untergebracht werden müssten. Problematisch wirkt sich hier auch die hierarchische Gliederung des Dokuments im Gegensatz zur modularen der TEI aus. Vielleicht ließe sich mit einem TEI-generierten ODD und einem aus dem Word-Dokument semi-automatisch umgewandelten ODD und einer "Vereinigung" mittels XSLT einiges abkürzen.

Ich hoffe, dass ich Sie nicht missverstanden habe, wenn doch bitte ich um Nachfrage. Best Grüße, Torsten Schaßan -- Torsten Schassan Digitale Editionen Abteilung Handschriften und Sondersammlungen Herzog August Bibliothek, Postfach 1364, D-38299 Wolfenbuettel Tel.: +49-5331-808-130 (Fax -165), schassan {at} hab.de *neu: Handschriftendatenbank* http://diglib.hab.de/?db=mss http://www.hab.de/forschung/projekte/europeana-regia.htm

Lieber Herr Claussnitzer, <snip/> Aus dem ODD kann aus Roma heraus eine lesbare Dokumentation gewonnen werden, dieses Argument spricht also nicht unbedingt für die Word-Variante. Das Element <desc/> ist hier die Leerstelle, welche die ausführlichere Beschreibung aufnehmen würde. Das ODD hätte tatsächlich den Charme, das was Sebastian Meyer umschrieben hat, zugleich formal zu fassen und daraus ein Schema generieren zu können. Dieser Schritt wäre bei der Word-Lösung ebenfalls noch gehen.