From 23e78dae95889ad12a1887466f895d7eaa11502b Mon Sep 17 00:00:00 2001
From: Alice BRENON <alice.brenon@ens-lyon.fr>
Date: Mon, 28 Feb 2022 18:19:24 +0100
Subject: [PATCH] Finish the part about other schemes

---
 ICHLL_Brenon.md | 53 +++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 47 insertions(+), 6 deletions(-)

diff --git a/ICHLL_Brenon.md b/ICHLL_Brenon.md
index 89c0a76..c9f2e28 100644
--- a/ICHLL_Brenon.md
+++ b/ICHLL_Brenon.md
@@ -118,9 +118,9 @@ Back to the "Encyclopédie" article we read that a dictionary remaining strictly
 at the language level, a vocabulary, can be seen as the empty frame required for
 an encyclopedic dictionary that will fill it with additional depth. Given how
 d'Alembert insists on the importance of brevity for a clear definition in the
-"Dictionnaire de Langues" entry, it is clear that for the *encyclopédistes*,
-encyclopedia aren't superior to dictionaries but really depart from them in
-terms of purpose.
+"Dictionnaire de Langues" entry, it is clear that the *encyclopédistes* did not
+consider encyclopedias superior to dictionaries but really as a new subgenre
+departing from them in terms of purpose.
 
 ## La Grande Encyclopédie
 
@@ -787,14 +787,55 @@ and a half.
 
 ## Comparison to other approaches
 
-Before deciding to give up on the *dictionaries* module and attempting to devise
-or own encoding scheme, several scenarios have been considered and compared to
-find the most compatible with our .
+The above section about the structure of the *dictionaries* module and the
+features found in encyclopedias follows quite closely our own journey trying to
+encode first manually then by automatic means the articles of our corpus. This
+back and forth between trying to find patterns in the graph which reflects the patterns
+found in the text and questioning the relevance of the results explains the
+choice we ended up making but also the alternatives we have considered.
 
 ### Bend the semantics
 
+Several times, the issue of the semantics of some elements which posess the
+properties we need came up. This is the case for instance of the `<sense/>` and
+`<node/>` elements. It is very tempting to bend their documented semantics or to
+consider that their inclusion properties is part of what defines them, and hence
+justifies their ways in creative ways not directly recommended by the TEI
+specifications.
+
+This is the approach followed by project Basnum[^Basnum] which studies and
+provides a XML-TEI encoding of the *Dictionnaire Universel* by Furetière, or
+rather its second edition edited by Basnage, an encyclopedic dictionary from the
+very early 18\textsuperscript{th} century. In the articles encoded for this
+project, `<note/>` elements are nested and used to structure the encyclopedic
+developments that occur in the articles.
+
+We have chosen not to follow the same path in the name of the FAIR principles to
+avoid the emergence of a custom usage differing from the documented one.
+
+[^Basnum]: [https://anr.fr/Projet-ANR-18-CE38-0003](https://anr.fr/Projet-ANR-18-CE38-0003)
+
 ### Custom schema
 
+The other major reason behind our choice was the inclusion rules which exist
+between TEI elements and pushed us to look for different combinations. Another
+valid approach would have consisted in changing the structure of the inclusion
+graph itself, that is to say modify the rules. If `<entry/>` is the perfect
+element to encode article themselves, all that is really missing is the ability
+to accomodate nested structures with the `<div/>` element. Generating customized TEI
+schemas is made really easy with tools like ROMA[^ROMA], which we used to
+preview our change and suggest it to the TEI community.
+
+[^ROMA]: [https://roma.tei-c.org/](https://roma.tei-c.org/)
+
+Despite it not getting a wide adhesion, some suggested it could be used locally
+within the scope of project DISCO-LGE. However we chose not to do so, partially
+for the same reasons of interoperability as the previous scenario, but also for
+reasons of sturdiness in front of future evolutions. Making sure the alternative
+schema would remain useful entails to maintain it regenerating it should the
+schema format evolve, with the possibility that the tools to edit it changes or
+stop being maintained.
+
 # Conclusion
 
 Despite long discussions and interesting proposals each with strong arguments both in
-- 
GitLab