Aurélian Houé

Florent Cédric Seguin

Frizon De Lamotte

Nathalie Julien

Willy Allègre
email: willy.allegre@vyv3.fr

Modular and Distributed Architecture using an Embedded Digital Twin for Assistive Technologies Adaptation

Keywords: Embedded Digital Twin, Distributed architecture, Modular architecture, Assistive technologies

Access to and use of assistive technologies will become a more important issue over the coming decades, as the population ages and the number of people with disabilities increases. To meet the particular needs of various disability situations, specific assistive solutions need to be developed. This paper tackles the problem by proposing a system that adapts to each person and their particular disability. It will rely on a distributed and modular architecture to modify usual assistive devices providing a new ability to respond dynamically to user needs. To control reconfiguration and communication with the environment, the architecture will be orchestrated by an embedded digital twin of the assistive technology.

Introduction

In 2021, 1 in 7 person older than fifteen was identified as having a handicap in France, according to the study lead by the DREES (French Directorate for Research, Studies, Evaluation and Statistics) organism [START_REF] Dauphin | Synthèse Élargir les sources d'étude quantitative de la population handicapée: Que vaut l'indicateur[END_REF]. This study brings also that with the elderly increasing number, the proportion of people with special needs is also rising, with 25% of 60 and older people facing a high restriction in their daily life. If this assessment is true at country level, globally the same situation can be drawn.

According to the 2019 UN (United Nation) report on world ageing in population, 1 in 6 people will be over the age of 65 [2] in 2050. Thus, giving an access to assistive technologies for those people is necessary. Some actions and instructions have been proposed in this way, for instance the strategy for disability inclusion of the United Nations [START_REF]United nations disability inclusion strategy[END_REF] poses the questions of accessibility, participation, accommodation and organizational culture to promote integration of the people with disability.

ICF (International Classification of Functioning) [START_REF] Üstün | The International Classification of Functioning, Disability and Health: a new tool for understanding disability and health[END_REF] and PPH (Processus de Production du Handicap) [START_REF] Fougeyrollas | La funambule, le fil et la toile[END_REF] define a formal structure to understand the situation of people with special needs. In these models, disability is considered as the interaction between the person, its habits and its physical and social environment. It results in specific needs expressed by the person varying in time along with its handicap. Thus assistive devices or technologies are designed to modify those interactions in order to improve the situation of people with disabilities. In France, the 2020 report on assistive devices [6] reveals that 30 to 40 % of these devices are discarded within the first purchasing year. They raise the issue of the correct response given to the person's needs through the device prescription and so, the importance of assessing reasons for end of use to provide a device more suitable to the patient. Even power wheelchairs are not spared, with a disuse rate of 5% during the first year [6]. In order to propose a solution, it has been decided to divide the handicap specific needs as it is proposed in CML (Concept Maturity Level) model. This model, initially used in space industry, is a promising method to conceive medical technologies [START_REF] Trognon | Shaping User-Centered Health Innovation Through Assessment[END_REF] by evaluating the conception maturity following three axis. First it evaluates the "Needs"axis, then the "Schedule" axis for the administrative and economic project maturity and finally the "Technical axis" to evaluate the solution development. In the handicap domain, as it was highlighted before, needs are both various and variable because of the strong evolution of the person with its environment. Economically speaking, handicap can be considered as a niche market because of its needs diversity, as a suitable solution for a person at a time may be inadequate for another or become inadequate later. Thus, it results on a huge variability requiring specific development for each person with disability. Following this statement it has been decided to answer this problematic taking into account the assistive technology adaptability.

In Chapter 2, the state of the art shows that many of the architectures proposed for designing assistive technologies are fixed [START_REF] Ariza | Low-Cost Assistive Technologies for Disabled People Using Open-Source Hardware and Software: A Systematic Literature Review[END_REF], with no possibility of adaptation for the patient. Chapters 3 and 4 present a new solution for designing assistive products through adaptation, in order to adapt a single architecture for several assistive devices. Based on use cases defined by healthcare professionals, a modular, distributed software architecture is presented in Chapter 3, and its hardware is described in Chapter 4. Experiments and results are presented in Chapter 5. The hardware design of this architecture and several tests of its basic functions have been carried out as a proof of concept. Chapter 6 concludes the paper.

Related Works

Assistive technologies are an important field of study due to the many challenges their conception faces. The IoT (Internet of Things) systems development and the need to improve people with disability life and access to assistive technologies have resulted in many types of system and disabilities being explored in literature. The most treated impairments [START_REF] Ariza | Low-Cost Assistive Technologies for Disabled People Using Open-Source Hardware and Software: A Systematic Literature Review[END_REF] are vision disabilities, mobility issues as well as hearing impairments. For instance, [START_REF] Sonth | OCR based facilitator for the visually challenged[END_REF] proposed a system acquiring images from a lowcost camera, processing them on a Raspberry Pi to extract texts and to read them with a text to speech system. In [START_REF] Mahamud | Watch IT: An assistive device for deaf and hearing impaired[END_REF], authors presented a system aiming to facilitate communication with hearing impaired people. The system is based on a mobile app sending text to an Arduino UNO and displaying it on an LCD screen. In [START_REF] Chatterjee | A low-cost assistive wheelchair for handicapped , elderly people[END_REF], a mixed control wheelchair is presented, aiming to help paralyzed people controlling it, through enhancement with low-cost sensors. With an Arduino UNO it acquires data from accelerometer, ultrasonic sensors and servo motors. The Arduino is connected to a Raspberry Pi and using a camera acquiring eye movement, the person with disability can control its wheelchair.

Nonetheless, many systems developed in the literature are based on the same architecture types, using fixed sensors and micro-controller unit or a micro-computer as Raspberry Pi to control actuators and to treat data [START_REF] Ariza | Low-Cost Assistive Technologies for Disabled People Using Open-Source Hardware and Software: A Systematic Literature Review[END_REF]. Moreover, for different disabilities, the system architectures are still almost the same. Those systems, as it can be seen in [START_REF] Sonth | OCR based facilitator for the visually challenged[END_REF], [START_REF] Mahamud | Watch IT: An assistive device for deaf and hearing impaired[END_REF] and [START_REF] Chatterjee | A low-cost assistive wheelchair for handicapped , elderly people[END_REF], are in many cases immutable, even though from one people to another with the same disability, needs can change.

Thus, a question that could be addressed is related to the architecture adaptability. In [START_REF] Leaman | A Comprehensive Review of Smart Wheelchairs: Past, Present, and Future[END_REF], authors conclude by approaching the research guiding principles in smart wheelchair domain. They recommend that the best parts of wheelchairs prototypes "should be fused into a modular upgradable system that can be marketed to the millions of people who need PWs (Power Wheelchairs).". The flexibility can also be a mean to make the architecture responds to the needs of as many people as possible and with a better accuracy. For instance, in [START_REF] Raad | An IOT based Wearable Smart Glove for Remote Monitoring of Rheumatoid Arthritis Patients[END_REF], authors proposed a system aiming to help therapists treat rheumatoid arthritis thanks to a glove acquiring data with flex and force sensors through an Arduino. They conclude their study by expressing the needs for their system to adapt to the patient's situation, by adding more sensor flexibility. Some research as in [START_REF] Bumuller | Development of a modular smart wheelchair[END_REF] have been made in the adaptability direction, here in smart wheelchair area or in wearable systems with [START_REF] Botezatu | On the Design of a Modular Wearable Solution for Assistive Technologies[END_REF] proposing a wearable modular electronic system named "VibroWear" for health monitoring. In order to guide further developments, technologies used in those articles are listed (as well as their purpose) in Table 1. Textual Communication [START_REF] Mahamud | Watch IT: An assistive device for deaf and hearing impaired[END_REF] LCD display Arduino Navigation [START_REF] Nandini | Smart Cane for Assisting Visually Impaired People[END_REF] Led, Water sensor, US sensor Arduino Diagnostic Help [START_REF] Raad | An IOT based Wearable Smart Glove for Remote Monitoring of Rheumatoid Arthritis Patients[END_REF] Force sensor Arduino

3 Modular and distributed architecture approach

Case study definition

As this architecture aims to respond to needs expressed by professionals, a list of promising assistive devices for use cases has been defined. The need for variability can come either from the product type or from the person's disability. For instance cognitive handicap and motor handicap may have access to the same assistive device but will not need the same functionality on it. Table 2 presents the different results brought from discussions with occupational therapists and biomedical engineer experts. Usage tracking and gesture learning are the two needs identified in each cases, indeed they could offer occupational therapists important feedback on the device use and on the improvement of the patient condition. Furthermore, two specific use case scenarios have emerged, from table 2 : a better suited glass to help the patient stay hydrated and a power wheelchair enhancement. Our works will focus on those cases.

As adapted wheelchair joysticks are among the most produced devices by the professionals that have been questioned, enhancing them will have a positive impact in many patients lives. Plus, literature shows that wheelchair enhancement is a hot topic as mentioned in [START_REF] Leaman | A Comprehensive Review of Smart Wheelchairs: Past, Present, and Future[END_REF]. It concludes on the lack of adaptable system to upgrade power wheelchair. When upgrading them, authors mainly focused on one objective producing specialized architectures ( [START_REF] Chatterjee | A low-cost assistive wheelchair for handicapped , elderly people[END_REF], [START_REF] Raad | An IOT based Wearable Smart Glove for Remote Monitoring of Rheumatoid Arthritis Patients[END_REF]), using basic sensors that could be integrated in our adaptable structure. Furthermore, as many patients may have a wheelchair but with different handicap, the adaptability is of at most importance because they will not have the same needs. Some people could only need a usage tracking, and others a whole system that could be used to control their environment, using sensors as RFID (Radio Frequency Identification), ultra-sonic sensors or through an HMI (Human-Machine Interface).

