# Données ENCPOS
Actuellement toutes les métadonnées des positions se situent dans un fichier TSV donc la question est sur l'avenir pour la gestion des fichiers.
# Les données ENCPOS
## Métadonnées
[https://github.com/chartes/encpos/blob/master/data/encpos.tsv](https://)
Actuellement le TSV contient ces différentes entrées:
| |desc|exemple|effectif|
|-|----|-------|--------|
|id|id du fichier|ENCPOS_1849_01|3216|
|title_rich|titre des thèses avec les balises|Le duché de Genevois aux <abbr>xvi<sup>e</sup></abbr> et <abbr>xvii<sup>e</sup></abbr> siècles : aspects institutionnels d’un apanage savoyard|2916|
|author_name|Nom de l'auteur|Taupiac|2919|
|author_firstname|Prénom de l'auteur|Marie|2918|
|author_idref-key|Nom et prénom de l'auteur dans idref|Bon, Bruno (1973-....)|190|
|author_idref-id|Id d'un auteur dans la base idref|202997847|1413|
|promotion_year|Année de la promotion du chartiste|2017|3209|
|pagination|Les pages de la thèses dans le livre|369-371|2736|
|these_id|Id de la thèse|2017THESE18|1347|
|these_biblionumber-benc|Code bibliographique de la thèse dans l'indexation de la Benc|119190|1347|
|these_ppn-sudoc|Code du sudoc de la thèse|202997804|1346|
|topic_notBefore|Date de début de la période évoqué par la thèse|1595|2816|
|topic_notAfter|Date de fin de la période évoqué par la thèse|1815|2815|
|title_text|titre des thèses sans les balises|Le duché de Genevois aux xvie et xviie siècles : aspects institutionnels d’un apanage savoyard|2742|
|author_gender|Genre de l'auteur|1|2857|
|enc_teacher|Personne devenu professeur de l'école|1|28|
|site:id?|Id de la position sur l'ancien site|201524|2816|
Analyse appronfondie après suppression des PREV et NEXT qui ne concernent pas les positions et donc n'ont pas de métadonnées, ce qui est logique:
# Analyse concernant les positions de thèse
## Tableau récapitulatif de l'Etat actuelle des données
| |desc|exemple|effectif|
|-|----|-------|--------|
|id|id du fichier|ENCPOS_1849_01|2919|
|title_rich|titre des thèses avec les balises|`Le duché de Genevois aux <abbr>xvi<sup>e</sup></abbr> et <abbr>xvii<sup>e</sup></abbr> siècles : aspects institutionnels d’un apanage savoyard`|2919|
|author_name|Nom de l'auteur|Taupiac|2919|
|author_firstname|Prénom de l'auteur|Marie|2918|
|author_idref-key|Nom et prénom de l'auteur dans idref|Bon, Bruno (1973-....)|190|
|author_idref-id|Id d'un auteur dans la base idref|202997847|1357|
|promotion_year|Année de la promotion du chartiste|2017|2919|
|pagination|Les pages de la thèses dans le livre|369-371|2439|
|these_id|Id de la thèse|2017THESE18|1347|
|these_biblionumber-benc|Code bibliographique de la thèse dans l'indexation de la Benc|119190|1347|
|these_ppn-sudoc|Code du sudoc de la thèse|202997804|1346|
|topic_notBefore|Date de début de la période évoqué par la thèse|1595|2816|
|topic_notAfter|Date de fin de la période évoqué par la thèse|1815|2815|
|title_text|titre des thèses sans les balises|Le duché de Genevois aux xvie et xviie siècles : aspects institutionnels d’un apanage savoyard|2742|
|author_gender|Genre de l'auteur|1|2857|
|enc_teacher|Personne devenu professeur de l'école|1|28|
|site:id?|Id de la position sur l'ancien site|201524|2816|
## Demande et question autour de ces données
`these_id`, `these_biblionumber-benc`, `these_ppn-sudoc` très peu présent avant 1968. Ce sont les données centrales pour faire les lien avec le projet TENC@ donc c'est le travail prioritaire à faire. Voir le fichier <strong>`encpos_empty_these_id_sudoc_benc.ods`</strong>
`author_idref` est aussi assez peu remplie entre 1864 et 1960, il serait bien de compléter ces entrées pour pouvoir faire des rebonds avec la BnF pour pouvoir offrir plus d'informations sur la suite de la carrière universitaire/ bibliographique de la majorité des anciens archivistes paléographes.
`author_idref-key` est aussi peu rempli mais ces informations sont récupérables à travers l'API Idref donc ce n'est pas obligatoire de le rajouter à la main. Voir le fichier <strong>`encpos_empty_idrefkey.ods`</strong>
`topic_notBefore`, `topic_notAfter` il manque 103 entrées. Il s'agit de données qui nous sont utiles pour trier les positions de thèses en fonction de périodes temporelles ou autres. Voir le fichier <strong>`encpos_empty_topicnotBeforeAfter.ods`</strong>
`pagination` il en manque 5 en 1850 mais on n'a pas les images et les fichiers XML de ces positions de thèses donc c'est logique et mais il y a un énorme manque d'informations après 2000. Voir le fichier <strong>`encpos_empty_pagination.ods`</strong>
1 `author_firstname` manque car cet information est absente de la thèse ENCPOS_1964_18.
Les trois dernières entrées sont vides actuellement ou presque et ce sont des entrées centrales pour faire le lien avec les données de la bibliothèque. Il serait important que Valentin remplissent ces tableaux pour commencer en ainsi faire le lien entre nos deus jeux de données pour pouvoir les reliers à la suite.
La case `author_idref` est aussi assez peu remplie entre 1864 et 1960, il serait bien de compléter ces entrées pour pouvoir faire des rebonds avec la BnF pour pouvoir offrir plus d'informations sur la suite de la carrière universitaire/ bibliographique de la majorité des anciens archivistes paléographes.
## Fichier PREV/ NEXT
Les fichiers PREV/NEXT sont les parties qui précèdent et succèdent les positions de thèses dans les différents revues.
Ce sont des fichiers qui sont utiles pour le respect du livre et de ces données mais pas pour les positions de thèses. La question est faut-il les servir en DTS ou non ?
-> réponse : plutôt oui pour les PREV mais pas pour les NEXT
# CapiTainiser
Rendre un texte utilisable par CapiTainS demande la mise en place d'une structure de rangement des fichiers en arborescene avec des fichiers `__capitains__.xml` qui contiennent les métadonnées des collections et les informations concernant .
Exemple d'un arbre d'arborescence :
```
data
│
└───ENCPOS
│ │ __capitains__.xml
│ │
│ └───ENCPOS_1849
│ │ │ __capitains__.xml
│ │ └───ENCPOS_1849_PREV
│ │ | │ __capitains__.xml
│ │ │ │ ENCPOS_1849_PREV.xml
│ │ └───ENCPOS_1849_01
│ │ | │ __capitains__.xml
│ │ │ │ ENCPOS_1849_01.xml
│ │ └───ENCPOS_1849_02
│ │ | │ __capitains__.xml
│ │ │ │ ENCPOS_1849_02.xml
│ │ └───...
│ |
│ │
│ └───ENCPOS_1850
│ │
│ └───...
│
└───guidelines
│ __capitains__.xml
│
...
```
Exemple d'un fichier `__capitains__.xml` pour les métadonnées d'une collections collections:
```xml
<?xml-model href="https://raw.githubusercontent.com/Capitains/guidelines/master/capitains.rng" schematypens="http://relaxng.org/ns/structure/1.0"?>
<cpt:collection xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cpt="http://purl.org/capitains/ns/1.0#" xmlns:bib="http://bibliotek-o.org/1.0/ontology/">
<cpt:identifier>ENCPOS</cpt:identifier>
<dc:title xml:lang="fre">Les positions des thèses de l'Ecole nationale des chartes</dc:title>
<dc:type>dts:textgroup</dc:type>
<dc:publisher>Ecole nationale des chartes</dc:publisher>
<cpt:structured-metadata>
<bib:AbbreviatedTitle>Positions de thèses de l'Ecole nationale des chartes</bib:AbbreviatedTitle>
</cpt:structured-metadata>
<cpt:members>
<cpt:collection path="./ENCPOS_1849/__capitains__.xml" identifier="ENCPOS_1849"/>
<cpt:collection path="./ENCPOS_1850/__capitains__.xml" identifier="ENCPOS_1850"/>
<cpt:collection path="./ENCPOS_1851/__capitains__.xml" identifier="ENCPOS_1851"/>
<cpt:collection path="./ENCPOS_1999/__capitains__.xml" identifier="ENCPOS_1999"/>
</cpt:members>
</cpt:collection>
```
Exemple d'un fichier `__capitains__.xml` pour les métadonnées d'un texte :
```xml
<?xml-model href="../../../capitains.rng" schematypens="http://relaxng.org/ns/structure/1.0"?>
<collection xmlns:ti="http://chs.harvard.edu/xmlns/cts" xmlns:dct="http://purl.org/dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cpt="http://purl.org/capitains/ns/1.0#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:bib="http://bibliotek-o.org/1.0/ontology/" xmlns:cts="http://chs.harvard.edu/xmlns/cts" xmlns:foaf="http://xmlns.com/foaf/0.1/">
<cpt:identifier>ENCPOS_1849_01</cpt:identifier>
<cpt:parent>ENCPOS_1849</cpt:parent>
<dc:title xml:lang="fre">Recherches sur l’origine et la nature des insurrections des habitants de Vézelay contre leurs abbés, pendant la première moitié du xiie siècle</dc:title>
<dc:type>dts:work</dc:type>
<cpt:members>
<cpt:collection readable="true" path="./ENCPOS_1849_01.xml">
<cpt:identifier>ENCPOS_1849_01</cpt:identifier>
<cpt:parent>ENCPOS_1849</cpt:parent>
<dc:title xml:lang="fre">Recherches sur l’origine et la nature des insurrections des habitants de Vézelay contre leurs abbés, pendant la première moitié du xiie siècle</dc:title>
<dc:type>dts:edition</dc:type>
<dc:creator>Bastard, De, Léon</dc:creator>
<dc:date>1849</dc:date>
<!-- voir dc:creation -->
<dc:publisher xml:lang="mul">École des chartes, Paris</dc:publisher>
<dc:language>fr</dc:language>
<dc:coverage>1100-1150</dc:coverage>
<dc:format>application/tei+xml</dc:format>
<structured-metadata>
<dct:bibliographicCitation>Bibliographie à voir plus tard</dct:bibliographicCitation>
<dct:created>time</dct:created>
</structured-metadata>
</cpt:collection>
</cpt:members>
</collection>
```
La problématique pour créer de tels fichiers est qu'actuellement tout est créer à partir du fichier encpos.tsv
## La question d'un capitainiser indépendant des données.
Une possibiltié pour l'avenir et créer un capitainiser indépendant des données serait de faire en sorte de créer un modèle pour des fichiers XML qui doivent correspondre à notre capitainiser et ainsi valider automatiquement que la création des fichiers différents précémment montré soit possible.
La réinjection des métadonnées vers les fichiers XML dépendrai donc de chaque projet et qui devrai le faire avant toute capitainisation.
Après la question de la configuration d'un tel outil s'ouvre on peut demander que les données soit dans un fichier et respecte l'arbre final qu'on souhaite et on rajouterai de manière automatique uniquement les fichiers `__capitains__.xml`
Une autre possibilité est de demander la création d'un fichier de configuration qui demanderai de structure à travers un fichier JSON ou XML pour ensuite recréer l'arborescence souhaité.
Il faut ensuite réfléchir à la question des données "minimales" exigables dans le future RNG. J'ai réfléchi à travers la norme Dublin Core qui est acutellement implémenter dans CapiTainS
## DublinCore et équivalent TEI
1. Title = `<fileDesc><titleStmt><title>` Obligatoire
1. Creator = `<fileDesc><titleStmt><author>` Obligatoire (quitte à mettre anonyme)
1. Subject = `profileDesc/textClass/keywords/term` Non obligatoire
1. Description = `encodingDesc ou profileDesc/abstract` Non obligatoire
1. Publisher = `<fileDesc><publicationStmt><publisher>` Obligatoire ou inconnue
2. Contributor =`fileDesc/titleStmt/editor, respStmt` Non obligatoire
3. Date =`<fileDesc><publicationStmt><date>` Obligatoire ou inconnue
1. Type =`"text"`
2. Format =`"text/xml"`
3. Identifier =`fileDesc/publicationStmt/idno` Non obligatoire
4. Source =`fileDesc/sourceDesc` Non obligatoire
5. Language =`@xml:lang ou profileDesc/langUsage/` Obligatoire
6. Relation =`fileDesc/seriesStmt/` Non Obligatoire
7. Coverage =`profileDesc/textDesc` Non Obligatoire
8. Rights =`<fileDesc><publicationStmt><availability>` Obligatoire
L'obligation de la présence de ces entrées dans les XML peut permettre la simplication d'injection des données directement dans les fichiers `__capitains__.xml` et ainsi pouvoir faire efficacement créer la base nécessaire à une capitainsitation
## Choix de l'encodingDesc à implémenter
Actuellement on utilise l'ancienne version de l'encodingDesc :
```xml
<encodingDesc>
<refsDecl n="capitains">
<cRefPattern n="position" matchPattern="(\w+)" replacementPattern="#xpath(/tei:TEI/tei:text/tei:body[@n='$1'])">
<p>This pointer pattern extracts introduction, sources, parts, conclusion and appendix</p>
</cRefPattern>
</refsDecl>
</encodingDesc>
```
Actuellement proposition au teiConsortium pour faire un évolution du modèle TEI et intégré de nouvelles balises à l'encodingDesc avec la création d'une balise CiteStructure ([proposition Tei consortium](https://github.com/distributed-text-services/tei-proposal/blob/master/RevisedNewProposal.md))
Proposition qui a maintenant un an et qui n'est pas validé donc à part si un retour nous indique que cette question va être vite résolu, il semble plus logique de se concentrer sur l'implémentaiton de la première version
# CapiTainS / DTS
## DTS état actuelle
1. Fonctionnement DTS/Collections ok ([exemple des collections](http://0.0.0.0:5050/nautilus/dts/collections)) ([exemple d'une position](http://0.0.0.0:5050/nautilus/dts/collections?id=ENCPOS_1849_01))
2. Fonctionnement DTS/Navigation ([exemple du niveau navigation d'une position](http://0.0.0.0:5050/nautilus/dts/navigation?id=ENCPOS_1849_01)) ([exemple du niveau navigation d'un fichier test au niveau 1](http://0.0.0.0:5050/nautilus/dts/navigation?id=urn%3Acts%3AlatinLit%3Aphi1294.phi002.perseus-lat2))
([exemple du niveau navigation d'un fichier test au niveau 2](http://0.0.0.0:5050/nautilus/dts/navigation?id=urn%3Acts%3AlatinLit%3Aphi1294.phi002.perseus-lat2&level=2))
4. Fonctionnement DTS/Document pour un xml complet cela marche ([exemple du niveau navigation d'un fichier xml](http://0.0.0.0:5050/nautilus/dts/document?id=ENCPOS_1849_01))
5. Grande difficulté à faire fonctionner les sous références et donc toutes les fonctions qui dépendant de &start, &end, &ref ([exemple du niveau navigation d'un fichier test au niveau 2](http://0.0.0.0:5050/nautilus/dts/navigation?id=urn%3Acts%3AlatinLit%3Aphi1294.phi002.perseus-lat2&level=2&start=1&end=3))
## Modification effectué
1. Modification de la fonction def getTextualNode dans `local.py` à la ligne 382. S'il n'y a pas de sous référence, on peut envoyer le texte tel quel sur DTS. A partir de là qu'on doit contrôler l'intérieur de l'encodingDesc, entrer les différents Xpath selon les informations de l'EncodingDesc
1. Rajout de la feuille `resources/prototypes/dts/text.py` pour permettre la gestion du texte à travers `PrototypeDtsPassage` et `PrototypeDtsText` pour remplacer `resources/prototypes/cts/text.py`. (Encore à reprendre)
1. `/local/capitains/dts.py` mise à jour pour que ça fonctionne en DTS en non CTS (Encore à reprendre)
2. Retour sur def `_make_passage_kwargs(urn, reference)` qui semble être une focntion
## Mise en ligne du site
La création du site est actuellement possible car on peut renvoyer les textes complets mais la question autour des sous parties restent complète et doit être réglé.
# Proposition Site
Différente image à proposer comme mack-up du site
FOnctionnement par décennie sur le côté (https://www.persee.fr/collection/mefr) inspirée de Persée
FOnction recherché réduite sur le côté avec les dates, nom, prénom, titre de thèse et recherche dans les thèses
Donc nécessité de brancher un elasticsearch ou un existDB pour faciliter la recherche (là dessus méconnaissance réel donc à voir comment faire/ formation ??)
Résultat fonction rechercher, une liste à la méthode de revues.org me semblent pertinent avec la mise en valeur des informations des différentes
Affichage du texte comme sur le site DTS Demo, bouton pour IIIF
Ajout d'une liaison avec idref sur BNF/Sudoc/Wikidata grâçe à idref ([Exemple Olivier Poncet](https://www.wikidata.org/wiki/Q3351290))
## TODO Valentin
- enrichissement des métadonnées à décider avec BENC
- `idref` ?
- lien id_position / id_thèse
- faire le point sur la couverture de :
- `these_id`
- `these_biblionumber-benc`
- `these_ppn-sudoc`
- `author_firstname`
- `author_idref-key`
- Analyser le contenu des `ENCPOS_YYYY_NEXT.xml` : les servir en DTS ?
```xml
<?xml-model href="../../../capitains.rng" schematypens="http://relaxng.org/ns/structure/1.0"?>
<collection xmlns:ti="http://chs.harvard.edu/xmlns/cts" xmlns:dct="http://purl.org/dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cpt="http://purl.org/capitains/ns/1.0#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:bib="http://bibliotek-o.org/1.0/ontology/" xmlns:cts="http://chs.harvard.edu/xmlns/cts" xmlns:foaf="http://xmlns.com/foaf/0.1/">
<cpt:identifier>ENCPOS_1999_35</cpt:identifier>
<cpt:parent>ENCPOS_1999</cpt:parent>
<dc:title xml:lang="fre">L’Ars lectoria Ecclesie de Jean de Garlande. Étude, édition et traduction</dc:title>
<dc:type>dts:work</dc:type>
<cpt:members>
<cpt:collection readable="true" path="./ENCPOS_1999_35.xml">
<cpt:identifier>ENCPOS_1999_35</cpt:identifier>
<cpt:parent>ENCPOS_1999</cpt:parent>
<dc:title xml:lang="fre">L’Ars lectoria Ecclesie de Jean de Garlande. Étude, édition et traduction</dc:title>
<dc:type>dts:edition</dc:type>
<dc:creator>Marguin, Elsa</dc:creator>
<dc:date>1999</dc:date>
<!-- voir dc:creation -->
<dc:publisher xml:lang="mul">École des chartes, Paris</dc:publisher>
<dc:language>fr</dc:language>
<dc:coverage>1200-1252</dc:coverage>
<dc:format>application/tei+xml</dc:format>
<structured-metadata>
<dct:bibliographicCitation>Bibliographie à voir plus tard</dct:bibliographicCitation>
<dct:created>time</dct:created>
</structured-metadata>
</cpt:collection>
</cpt:members>
</collection>
```
#TODO
Essayer de voir ce qui se passe quand on crée une métadonnée différente et s'assurer que toutes les métadonnées apparaissent à chaque étape.
Réfléchir à TEI Header
S'assurer que le resolverDTS renvoie toutes les informations et que tout circule bien
Question du rich-title où le mettre
Mettre à jour le End-Point de l'API