# Typage des zones dans les manuscrits (médiévaux)

## Réunion du 18 février 2021

### Présentations de documents et de leur segmentation

DS présente des exemples de mss hébreux et des éditions.

FC présente des correspondances contemporaines.

AC présente des rapports de police et les données LECTAUREP.

### Questions débattues

1. logique vs physique: que doit privilégier l'ontologie ?

plutôt le second (structure physique des sources).

2. Comment faire la part du général (l'ontologie) et du spécifique au projet?

3. Faut-il fusionner certaines zones ? Ex. `Paratext` pourrait fusionner titre courant, réclame, …

On notera que

- des régions peuvent être fusionnées au moment de l'entraînement de Kraken, avec la commande merge `-mr`.

- le besoin se présente en lien avec la typologie documentaire, ex.
- Lettres: faut-il considérer toutes les mentions type date, etc., comme du Paratext? Margin?
- tableaux: faut-il des types de colonnes, de rows ?

### Ontologie à deux niveaux ?

Tout cela amène à s'interroger sur l'intérêt d'une **ontologie à deux niveaux**, avec des grands types structurels/physiques, et des sous-types, avec valeurs suggérées et place au «project specific».

Comment faire ce double niveau d'annotation ?

Ou faut-il une ontologie à deux niveaux: types contraints, mais sous-types libres du moment qu'ils sont rattachés à un de nos types ?
Mais comment l'exprimer ? Est-ce possible dans les différents formats, notamment ALto?

* Faut-il imaginer des noms concaténés, `Margin:addition` ?
* Une série de valeurs séparées par des expaces `Margin Addition` ?

Distinction printed/typewriter/handwritten ? Comment la gérer ?

Tout le monde d'accord pour dire que doit se faire plutôt au niveau des lignes. Mais: les lignes peuvent être mixtes. Par ex.:

> Nom: Madame Michu

### Autres points

- atelier hackathon avec Zürich ?
- zones à valider ou fusionner -> débat à poursuivre
- faut-il supprimer tout plein de zones au profit de header et footer ?
- Marie Puren se propose de retranscrire SegmOnto en CIDOC CRM, ex.


### Devoirs maison

Revoir les propositions de zones sur la PR Github, les amender, et proposer d'éventuels sous-types.

Prochaine réunion le 25 mars à 10h.

## Réunion du 6 janvier 2021

### Délimitation

- bornes chronologiques?
- textes documentaires ?

### Standard

- mapping TEI
- faire standard pour les outils
- Faut-il différents niveaux de granularité?

- règles d'imbrication (zones et zones, lignes): doit-on les conserver ? Ou raisonner à plat?

Vraisemblablement, des limites de modèle hiérarchique sont délicates à implémenter ET gênantes dans certains cas (exemple des registres notariaux).

## État des lieux sur quelques corpus

### Régions

|zone|cbad|fr_412|btv1b9080806r|fr_844|
|---|---|---|---|---|
|ImageRegion|1975|||66|
|MusicRegion||||780|
|TextRegion|28763|304|238|190|
|TextRegion:Handwritten\u0020text;|14258||||
|TextRegion:Image/Drawing/Figure;|14||||
|TextRegion:Machine\u0020Printed\u0020text;|14363||||
|TextRegion:Seal;|3||||
|TextRegion:Signature;|30||||
|TextRegion:untyped|95|304|238|190|

### Lignes

|zone|cbad|fr_412_bin|btv1b9080806r_bin|fr_844|
|--|--|--|--|--|
|Handwritten\u0020text;|95||||
|Machine\u0020Printed\u0020text;|28||||
|paragraph;||||1|
|untyped|193619|12389|9282|2399

## Schéma PageXML

### Régions disponibles

Schéma définit des éléments de niveau «zones de texte», qui sont:

(pc:TextRegion | pc:ImageRegion | pc:LineDrawingRegion | pc:GraphicRegion | pc:TableRegion | pc:ChartRegion | pc:MapRegion | pc:SeparatorRegion | pc:MathsRegion | pc:ChemRegion | pc:MusicRegion | pc:AdvertRegion | pc:NoiseRegion | pc:UnknownRegion | pc:CustomRegion)

- `pc:TextRegion`: Pure text is represented as a text region. This includes drop capitals, but practically ornate text may be considered as a graphic.
- `pc:ImageRegion`: An image is considered to be more intricate and complex than a graphic. These can be photos or drawings.
- `pc:LineDrawingRegion`: A line drawing is a single colour illustration without solid areas.
- `pc:GraphicRegion`: Regions containing simple graphics, such as a company logo, should be marked as graphic regions.
- `pc:TableRegion`: Tabular data in any form is represented with a table region. Rows and columns may or may not have separator lines; these lines are not separator regions.
- `pc:ChartRegion`: Regions containing charts or graphs of any type, should be marked as chart regions.
- `pc:MapRegion`: Regions containing maps.
- `pc:SeparatorRegion`: Separators are lines that lie between columns and paragraphs and can be used to logically separate different articles from each other.
- `pc:MathsRegion`: Regions containing equations and mathematical symbols should be marked as maths regions.
- `pc:ChemRegion`: Regions containing chemical formulas.
- `pc:MusicRegion`: Regions containing musical notations.
- `pc:AdvertRegion`: Regions containing advertisements.
- `pc:NoiseRegion`: Noise regions are regions where no real data lies, only false data created by artifacts on the document or scanner noise.
- `pc:UnknownRegion`: To be used if the region type cannot be ascertained.
- `pc:CustomRegion`: Regions containing content that is not covered by the default types (text, graphic, image, line drawing, chart, table, separator, maths, map, music, chem, advert, noise, unknown).

### Éliminer ?

On peut **éliminer** a priori: `pc:ChemRegion`, `pc:AdvertRegion`.

### Conserver ?

À **conserver** pour nos manuscrits médiévaux (latins et romans notamment)
- sans hésitation: `pc:TextRegion`, `pc:TableRegion`, `pc:MathsRegion`, `pc:MusicRegion`;
- pour l'enluminure et la décoration: `pc:ImageRegion` (pour les miniatures?), `pc:LineDrawingRegion` (pour les dessins à la plume?), `pc:GraphicRegion` (pour les initiales? Ou faut-il plutôt utiliser une zone de texte? et pour tout autre élément de décor, notamment bouts-de-ligne?)
- éventuellement aussi, `pc:SeparatorRegion`, `pc:NoiseRegion` (trous, etc.), `pc:UnknownRegion`, `pc:CustomRegion`,
- conserver même si rare (?): `pc:ChartRegion` et `pc:MapRegion`.

## Problèmes

- Peut-on harmoniser notre encodage des zones, et décider d'un format pivot (par ex., Page XML) ? Et dans ce cas,
1. comment distinguer d'une part l'usage des catégories de région (ex., MusicRegion, MathsRegion), avec le typage des TextRegion qu'on observe parfois dans les données d'entraînement ?
2. pour la musique ou les maths, par exemple, les régions MusicRegion ou MathsRegion ne peuvent accueillir directement de lignes, contrairement aux TextRegion…
3. comment traiter les lettrines: comme de l'`Image`, du `Graphic` ou bien du `Text`? Je penche pour la dernière option, avec un typage de la `TextRegion` ou de la `TextLine`?

-> type de propriétés de structure `drop-capital`, `marginalia`, … proposées par Transkribus. Éventuellement à reprendre

4. comment traiter les bouts-de-ligne, et autres éléments de décor de niveau ligne?

Proposition de BK (mail du 14/11):

> PageXML a beaucoup des zones sémantiques,
même si leur sémantique n'est pas bien définie et qu'elles limitent les
choses qui peuvent être à l'intérieur de ces zones. Alto n'en a presque
pas.
> Mon opinion personnelle est qu'ils devraient être ignorés et que la
sémantique devrait être imposée par les attributs type/TAGREF sur les
blocs de texte normaux, même s'il ne s'agit pas de zones textuelles.

Du coup, faut-il repasser en Alto 4.2 ?

- Que Kraken prend-il en compte ? Seulement les zones de ligne avec leurs types ? Ou toutes les régions ?

On dirait bien que Kraken ne prend en compte que le typage des textLines et textRegions… (donc va falloir transformer)