Adapted glass is also an interesting use case due to its simplicity and to the various use scenarios that illustrates the whole architecture interest. Table 2 shows that dehydration feedback and usage tracking are two important adapted glass evolution. It was decided that this use case would be used as a first proof of concept.

Distributed architecture

In order to respond to these objectives, a focus on the development of a distributed architecture has been made. The main difference between a monolithic and a decentralized architecture is the computational power which is, in the first case centralized in a control microprocessor and in the second case distributed. Each component, node, or block has a specific role and communicates with other nodes to perform the system function. This statement is the hearth of modular robotic principles as in [START_REF] Murata | M-TRAN: self-reconfigurable modular robotic system[END_REF], presenting an homogeneous modular robot in which each component has the same function. Heterogeneous robots also respect this principle but each node has a specific purpose, which is closer to the architecture that was designed. As stated in [START_REF] Andreev | Control System Mobile Robots with Modular Architecture as a Multi-Agent System with a Hierarchical Topology[END_REF], in a decentralized computational structure, one of the main issue is to exchange information and coordinate all the controllers to achieve the structure goal.

Following this idea, structural nodes is decomposed in two types 1) "control block" and 2) "sensor-actuator blocks". On the one hand, control module implements the coordination system gathering information, executing fundamental behavior and redirecting information to the devices. On the other hand, sensor-actuator blocks are composed of a control unit and one or several functions depending on the sensors or actuators connected on the module. To answer the information flow issue between blocks, a communication protocol to allow control block managing several heterogeneous sensor-actuator blocks, with special needs, had been formalized.

The method proposed in this paper is inspired by publish-subscribe communication protocol as MQTT. On these message patterns, when connecting to a central node (called the broker), devices subscribe to a number of "subjects" produced by the broker in order to receive updates when necessary. On the other side, the broker is receiving data from the devices, which are either analysed and redirected to the subscribed devices or just redirected. These protocols are mainly used in IoT systems through remote communication as WiFi, as they offer a great flexibility with regards to the data flow [START_REF] Kodali | MQTT based home automation system using ESP8266[END_REF]. These concepts have been applied, in our architecture, to wired communication: the control block being the central node and the sensor- Fig. 1 Publish-subscribe communication between blocks actuator blocks being the editors and subscriber subjects. The control node handles the new device connection by requiring their configuration at first in order to save it in memory. Then, the communication can begin between the device and the control unit, which receives its data and redirects them to subscribed blocks. This way, sensor-actuator nodes are able to exchange information and adapt their behaviour regarding received data. Figure 1 describes this protocol operation for an example. The accelerometer block and the led block are required to send data if necessary (red arrows). After collecting these information, the control node updates its internal values. Then, subjects as x, y and z accelerations, timer or more conceptualized subjects as movement are extracted from current data. Following extraction, they are sent using broadcast for timer (big blue arrow), direct transmission for movement (thin blue arrows) or network transmission if needed. When the led block receives movement information, it can update its status if there was movement (object has been or is being used) or not. Thus, regarding the state of the accelerometer node, the led node can modify its behaviour. In order to follow the entire system operation, and interact with it either passively (to observe it) or actively (to modify it) it has been choose to develop a digital twin module embedded in the control block and exchanging information with the controller module.

Embedded Digital Twin Module

The digital twin (DT) concept is mainly used in manufacturing or industrial applications because it offers a powerful tool to control factories, predict errors and avoid them. Thus, the first definition and structure was proposed in those domains in 2014, by Grieves in [START_REF] Grieves | Digital Twin: Manufacturing Excellence through Virtual Factory Replication[END_REF], and it is still a hot-topic in Industry 4.0. Since then, DT technologies have gained interests in other domains like the healthcare industry [START_REF] Liu | A Novel Cloud-Based Framework for the Elderly Healthcare Services Using Digital Twin[END_REF] or in smart cities. Consequently, plenty of definition for DT have been mentioned as it can be seen in [START_REF] Semeraro | Digital twin paradigm: A systematic literature review[END_REF]. The definition proposed in ISO 23247 is more suited to manufacturing applications, so the definition proposed in [START_REF] Julien | How to characterize a Digital Twin: A Usage-Driven Classification[END_REF] has proved more suitable.

The DT is defined as a dynamic virtual representation of an object (product, process or service). They also highlighted basic characteristics that must be included in a DT: a continuous connection between physical and virtual space, the ability to manage suitable data, an architecture allowing in-line and off-line twin modification, its physical counterpart control, learning ability and prediction ability. Thus, an important aspect of DT that is underlined in those features, is its dynamism. This concept is at the center of our architecture, which is why it was considered that this technology would act as a conductor for our whole system.

Embedded Digital Twin (eDT) is a topology where the DT and it's physical counter part share the same computing power, as described in [START_REF] Schroeder | Digital Twin connectivity topologies[END_REF]. Among the other topologies, the embedded solution was the most relevant considering that collaboration between assistive technologies within the person environment. Using an embedded DT, acquired data from the different nodes of one device are directly transferred from the controller module to the DT module using a shared memory. Then, the DT can share, if necessary, those information with human or DT collaborators. Furthermore, an efficient power management strategy, that will rely on the embedded DT decision, is beeing considered. Being as close as possible to the device allows it to easily change its current configuration through the shared memory. This, in order to either modify the operation of the system (changing a threshold for instance) when receiving the instruction to do so or to guarantee that the assistive device is using the necessary amount of power. Another situation is that the system will sometimes need to collect more data (in an hazardous or unknown scenario) and the DT will be the lever for the architecture to adapt and collect cleverly data as described in [START_REF] Julien | Integrating Lean Data and Digital Sobriety in Digital Twins through Dynamic Accuracy Management[END_REF].

To be compliant with DT standards, our objectives and the DT architecture is aligned to the standard ISO 23247 standard [27]. It proposes a DT architecture for manufacturing applications, that needed to be adapted to our purpose taking into account the embedded aspect of the DT. Figure 2 represents the three main actors that were identified which are 1) ITs, 2) the person with the disability and 3) occupational therapists and their interaction with the assistive technology. The DT entity is embedded in the Shared Computational Entity of the Physical Twin and can be accessed by therapists and ITs through an Interface Functional Element. It interacts with the Controller Entity using the Shared Memory Entity. It integrates the communication functionalities in order to collaborate with the environment and functions to manage the whole device. The Controller Entity delivers DT module orders to sensor-actuator blocks and controls the data flow presented in Figure 1.

Using ISO 23247 nomenclature and literature elements, [START_REF] Julien | Typology of Manufacturing Digital Twins: A First Step Towards A Deployment Methodology[END_REF] proposed a description tool named the "digital twin typology" to put a first step into a DT design methodology using eleven criteria. Applying this approach, elements of our DT typology are summarized in table 3. One criterion (Smart Manufacturing System) was discarded because it was not relevant in our project. Using this tool, the functions that will be implemented in the first version of our DT and the users with whom it will collaborate, were expressed. Fig. 3 Hardware structure illustration bedding system DT module and the controller module. Following the related works study results in Table 1, an ESP32 to embed the DT has been choose. It is a low-cost and widespread MCU like Arduinos, which has the advantage to integrate WiFi and BLE. Device blocks are composed of a smaller microcontroller and functionalities that can be sensors or actuators. This MCU should be able to communicate with the control node and carry out minimal computational functions on data such as simple comparison. To be compliant with the results in Table 1,a few devices to be implemented in the first experimentation which are the accelerometer, the joystick, the ultra-sonic sensor, the leds and the buzzers has been choose.

A.Houé et al.

Used by patients

Configuration by ITs

For the data communication between control node and device nodes, several choices were possible but the four main were SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit), CAN (Controlled Area Network) and UART (Universal Asynchronous Receiver / Transmitter). The use I2C over CAN bus was prefered because even though it seemed to be a good choice regarding the architecture communication logic, it is not, by nature, available on all ESP32. UART might have been a more standard choice but the development would have been far more complex than with I2C, because it is not a native master-slave communication protocol. SPI protocol could have been used, because it is faster than I2C, nonetheless, each device connected to the main block requires a chip select pin. Whereas, with I2C only two cables are used to connect the device on the bus, using software addresses to differentiate two modules. Finally, I2C offers the possibility to broadcast data to slaves thanks to address 0, making it a suitable choice for our application and experimentation. As it can be noticed on Figure 3, another communication cable named "INT" to handle node connection and disconnection to the central unit is added. Indeed, I2C does not allow slaves to send data to the master node, this third signal is required to warn the control node when user want to change the physical configuration.

Experimentation and Results

To evaluate architecture design choices, experiments have been led on the adapted glass use case. Figure 4 illustrates the different cases that have been focused on. In the first case, the glass is equipped with control block and usage tracking capacity that can be achieved with an accelerometer. It gathers data about the object use and allow health professionals to know if, when, and how the device has been used. In the second scenario, a feedback capacity is added. If the glass is not used on a regular basis, it will send a feedback to remind the person to drink. This feedback could take several forms as visual or sound effects. Even if the feedback is still luminous, adaptation could be achieved by switching the effect using "sub-capacities" to change from one behaviour to another. In the luminous feedback case, professionals could decide that a static light is better than a dynamic one. Finally, the third scenario illustrates the case when the feedback capacity is faulty. In this situation, the DT could decide to communicate with an other equipment in its environment, to fulfill its warning goal. This second object, could decide to accept or decline this demand, depending on the situation. The communication protocol between control and sensor-actuator blocks was successfully developed, broadcasting general interest data on the I2C bus which are correctly received by devices. Control block is able to request information from them in order to extract subjects to which some devices are subscribed. When a new device is connected, the control block asks for its subscriptions, those that were configured before the sensor-actuator node was programmed. Devices connection and disconnection was successfully implemented and managed by the control block. Power management was not tested directly on the architecture but previous works on the system have shown that it is functional as well as data saving. First scenario is still under development. Second scenario has been fully tested. Third one requires more works on the implementation of the wireless communication before it can be tested.

Conclusion and future works

