---
# System prepended metadata

title: Coaching PARES

---

# Coaching PARES

# 1. Coaching, 3.3.2025: Introduction 

## Devoirs 
- Create a Transkribus Account 
- Have a read/look at: https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/
    - Especially: https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/2_Editionsarbeit/03_Transkription/ 

## Contenu

[toc]

[French Version]

Présents : Fanny (PostDoc), Melike (HiWi), Stéphanie (HiWi Lehrstul), Claudia (PostDoc), Cécile (HiWi), Ursula (Bossin)  

## 1. Où va-t-on ? Des plates-formes d'archivage et d'édition exemplaires 

Par plateforme d'archivage ou d'édition, les projets entendent des choses très différentes ; voici un aperçu de projets importants, dont certains sont exemplaires :

- Archives Hugo Schuchardt : https://gams.uni-graz.at/context:hsa
    - Edition numérique 'classique' de lettres, qui met en outre à disposition quelques documents d'archives (journal de l'épouse, photographies) non transcrits et édités. 
- Lavater-online : https://www.jclavater-briefwechsel.ch/home
    - Edition de lettres avec une part de lettres uniquement transcrites (voir https://www.jclavater-briefwechsel.ch/edition/list?query=state :(Transcription%2520OR%2520Edition).
- Iurisprudentia : https://rwi.app/iurisprudentia/de
    - Pas de 'véritable édition', car 'seulement' des transcriptions (automatiques, en grande partie non corrigées), donc 'version de laboratoire'. A été transcrite avec l'outil Transkribus et - chose plutôt inhabituelle - également publiée. 
- Stoffe online : https://fd-stoffe-online.ch/intro
    - Edition avec une partie « archives », mais contrairement aux archives Schuchardt, les parties « archives » sont transcrites (il existe des numérisations non transcrites de l'ensemble des substances, mais elles n'ont pas été publiées).
- hallernet : http://hallernet.org/
    - Ne se présente pas comme des 'archives', mais met en avant sa fonction de plateforme de mise en réseau de diverses correspondances et écrits relatifs à Albrecht von Haller. 
    - Contient également de nombreuses numérisations de manuscrits qui n'ont pas (encore ?) été éditées.
- Becher-online - encore en construction grâce aux ALS et à Unibe. A l'avenir, l'œuvre d'Ulrich Becher sera principalement mise à disposition sous forme d'archives numériques, idéalement avec des éditions numériques exemplaires. 


## 2. Entrée en matière : notions et concepts centraux
Pour le travail éditorial dans PARES, quelques concepts de base des digital humanities (DH), notamment en ce qui concerne les digitale schloarly editions (DSE), sont nécessaires :

### 1. Avec quoi travaillons-nous ? (Méta)données et code

#### Données
- En principe, nous travaillons *toujours* avec des données numériques dans le champ DH et nous les traitons, indépendamment du format et de l'outil ou de l'interface graphique (voir ci-dessous). Nous ne travaillons donc pas avec des manuscrits, mais avec leur numérisation en tant que données, pas avec des livres, mais avec du texte numérique, etc. 

    => Aussi banal que cela puisse paraître, il est décisif, dans le travail quotidien, de passer de la 'logique du papier' à la logique des données, car c'est dans cette dernière que se posent des problèmes et des solutions tout à fait différents pour les thèmes des sciences humaines (ce que cela signifie pour les DSE a été décrit en détail par Patrick Sahle en 2013 dans son ouvrage de référence en trois parties [« Digitale Editionsformen »](https://www.i-d-e.de/publikationen/schriften/s7-9-digitale-editionsformen/), ). 

- Toutes les données sont basées sur un code et peuvent être traitées comme tel ('coder'). Il ne faut pas confondre cela avec la programmation d'applications : en règle générale, « notre » code ne génère pas de programme, c'est-à-dire d'opérations de calcul, mais est lu par des programmes (et par nous). La syntaxe de code la plus utilisée (surtout XML, voir ci-dessous) n'est donc pas un 'langage de programmation', mais un **'langage de balisage'**.

#### Code vs GUI
- Pour faciliter la tâche des chercheurs en sciences humaines, il existe de nombreuses interfaces utilisateur graphiques (GUI) qui affichent le code sous une forme plus agréable. L'interface graphique la plus célèbre pour le traitement de texte est Word - mais nous ne voyons pas le code XML qui se cache derrière. Un autre exemple est ce document Markdown qui peut être affiché comme code Markdown (MD) ou comme document texte rendu.
     - Le code 'montre' tout et est donc 'honnête', mais doit être appris. Vous voyez ce que vous obtenez'. 
    - L'interface utilisateur au-dessus du code l'interprète d'une certaine manière, ce qui soulage le travail de compréhension, mais est souvent plus limité et sujet aux erreurs. 

#### Métadonnées
- Les métadonnées sont des données sur les données. 
- La distinction entre données et métadonnées est 'seulement' conceptuelle et perspective, jamais objective : 
    - Du point de vue des utilisateurs de la bibliothèque, les bibliothécaires travaillent avec des métadonnées sur les textes (numériques et physiques) de la bibliothèque. Mais comme ils s'intéressent peu à ces textes, ils ne parleraient pas de métadonnées (d'autant plus que cela ne rendrait pas justice à la complexité de la saisie de données bibliothéconomiques appelée FRBR). 
    - Chaque ensemble de métadonnées peut lui-même avoir différentes métadonnées : l'en-tête TEI d'une lettre rassemble les métadonnées sur une lettre codée en TEI/XML, une table de métadonnées peut regrouper tous les en-têtes TEI en un ensemble de lettres, l'ensemble de lettres peut être saisi comme un seul nœud de données dans une base de données, etc).
    
    => Pour nous, la question importante n'est pas : *sont-elles* des métadonnées ? Mais plutôt : *sur quelles* données (ou ensembles de données) me renseignent-elles ?


Les métadonnées suivantes sont importantes dans le projet :
    - Métadonnées des archives et des bibliothèques qui doivent être affinées.
    - Métadonnées personnelles ainsi créées dans la base de données Heurist. 
    - Métadonnées dans les documents édités, appelées en-têtes TEI. 
        - Pour les lettres, la section 'Correspdesc' (description de la correspondance), cf. https://www.tei-c.org/release/doc/tei-p5-doc/de/html/ref-correspDesc.html 

### 2. situation initiale : les sources en tant que données d'images 
Les images numériques peuvent avoir différents formats (jpeg, tiff, png, etc.). Pour leur traitement, cela est toutefois moins important aujourd'hui que la question de savoir comment les images numériques sont accessibles sur Internet. Dans ce contexte, le IIIF (international image interoperability framework) est devenu un outil central :