Adaptability in the development of assistive technologies could be a great improvement to simplify their access and conception. Most of the architectures found in the literature are based a similar structure with sensors and actuators even thought they are used for different purposes. Using the distributed and modular architecture presented in this paper, healthcare professionals have been offered a innovative way of creating multiple assistive devices for different disabilities using the same technology. Embedded DT will help to control the object reconfiguration and com-munication and will be a lever to help occupational therapists study the use of assistive devices and to decide if changing it is required. First developments have been carried on to evaluate the proposed architecture, and some fundamental functions have been successfully implemented. Preliminary works on data-logging activity of assistive objects, that initiated our researches, still need to be implemented on our modular and distributed architecture.

To implement the third use case scenario presented on Figure 4, future developments will be focused on integrating and testing the communication between several assistive technologies, and other smart objects from the person environment. Then, our next works will focused on smart wheelchairs as it offers a more complex use case with a wide range of adaptability options, and it could also benefits to a larger number of people. Finally, occupational therapists have shown great interests about helping patients with feedback about the gesture learning, thus,"computational blocks" with a higher computational capacity could be implemented, in order to analyse the gesture and to generate information about its quality or improvement. In the same way other type of nodes might be implemented in the future.

Fig. 2

 2 Fig. 2 Embedded digital twin architecture

Fig. 4

 4 Fig. 4 Adapted glass use cases

Table 1

 1 Related works overview

	Application	Papers	Sensors/Actuators	Controllers
	Text-to-speech	[9]	Camera	Raspberry Pi
	Wheelchair control	[11, 14, 17] US sensor, Accelerometer,	Arduino, Raspberry Pi
			Buzzer, SPO2, Temperature
			sensor

Table 2

 2 Use cases

	Assistive device	Aim	Needs
	Adapted glass	Grab the glass	Usage tracking, dehydration feedback,
			gesture learning
	Adapted fork	Grab the fork	Usage tracking, gesture learning
	Adapted sport equipment	Use the equipment Usage tracking, gesture learning
	Adapted wheelchair joystick Use the joystick	Usage tracking, gesture learning,
			wheelchair enhancement
	Adapted pen	Use the pen	Usage tracking, gesture learning

Table 3

 3 Embedded digital twin typology

	Criterion	Description	Value for the Digital Twin
	Physical Element	The physical twin	One assistive device
	Type	Prototype, instance or aggregate	Instance
	Level	Hardware technological level: system of systems, system, equipment or component	Equipment
	Maturity	DT role in the system: control DT, cognitive DT or collaborative DT	Control DT
	Topology	Connection between cyber-physical space: joint, disjoint and embedded.	Embedded
		Human place in the DT decision process. Can
	Decision loop	be open (human interaction), closed (no	Mixed
		human interaction) or mixed
	Synchronisation	Data harvesting method. Synchronous or not Asynchronous, event based
	Users	Collaborators of the DT	Technicians, occupational therapists and patients
	Usages	Basic functions implemented by the DT	Analysis, comparison, collaboration
			On-line reconfiguration,
	Applications	Global goal reached using these skills	real-time control, off-line
			analytics
	4 Hardware design
	The modular and distributive architecture will be deploy on a hardware system illus-
	trated on Figure 3. The control block consists of a microcontroller, communication
	peripheral, external memory to save collected data and a battery. It is the one em-

Acknowledgments

This study was conducted as part of the project " Handicap Innovation Territoire " led by Lorient Agglomeration and supported by Brittany and French state under the "Territoires d'innovation du Programme d'investissements d'avenir " part, managed by the "Banque des territoires". Authors would also like to thank the M@D chair team for their help, and the UBS Foundation for funding these researches. This work also benefits from previous internship work, so authors wanted to thank Gaëtan Izzi for its contribution.


Distributed under a Creative Commons Attribution| 4.0 International License Y a-t-il un pilote dans la blockchain ? Réflexions sur l'identification d'un responsable de traitement dans le cadre de la blockchain Alice Mornet To cite this version: Alice Mornet. Y a-t-il un pilote dans la blockchain ? Réflexions sur l'identification d'un responsable de traitement dans le cadre de la blockchain. Lexbase Hebdo édition affaires, 2021, 666. hal-04327444 Y a-t-il un pilote dans la blockchain ? Réflexions sur l'identification d'un responsable de traitement dans le cadre de la blockchain Alice MORNET Vouée à devenir le « nouveau moteur de l'économie mondiale » 1 , la blockchain est l'objet de nombreux fantasmes. Qualifiée de disruptive ou de révolutionnaire, elle se révèle évanescente et demeure difficilement saisissable pour les non-initiés. Sa définition est pourtant aisée : la blockchain est une technologie de stockage et de transmission d'informations 2 . Elle apparaît, concrètement, comme une grande base de données contenant l'historique de l'ensemble des opérations réalisées depuis sa création. Utilisant des procédés relativement anciens -réseaux pair-à-pair ; cryptographie asymétrique -elle se singularise par ses caractéristiques. Transparence, sécurité et désintermédiation constituent ainsi le triptyque donnant à la technologie blockchain toute sa valeur. Élaborée dès 2008 avec le « bitcoin », elle connaît aujourd'hui de nouveaux usages et promet de s'étendre à d'autres domaines 3 . Profondément inédite, la blockchain se développe en niant les règles de protection des données à caractère personnel 4 qui connaissent, elles aussi, une évolution fulgurante. Trouvant leur origine dans la loi Informatique et Libertés du 6 janvier 1978, elles ont été sensiblement remaniées par le règlement (UE) 2016/679 (ci-après « RGPD ») 5 .

Opposer les règles du RGPD à la blockchain n'a de sens que si celle-ci contient effectivement des données à caractère personnel 6 . Sur ce point, il existe aujourd'hui un

consensus 7 et d'aucuns contestent la présence de telles données sur la blockchain et, de facto, l'application du RGPD. Technologiquement réalisable 8 , un anonymat total 9 l'écarterait mais serait alors susceptible de nuire à la prévention et à la lutte contre la criminalité 10 . La blockchain doit donc se soumettre au RGPD et cette conciliation constitue, selon le Professeur Mekki, « l'enjeu de demain » 11 .

Entré en vigueur en 2016, le RGPD a pour ambition d'« instaurer un cadre solide, cohérent et moderne » en matière de protection des données « qui soit neutre sur le plan technologique et résistant à l'épreuve du temps pour plusieurs décennies » 12 . Le principe de neutralité dont le RGPD se prévaut implique alors qu'il puisse résister aux évolutions technologiques 13 . Pourtant, nombreux sont les auteurs ayant souligné son apparente incompatibilité avec la blockchain 14 . Si plusieurs points d'achoppement ont été relevés, l'identification d'un responsable de traitement interroge particulièrement. Obéissant à une analyse contextuelle et factuelle 15 , la détermination de ce personnage central suppose d'identifier la partie définissant la finalité -le but -et les moyens du traitement -le comment 16 . Si elle apparaît parfois évidente, cette identification peut également se révéler 7 F. CHAFIOL, A. BARBET-MASSIN, « La blockchain à l'heure de l'entrée en application du règlement général sur la protection des données », op. cit. ; M. POPPE, « Quelle relation entre la protection des données à caractère personnel et la blockchain ? », Revue Lamy droit des affaires, n°129, 2017 ; O. LASMOLES, « La difficile appréhension des blockchains par le droit », Revue internationale de droit économique, 2018/4, t. XXXII, pp. 453-469 ; CNIL, Blockchain : Premiers éléments d'analyse de la CNIL, Sept. 2018, 11 p. ; S. CULLAFFROZ-JOVER, E. BACQ, « Blockchain et données à caractère personnel, l'improbable conciliation ? », Droit et Patrimoine, n°290, 2019. 8 Le procédé cryptographique dit de « la preuve sans divulgation de connaissance » semble susceptible d'assurer un certain anonymat : V. FAURE-MUNTIAN, C. de GANAY, R. LE GLEUT, Rapport sur les enjeux technologiques des blockchains (chaînes de blocs), Sénat, 20 juin 2018 ; T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit. 9 Les données présentes sur la blockchain sont cryptées et n'apparaissent pas en clair. Toutefois, elles ne sont pas anonymes mais simplement « pseudonymisées », au sens du RGPD, en ce que l'identification de la personne concernée demeure permise. V. à ce sujet, J. DEROULEZ, « L'actualisation des enjeux liés aux données personnelles. Blockchain », op. cit. Or, dans les méandres de la blockchain, cette qualité peine à trouver son sujet et fragilise alors le droit à la protection des données à caractère personnel. Si l'identification d'un responsable de traitement au sens du RGPD semble impossible dans le cadre de la blockchain (I), une responsabilisation de ses acteurs, à l'aune du droit de la responsabilité civile, paraît permise (II).

I. Les limites rédhibitoires du RGPD : l'impossible identification d'un responsable de traitement dans la blockchain

Nombreux sont les auteurs à dénoncer la difficulté 20 , voire l'impossibilité 21 , qu'il y a à identifier les responsables de traitement dans le cadre d'une blockchain. Une telle gêne, résultant de l'incompatibilité structurelle existante entre la blockchain et le RGPD (A) empêche, il est vrai, d'identifier précisément un responsable de traitement (B). de prérogatives propres à garantir leur sauvegarde. Pour exercer ses droits27 , elle doit s'adresser aux « responsables de traitement », c'est-à-dire aux personnes physiques ou morales qui définissent les moyens et les finalités du traitement 28 . Tenus de répondre aux sollicitations des personnes concernées, ces derniers sont également chargés de veiller à la sécurité du traitement et, plus largement, au respect des exigences du RGPD [START_REF]Sur les obligations imposées aux responsables de traitement : Chapitre IV[END_REF] . À ce duo d'acteurs s'ajoutent parfois des « sous-traitants » qui recouvrent les personnes physiques ou morales traitant les données pour le compte du responsable de traitement 30 . Déterminantes, ces qualités commandent le bénéfice de droits ou l'attribution d'obligations en organisant, de facto, la protection des données à caractère personnel. S'articulant autour du responsable de traitement, le régime imposé se révèle profondément vertical et le RGPD a encore accentué ce trait distinctif en densifiant le rôle de cet acteur qui doit désormais veiller, de manière autonome, à la conformité de ses opérations [START_REF]Conformément au principe d'accountability : A. DEBET, « Les nouveaux instruments de conformité[END_REF] .

A. Une impossibilité résultant d'une incompatibilité structurelle

L'identification d'un responsable de traitement apparaît indispensable à l'effectivité du droit à la protection des données à caractère personnel. Pourtant, la blockchain, de par ses multiples intervenants et sa structure décentralisée, semble résister à cette condition sine qua non.

B. Une impossibilité apparemment irréversible

Fondamentale, la question de l'identification du responsable de traitement au sein de la blockchain n'est pas totalement éludée par la doctrine. Néanmoins, au regard des spécificités de la technologie, des divergences d'appréciation subsistent et, faute de consensus, aucune figure ne semble se démarquer.

Pour certains auteurs, les plateformes d'échange de jetons méritent d'être qualifiées de responsables de traitement [START_REF] Chafiol | les responsabilités des noeuds et des utilisateurs semblent majoritairement admises. Toutefois, au regard de leurs limites, ne conviendrait-il pas de les qualifier, ensemble, de coresponsables[END_REF] . S'il est vrai qu'elles collectent les données des utilisateurs tout en définissant les finalités et les moyens d'un tel traitement, elles n'interviennent pas dans le fonctionnement concret de la blockchain 33 . D'autres auteurs attribuent la qualité de responsable de traitement aux concepteurs 34 . Incontestablement, ce sont eux qui conçoivent l'architecture de la chaîne. Cependant, la finalité déterminée reste à ce stade très large, une blockchain n'étant qu'un protocole pouvant servir de nombreux usages. Par exemple, Ethereum permet de développer une multitude d'applications parmi lesquelles la vente d'actifs ou la location de stockage cloud. La responsabilité pourrait alors être recherchée sur les concepteurs de ces applications, déterminant plus finement la finalité du traitement. Néanmoins, si cela autorise l'utilisateur, en tant que personne concernée, à contacter ces derniers afin d'exercer ses droits, une faille de sécurité imputable à blockchain elle-même ne semble pas pouvoir leur être reprochée 35 . La responsabilité des mineurs apparaît, en revanche, majoritairement écartée par la doctrine. Il est vrai qu'ils ne jouent aucun rôle dans la détermination de la finalité des traitements opérés sur la chaîne, en se contentant de valider les opérations effectuées par les utilisateurs 36 . Un rapport envisage cependant la responsabilité des noeuds 37 . Participant à la validation des blocs, ils peuvent également, s'ils sont majoritaires, modifier les règles de la blockchain. Ils ont donc une incidence importante sur les moyens du traitement et, lorsqu'ils valident une opération, déterminent effectivement sa finalité.

De telles divergences, ne permettant pas de proposer une solution satisfaisante, ont conduit la CNIL à se prononcer. Contre toute attente, elle qualifia les utilisateurs de responsables de traitement 38 . S'ils déterminent la finalité du traitement qu'ils opèrent sur la blockchain, leur incidence sur les moyens demeure minime 39 et ils ne semblent pas suffisamment contrôler la chaîne pour endosser une telle responsabilité. Surtout, une telle 33 Les finalités du traitement opéré par les plateformes sont, en effet, spécifiques en concernant la lutte contre le blanchiment et les terrorisme, d'une part ; l'exécution des relations contractuelles conclues entre elles et les utilisateurs, d'autre part. La lecture de la politique de confidentialité de la plateforme d'achat Coinhouse confirme une telle interprétation : https://www.coinhouse.com/fr/politique-de-confidentialite/. 34 M. POPPE, « Quelle relation entre la protection des données à caractère personnel et la blockchain ? », op. cit. 35 En outre, ces concepteurs ne sont pas toujours identifiables en ce qu'ils usent de pseudonymes ou de logiciels libres : H. CHRISTODOULOU, « Les nouvelles technologies à l'origine de l'évolution contractuelle », Comm. com. électr., n°11, 2020, Étude 20. 36 lecture n'apparaît pas acceptable en ce qu'elle suppose qu'une même personne puisse cumuler les qualités de responsable de traitement et de personne concernée [START_REF] Belic | Data Protection Challenges of public permissionles blockchains in relation to the GDPR[END_REF] . Consciente de cette difficulté, la CNIL l'écarte en invoquant l'exception tenant à l'usage domestique 41 selon laquelle le RGPD n'a pas à s'appliquer aux traitements réalisés « dans le cadre d'une activité strictement personnelle ou domestique » 42 . Or, selon le dispositif de l'instrument, il s'applique en revanche aux responsables fournissant les moyens de traiter les données pour de telles activités 43 . Partant, si un particulier utilise la blockchain pour transférer des bitcoins, l'opération est certes personnelle mais se trouve permise par une technologie devant répondre au RGPD.

Par ailleurs, l'assertion de la CNIL apparaît contraire à la jurisprudence de la Cour de justice de l'Union européenne 44 qui écarte l'exception susvisée lorsque les données sont « rendues accessibles à un nombre indéfini de personnes » 45 . Publique par nature, la blockchain semble permettre un tel accès, peu important que les données demeurent cryptées. L'exception ne semble donc pas applicable et les qualités de personne concernée et de responsable pourraient donc, en pratique, se cumuler. Or comment peut-on être, à la fois, débiteur et créancier de la même obligation ? En droit français, la confusion de ces qualités entraîne l'extinction de l'obligation 46 , du moment qu'il s'agit d'un droit de créance [START_REF] Dagorne-Labbe | Confusion » in Répertoire de droit civil[END_REF] . Si la nature des démembrements du droit à la protection des données reste floue [START_REF] Pailler | L'article 8 de la Charte des droits fondamentaux de l'Union européenne -Quel apport à la protection des données à caractère personnel ?[END_REF] , il est certain qu'admettre un tel cumul porte atteinte à son essence, la personne concernée n'apparaissant pas suffisamment armée pour veiller à la protection de ses intérêts. qualification nécessite de démontrer que les décisions tenant à la finalité et aux moyens résultent d'une intention commune ou, au moins, convergente. Il n'est donc pas indispensable que les intervenants poursuivent des finalités identiques du moment qu'elles apparaissent étroitement liées ou complémentaires 50 . De même, les moyens n'ont pas à être déterminés par l'ensemble des participants si chacun d'eux à une réelle influence sur ces derniers [START_REF] Cjue | [END_REF] . Si, à certains égards, la blockchain témoigne d'une telle oeuvre commune, le RGPD exige toutefois des coresponsables qu'ils définissent « de manière transparente leurs obligations respectives » et qu'existe une claire répartition des responsabilités de chaque intervenant 52 . Protégeant la personne concernée, en favorisant la transparence du système, cette condition est ignorée par les acteurs de la blockchain [START_REF] Deroulez | Quel responsable de traitement ?[END_REF] . De surcroît, admettre cette coresponsabilité n'apparaît pas susceptible d'assurer la protection des données traitées dans la blockchain. En effet, les noeuds et les utilisateurs restent instables et il est très difficile de les identifier et, a fortiori, de les localiser [START_REF] Douville | Blockchain et protection des données à caractère personnel[END_REF] . D'autre part, même si leur responsabilité était jugée solidaire en permettant à la personne concernée de s'adresser à un seul d'entre eux, celui-ci ne n'aura pas accès aux données en clair [START_REF]Blockchain and the General Data Protection Regulation, Can distributed ledgers be squared with European data protection law ?[END_REF] et n'aura donc aucune emprise sur celles-ci [START_REF] Finck | produits défectueux pourrait être envisagée 60 . Au-delà du triptyque classique de la responsabilité civile, il conviendra alors de démontrer que la blockchain, pouvant s'analyser comme un produit 61 , présente un défaut qui serait imputable à un producteur. Là encore, l'identification de ce protagoniste risque de se révéler périlleuse[END_REF] .

Finalement, aucun sujet ne semble avoir le contrôle des données traitées sur la blockchain 57 . Extrêmement gênante, cette situation empêche la personne concernée d'exercer ses droits et lui cause, de facto, un préjudice. De même, celui-ci pourrait naître d'une atteinte à la sécurité de la blockchain qui emporterait des vols ou des destructions de données. Qu'il s'agisse de l'exercice des droits, qui est contrarié, ou d'une atteinte plus directe à la donnée, à qui la personne concernée peut-elle s'adresser pour obtenir la cessation de l'atteinte et la réparation de son préjudice ? Si tout contrôle de la blockchain, au sens du RGPD, semble interdit, en va-t-il de même pour les actions en responsabilité qu'il prévoit ? À la lecture de ses La responsabilité du fait des choses 71 pourrait, éventuellement, offrir un palliatif intéressant. Fondée sur la théorie du risque, elle semble particulièrement adaptée à la technologie disruptive qu'est la blockchain. Néanmoins, là encore, certaines corrections devront être apportées. Tout d'abord, il faudrait écarter définitivement le régime des produits défectueux, sous peine d'empêcher la victime de se fonder sur la responsabilité du fait des choses [START_REF]En effet, la victime ne peut se fonder sur la responsabilité du fait des choses dans le cas où son action relèverait du régime des produits défectueux, quand bien même l'exonération pour risque de développement serait applicable : CJCE, 5 ème ch[END_REF] . Ensuite, il conviendrait d'admettre que cette dernière puisse s'appliquer aux choses incorporelles [START_REF]Le Projet de réforme du droit de la responsabilité civile exclue les choses incorporelles[END_REF] , ce que les développements informatiques et technologiques justifient plus que jamais [START_REF] Grynbaum | Responsabilité du fait des choses inanimées[END_REF] . Enfin, les conditions nécessaires à son engagement devraient être appréciées à l'aune des particularités de la blockchain. À cet égard, si la démonstration du préjudice [START_REF]Résultant d'une atteinte au droit à la protection des données, celui-ci pourrait être moral et/ou matériel[END_REF] et du lien de causalité ne devrait pas soulever de difficultés particulières, en va-t-il de même quant au fait de la chose ? En considérant que la blockchain constitue une chose inerte, il conviendra de rapporter la preuve de son rôle actif dans la réalisation du dommage 76 . Un défaut de sécurité, même postérieur à son entrée en circulation, voire même l'incompatibilité intrinsèque de cette technologie avec les règles du RGPD pourraient, a priori, suffire à établir le critère de l'anormalité.