- IIIF : cadre qui met à disposition des métadonnées standardisées sur les ressources d'images de manière à ce que l'image puisse être représentée indépendamment de sa présentation sur son serveur d'origine. 
- Un manifeste IIIF est un fichier en code JSON (JavaScript object syntax) qui permet de retrouver l'image sur son serveur d'origine. Un exemple est ce manifeste d'une lettre d'Annemarie Schwarzenbach, qui réunit toutes les pages de la lettre : https://iiif.annemarie-schwarzenbach.ch/presentation/letter_0001.json 
    - La lettre elle-même se trouve sur un serveur IIIV de la Bibliothèque universitaire de Lausanne (BCU) et y possède un manifeste IIIF par page : https://patrinum.ch/nanna/api/multimedia/image/v2/recid%3A587676-BCUL-PREVIEW-426354_0003.jpg/info.json
    - Si l'on veut voir la page de la lettre elle-même, on peut soit entrer les manifestes dans un visualiseur IIIF (voir ci-dessous), soit simplement remplacer le suffixe `/info.json` par `/full/max/0/default.jpg`, c'est-à-dire : https://patrinum.ch/nanna/api/multimedia/image/v2/recid%3A587676-BCUL-PREVIEW-426354_0003.jpg/full/max/0/default.jpg
    
- IIIF-Viewer : permet de récupérer n'importe quelle image ou séquence d'images possédant un manifeste IIIF et de l'afficher selon ses propres paramètres.
   
    - https://universalviewer.io/
    - https://projectmirador.org/
    - https://viewer.zb.uzh.ch/index.php
-> Cela peut être testé avec https://iiif.annemarie-schwarzenbach.ch/presentation/letter_0001.json (toutes les visionneuses ne parviennent pas à lire correctement le manifeste !) 


### 3. De l'image au 'texte brut' : transcription ATR

Automatic Text Recognition (ATR) - ou dans le cas spécifique des manuscrits : Handwritten Text Recognition (HTR) - permet de transformer le texte en image en texte en code. Nous utilisons pour cela l'outil [Transkribus](https://app.transkribus.org/).

- Le code de sortie le plus répandu de l'ATR est PAGE-XML. XML signifie e**X**tended **M**arkup **L**anguage - c'est-à-dire un 'langage de balisage étendu'. Dans ce cas, PAGE signifie qu'il crée un nouveau fichier XML pour chaque page.
- ATR peut se baser sur différentes technologies : 
    - la plus ancienne est l'OCR (optical character recognition), qui tente de lire optiquement chaque caractère sur la base d'une similitude formelle et qui n'est plus guère utilisée aujourd'hui. 
    - Les outils ATR plus récents utilisent différentes formes d'IA qui déterminent la similitude non pas par de simples comparaisons, mais par des probabilités. Les modèles pertinents pour l'utilisation de transcribus sont : 
        - **Modèles Pylaia** : Sont spécialisés dans certains types d'écriture et peuvent être entraînés ultérieurement pour une écriture spécifique.
        - **Modèles transformateurs** ('supermodèles', par ex. 'The Text Titan') : Basés sur la forme la plus récente d'IA (architecture de ChatGPT, etc.) et peuvent donc reconnaître différentes polices de caractères en même temps, MAIS ne peuvent pas encore être entraînés/enrichis par nos soins.

Perspectives pour le 2e coaching : 

### [4. conversions : différents langages de balisage]

### [5. TEI/XML : Que signifie coder en DSE ?]





# 1. Coaching, 3.3.2025 [German Version]

Anwesend: Fanny (PostDoc), Melike (HiWi), Stéphanie (HiWi Lehrstul), Claudia (PostDoc), Cécile (HiWi), Ursula (Bossin)  

## Wohin geht die Reise? Vorbildliche Archiv- und Editionsplattformen 

Unter einer Archiv- bzw. Editionsplattform verstehen Projekte sehr Unterschiedliches, hier ein Überblick über wichtige, z.T. vorbildhafte Projekte:

- Hugo Schuchardt Archiv: https://gams.uni-graz.at/context:hsa
    - Weitgehend 'klassische' digitale Edition von Briefen, die zusätzlich wenige Archivmaterialien (Tagebuch der Ehefrau, Fotografien) untranskribiert und -ediert zur Verfügung stellt. 