Si la mise en oeuvre de la responsabilité du fait des choses semble permise, il conviendra toutefois d'identifier un responsable, le gardien, en recherchant la personne ayant l'usage, le contrôle et la direction de la blockchain au moment du dommage 77 . Un tel exercice promet d'être périlleux et la présomption pesant sur le propriétaire 78 n'apportera aucun secours. De même, la distinction opérée entre la garde de la structure et du comportement ne constitue pas une alternative satisfaisante. En effet, alors que les concepteurs peuvent, a priori, être considérés comme les gardiens de la structure, ils abandonnent ensuite cette dernière aux noeuds qui ont la possibilité de la modifier. Serait-il possible, enfin, d'imaginer une garde collective qui incomberait à l'ensemble des intervenants ? Si le principe reste l'unicité, la jurisprudence admet qu'une garde commune soit caractérisée dès lors que des pouvoirs de droit ou de fait se trouvent exercés au même titre sur la chose ou, dans un souci d'indemnisation, lorsque le gardien ne peut être identifié aisément 79 . Séduisante, cette solution pourrait toutefois conduire à exclure la réparation dans le cas où la victime compte parmi les cogardiens 80 . Pour contrer cette difficulté, la garde devrait être réputée partagée entre les concepteurs, les noeuds et les mineurs, à l'exception des utilisateurs. Face à l'opacité de la blockchain, une présomption de garde commune pourrait être admise tout en autorisant un recours subrogatoire vers le véritable gardien s'il peut être identifié. Protégeant la personne concernée, cette solution renouerait avec la logique du RGPD tout en demeurant cohérente avec la théorie du risque fondant la responsabilité du fait des choses. Plus loin encore, la logique d'indemnisation pourrait gommer l'intérêt d'identifier un responsable. Il est en ce sens permis d'imaginer la création d'un fonds de garantie qui, à titre subsidiaire, serait chargé d'indemniser les dommages générés par la blockchain. Alimenté par l'ensemble de ses intervenants, il contribuerait à l'effectivité du droit à la protection des données tout en ne constituant pas une charge excessive sur les acteurs de cette technologie inédite. Si de nombreuses interrogations demeurent, la responsabilité civile pourrait offrir un palliatif au RGPD avant que ne soit définitivement tranchée la question de sa compatibilité avec la blockchain. Pour cela, il conviendrait de modeler les notions de responsable de traitement ou de responsabilité conjointe et renoncer à la prétendue neutralité technologique de cet instrument européen.

79 V. par exemple, Cass. 2 ème Civ., 13 janv. 2005, n°03-12.884 80 Cass. 2 ème Civ., 20 nov. 1968, Bull. civ. II, n°77 -RTD civ., 1969, 335, obs. Durry -Cass. 2 ème Civ., 25 nov. 1999, n°97-20.343.

publique 23 .

 23 Alors que les deux premières catégories admettent une certaine hiérarchie 24 , la troisième est la seule à réunir les qualités d'une véritable blockchain. Caractérisée par l'horizontalité, la décentralisation et la distribution, ses intervenants sont strictement égaux et n'ont, a priori, aucune obligation les uns envers les autres. En outre, aucun tiers de confiance n'est chargé de veiller à la conformité de la chaîne, cette fonction étant dévolue à l'ensemble des membres participants. Plusieurs acteurs coexistent, en effet, dans le cadre d'une blockchain. Les développeurs et programmeurs sont les premiers intervenants en ce qu'ils déterminent son architecture et son fonctionnement. Les utilisateurs, quant à eux, écrivent sur la chaîne et l'utilisent pour réaliser une transaction ou pour enregistrer une information. Les mineurs en constituent le maillon indispensable en étant chargés de vérifier les transactions qui s'y opèrent. Les noeuds, enfin, détiennent le registre, doivent valider les transactions opérées sur la blockchain et peuvent, sous réserve d'atteindre un consensus suffisant, en modifier les règles. Si la présentation ne peut qu'être synthétique, il convient de préciser qu'aucune de ces qualités n'est exclusive et qu'il est tout à fait possible, par exemple, de cumuler le rôle de participant et de mineur, comme il est obligatoire, pour être mineur, d'être également un noeud du réseau. Ce quatuor d'acteurs, indispensable au bon fonctionnement d'une blockchain, accueille parfois d'autres intervenants. Il en va ainsi des oracles et des plateformes intermédiaires. Tandis que les premiers assurent l'exécution des smart contracts éventuellement intégrés dans la chaîne 25 , les secondes sont chargées de vendre ou d'échanger les bitcoins ou autres cryptomonnaies nécessaires à son utilisation. Le régime de protection des données répond, quant à lui, à un modèle vertical et centralisé. Conformément à son caractère fondamental 26 , le droit à la protection des données suppose que la personne dont les données sont traitées -la « personne concernée » -dispose 23 Pour une présentation des différents types de blockchain : M. MEKKI, « If code is law, then code is justice ? Droits et algorithmes », Gaz. Pal., n°24, 2017, p. 10 ; M. MEKKI, « Les mystères de la blockchain », op. cit., p. 2160. 24 Dans une blockchain privée, une autorité centrale est chargée de maitriser la chaîne et les relations peuvent être contractualisées. De même, pour les blockchains par consortium, les participants sont limitativement énumérés et des responsables peuvent être érigés par contrat : D. LEGEAIS, « Blockchain » in J-Class. Banque -Crédit -Bourse, Fasc. 179, 1 er janv. 2020, n°12. 25 Les smart contracts sont des programmes informatiques pouvant exécuter automatiquement certaines instructions préalablement définies. Quant aux oracles, ils permettent d'intégrer à la blockchain des variables issues du monde réel. Sur ces notions : C. ZOLYNSKI, « Blockchain et smart contracts : premiers regards sur une technologie disruptive », Revue de droit bancaire et financier, janvier-février 2017, doss. 4 ; M. MEKKI, « Le contrat, objet des smart contracts (Partie I), Dalloz IP/IT, 2018, p. 409 ; M. MEKKI, « Le smart contract, objet du droit (Partie 2) », op. cit., p. 27. 26 V. not. à ce sujet, E. DEBAETS, Le droit à la protection des données personnelles : recherche sur un droit fondamental, thèse dactylographiée, Paris 1, 2014, 811 p.

  10 A. ELKAHWAGY, « La délinquance économique à l'heure du numérique : Bitcoin, blanchiment et autres observations », Arch. pol. crim., n°39, 2017, pp. 55-66. 11 M. MEKKI, « Le smart contract, objet du droit (Partie 2) », Dalloz IP/IT, 2019, p. 27. 12 Proposition de Règlement du Parlement européen et du Conseil relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données (règlement général sur la protection des données), COM(2012) 11 final, p. 115. 13 À propos de ce principe : A. ROBIN, « Neutralité du Net : vers une consécration européenne du principe ? », Comm. com. électr., 2015, étude 12. 14 J. DEROULEZ, « Blockchain et données personnelles. Quelle protection de la vie privée ? », JCP G, n°38, 2017, 973 ; F. CHAFIOL, A. BARBET-MASSIN, « La blockchain à l'heure de l'entrée en application du règlement général sur la protection des données », op. cit. Guidelines 07/2020 on the concepts of controller and processor in the GDPR, 2 sept. 2020, p. 10. 16 G29, Avis 1/2010, op. cit., p. 14 ; EDPB, Guidelines 07/2020, op. cit., p. 13. extrêmement complexe 17 . Fonctionnelle, la notion de responsable de traitement permet d'attribuer les responsabilités 18 et, ainsi, de garantir l'effectivité des dispositions du RGPD 19 .

; M. POPPE, « Quelle relation entre la protection des données à caractère personnel et la blockchain ? », op. cit. ; T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit. 15 G29, Avis 1/2010 sur les notions de « responsable du traitement » et de « sous-traitant », WP 169, 16 fév. 2010, p. 9 ; EDPB,

sa logique semble incompatible avec celle de la blockchain 22 . Dans sa conception originelle, la technologie blockchain apparaît horizontale. Toutefois, il convient d'opérer une distinction selon que celle-ci est privée, par consortium ou

  Alors que le RGPD devrait présenter une certaine neutralité technologique, La difficile appréhension des blockchains par le droit », op. cit., pp. 453-469 ; T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit.

	17 EDPB, Guidelines 07/2020, op. cit., p. 11 et 15.
	18 G29, Avis 1/2010, op. cit., p. 10 ; EDPB, Guidelines 07/2020, op. cit., p. 3.
	19 G29, Avis 1/2010 op. cit., p. 7.
	20 E. A. CAPRIOLI, « Les enjeux juridiques et sécurité des blockchains », Cahiers de droit de l'entreprise, n°3,
	2017, dossier 19 ; Simmons & Simmons LLP, « Le droit et la technologie blockchain : une approche sectorielle »,
	Contrats Concurrence Consommation, n°10, 2017, étude 10 ; O. LASMOLES, «

21

L.-D. IBANEZ, K. O'HARA, E. SIMPERL, "On Blockchains and the General Data Protection Regulation", EU Blockchain Forum and Observatory, 6 July 2018, p. 10 ; J. DEROULEZ, « Quel responsable de traitement ? », Revue Lamy Droit de l'Immatériel, n°156, 2019. 22 V. également en ce sens, T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit.

  Ils pourraient, en revanche, être qualifiés de sous-traitants : CNIL, Blockchain : Premiers éléments d'analyse de la CNIL, op. cit., p. 2 ; European Parliament, Blockchain and the General Data Protection Regulation, Can distributed ledgers be squared with European data protection law ?, July 2019, p. 46 ; T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit. 37 European Parliament, Blockchain and the General Data Protection Regulation, Can distributed ledgers be squared with European data protection law ?, op. cit., p. 46. Le Professeur Douville a également pu envisager cette hypothèse tout en démontrant ses limites : T. DOUVILLE, « Blockchain et protection des données à caractère personnel », op. cit. 38 CNIL, Blockchain : Premiers éléments d'analyse de la CNIL, op. cit., p. 2. Le parlement européen semble également privilégier cette hypothèse : Parlement européen, Rapport sur la chaîne de blocs : une politique commerciale tournée vers l'avenir, 2018/2085(INI), 27 nov. 2018, §23. 39 European Parliament, Blockchain and the General Data Protection Regulation, Can distributed ledgers be squared with European data protection law ?, op. cit., p. 48.

G. MAZZOLINI, « La blockchain, nouveau moteur de l'économie mondiale », Les Échos, 7 déc.

2 L'ordonnance n°2016-520 du 28 avril 2016 a introduit une définition de la blockchain au sein de l'article L.223-12 du Code monétaire et financier aux termes duquel celle-ci est définie comme « un dispositif d'enregistrement électronique partagé permettant l'authentification » des opérations réalisées.3 Sur les différentes utilisations de la blockchain : M. MEKKI, « Les mystères de la blockchain », Rec. D., 2017, p. 2160.4 La technologie fragilise de nombreuses dimensions du droit à la protection des données. Par exemple, son immuabilité interdit, en principe, toute rectification ou suppression de données. De même, sa distribution internationale empêche de déterminer, précisément, le droit applicable. V. not. au sujet de ces difficultés, J. DEROULEZ, « L'actualisation des enjeux liés aux données personnelles. Blockchain », Lamy Droit de l'Immatériel, n°156, 2019 ; F. CHAFIOL, A. BARBET-MASSIN, « La blockchain à l'heure de l'entrée en application du règlement général sur la protection des données », Dalloz IP/IT, 2017, p. 637 ; T. DOUVILLE, « Blockchain et protection des données à caractère personnel », AJ Contrat, 2019, p. 316. 5 Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données), JO L 119 du 4 mai 2016, p. 1.6 Le RGPD subordonne son application à la présence d'un traitement de données à caractère personnel : Art. 1 §1, Ibid.

Sur les droits dévolus aux personnes concernées et leurs modalités d'exercice : Chapitre III, Règlement (UE) 2016/679, précité.


Chloé Touzé

Peggy Chekroun

Social power reduces the consequences of cognitive inconsistency in a Stroop task

• • •    ղ • • •    0


Elpida Perdiki
email: eperdiki@helit.duth.gr

Preparing Big Manuscript Data for Hierarchical Clustering with Minimal HTR Training

Keywords: big data, byzantine manuscripts, deep learning, HTR models, Transkribus

technologies have progressed enough to offer high-accuracy results in recognising handwritten documents, even on a synchronous level. Despite the state-of-the-art algorithms and software, historical documents (especially those written in Greek) remain a real-world challenge for researchers. A large number of unedited or under-edited works of Greek Literature (ancient or Byzantine, especially the latter) exist to this day due to the complexity of producing critical editions. To critically edit a literary text, scholars need to pinpoint text variations on several manuscripts, which requires fully (or at least partially) transcribed manuscripts. For a large manuscript tradition (i.e., a large number of manuscripts transmitting the same work), such a process can be a painstaking and time-consuming project. To that end, HTR algorithms that train AI models can significantly assist, even when not resulting in entirely accurate transcriptions. Deep learning models, though, require a quantum of data to be effective. This, in turn, intensifies the same problem: big (transcribed) data require heavy loads of manual transcriptions as training sets. In the absence of such transcriptions, this study experiments with training sets of various sizes to determine the minimum amount of manual transcription needed to produce usable results. HTR models are trained through the Transkribus platform on manuscripts from multiple works of a single Byzantine author, John Chrysostom. By gradually reducing the number of manually transcribed texts and by training mixed models from multiple manuscripts, economic transcriptions of large bodies of manuscripts (in the hundreds) can be achieved. Results of these experiments show that if the right combination of manuscripts is selected, and with the transfer-learning tools provided by Transkribus, the required training sets can be reduced by up to 80%. Certain peculiarities of Greek manuscripts, which lead to easy automated cleaning of resulting transcriptions, could further improve these results. The ultimate goal of these experiments is to produce a transcription with the minimum required accuracy (and therefore the minimum manual input) for text clustering. If we can accurately assess HTR learning and outcomes, we may find that less data could be enough. This case study proposes a solution for researching/editing authors and works that were popular enough to survive in hundreds (if not thousands) of manuscripts and are, therefore, unfeasible to be evaluated by humans.

I INTRODUCTION

The humanitarian spirit of Antiquity and Byzantium has passed down to younger generations a multitude of manuscripts that preserve ancient and Byzantine Greek literary texts. Many of these manuscripts remain unedited or under-edited due to the complexity of producing critical editions. This process requires heavy loads of manuscript research until all disparate text variations (instances of manuscripts that contain the same opus transmitting different text) are collected and collated to the last detail. Especially in cases of rich manuscript traditions (i.e., a significant number of manuscripts transmitting the same work), this process is not only

II LITERATURE REVIEW

Text recognition systems are well-researched and continuously developing. Currently, there are two main systems for image text extraction: OCR (Optical Character Recognition), targeting printed text, and HTR for handwritten documents, where character recognition is not straightforward [START_REF] Firmani | Codice Ratio --Episode 1: Machine Transcription of the Manuscripts[END_REF][START_REF] Ströbel | Evaluation of HTR models without Ground Truth Material[END_REF]. HTR is further divided into offline (meaning recognition from a scanned document image) or online (text recognition while the text is being written) [START_REF] Ingle | A Scalable Handwritten Text Recognition System[END_REF]. Furthermore, the ever-increasing need for transcription of historical documents, currently archived in libraries and collections worldwide, has led to the development of HTR systems, mainly focused on ancient or medieval handwriting.

The most recent bibliography suggests applications such as Tesseract [START_REF] Patel | Optical Character Recognition by Open source OCR Tool Tesseract: A Case Study[END_REF][START_REF] White | Training Tesseract for Ancient Greek OCR[END_REF], 4 Kraken [START_REF] Schoen | Optical Character Recognition (OCR) and Medieval Manuscripts: Reconsidering Transcriptions in the Digital Age[END_REF][START_REF] Kiessling | Kraken -an Universal Text Recognizer for the Humanities[END_REF],5 eScriptorium [START_REF] Kiessling | eScriptorium: An Open Source Platform for Historical Document Analysis[END_REF], Transkribus [START_REF] Kahle | Transkribus -A Service Platform for Transcription, Recognition and Retrieval of Historical Documents[END_REF][START_REF] Muehlberger | Transforming scholarship in the archives through handwritten text recognition: Transkribus as a case study[END_REF], or μDoc [START_REF] Tsochatzidis | HTR for Greek Historical Handwritten Documents[END_REF]. Despite being listed in line here, it should be noted that the above methods cannot be measured reliably against each other, as they are diverse in architecture and function (i.e., Kraken and Tesseract are OCR engines, while eScriptorium and Transkribus are interface platforms for HTR). Regardless, already conducted experiments [START_REF] Ströbel | Improving OCR of Black Letter in Historical Newspapers: The Unreasonable Effectiveness of HTR Models on Low-Resolution Images[END_REF][START_REF] Ströbel | How Much Data Do You Need? About the Creation of a Ground Truth for Black Letter and the Effectiveness of Neural OCR[END_REF]Clérice, 2022b] have demonstrated that from the HTR mentioned above tools, Transkribus and e-Scriptorium (which implements Kraken) are the most successful in producing low CER (Character Error Rate) text recognitions. Part of this success is due to the different and more efficient layout analysis performed by both Transkribus and eScriptorium, an analysis that does not restrict segmentation in rectangular regions, as handwritten text can expand in many forms and directions [START_REF] Stokes | The eScriptorium VRE for Manuscript Cultures[END_REF]. It was decided to exploit the Transkribus system for experimenting with Greek manuscripts HTR and the reason behind this decision was twofold. First of all, while most other systems are executed via CLI (Command Line Interface), assuming coding fluency, Transkribus is offered as a GUI (Graphical User Interface) 6 and Web-based application,7 making it accessible to most researchers. Currently, eScriptorium also offers a Web-based platform upon registration and further contact with their team [START_REF] Kiessling | eScriptorium: An Open Source Platform for Historical Document Analysis[END_REF][START_REF] Stokes | The eScriptorium VRE for Manuscript Cultures[END_REF]. However, their interface was partially developed when this research began experiments. That being said, we intend to expand our training methods with the exploitation of eScriptorium. Secondly, unless one uses its official servers, eScriptorium/Kraken needs high computational power to train models [START_REF] Stokes | The eScriptorium VRE for Manuscript Cultures[END_REF]. Unfortunately, not many scholars have access to high-performing hardware. On the contrary, since Transkribus is connected to the Innsbruck server, all computations and training are performed there [START_REF] Kahle | Transkribus -A Service Platform for Transcription, Recognition and Retrieval of Historical Documents[END_REF]Muehlberger et al., 2019, pp. 959, 962]. So, each user can train models even from a low-cost laptop. It should also be noted that, to our best knowledge, currently there are no published and readily available HTR models for ancient Greek or Byzantine textual data.8

III METHODS OF MANUSCRIPTS AUTOMATIC TRANSCRIPTION 3.1 Data Availability