- Lavater-online: https://www.jclavater-briefwechsel.ch/home
    - Briefedition mit einem Anteil nur transkribierter Briefe (siehe https://www.jclavater-briefwechsel.ch/edition/list?query=state:(Transkription%2520OR%2520Edition).
- Iurisprudentia: https://rwi.app/iurisprudentia/de
    - Keine 'eigentliche Edition', da 'nur' (maschinelle, weitgehend unkorrigierte) Transkriptionen, deshalb "Labor-Version". Wurde mit dem tool Transkribus transkribiert und - eher unüblich - auch publiziert. 
- Stoffe online: https://fd-stoffe-online.ch/intro
    - Edition mit Archiv-Teil, jedoch anders als im Schuchardt Archiv sind die 'Archiv'-Bestandteile transkribiert (untranskribierte Digitalisate aus dem Stoffe-Konvolut gibt es zwar, wurden jedoch nicht veröffentlicht)
- hallernet: http://hallernet.org/
    - Gibt sich nicht als 'Archiv' zu erkennen, stellt aber seine Funktion als Vernetzungsplattform diverser Korrespondenzen und Schriften rund um Albrecht von Haller in den Vordergrund. 
    - Enthält ebenfalls etliche (noch?) nicht edierte Digitalisate von Manuskripten.
- Becher-online - noch im Aufbau durch SLA und Unibe. Wird in Zukunft Ulrich Bechers Werk primär als digitales Archiv zur Verfügung stellen, idealerweise mit exemplarischen digitalen Editionen. 


## Einstieg: Zentrale Begriffe und Konzepte
Für die editorische Arbeit in PARES sind einige Grundkonzepte der digital humanities (DH), insbesondere bezüglich digitale schloarly editions (DSE) notwendig:

### 1. Womit arbeiten wir? (Meta-)Daten und Code

#### Daten
- Grundsätzlich arbeiten wir im DH-Feld *immer* mit digitalen Daten und bearbeiten diese, unabhängig von Format und tool bzw. GUI (s.u.). Wir arbeiten also nicht mit Manuskripten, sondern ihrem Digitalisat als Data, nicht mit Büchern, sondern digitalem Text etc. 

    => So banal das scheint, ist es in der täglichen Arbeit entscheidend von der 'Logik des Papiers' zur Logik von Daten zu kommen, da sich in dieser ganz andere Probleme und Lösungen für geisteswissenschaftliche Themen ergeben (was das für DSE bedeutet hat Patrick Sahle 2013 ausführlich beschrieben im dreiteiligen Standardwerk ["Digitale Editionsformen"](https://www.i-d-e.de/publikationen/schriften/s7-9-digitale-editionsformen/), ). 

- Alle Daten bestehen auf der Basis von Code und können als solcher bearbeitet werden ('Codieren'). Das ist nich zu verwechseln mit dem Programmieren von Anwendungen: 'Unser' Code erzeugt i.d.R. kein Programm, d.h. keine Rechenoperationen, sondern wird von Programmen (und uns) ausgelesen. Die meistens verwendete Code-Syntax (v.a. XML, s.u.) ist darum keine 'Programmiersprache', sondern eine **'Auszeichnungssprache'**.

#### Code vs GUI
- Um es Geisteswissenschaftler:innen einfach zu machen, existieren viele Oberflächen (graphical user interfaces = GUI), die den Code bereits in schönerer Form ausgeben. Die berühmteste GUI zur Textverarbeitung ist Word - nur sehen wir den XML-Code dahinter nicht. Ein anderes Beispiel ist dieses Markdown-Dokument, das sich als Markdown (MD) Code, oder als gerendertes Textdokument darstellen lässt.
     - Der Code 'zeigt' alles und ist dadurch 'ehrlich', muss aber erlernt werden. 'You see what you get'. 
    - Die Benutzeroberfläche über dem Code interpretiert diesen auf eine bestimmte Weise, nimmt also Verstehensarbeit ab, ist aber oftmals begrenzter und fehleranfälliger. 

#### Metadaten
- Metadaten sind Daten über Daten. 
- Die Unterscheidung von Daten und Metadaten ist 'nur' konzeptuell und perspektivisch, nie objektiv: 
    - Bibliothekar:innen arbeiten aus der Sicht der Bibliotheksbenutzer:innen mit Metadaten über die (digitalen und physischen) Texte der Bibliothek. Da sie sich selbst jedoch wenig für diese Texte interessieren, würden sie kaum von Metadaten sprechen (zumal das der Komplexität der bibliothekarischen Datenerfassung namens FRBR nicht gerecht würde) 
    - Jeder Metadatensatz kann selbst unterschiedliche Metadaten haben: der TEI-Header eines Briefes versammelt die Metadaten über ein TEI/XML codierten Brief, eine Metadatentabellen kann alle TEI-Header zu einem Briefkonvolut zusammenfassen, das Briefkonvolut kann als einzelner Datenknotenpunkt in einer Datenbank erfasst werden etc.)
    
    => Für uns wichtig ist nicht die Frage: *Sind* das Metadaten? Sondern: *über welche* Daten(-Sätze) geben sie mir Auskunft?
    
    Im Projekt sind folgede Metadaten wichtig:
    - Metadaten der Archive und Bibliotheken, die verfeinert werden müssen
    - So erzeugte eigene Metadaten in der Heurist-Datenbank 
    - Metadaten in den edierten Dokumenten, sog. TEI-header. 
        - Für Briefe der dortige Abschnitt 'Correspdesc' (Korrespondenz Beschreibung), vgl. https://www.tei-c.org/release/doc/tei-p5-doc/de/html/ref-correspDesc.html 

### 2. Ausgangslage: Quellen als Bilddaten 
Digitale Bilder können verschiedene Formate besitzen (jpeg, tiff, png etc.). Für ihre Bearbeitung ist dies heute jedoch weniger wichtig als die Frage, wie die digitalen Bilder auf dem Internet zugänglich sind. Dabei hat sich der IIIF (international image interoperability framework) zum zentralen Werkzeug entwickelt:

- IIIF: Framework, das standardisierte Metadaten über Bildressourcen so zur Verfügung stellt, dass das Bild unabhängig von der Präsentation auf seinem Ursprungsserver dargestellt werden kann. 
- Ein IIIF-Manifest ist eine Datein in JSON-Code (JavaScript object syntax), das das Bild auf seinem Ursprungsserver auffindbar macht. Ein Beispiel ist dieses Manifest eines Briefes von Annemarie Schwarzenbach, das alle Briefseiten vereint: https://iiif.annemarie-schwarzenbach.ch/presentation/letter_0001.json 
    - Der Brief selbst liegt auf einem IIIV-Server der Universitätsbibliothek Lausanne (BCU) und hat dort  ein IIIF-Manifest pro Seite: https://patrinum.ch/nanna/api/multimedia/image/v2/recid%3A587676-BCUL-PREVIEW-426354_0003.jpg/info.json
    - Wenn man die einzelne Briefseite selbst anschauen will, kann man die Manifeste entweder in einen IIIF-Viewer eingeben (s.u) oder einfach die Endung `/info.json` ersetzen durch `/full/max/0/default.jpg` ersetzen, d.h.: https://patrinum.ch/nanna/api/multimedia/image/v2/recid%3A587676-BCUL-PREVIEW-426354_0003.jpg/full/max/0/default.jpg
    
- IIIF-Viewer: Erlaubt ein beliebiges Bild oder eine Folge von Bildern, die ein IIIF-Manifest besitzen, abzurufen und nach eigenen Parametern darzustellen.
   
    - https://universalviewer.io/
    - https://projectmirador.org/
    - https://viewer.zb.uzh.ch/index.php
-> Das kann mit https://iiif.annemarie-schwarzenbach.ch/presentation/letter_0001.json getestet werden (nicht jeder viewer schafft es, das Manifest korrekt auszulesen!). 


### 3. Vom Bild zum 'Rohtext': ATR-Transkription

Automatic Text Recognition (ATR) - oder im spezifischen Fall von Handschriften: Handwritten Text Recognition (HTR) - erlaubt es, Text-als-Bild zu Text-als-Code zu transformieren. Wir verwenden hierfür das tool [Transkribus](https://app.transkribus.org/).

- Der verbreitetste Ausgabe-Code von ATR ist PAGE-XML. XML steht für e**X**tended **M**arkup **L**anguage - d.h. eine 'erweiterte Auszeichnungssprache'. PAGE heisst in diesem Fall, dass es für jede Seite eine neue XML-Datei erzeugt.
- ATR kann auf verschiedenen Technologien basieren: 
    - die älteste ist OCR (optical character recognition), die jedes einzelne Zeichen versucht optisch anhand von formaler Ähnlichkeit auszulesen und heute kaum mehr benutzt ist. 
    - Neuere ATR-tools verwenden verschiedene Formen von KI, die Ähnlichkeit nicht durch einfache Vergleiche, sondern durch Wahrscheinlichkeiten feststellen. Für die Verwendung von Transkribus relevant sind: 
        - **Pylaia-Modelle**: Sind spezialisiert auf gewisse Schrifttypen und können nachtrainiert werden auf eine spezifische Schrift hin.
        - **Transformer-Modelle** ('Supermodelle', e.g. 'The Text Titan'): Basieren auf der neuesten Form von KI (Architektur v. ChatGPT etc.) und können darum verschiedene Schrifttypen gleichzeitig erkennen, ABER können zurzeit von uns noch nicht nachtrainiert/angereichert werden.

Ausblick auf 2. Coaching: 

### [4. Konversionen: Verschiedene Auszeichnungssprachen]

### [5. TEI/XML: Was bedeuetet Codieren in DSE?]


# 2. Coaching, 10.3.2025: Transkribus 


Présent : Fanny (PostDoc), Melike (HiWi), Stéphanie (HiWi Lehrstul), Claudia (PostDoc), Cécile (HiWi)

[toc]

Nous nous appuyons aujourd'hui sur les ressources suivantes: 
- Le manuel de la semaine dernière, notamment le troisième chapitre sur [De l'image au 'texte brut' : transcription ATR](https://hackmd.io/fuJvtiq7R66lu4gMXAm1Xw?stext=8233%3A49%3A0%3A1741592989%3Afdbp5D&both=)
- Les [chapitres de Proto4DigEd sur la transcription](https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/2_Editionsarbeit/03_Transkription/) 

La [documentation spécifique au projet d'édition numérique d'Annemarie Schwarzenbachb sur la procédure de transcription](https://hackmd.io/@DSE-AS/Transkribus_Dokumentation) pourrait être intéressante, même si elle ne concerne malheureusement que les collègues germanophones de l'équipe. Elle aborde quelques cas spéciaux (notamment la transcription de reportages photographiques complexes) qui ne joueront vraisemblablement guère de rôle dans PARES. 

## 1. fonctions de base de Transkribus

:::warning
Transkribus modifie son interface et ses fonctionnalités dans des mises à jour irrégulières et parfois imprévisibles. En principe, pas de panique ! Si des données et des fonctions ne sont plus accessibles, il est important d'en informer les membres de l'équipe et surtout le personnel technique.
-> Jusqu'à présent, des solutions ont été trouvées à tous les problèmes !
::: 


### 1. système de crédits

Transkribus a un modèle dans lequel chaque activité opérationnelle du serveur (reconnaissance de la mise en page, reconnaissance du texte, reconnaissance des tableaux) consomme des 'crédits'. Il est relativement généreux dans l'attribution de crédits **'personnels'** ; ceux-ci ne permettent cependant pas toutes les fonctions et, surtout, le traitement avec ceux-ci peut être considérablement retardé (faible priorité du serveur). 
Pour un travail professionnel, des crédits **'professionnels'** sont nécessaires, ce qui est rendu possible par l'inscription à des abonnements institutionnels et à certaines collections (voir ci-dessous).

### 2. collections

Les collections de Transkribus ne fonctionnent pas seulement comme des dossiers dans lesquels il est possible de faire des recherches et de les organiser. Certaines fonctions leur sont associées : Si une collection est affectée à un projet et qu'une personne s'y trouve également, cela permet d'utiliser des crédits 'professionnels'. 

:::danger
La suppression de collections entières et de leur contenu est possible pour tous les membres de l'équipe qui ont une fonction 'owner'. Cette suppression ne peut pas être annulée.
En revanche, il n'est pas possible de supprimer des documents individuels que quelqu'un d'autre a téléchargés (sauf si la collection entière est supprimée, ce qui n'est PAS recommandé). 
:::

### 3. traitement manuel vs. automatique 

Transkribus permet d'effectuer toutes les étapes automatisées manuellement. Dans le cas de mises en page de texte qui diffèrent de la norme (par ex. lignes obliques ou verticales), un (pré)traitement manuel est souvent nécessaire.

### 4. modèles de reconnaissance

#### 4.1 Modèles de mise en page
- Ne sont nécessaires que si les modèles ATR produisent de très mauvais résultats.
    - Pour les grandes quantités de texte, il vaut la peine de faire différents essais avec eux. Pour les petites quantités de texte, un prétraitement manuel est souvent aussi rapide ou plus rapide.  
- Il est absolument recommandé pour les mises en page en colonnes de textes imprimés (p. ex. dans les journaux). Des préréglages spécifiques doivent être effectués pour leur reconnaissance. 

#### 4.1.1 Reconnaissance de texte avec les modèles Pylaia (modèle standard)

##### Modèles Pylaia prédéfinis

- Deux formes : Modèles Pylaia publics ou modèles Pylaia disponibles à l'intérieur du projet (en accédant à une collection). 
- Plus le nombre de CER est petit, plus le modèle devrait être utilisable pour ses objectifs (par ex. pour des impressions ou certains manuscrits historiques).


##### Entraînement d'un modèle Pylaia

- L'entraînement est un processus plus long, qui nécessite des matériaux de base déjà correctement transcrits (ce qu'on appelle la 'vérité terrain'). Nous n'entrerons pas dans les détails de l'entraînement aujourd'hui. 
- Le modèle 'Proto4DigEd 2. modèle_2' est déjà entraîné par le projet : il maîtrise en général l'écriture de Gaston Paris de manière satisfaisante, mais pas parfaite. 

#### 4.2 Reconnaissance de texte avec le modèle Transformer (super-modèle Text Titan I)

- Text Titan I est capable de transcrire automatiquement des manuscrits difficiles, mais son accès est limité à certains abonnements et collections. 

## 2. Tâches

Pour résoudre les tâches, vous avez besoin des fichiers image dans le dossier suivant : 
https://drive.google.com/drive/folders/1Xh4o5-7rxCnAMhAn1UicjOVFbO3MpJSm?usp=sharing

Les exercices se font en ligne : 
- Téléchargement
- Écriture à la main. Création manuelle de la mise en page
- Écritures manuscrites : ATR avec Pylaia
- (Manuscrits : ATR avec texte Titan I)
- (Impression : création manuelle de la mise en page)


# 2. Coaching, 10.3.2025: Transkribus [German version]

Wir bauen heute auf folgende Ressourcen auf: 
- Das Handbuch der letzten Woche, insbesondere das dritte Kapitel zum Thema [De l'image au 'texte brut' : transcription ATR](https://hackmd.io/fuJvtiq7R66lu4gMXAm1Xw?stext=8233%3A49%3A0%3A1741592989%3Afdbp5D&both=)
- Die [Proto4DigEd-Kapitel zur Transkription](https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/2_Editionsarbeit/03_Transkription/) 

Von Interesse, wenn auch leider nur für die deutschsprachigen Team-Kolleginnen, könnte [die projektspezifische Dokumentation der Digitalen Edition Annemarie Schwarzenbachbs zum Vorgehen in Transkribus](https://hackmd.io/@DSE-AS/Transkribus_Dokumentation) sein. Sie geht auf einige Spezialfälle (insbesondere die Transkription von komplexen Fotoreportage) ein, die in PARES voraussichtlich kaum eine Rolle spielen werden. 

## 1. Grundfunktionen von Transkribus

:::warning
Transkribus ändert in unregelmässigen und z.T. unvorhersehbaren Updates die Oberfläche und Funktionalität. Grundsätzlich gilt: Keine Panik! Wenn Daten und Funktionen nicht mehr zugänglich sind, ist es wichtig, die Team-Mitglieder und v.a. das technische Personal zu informieren.
-> Bislang wurden für alle Probleme Lösungen gefunden!
:::

### 1. Credit-System

Transkribus hat ein Modell, in dem jede operationelle Server-Aktivität (Layout-Erkennung, Texterkennung, Tabellenerkennung) 'Credits' verbraucht. Es ist relativ grosszügig in der Vergabe **'persönlicher' Credits**; diese erlauben jedoch nicht jede Funktion und vor allem kann sich die Verarbeitung mit diesen wesentlich verzögert gestalten (geringe Server-Priorität). 
Für professionelles Arbeiten werden **'professionelle' Credits** nötig, die durch die Aufnahme in institutionelle Abonnements und bestimmte Collections ermöglicht wird (s.u.).

### 2. Collections

Collections in Transkribus funktionieren nicht nur wie Ordner, die sich durchsuchen und gliedern lassen. Mit ihnen verknüpft sind bestimmte Funktionen: Ist eine Collection einem Projekt zugewiesen und eine sich darin befindliche Person ebenfalls, erlaubt dies die Verwendung 'professioneller' Credits. 

:::danger
Das Löschen ganzer Collections und ihrer Inhalte ist allen Team-Mitgliedern, die eine 'owner'-Funktion haben, möglich. Dieses Löschen lässt sich nicht rückgängig machen.
Hingegen lassen sich Einzeldokumente, die jemand anders hochgeladen hat, nicht löschen (ausser die ganze Collection wird gelöscht, was NICHT empfohlen wird). 
:::

### 3. Manuelle vs. automatische Verarbeitung 

Transkribus erlaubt alle automatisierten Schritte auch manuell auszuführen. Im Falle von Textlayouts, die vom Standard abweichen (z.B. schräge oder vertikale Zeilen) ist oftmals eine manuelle (Vor-)Bearbeitung nötig.

### 4. Erkennungsmodell-Modelle

#### 4.1 Layout-Modelle
- Sind nur notwendig, wenn die ATR-Modelle sehr schlechte Ergebnisse erzeugen.
    - Bei grösseren Textmengen lohnt es sich, verschiedene Versuche damit zu machen. Bei kleinen Textmengen ist oft eine manuelle Vorbearbeitung gleich schnell oder schneller.  
- Unbedingt empfohlen bei Spalten-Layouts von gedrucktem Text (z.B. in Zeitungen). Für ihre Erkennung müssen spezifische Voreinstellungen gemacht werden. 

#### 4.1.1 Texterkennung mit Pylaia-Modellen (Standard-Modell)

##### Vorgefertigte Pylaia-Modelle

- Zwei Formen: Öffentliche Pylaia-Modelle oder Pylaia-Modelle die projektintern verfügbar sind (durch Zutritt in eine Collection). 
- Je kleiner die CER-Zahl ist, desto besser sollte das Modell für seine Zwecke nutzbar sein (z.B. für Prints oder bestimmte historische Handschriften)


##### Training eines Pylaia-Modells

- Das Training ist ein längerer Prozess, der bereits korrekt transkribiertes Grundlagenmatierial (sog. 'Ground Truth') benötigt. Wir werden heute nicht in die Details des Trainings gehen. 
- Bereits vom Projekt trainiert ist das Modell'Proto4DigEd 2. Modell_2': Es meistert die Handschrift Gaston Paris' in der Regel befriedigend, aber nicht perfekt. 

#### 4.2 Texterkennung mit dem Transformer-Modell (Super-Modell Text Titan I)

- Text Titan I ist fähig, auch schwierige Handschriften automatisch zu transkribieren, sein Zugang ist jedoch auf bestimmte Abonnements und Collections eingeschränkt. 

## 2. Aufgaben

Für die Lösung der Aufgaben benötigt ihr die Bild-Dateien in folgendem Ordner: 
https://drive.google.com/drive/folders/1Xh4o5-7rxCnAMhAn1UicjOVFbO3MpJSm?usp=sharing

Geübt wird: 
- Upload
- Handschriften. Manuelle Layout-Erstellung
- Handschriften: ATR mit Pylaia
- (Handschriften: ATR mit Text Titan I)
- (Print: Manuelle Layout-Erstellung)


# 3. Coaching, 17.3.25 : TEI/XML 

**Organisation** : Annulation du coaching les 24 et 31 mars – ensuite, nous poursuivrons avec le workflow PARES !

## 0. Retour sur Transkribus
- Transcription avec le modèle **Proto4DigED** (modèle Pylaia) ou **Text Titan** (« supermodèle »/modèle Transformer)
- Édition manuelle (si souhaité : courte introduction à la configuration des mises en page complexes)

## 1. Propriétés fondamentales de TEI/XML

### Ressources Internet utiles :
- [Introduction simple à TEI/XML et Oxygen par l'Université de l'Illinois](https://guides.library.illinois.edu/c.php?g=347707&p=2344750)
- [Introduction à TEI/XML du consortium TEI](https://tei-c.org/release/doc/tei-p5-doc/en/html/SG.html)
- Entrée [TEI](https://www.digitale-edition.at/o:konde.178) dans le [Konde Weißbuch Digitale Edition](https://www.digitale-edition.at) (le lexique numérique le plus important pour l'édition numérique)
- [Chapitre du manuel Proto4DigEd sur l'annotation sémantique en TEI/XML](https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/2_Editionsarbeit/05_semantic_annotation/) (disponible en anglais ou en allemand)

### Qu'est-ce que XML ?

Le **eXtensible Markup Language** (langage de balisage extensible) permet de coder des textes complexes avec un haut degré de balises extensibles et spécifiques au projet.  
Cependant, la représentation (**rendering**) d’un document XML doit être spécialisée, c'est-à-dire adaptée au projet (par exemple, via des configurations ODD dans **TEI Publisher**, voir ci-dessous).

### Qu'est-ce que TEI ?

L’**Initiative d'encodage de texte (TEI)** a développé un ensemble de codages XML et de règles d’utilisation qui sont aujourd’hui fondamentaux dans les **Humanités numériques**. Cet ensemble est régulièrement mis à jour et enrichi. Il est accessible ici : [https://tei-c.org](https://tei-c.org)

:::warning  
TEI/XML n'est pas une norme stricte. Autrement dit, pour un même phénomène textuel, il n’existe pas **une seule** manière correcte de coder l’information, mais souvent plusieurs alternatives tout aussi valables.  
Cela donne une certaine liberté aux projets, mais peut aussi entraîner des problèmes d’interopérabilité.  
:::

La sélection spécifique de codages TEI/XML et leur utilisation propre à un projet s’appelle un **schéma**.

### Règles de base de XML et TEI/XML :

- Un document XML doit être **bien formé**, sinon il ne pourra pas être traité (rendu/publication impossible). Cela signifie entre autres :
    - Les balises ouvertes (ex. `<p>`) doivent être **fermées** (`</p>`)
    - Dans une spécification de balise (ex. `<div type="letter">`), un **type** doit être défini (non autorisé : `<div type="">`)
    
- Un document XML doit être **valide** selon un schéma TEI. Même s'il peut être traité sans validation correcte, certaines représentations risquent de ne pas s’afficher correctement. Exemples :
    - La balise `<head>` doit apparaître en premier à l’intérieur d’un `<div>...</div>`
    - À l’intérieur de `<closer>...</closer>`, les paragraphes (`<p>`) ne sont pas autorisés.

**Structure de base** :
- Informations sur l’encodage (jeu de caractères : UTF-8 ; version TEI ; référence au schéma du projet, si applicable)
- **TEI Header**, qui joue le rôle d’un **impressum** et contient des informations sur :
    - Qui est l’auteur du document original ?
    - Qui a encodé le document (éditeurs, équipe du projet, direction du projet, etc.) ?
    - Où et comment le document est-il publié ?

    → Dans le cas des lettres, il existe des règles standardisées avec [`CorrespDesc`](https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-correspDesc.html) pour structurer les métadonnées, afin de garantir l’interopérabilité, par exemple avec [https://correspsearch.net](https://correspsearch.net).  

## 2. Outils d’édition pour TEI/XML

Tout éditeur de code permet de travailler avec du TEI/XML. Cependant, des éditeurs spécialisés comme **Oxygen** facilitent la tâche en permettant notamment de valider les schémas de projet et de signaler le code invalide. Oxygen dispose également d'un **mode auteur**, où le code est rendu visuellement, et où l’enrichissement du texte peut se faire via une interface proche de Word.

Alors qu’Oxygen traite les fichiers localement, il est aussi possible d’utiliser des outils en ligne comme **TEI Publisher**. À l’origine conçu uniquement pour la publication des données, cet outil offre aujourd’hui de nombreuses fonctionnalités d’édition.

## 3. Exercices

### 3.1 Installation de l’éditeur Oxygen

[https://www.oxygenxml.com/xml_editor/download_oxygenxml_editor.html](https://www.oxygenxml.com/xml_editor/download_oxygenxml_editor.html)

### 3.2 Installation du framework dans Oxygen

1. Ouvrir **Options > Preferences > Add-ons** (Windows) ou **Oxygen XML Editor > Preferences > Add-ons** (autres systèmes).
2. Ajouter un nouvel add-on en entrant cette URL :  
   `https://docs.annemarie-schwarzenbach.ch/dseas.xml`
3. Activer **Enable automatic updates checking** pour être averti des mises à jour.
4. Confirmer avec **OK**.
5. Ouvrir **Help > Install new add-ons...**, sélectionner l’URL dse-as dans le menu déroulant.
6. Sélectionner la dernière version de l’add-on, cliquer sur **Next** et confirmer toutes les étapes suivantes.
7. Redémarrer l’application.  
   _Remarque : Le framework/add-on se met à jour automatiquement au démarrage d’Oxygen._
8. Ouvrir **Options > Preferences > Document Type Associations** et s’assurer que le framework est activé.

### 3.3 Upload de fichiers TEI/XML dans Oxygen

1. Exporter depuis Transkribus un fichier TEI/XML de votre choix.
    - Alternative : utiliser des fichiers TEI/XML déjà édités, disponibles dans le dossier **Coaching [Google Drive](https://drive.google.com/drive/folders/1Xh4o5-7rxCnAMhAn1UicjOVFbO3MpJSm?usp=drive_link)**
3. Ouvrir le fichier dans Oxygen.
4. Remplacer la deuxième ligne (`<TEI xmlns="http://www.tei-c.org/ns/1.0">`) par :  
   `<TEI xmlns="http://www.tei-c.org/ns/1.0" type="dseas-letter">`
5. Passer en mode Auteur. Si le bon framework s'affiche, tout fonctionne correctement.

### 3.4 Travailler en mode Texte et Auteur dans Oxygen

8. Ajouter des rendus, références et commentaires en mode Auteur.
9. Revenir en mode Texte et observer les balises générées.
10. Pouvez-vous reproduire les résultats du mode Auteur en mode Texte ?
    - Utilisez la combinaison de touches `ctrl/cmd + E` pour obtenir des suggestions de balises.

### 3.5 Upload et édition de TEI/XML dans TEI Publisher

1. Ouvrir [https://teipublisher.com/exist/apps/tei-publisher/](https://teipublisher.com/exist/apps/tei-publisher/)
2. Se connecter via **Anmelden** (en haut à droite) :  
   **Identifiant :** `tei-demo` / **Mot de passe :** `demo`
3. Cliquer sur **Spielwiese** (deuxième option en haut).
4. Cliquer sur **Hochladen** (en haut à droite) ou glisser-déposer un document.
5. Sélectionner les paramètres ODD et Template.
6. Tester différentes options de rendu et d'édition.



# 3. Coaching, 17.3.25: TEI/XML [German Version]

Organisatorisches: Ausfall des Coachings am 24. und 31. März - danach geht es mit dem PARES-Workflow weiter!

## 0. Rückblick Transkribus
- Transkription mit Proto4DigED_Modell (Pylaia-Modell) oder Text Titan ('Supermodell'/Transformer-Modell)
- Manuelle Bearbeitung (falls gewünscht: kurze Einleitung in die Voreinstellung von komplexen Print-Layouts)

## 1. Grundeigenschaften von TEI/XML

### Hilfreiche Internet-Ressourcen: 
- [Einfache Einführung in TEI/XML und Oxygen der Universität Illinois](https://guides.library.illinois.edu/c.php?g=347707&p=2344750)
- [Einführung in TEI/XML des TEI-Konsortiums](https://tei-c.org/release/doc/tei-p5-doc/en/html/SG.html)
- Eintrag [TEI](https://www.digitale-edition.at/o:konde.178) im [Konde Weißbuch Digitale Edition](https://www.digitale-edition.at) (wichtigstes digitales Lexikon zum digitalen Edieren)
- [Proto4DigEd-Handbuchkapitel zur semantischen Annotation in TEI/XML](https://digital-editions.pages.uzh.ch/proto4diged/handbook/en/2_Editionsarbeit/05_semantic_annotation/) (wahlweise auf Englisch oder Deutsch)

### Was ist XML?

Die eXtensible (erweiterbare) Markup Language (Auszeichnungssprache) erlaubt das codieren komplexer Texte mit einem hohen Grat an erweiterbaren, projektspezifischen Tags.
Entsprechend muss aber auch die Darstellung ('Rendering') von XML spezialisiert, d.h. projektsprezifisch erfolgen (z.B. in Form von ODD-Voreinstellungen im TEI Publisher, s.u.). 

### Was ist TEI?

Die Text Encoding Initiative hat ein Set bzw. eine Auswahl von XML-Codierungen und Regeln zu ihrer Verwendung geschaffen, die heute in den Digital Humanities grundlegend sind. Auswahl und Regeln werden regelmäßig angepasst bzw. erweitert. Sie finden sich hier: https://tei-c.org

:::warning
TEI/XML ist kein Standard, d.h. für ein Textphänomen gibt es nicht **eine** korrekte Codierung, sondern oftmals eine Auswahl verschiedener möglicher Codierungen, die gleichmeraßen korrekt sein können. Dies soll Projekten Freiheit geben, führt jedoch auch zu fehlender Interoperabilität.
:::

Die projekteigene Auswahl verschiedener TEI/XML-Codierungen und ihrer projektspezfischen Verwendung nennt sich **Schema**.

### Grundregeln von XML und TEI/XML: 

- Das XML- Dokument muss 'wohlgeformt' sein, ansonsten kann es nicht prozessiert (gerendert/veröffentlicht) werden. Das heisst u.a.: 
    - 'Geöffnete' tags (z.B. `<p>`) müssen 'geschlossen' werden (`</p>`)
    - Innerhalb einer Tag-Spezifikation(z.B. `<div type="letter">`) muss ein  Typ angegeben werden (nicht erlaubt wäre: `<div type="">`)
    
- Das XML-Dokument muss gemäss eines TEI Schemas 'valide' sein. Es kann zwar auch ohne korrekte Validität prozessiert werden, aber gewisse Renderings werden ggfls. nicht korrekt dargestellt. Z.B.:
    - Das TEI/XML-Tag `<head>`Titel`</head>` muss an erster Stelle innerhalb eines `<div>`...`<div>` Tags stehen
    - Innerhlab des Tags `<closer>`...`</closer>` dürfen keine Paragraphen (`<p>`) stehen. 

**Aufbauregeln**: 
- Informationen zur Codierungsart (Zeichensatz: UTF-8; TEI-Version, ggfls. Verweis auf Name und Speicherort v. projekteigenem Schema)
- TEI-Header, entspricht einem Impressum und enthält Informationen zu: 
    - Wer ist Urheber des Originaldokuments?
    - Wer hat das Dokument codiert (Herausgeber:innen, Projektteam, Projektleitung etc)? 
    - Wo und wie wird das Dokument veröffentlicht?

    -> Im Falle von Briefen gibt es mit dem ['CorrespDesc'](https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-correspDesc.html) standardisierte Regeln, welche informationen im TEI-Header abgelegt werden müssen, um die Metadaten z.B. für https://correspsearch.net interoperabel zu machen.      
    


## 2. Editionstools für TEI/XML

Grundsätzlich kann mit jedem Code-Editor TEI/XMl bearbeitet werden. Spezifisch auf XML ausgerichtete Editoren wie Oxygen erleichtern das jedoch, indem sie erlauben z.B. projekteigene Schemata zu validieren und nicht-validen Code darstellen. Zudem verfügt Oxygen über einen 'Autor-Modus' bzw. den 'Autor-Editor', in dem der Cpde bereits gerendert dargestellt wird und sich Anreicherungen mit einer Word-ähnlihen Oberfläche machen lassen.   

Während Oxygen lokal Daten verarbeitet, gibt es auch die Möglichkeit, TEI/XML Daten in Online-tools wie dem TEI Publisher zu verarbeiten. Dieser war usrpünglich - wie es der Name sagt - nur zur Publikation der Daten, nicht zu ihrer Verarbeitung gedacht, hat aber mittlerweile viele Funktionen eines Editors erhalten. 

## 3. Aufgaben

### 3.1 Installation des oxygen-editors

https://www.oxygenxml.com/xml_editor/download_oxygenxml_editor.html

### 3.2 Installation des frameworks im oxygen-editor

1. Open Options > Preferences > Add-ons on Windows or Oxygen XML Editor > Preferences > Add-ons (on other platforms) from the menu.
2. Add a new add-on by entering this URL: https://docs.annemarie-schwarzenbach.ch/dseas.xml
3. "Enable automatic updates checking" should be activated. This will automatically prompt you to update the framework when an update was deployed.
4. Confirm with OK.
5. Open Help > Install new add-ons... from the menu. Select the dse-as URL from the dropdown menu ("Show add-ons from").
6. The latest version of the add-on should be displayed. Select it, choose Next and confirm all upcoming prompts (including possible certificate warnings).
7. Restart the application. Note: The framework/add-on should keep itself up to date. Updates will be offered during the start of oXygen.
8. Open Options > Preferences > Document Type Associations on Windows or Oxygen XML Editor > Preferences > Document Type Associations (on other platforms) from the menu and make sure the framework is activated.
 
### 3.3 Upload von TEI/XML-Daten in Oxygen

1. Exportiert aus Transkribus das TEI/XML einer Transkription Eurer Wahl
    - Alternative: Bereits edierte TEI/XML-Dokumente im Coaching-[GoogleDrive](https://drive.google.com/drive/folders/1Xh4o5-7rxCnAMhAn1UicjOVFbO3MpJSm?usp=drive_link), bzw. [hier]() 
3. Öffnet es in Oxygen 
4. Ersetzt die zweite Zeile (`<TEI xmlns="http://www.tei-c.org/ns/1.0">`) mit folgener `<TEI xmlns="http://www.tei-c.org/ns/1.0" type="dseas-letter">`
5. Wechselt in den Autor-Modus. Wenn ihr das richtige framework sieht, hat alles geklappt.

### 3.4 Arbeiten im Text- und Autor-Modus von Oxygen
8. Fügt im Autor-Modus Renderings, Referenzen und Kommentare hinzu
9. Wechselt zurück in den Text-Modus, welche Taggings sind entstanden?
10. Könnt Ihr die Resultate des Autor-Modus im Text-Modus reproduzieren?
    - benutzt die Tastenkombination ctrl/cmd + E, um tags vorgeschlagen zu bekommen

### 3.5 Upload und Bearbeitung von TEI/XML im TEI Publisher

1. Öffne https://teipublisher.com/exist/apps/tei-publisher/
2. Login über 'Anmelden' rechts oben:  `tei-demo` mit Passwort `demo`
3. "Spielwiese" (zweitoberste Option) anklicken
4. "Hochladen" rechts oben klicken (oder via drag-and-drop Dokument dorthin ziehen) -> Das Dokument erscheint zuunterst in der Liste 
5. Rechts oben ODD- und Template-Settings auswählen 
![grafik](https://hackmd.io/_uploads/B1CkBLB2kx.png)
6. Nun können verschiedene Drastellungsweisen ("ODDs") und Benutzeroberflächen/GUIs ("Templates") ausprobiert werden
- Für einen framework-ähnlichen Bearbeitungsmodus: 
    - ODD: Annotations
    - Template:Annotation Editing 

# 4. Coaching, 13th of November 2025: Edition model 

Basic framework of a PARES edition model on Hackmd: [PARES edition model](https://hackmd.io/@PARES/ryKtJfXlWg/edit)
See also: [Edition model of the Schwarzenbach Edition](https://hackmd.io/@DSE-AS/Editionsmodell) (only in German)

## Why an edition model?

- Clarifies the preparation of data in transcription and edition on three levels:
- Macro level: Main components of the edition: Raw text (transcription), TEI header, TEI body
- Meso level: Conceptual components (form of the source, editorial interventions, etc.)
- Micro level: Concrete coding according to [TEI-C](https://tei-c.org/) and/or [dTA](https://deutschestextarchiv.de/)

=> Procedure: Formulate the requirements for structure and markup based on sample material

## Fundamental questions:
- Does the project require principles that apply to all transcribed and edited documents in the PARES portal, i.e. in particular to both parts of the project?
    - Arguments in favour: Interoperability of data, simplified collaboration between teams, same display principles (front end)
    - Arguments against: Too many different requirements of the sub-projects in terms of research basis and presentation
- Should all data be prepared in the same way on Transkribus, regardless of whether it is intended for publication or not?
    - Effort on the transcription side may be greater
    - Advantages: acceleration of the editing process, better data basis for follow-up projects

## Procedure

### 1. Discussion of the [basic framework](https://hackmd.io/AOZDW0FqRWSz_HT3mpKuGg?view)
- Clarification of terms and concepts
- Additions/deletions

### 2. Tests in Transkribus
- Upload via IIIF: https://gitlab.uzh.ch/digital-editions/pares/iiif-manifests
- Structural analysis
- Markup

### 3. Development of the edition model (1st transcription)
- What should be transcribed and how?
- What conclusions can already be drawn for coding in the TEI header and body?

Translated with DeepL.com (free version)

# 4. Coaching, 13.11.2025: Editionsmodell [German Version]

Grundgerüst eines PARES-Editionsmodells auf Hackmd: [PARES Editionsmodell](https://hackmd.io/@PARES/ryKtJfXlWg/edit)
Siehe auch: [Editionsmodell der Schwarzenbach-Edition](https://hackmd.io/@DSE-AS/Editionsmodell) 

## Wozu ein Editionsmodell?

- Klärt die Aufbereitung der Daten in Transkription und Edition auf drei Ebenen: 
    - Makroebene: Haupt-Bestandteile der Edition: Rohtext (Transkription), TEI-Header, TEI-Body
    - Mesoebene: Konzeptuelle Bestandteile (Form der Quelle, editorische Eingriffe etc.) 
    - Mikroebene: Konkrete Codierung nach [TEI-C](https://tei-c.org/) und/oder [dTA](https://www.deutschestextarchiv.de/doku/basisformat/)
=> Vorgehen: Von exemplarischem Material die Anforderungen an Struktur und Auszeichnung formulieren

## Grundfragen: 
- Benötigt das Projekt Grundsätze, die für alle transkribierten und edierten Dokumente im PARES-Portal gilt, d.h. insbsondere für beide Projektteile?
    - Dafür spricht: Interoperabilität der Daten,vereinfachte Zusammenarbeit zwischen den Teams gleiche Darstellungsprizipien (Frontend) 
    - Dagegen könnte sprechen: Zu unterschiedliche Anforderungen der Unterprojekte hinsichtlich Forschungsgrundlagen und Präsentation

- Sollen alle Daten auf Transkribus gleich vorbereitet werden, unabhängig davon, ob sie für die Edition vorgesehen sind oder nicht?
    - Aufwand auf Transkriptionsseite ggfls. grösser
    - Vorteile: Beschleunigung des Editionsprozesses, bessere Datengrundlage für Nachfolgeprojekte

## Vorgehen

### 1. Diskussion des Grundgerüstes
- Klärung der Begriffe und Konzepte
- Ergänzung/Streichung

### 2. Tests in Transkribus 
- Upload via IIIF
- Strukturanalyse
- Auszeichnungen

### 3. Ausarbeitung des Editionsmodells (1. Transkription)
- Was soll wie transkribiert werde?
- Welche Schlüsse lassen sich bereits für die Codierung im TEI-Header und -Body ziehen?