As described previously, the 11 case study manuscripts were used as training data. The manuscripts are dated to the 10 th -14 th century and transmit John Chrysostom's Homilies on St. Paul's Epistles to Titus. 9 Homilies 1 and 5 were used as data sets in all conducted experiments based on the availability of digital images.

Most digital reproductions of manuscripts are under some degree of copyright protection. As a result, data gathering is not always a straightforward process. Quite the opposite, the author produced ground truth data from scratch for the following experiments, which are fully provided to the research community. Instead of the digital files of the manuscripts, links to the libraries' digital archives are given, if applicable. The detailed dataset can be found in [Perdiki, 2023]. However, the best-performing general model from our training is currently not available in Transkribus. It will be released upon my thesis publication in the coming months, subject to Transkribus approval [Perdiki, forthcoming].

Methodology

Transkribus documentation denotes that for a successful HTR model training, at least 15,000 words of diplomatic transcription input are required. However, since such transcriptions are unavailable, producing them from scratch would demand heavy economic and human resources, for a data set consisting of million words. Early experiments on Transkribus indicated that most erroneous outputs involved misrecognition of accents, punctuation or word tokens splitting (due to the scripta continua form of the writing style -which, however, is normalised in the transcription, while abbreviations are marked up and later expanded in the metadata section), 10 see Figure 1. Most of the time, the last character of a word token (usually pronouns or conjunctions with an average of three characters in length) was erroneously connected with the following or the previous word token. In addition, probably for the same reason, 11 when tokenisation fails, so does accent recognition. See, i.e., line 5 of Figure 1, where instead of μὴ νεκροὺς (transl.: not the dead) HTR recognises μὴν ἐκροὺς (meaningless) and so adds the smooth breathing diacritical mark above the letter ε. This diacritics addition is an interesting mistake; according to ancient Greek grammar, when a word begins with the letter ε, it commonly has the smooth breathing mark. Other times, accent recognition rightfully fails because accents are already misplaced in the manuscripts. For instance, cf. Figure 2 and line 3 of Figure 1, where the grave accent of the adjective πολὺς is not recognised since it is misplaced above the last character, the consonant ς. Such instances, should not be considered as HTR errors. It should also be mentioned that accent misrecognition might be negatively affected by the non-expansion of the line region to the upper margin (see Figure 2; the line region is depicted with the blue rectangle and baseline with the purple underline). Following Transkribus guidelines regarding the higher importance of baseline region (i.e., the imaginary horizontal line on which text characters rest) in HTR results [Muehlberger et al., 2019, p. 959], 12 adjustments were made only on the relevant baselines in all mentioned experiments. This inaction on line-region adjustment proves to be a limitation and should be corrected in future experiments. Moreover, not all manuscripts consist of a baseline. In rare cases, letters are written from a hanging line instead, a feature that can be challenging for the HTR system -cf. Figure 3 and [START_REF] Perdiki | Handling Big Manuscript Data[END_REF]. Such errors, as mentioned above, can be easily cleaned to lower CER significantly. Moreover, despite successful OCR demands of above 90% accuracy [START_REF] Holley | How good can it get? Analysing and improving OCR accuracy in large scale historic newspaper digitisation programs[END_REF]Clérice 2022a], the complex peculiarities of HTR allow for a lower level of accuracy, especially if we consider that keyword spotting techniques return accurate results even with a 30% CER [Muehlberger et al., 2019, p. 963;[START_REF] Tomoiaga | Field typing for improved recognition on heterogeneous handwritten forms[END_REF][START_REF] Stokes | The eScriptorium VRE for Manuscript Cultures[END_REF][START_REF] Ströbel | Evaluation of HTR models without Ground Truth Material[END_REF]. Consequently, aiming for better HTR results, a maximum 20% CER threshold was initially decided -as a hypothesis -for a model to be deemed adequately accurate (i.e., to serve as data for text clustering). 13 That being said, it should be pointed out that this threshold must be set upon firm grounds, so the author's current benchmarking experiments with HTR results (unpublished for the moment) are adapting a different methodology to test the limits of such a metric accurately. Tests include HTR-produced text normalization by eliminating accents, brake lines (i.e., in hyphenated words), and even data contamination (i.e., combining HTR and manual transcriptions' data to reduce/increase CER percentage). Although important in evaluation [Sánchez et al., 2019, p. 124;[START_REF] Kang | Pay attention to what you read: Non-recurrent handwritten text-Line recognition[END_REF], using WER (Word Error Rate) instead of CER was ruled out due to the errors described in the previous section (i.e., despite being a single erroneous character, a falsely recognised accent can lead to a WER, but such inaccuracies seem irrelevant as they can be normalised). Lastly, previous research concluded that, although AI machine learning algorithms require a quantum of data to be effective, there is certainly a limit to the data set volume or the training epochs number to avoid overfitting [START_REF] Rabus | Recognizing handwritten text in Slavic manuscripts: A neural-network approach using Transkribus[END_REF][START_REF] Ströbel | How Much Data Do You Need? About the Creation of a Ground Truth for Black Letter and the Effectiveness of Neural OCR[END_REF][START_REF] Perdiki | Handling Big Manuscript Data[END_REF].

IV RESULTS

Upon these three criteria, experiments were conducted under four main methods and mainly under the same system configurations (reported in Table 1). The four methods did not share the same objective. The first's methods objective was to determine the minimum amount of required training data (with a hypothesis of a 20% CER threshold). The second method aimed both to validate the HTR model with unseen data and test the possibility of revealing scripts' similarity. On the other hand, to achieve better performance with less data, the third method's main objective was the contamination of training data. In addition to that, in the fourth experiment stage, aiming at the optimum performance, comparing the two HTR training methods (HTR+ and PyLaia) provided by Transkribus, a different training set of the same manuscripts was used to train HTR models via PyLaia.

Particularly, the first method was HTR model training with gradual data set reduction to define the minimum amount of data needed to produce usable results. As depicted in Figure 4, 24 models were trained (via CITlab HTR+ method) from 8 different manuscripts (three models per manuscript), 14 with a decreasing number of words: transcription input of ~3,000, ~2,000 and ~1,000 words from John Chrysostom's 1 st Homily, with a minimum of 50 epochs of each training set. A 10% portion of the data input was reserved in each training set as validation data. Most models performed below the 20% CER threshold, even under the low 1,000-word input test. The few exceptions of poor recognition results overlapped with some low-quality manuscript digitisations. Usually, the breaking point of the model training was around 5-10 epochs. 14 Two manuscripts of the dataset, E and W, were excluded from this testing due to their insufficient number of words. 15 In most cases, the number of epochs was set up to 50. This fixed choice was an attempt to standardise configurations so as to clarify which factors affect the HTR performance, i.e., the number of training data, the number of epochs, the quality of the image data or otherwise. 16 The early stopping technique is not applicable in the HTR+ method (the system of choice for the majority of the experiments). PyLaia, on the contrary, does provide that option, so early stopping was set to the predefined number of 20. Since Transkribus had announced that HTR+ would not be supported any further than November 2022, the exploitation of both systems was decided as a form of systems performance comparison. See, https://readcoop.eu/glossary/htr-plus/ (Accessed: 24 February 2023). With the aim of testing script similarity out of text recognition and limiting the manual production of data input even further, a cyclical application of each trained model to 10 manuscripts was performed (some of these manuscripts were palaeographically similar in style). The experiment hypothesis of this method was whether an already trained model could accurately recognise the text of a different but similar writing style manuscript. This process would also serve as a manuscript clustering method if proven successful. However, as seen in Figure 5, the resulting 90 text recognitions were mainly inaccurate. Only 9 out of 90 combinations recovered text with a lower than 20% CER, despite exploiting the 3,000-word input training sets. Prior to the results, it was uncertain whether the given manuscripts' combinations would reflect the models' optimum performance. As a result, clustering algorithms that would predict script similarity seem necessary (cf. [START_REF] Stutzmann | Clustering of medieval scripts through computer image analysis: Towards an evaluation protocol[END_REF]). The third method of experimenting with HTR extended the second method's hypothesis. If one mixes training data from more than one manuscript, as a corpus expansion process, the data set will be enlarged without demanding extra manual input. So, a hypothesis was made to test whether this would result in mixed models of high accuracy. Furthermore, combining all transcriptions in a single training set would test the possibility of building an optimum model capable of accurately transcribing any of our Greek manuscripts. The nine best matches, produced under the second method experiments, served as the data for the manuscripts' combinations. The data set was formed out of randomly selected pages from each manuscript. These combined data consisted of ~2,000-word input transcription per combination. Each model was trained with 50 epochs via the CITlab HTR+ method. The validation set was formed out of a random 10% of the training data. Afterwards, the trained mixed models were applied to each of the training set's manuscripts, as in Figure 6 (i.e., the Q&L model was trained from Q and L manuscripts' combined data and then applied to each for text recognition). These models performed at 80% accuracy, within threshold limits, with a breaking point around 5-10 epochs.17 Lastly, a 9,000-word input from all 10 joined manuscripts, trained on 50 epochs and CITlab HTR+ method, validated from a random 10% of the data, and applied to every single manuscript, resulted in top-end CER performance (down to 4,48%, see Figure 6). The fourth and last methodology on HTR experiments via the Transkribus platform came as validation. With the same data set of the 11 manuscripts mentioned above and under the same methodology, the most successful of the above experiments (the first and third method) was performed on a different training set (John Chrysostom's 5 th Homily transcription) in two testing phases. Firstly, the training set consisted of ~3,000-word input and the HTR method was altered to PyLaia with 250 epochs. The validation set was a random 10% portion of the training data. The resulting CER was lower than 10% (breaking point on 20-30 epochs), yet higher compared to previous experiments with the HTR+ method and 50 epochs of training.

In addition to the CITlab HTR+ method's better performance, it appears that, with insufficient data, a higher epoch number returns the worst results, as already shown by Rabus [START_REF] Rabus | Recognizing handwritten text in Slavic manuscripts: A neural-network approach using Transkribus[END_REF]. Secondly, another attempt was made to build a general model, as all manuscripts are characterised by a certain (perceived) script uniformity and clarity (none of the manuscripts was heavy in ligatures, abbreviations, or damaged areas), however unique in writing style. By joining up the 5 th Homily's transcriptions (from 9 out of the 11 manuscripts), a 25,621-word input trained the general model. This training results in a 4.60% CER. In an attempt to further expand the data of the experiments, fine-tune this general model, and improve, thus, the recognition results, the model with the best performance18 -during phase 1 of the fourth method experiments-was added to the training process as a base model. The final CER on that last experiment was 3.90% on the validation set (at 3-10 epochs range breaking point), the minimum CER of all conducted experiments (see Table 2). Expanding upon the last two experiments (the last part of method 3 and method 4), it is important to emphasise the significance of general models. The aforementioned experiments have shown that even with a minimal data set one could easily provide the initial impulse for the training of a larger and more accurate HTR model. The 20% CER threshold needs yet to be proven as a sufficient amount of HTR-produced errors. If not, however, general models (despite their limits) would be an effective technique for fast and clean text extraction, regardless of the writing style.

Limitations

The end-all of the conducted experiments was to determine the minimum amount of data needed to produce an accurate transcription and to deliver data usable in text clustering. The hierarchical clustering ought not to be a detailed collation as stemmatological analysis is out of the scope of this research. Currently, experiments conducted by the author with data mining techniques are examining promising preliminary results for the task. However, data quality evaluation22 for text clustering needs to be further fine-tuned, by eliminating text noise. More often than not, HTR erroneous results include forced-hyphenated words in brake lines (without a hyphen symbol though), false accents (which do not result in semantic shift), or tokens concatenation due to the scripta continua. Such instances need to be automatically normalised,23 before proceeding to clustering algorithms.

As pointed out previously in this paper, the metrics used in our experiments should be further adjusted. While the 20% CER threshold remains to be proved for ensuring successful text clustering of automated transcriptions, benchmarking experiments have the potential to refine the required accuracy. Furthermore, the uneven distribution of errors on each page probably affects the erroneous HTR results, which should also be accounted for in future testing. More than that, the low number of input data equals insufficient data on the validation set. These experiments produce seemingly unexpected results. In other words, since our case study was a limit test, traditional metrics cannot always be applied. We seek to find more suitable evaluation techniques as we continue our experiments.

The aforementioned dual approach to early stopping (none for HTR+ and 20 for the PyLaia method) might prove to be a limitation on our results. As already explained, both systems were used to compare performance fairly. Nevertheless, since early stopping is not available for the HTR+ training, perhaps the reasonable choice would be to nullify PyLaia early stopping. The system's configurations need further improvement on the matter.

V CONCLUSION

Computational processes can highly assist philological research when dealing with a bulk of data. Time-consuming and painstaking tasks, often leading to errors due to their complexity, produce fruitful results when conducted via special algorithms. This paper presented methodologies for exploiting a specific HTR tool to enhance manuscript tradition research.

The Transkribus platform proved highly efficient in training HTR models and recognising text from digitised manuscripts. Even with minimal training data input, the accuracy of the produced models was high (cf. first experiment). With further testing and fine-tuning, developing general models that could transcribe a good portion of Greek manuscripts is more than possible. The two main conclusions of the previous experiments were: a) HTR models perform worse on unseen data, so including training data from more than one writing style is crucial (cf. experiments two and three), and b) one can produce successful HTR models with low CER percentage simply by combining small datasets of many handwriting instances (cf.

experiments three and four). Mass transcription from historical documents can fuel the research with much-needed data. Ongoing author's experiments are testing whether it is possible to perform algorithmic hierarchical clustering, through data mining techniques, even with some inaccuracy in HTR results.

Indeed, machine learning benefits from data plethora, but sometimes data can be expandedrather than produced from zero -and so training can produce functioning results. According to the research questions, humans can evaluate the process and fine-tune algorithms to high performance. By outsourcing tedious and prone to errors tasks to computing power and accuracy, researchers can concentrate on more analytical quests and lead the way forward.

Datasets and Models

Figure 1 .

 1 Figure 1. Highlighted in red rectangles are instances of HTR errors (at a normalised segmentation) due to scripta continua. I.e., line 21 depicts how tokens ἀλλὰ τί (transl.: but what) are falsely recognised as the single (meaningless) token ἀλλατι. Manuscript: NLG Athens 263, f. 158v.

Figure 2 .

 2 Figure 2. An instance of erroneous accent recognition. The depicted text should be transcribed as πολὺς ὁ γογγυσμός. For the HTR prediction cf. Figure 1, line 3. Manuscript: NLG Athens 263, f. 158v.

Figure 3 .

 3 Figure 3. An instance of a (HTR-challenging) hanging line, as recognised in Transkribus automatic segmentation. The HTR correctly recognises the line's dependent traces but, expecting a baseline, it rotates the page upside-down.

Figure 4 .

 4 Figure 4. CER results of decreasing training data (number of words of manually generated training data), as in [Perdiki and Konstantinidou, 2021].

Figure 5 .

 5 Figure 5. Cyclic application of each model to all manuscripts, as in [Perdiki and Konstantinidou, 2021]. The combination of identical letters (e.g., Q & Q) reflects model performance on the training data manuscript.

Figure 6 .

 6 Figure 6. CER of models with mixed training sets, as in [Perdiki and Konstantinidou, 2021].

Table 1 .

 1 System configurations for all experiments

		Training Set	Validation	Epochs 15 Early	Base	Training
		(words)	Set		Stopping 16	model	system
	Single models I	3,000	10%	50	N/A	No	HTR+
		2,000	10%	50	N/A	No	HTR+
		1,000	10%	50	N/A	No	HTR+
	Mixed models	2,000	10%	50	N/A	No	HTR+
	General model I	9,000	10%	50	N/A	Yes	HTR+
	Single models II	3,000	10%	50	20	No	PyLaia
		3,000	10%	250	20	No	PyLaia
	General model II	25,621	10%	50	20	Yes	PyLaia
		25,621	10%	250	20	Yes	PyLaia

Table 2 .

 2 CER of 50 and 250 epochs models.

	Training Data	Model Name	50 epochs CER	250 epochs CER
			(HTR+)	(PyLaia)
	Q: Athos, Dionysiou 70	Q-3000 19	11.62%	14.41%
	H: Athos, Vatopedi 328	H-3000	10.03%	13.70%
	A: Athens, Nat. Libr. 263	A-3000	10.03%	12.20%
	I: Alexandria, Patr. Libr. 34	I-3000	13.00%	14.60%
	D: Venice, ONB theol. gr.14	D-3000	(n/a) 20	14.20%
	E: Paris, Bibl. Nat., Gr. 745	E-3000	(n/a)	14.90%
	K: Munich, Gr. 377	K-3000	8.93%	12.30%
	L: Munich, Gr. 353	L-3000	8.12%	13.00%
	General Model (without a base model)	GM	17.18%	4.60%
	General Model (with a base model)	GMbm	(n/a) 21	3.90%

  Perdiki, E. (2023). List of manuscripts containing John Chrysostom's Homilies and the relevant manual transcriptions (1.2) [Data set]. Zenodo. https://doi.org/10.5281/zenodo.8102662 Perdiki, E. (forthcoming). HTR model 'Chrysostomicus I' (ID 44872). Transkribus.

http://jdmdh.episciences.org

https://web.archive.org/web/20220125061256/https:/github.com/tesseract-ocr/tesseract (Accessed: 20 October 2022). Nevertheless, there are also some voices of opposition regarding the results of Tesseract compared to similar systems, as stated in[START_REF] Smith | An Overview of the Tesseract OCR Engine[END_REF].

http://kraken.re/ (Accessed: 18 September 2020).

http://web.archive.org/web/20211113063459/https:/readcoop.eu/transkribus/download/ (Accessed: 19 July 2022).

http://web.archive.org/web/20220119164148/https:/transkribus.eu/lite/ (Accessed: 19 July 2022).

An HTR application for Byzantine manuscripts was described by[START_REF] Tsochatzidis | HTR for Greek Historical Handwritten Documents[END_REF], but it is currently unavailable to the public.

Of course, this percentage of error rate is not an ideal aim for HTR performance. Yet, it is a cost-efficient choice in order to balance low input data and high output accuracy.

Journal of Data Mining and Digital Humanitieshttp://jdmdh.episciences.org

The poor performance of the Q & L model, when applied to the L manuscript, has yet to be fully explained. Apart from the writing style, the only difference between the two manuscripts was that Q's data set was coloured digitisation, whereas L's was grey-scaled microfilm digitisation. However, that was also the case with the K manuscript, yet the relevant CERs returned under 20%. On the other hand, E's bad score is probably due to the insufficient amount of data and the poor image quality; this particular manuscript had a missing folio which drastically affected the HTR results (because of the missing word tokens). Its inclusion in the data set was deliberate to test the degree of effect such manuscript damages might have on our methodology.

In terms of CER percentage -i.e., the best model is considered the one with the lowest CER in the same textual data, but in a different manuscript (which means a different writing style).

The "3000" tag indicates the amount of word input on the training data set.

Manuscripts D and E were excluded from the 50 epochs training due to insufficient training data.

No base model was used during the general model's training via the HTR+ method.

A method proposed by Thibault Clérice[Clérice, 2022a] suggests using language models on sentences instead of n-grams to assess the quality of Character Error Rate (CER) in line-level classification systems. While this method has been employed for Kraken-trained models (an OCR system), it shows promise for efficiently processing large HTR datasets, particularly with previously unseen textual material.

Regarding the automatic correction of HTR-produced errors, see the work of[START_REF] Pavlopoulos | Error Correcting HTR'ed Byzantine Text, 15[END_REF].