<table><tr><td>2.1.3. Réunions scientifiques internes (équipe projet, partenaires)</td><td>Durée du projet scientifique + 5 ans</td><td>C</td><td></td></tr><tr><td>Ordre du jour, compte rendu de réunion et documents afférents, programme, support de présentation (texte, slide, vidéo...).</td><td></td><td></td><td>Il s'agit de tout type de données (issues de fouilles archéologiques, d'une enquête sociologique, historique, géographique...) quelles que soient leurs formes (textes, images, sons...) et leurs supports. Lorsqu'il y a obligation de gestion des archives intermédiaires au sein d'un autre service, les documents/données ne sont pas pris en compte (par exemple, pour l'archéologie, les services régionaux de l'archéologie, l'Ecole française d'Athènes...). Conserver la version achevée des documents. Certaines versions préparatoires peuvent être conservées en fonction de l'expertise du chercheur. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé.</td></tr><tr><td>2.2. Collecte et analyse de documents/données</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td></td></tr><tr><td>Carnet/cahier/journal de terrain, notes d'enquête, notes d'entretien, transcription d'entretien oral, guide d'entretien, questionnaire, fichier d'enregistrement, fiches individuelles, inventaire, document graphique (relevé de terrain, plan, coupe, restitution, dessin d'objet...), document cartographique, photographie, photographie aérienne, image satellitaire, modèle 3D, base de données, système d'information géographique, enregistrement sonore, produit audiovisuel et multimédia (film, vidéo...), échantillons, moulages, maquettes, rapport d'analyse, étude préliminaire, transcription et traduction de textes, guide/note méthodologique, documentation, programme de travail, notes, courriel.</td><td></td><td></td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, courriel : conserver les documents les plus significatifs.</td></tr><tr><td>2.3. Préparation de publication (ouvrages, article, compte rendu...)</td><td>Durée de la préparation + 5 ans</td><td>T</td><td></td></tr><tr><td>Texte préliminaire, illustration originale, épreuves, documentation préparatoire, compte rendu de réunion et documents afférents, vidéo de visioconférence, convention de collaboration, contrat de recherche, avis des rapporteurs, lettre, courriel.</td><td></td><td></td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, courriel : conserver les documents les plus significatifs.</td></tr><tr><td>2.4. Congrès, colloque, journée d'étude (organisation ou participation)</td><td>10 ans</td><td>T</td><td></td></tr><tr><td>Support de communication (texte/illustration, slide, vidéo...), résumé, texte et illustration préliminaires des actes, épreuves, poster scientifique, affiche, plaquette, documentation, documents d'organisation (programme, circulaire, résumés des communications...), ordre du jour, compte rendu de réunion et documents afférents, lettre, courriel, copies de documents relatifs à la gestion financière et aux missions.</td><td></td><td></td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, lettres, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions.</td></tr><tr><td>2.5. Sites Web (carnets de recherche, blogs...)</td><td>Validité</td><td>D</td><td></td></tr><tr><td>Texte de projet, cahier des charges, compte rendu de réunion, texte et illustration préparatoires, courriel.</td><td></td><td></td><td>Depuis 2006, la BNF assurer le dépôt légal de l'internet français.</td></tr></table>
<table>
  <tr>
    <td>2.6. Documentation<br>Photographies, dessins, cartes, enregistrements sonores, produit audiovisuel et multimédia, publications électroniques ou papier, rapport, notes de travail, notes de lecture, courriel, lettre, photothèque, collections de cartes, plans, dessins, collections de référence ou de comparaison (objet fabriqué), base de données.</td>
    <td>Durée d'exploitation + 5 ans</td>
    <td></td>
    <td>Conserver les documents selon l'intérêt. Seule la version finale de la base de données sera conservée. Publications : conserver seulement les textes lorsqu'ils participent à la cohérence scientifique d'un dossier contenant d'autres documents.</td>
  </tr>
  <tr>
    <td>2.7. Médiation scientifique<br>(Exposition, conférence, atelier grand public, émission de radio, émission de télévision, produit pédagogique...) Produit audiovisuel et multimédia (film, vidéo...), podcast, site Web, support de communication (catalogue, livret, programme, affiche, slides de présentation, vidéo...), poster, rushes, master, autorisation, invitation, documentation, courriel, document financier et de mission (copies).</td>
    <td>Durée du projet + 5 ans</td>
    <td>T</td>
    <td>Documentation, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé. Les podcasts et sites Web ne sont pas pris en compte.</td>
  </tr>
  <tr>
    <td>2.8. Correspondance<br>boîte aux lettres électronique, lettre.</td>
    <td>10 ans</td>
    <td>T</td>
    <td>Le tri porte sur les courriels : conserver les courriels et pièces jointes selon l'intérêt. Détruire les courriels privés.</td>
  </tr>
  <tr>
    <td>2.9. Enseignement et formation<br>2.9.1. Enseignement dispensé<br>Programme, support de cours (texte/illustration, slide, vidéo...) et documents afférents, plaquette pédagogique, documentation, notes, lettre, courriel.</td>
    <td>10 ans</td>
    <td>T</td>
    <td>Le tri porte sur la documentation, les notes, lettres et courriels : conserver selon l'intérêt.</td>
  </tr>
  <tr>
    <td>2.9.2. Direction et suivi de travaux d'étudiants<br>Travaux d'étudiants (thèses, mémoires), rapport (sur les mémoires et sur les soutenances), procès-verbal de soutenance, convocations, courriel, lettres, notes.</td>
    <td>10 ans</td>
    <td>T</td>
    <td>Travaux d'étudiants : les thèses sont archivées par le CINES (Arrêté du 25 mai 2016 fixant le cadre national de la formation et les modalités conduisant à la délivrance du diplôme national de doctorat, titre IV, art. 24-25). Les mémoires (master 1 et 2) sont archivés par les universités. Toutefois, certains documents peuvent être versés en fonction de l'expertise du chercheur et de leur apport au fonds. D pour les autres documents qui sont gérés par les universités.</td>
  </tr>
  <tr>
    <td>2.9.3. Accueil de chercheurs et de stagiaires<br>Dossier de chercheur invité (candidature (copie), projet de recherche, attestation (copie), rapport scientifique, lettre,</td>
    <td>10 ans</td>
    <td>T</td>
    <td>Conserver les documents scientifiques en fonction de l'expertise du chercheur. Détruire les candidatures, conventions, attestations,</td>
  </tr>
</table>
courriel.

Dossier de stagiaire (convention de stage
(copie), rapport de stage).

lettres, courriels.

The precise data selection and archiving process will be developed in close collaboration with the archives department of MSH Mondes, which has already been contacted.

**Estimated volume of data** 20

**Unit** GB

**Start date**

**End date**

**Final dispositions**

# Social Network Analysis_WP3

## Data description and collection or re-use of existing data

### Research output description

**Name** Social Network Analysis_WP3

**Description** The primary research output of WP3 will be a series of datasets and analytical results derived from Social Network Analysis (SNA) applied to technological traditions across archaeological sites. In this context, nodes will represent distinct technological traditions identified at specific sites, while edges will quantify the degree of similarity between them based on shared features, operational sequences, or production choices. The resulting networks will reveal patterns of technological convergence, divergence, and possible knowledge transmission routes. Outputs will include node and edge lists, network metrics (e.g., modularity, centrality, clustering), and visualizations of the structural relationships within and between traditions. All data will be stored in interoperable formats such as CSV and GraphML, accompanied by comprehensive metadata and documentation to ensure clarity, reusability, and integration with broader project datasets.

**Type** Dataset

**Workpackage** WP3

**Keywords (free-text)** Social Network Analysis

**Language** eng

**Issued Date**

**May contain personal data?** No

### Will existing data be reused?

**Justification** No reused of existing data

### How new data will be collected or produced?
<table><tr><td>Name of the method</td><td>Social Network Analysis</td></tr><tr><td>Description</td><td>The Social Network Analysis in WP3 will be based on derived data produced through prior technological analysis of lithic assemblages (as described in WP2). The method used for data production in WP3 is relational abstraction and similarity quantification, where technical traditions—identified per site—are compared based on a set of standardized analytical variables (e.g., core reduction strategies, tool morphologies, chaîne opératoire characteristics). The output of this process is a similarity matrix, which serves as the basis for constructing a weighted network in which nodes represent technical traditions and edges indicate degrees of technological similarity. This derived dataset is generated through comparative coding, normalization of variables, and computational calculation of similarity indices (e.g., Jaccard, cosine similarity, or custom domain-specific measures), using the statistical programming language R. R will also be used for network construction, visualization, and the computation of structural metrics, ensuring reproducibility and flexibility in analytical workflows.</td></tr><tr><td>Data Nature</td><td>Analysis data</td></tr><tr><td>Costs</td><td>• Personnel cost: 60 000 EUR</td></tr></table>

## Documentation and data quality

**What metadata and documentation (for example way of organising data) will accompany the data?**

<table><tr><td>Description</td><td>Data produced in WP3 will be organized using standardized formats and structured to ensure clarity, interoperability, and reusability. The core dataset—consisting of node and edge lists, similarity matrices, and computed network metrics—will be stored in open, machine-readable formats such as CSV and GraphML. Each dataset will be accompanied by detailed metadata, in English, including definitions of variables, methods used for similarity calculation, criteria for node and edge inclusion, and any preprocessing or normalization steps applied. Metadata will follow established standards such as the Dublin Core and Data Documentation Initiative (DDI) where applicable. All data files will be version-controlled, consistently named, and documented with a data dictionary, which explains each field, value range, and coding scheme. In addition, a methodological README file will accompany each dataset, outlining the data generation process, software environments (e.g., R version and packages used), and key analytical decisions to ensure transparency and reproducibility.</td></tr><tr><td>Metadata/data standards</td><td>• Dublin Core: https://rdamsc.bath.ac.uk/api2/m15</td></tr><tr><td>Metadata language code</td><td>eng</td></tr></table>

**What methods will be used to ensure their scientific quality?**

<table><tr><td>Description</td><td>To ensure the reliability and validity of the data used in WP3, several quality control procedures will be applied throughout the process of data preparation and analysis. First, input data derived from the technological analysis (WP2) will be cross-checked for consistency and completeness before being used to construct the similarity matrix. During data processing, all calculations of similarity scores and network metrics will be performed using scripted procedures in R, allowing for full reproducibility and reducing the risk of manual errors. Scripts will be version-controlled and peer-reviewed within the research team. Outliers and anomalies in the data (e.g., unexpected similarity scores or disconnected nodes) will be flagged and reviewed to ensure they reflect actual patterns rather than data entry or coding errors. Additionally, results from network analyses will be validated by comparing outputs under varying methodological parameters (e.g., different similarity thresholds) to assess their robustness. Full documentation of these procedures will be maintained and stored alongside the datasets for future auditability.</td></tr></table>
# Legal and ethical requirements, codes of conduct

## How will other legal issues, such as intellectual property rights and ownership, be managed? What legislation is applicable?

**Description**
The project data are public archives within the meaning of the Code du patrimoine, article L211-4. This status was reiterated by the directive issued by CNRS and Archives de France in 2007 (Instruction No. DAF/DPACI/RES/2007/002 of January 15, 2007. Traitement et conservation des archives des délégations du CNRS et des archives des unités de recherche et de service). Public archives are freely accessible, except for information subject to communication deadlines defined by the Code du patrimoine, in article L.213-2.
The disclosure, reuse, and dissemination of public archives that qualify as a work of the mind, as defined by the Code de la propriété intellectuelle, are regulated by the same code. Researchers and teacher-researchers, as public servants, retain their intellectual property rights (article L.111-1 of the Code de la propriété intellectuelle).

## What ethical issues and codes of conduct are there, and how will they be taken into account?

**Description**
The Code de la recherche establishes a link between scientific integrity and the preservation of scientific data, in accordance with the Code du patrimoine. In the long term, the archives department of the MSH Mondes will be responsible for the preservation and regulatory communication of the data, in line with the provisions set out in both codes.

# Data processing and analysis

## How and with what resources will the data be processed / analyzed?

**Description**
Data processing in WP3 will involve transforming the results of lithic technological analysis (WP2) into structured datasets suitable for Social Network Analysis. This will begin with the coding and normalization of technological variables across sites to ensure comparability. These variables will then be used to compute pairwise similarity scores between technical traditions using statistical methods implemented in R, employing functions from packages such as stats, proxy, or custom scripts. The resulting similarity matrix will be converted into a weighted edge list, which will then serve as the foundation for constructing network graphs using tools like igraph or tidygraph. Further processing will include the calculation of network metrics (e.g., degree, betweenness, modularity), filtering of weak ties or noise, and preparation of visualizations for interpretation. All processing steps will be fully documented in annotated R scripts to ensure transparency, reproducibility, and version control, with accompanying metadata describing variable transformations, thresholds applied, and decisions made during analysis.

# Storage and backup during the research process

## How will data be stored and backed up during the research?

**Storage needs**
During the project, data will be stored and backed up in multiple secure environments to ensure both accessibility and protection against loss:
* **Primary Storage:** Data will be stored on the professional, institutionally managed computer of **Solène Denis**, with access restricted to authorized project personnel.

* **Secondary Backup:** A monthly backup of project data will be saved to a dedicated external hard drive maintained by the project team.

The project's shared workspace on RESANA (a secure platform provided by the French Direction Interministérielle du Numérique - DINUM) will serve as an additional storage and collaboration space. Résana hosts data on nationally managed secured servers, ensuring institutional compliance and reliability.

A ShareDoc (CNRS IN2P3) project-specific file manager for MOBILITH will be set up, with weekly backups, providing robust redundancy and automated version control.

The use of at least three independent storage spaces - local, institutional online, and external managed backup - ensures the ability to recover data in the event of hardware failure, accidental deletion, or other incidents. In case of data loss or corruption, the most recent backup from ShareDoc or the external drive will be restored, with coordination from institutional IT support if needed.

Access to project data during the research phase will be restricted to MOBILITH project members and designated external experts. Controlled access is managed through institutional credentials for Résana and ShareDoc platforms. FileSender, the institutional secure file transfer service, will be used for any sensitive file exchanges between partners, ensuring encrypted transmission.

While the project does not involve highly sensitive personal data, appropriate data protection measures will be observed. In cases where potentially sensitive information is handled (e.g., site locations or unpublished archaeological findings), access will be limited, and data will be pseudonymized or aggregated as appropriate.

Data management and protection practices will comply with institutional and national policies, in alignment with GDPR and best practices for handling research data securely.

Perennial archiving costs are covered by the MSH Mondes archive service (CNRS servers) and, for definitive archiving, by the French National Archives and the Centre informatique national de l'enseignement supérieur (CINES), under the supervision of the Ministry of Higher Education.

The cost of storing and sharing the data that will be made public will be borne by the institutions for which the project participants work (data on portable PCs, by the IR* Huma-Num (storage on Sharedocs and dissemination via the SHS Nakala data warehouse), under the supervision of the CNRS, Aix Marseille University and the Condorcet campus, by the French government's Direction du Numérique (document sharing via the Resana collaborative platform), by CERN for the Zenodo generalist warehouse, and by the Centre de la Communication Scientifique Directe (CCSD) under the supervision of CNRS, INRIA and INRAE for the distribution of open access publications.

Processing will be carried out by those responsible for the research products, using tools already funded by the institutions (e.g. Excel) or free open-source tools such as OpenRefine and Calc, or QGIS.

**Estimated volume of data** 10

**Unit** MB

**Measures taken for data security**

Data security will be ensured through a combination of physical, digital, and procedural safeguards. All digital data will be stored on secure, institutionally managed servers with regular automated backups and controlled access based on user roles (see below). Sensitive or unpublished data will be protected by password-restricted folders, and encryption will be used when transferring data between devices or collaborators.

**Resana :**

Resana is hosted in Outscale's SecNumCloud 3DS in data centres in France. The operator is responsible for the availability of the service and for maintaining it in operational and security condition. The integrity and confidentiality of the information circulating are ensured by encryption mechanisms (HTTPS protocol). RESANA is not considered a "critical" service, in the sense of continuity of government action. In nominal mode, the service is available 24/7/365. However, it may be interrupted in the event of a technical incident or maintenance operation. DINUM aims to guarantee a maximum downtime of 4 hours and a maximum data loss time of 24 hours. RESANA is an information system that has been security-approved (RGS) by the qualified authority (Interministerial Digital Directorate) for the sharing of standard data. The information system takes into account the needs of confidentiality, integrity and availability of the service. All content uploaded to the platform is encrypted (AES 128 bit) and hosted on the Outscale SecNumCloud 3DS with 24/7 facilities management. However, its use is not authorised to convey sensitive information or information marked "Restricted Distribution", in accordance with II901 (NOR: PRMD1503279J).

Cf : https://resana.numerique.gouv.fr/public/utilisateur/afficherPageConnexionAnnexe? page=apropos

**Sharedocs :**
ShareDocs is a file manager implemented by IR\* Huma-Num, on its own servers, which can be
used via a web browser, a WebDAV client or file synchronisation software. The platform is based
on the FileRun application. It provides remote online storage on the French research network
(similar to tools such as DropBox, which are hosted on the public cloud). Hosted data can be
easily encrypted using tools such as ZED encrypt.

ShareDocs is designed for research projects that want to store, exchange, share and work on file-type data (sets of photos, transcribed texts, etc.). For example, ShareDocs can be used to prepare files for online publishing or for distribution in NAKALA.

A ShareDocs project account facilitates data sharing and collaborative work between several members of a project or research team in the social sciences and humanities. The project account is adapted to collaboration via collaborative editing and file versioning tools, as the project account is accessible to several members of a team (unlike an individual account). It allows the creation of a tree structure of folders and it is necessary to define access and editing rights in detail, as soon as they have been created and for a list of identified collaborators. The principle is to create a folder and file tree when a project account is opened, and then to grant different access and editing rights depending on the role of each team member.

For the 2023-2025 forecasts, the volume of a project account is 300 GB of storage.

A project account can only be accessed by a list of people who have been declared and
registered with Huma-Num by the project account manager.

The data stored on Sharedocs is hosted and backed up at the IN2P3 computing centre in Lyon, on Huma-Num servers. In the event of data loss, Huma-Num assures us that it will be possible to contact their helpdesk to recover it, via one of its backups.

https://documentation.huma-num.fr/sharedocs-stockage/

-

## Nakala :

The data deposited in NAKALA is stored on servers managed by Huma-Num and hosted at the IN2P3 computing centre. This centre was set up to manage data produced in particle physics, nuclear physics and astroparticle physics.

This major national centre is secure from a hardware point of view (e.g. redundant power
supply, network devices, cooling systems).

NAKALA data is stored on a NAS-type network storage device. A snapshot of the data is taken at regular intervals, enabling data to be restored quickly in the event of problems. In addition, a tape backup is made daily on the CCIN2P3 backup robot using TSM software published by IBM. NAKALA's metadata are stored in a SQL database (MariaDB) which is backed up daily on Huma-Num's infrastructure. The metadata is also exposed in RDF format via a Triple-Store (GraphDB) which is also backed up daily on the Huma-Num infrastructure. Continuity of the NAKALA¶ service

The NAKALA service is hosted on the Huma-Num infrastructure, which has a general disaster recovery plan. More specifically, the redundancy of the NAKALA service is ensured by :

- the NAKALA application is redundant on two different machines using a distribution tool (HAProxy), which avoids service interruptions in the event of a breakdown;

- the data is stored on a NAS-type device, so that data can be restored quickly. In addition, backups are made on magnetic tapes on a daily basis;

- Metadata is stored in a 'classic' relational database, which is backed up daily. This metadata is also stored in RDF format in a Triple-Store, which is backed up daily.

Source : https://documentation.huma-num.fr/nakala-faq/#comment-sont-sauvegardees-les-donnees

## Zenodo :

Zenodo is powered by CERN Data Centre and the InvenioRDM and is fully run on open source products all the way through.

Physically, Zenodo's entire technical infrastructure is located on CERN's premises which is subject to CERN's legal status (see above).

Zenodo servers are managed via OpenShift which itself runs on top of CERN's private cloud which is using OpenStack and Puppet configuration management system. Servers are monitored via CERN's monitoring infrastructure based on Logstash, OpenSearch, and Hadoop. Application errors are logged and aggregated in a local Sentry instance. Traffic to Zenodo frontend servers is load balanced via a combination of DNS load balancing and HAProxy load balancers.

Zenod I running on three independent systems: one production system, one quality assurance
system, and one development system. This ensures that all changes, whether at infrastructure
level or source code level, can be tested and validated on the quality assurance system prior to
being applied to our production system. Zenodo frontend servers are responsible for running
the InvenioRDM repository platform application which is based on Python and the Flask web
development framework. The frontend servers are running nginx HTTP server and uwsgi
application server in front of the application and nginx is in addition in charge of serving static
content. All files uploaded to Zenodo are stored in CERN's EOS service in an 5 petabytes disk
cluster. Each file copy has two replicas located on different disk servers. A daily incremental
backup is performed of the EOS storage cluster into a Ceph storage cluster located in a
different geographical location (~3.5 km apart). The backup retention policy keeps the last 7
daily backups, last 5 weekly backups and last 6 monthly backups. For each file we store two independent MD5 checksums. One checksum is stored by Invenio, and used to detect changes to files made from outside of Invenio. The other checksum is stored by EOS, and used for automatic detection and recovery of file corruption on disks. EOS is the primary low latency storage infrastructure for physics data from the Large Hadron Collider (LHC) and CERN currently operates multiple instances totalling 1+ exabyte of data. Metadata and persistent identifiers in Zenodo are stored in a PostgreSQL instance (with a master-slave setup) operated on CERN's Database on Demand infrastructure with 24-hourly backup cycle with one backup sent to tape storage once a week. Metadata is in addition indexed in an OpenSearch cluster for fast and powerful searching. Metadata is stored in JSON format in PostgreSQL in a structure described by versioned JSONSchemas. All changes to metadata records on Zenodo are versioned, and happening inside database transactions. In addition to the metadata and data storage, Zenodo relies on Redis for caching and RabbitMQ and python Celery for distributed background jobs. Zenodo uses self-hosted versions of Zammad for helpdesk management, listmonk for newsletter management, PgBouncers for database connection pooling, and IIPServer for our image zoom serving. CERN Data centre is located on CERN premises and all physical access is restricted to a limited number of staff with appropriate training and who have been granted access in line with their professional duties (e.g. Zenodo staff do not have physical access to the CERN Data Centre). Servers are managed according to the CERN Security Baseline for Servers, meaning e.g. remote access to the servers are restricted to Zenodo staff with appropriate training, and the operating system and installed applications are kept updated with latest security patches via the automatic configuration management system Puppet. Team runs both host and network based intrusion detection systems and monitors the traffic flow, pattern and contents into and out of CERN networks in order to detect attacks. All access to zenodo.org happens over HTTPS, except for static documentation pages which are hosted on GitHub Pages. Data: Zenodo stores user passwords using strong cryptographic password hashing algorithms (currently PBKDF2+SHA512). Users' access tokens to GitHub and ORCID are stored encrypted and can only be decrypted with the application's secret key. Application: The CERN is employing a suite of techniques to protect the sessions from being stolen by an attacker when logged in and run vulnerability scans against the application. CERN staff with access to user data operate under CERN Operational Circular no. 5, meaning among other things that staff should not exchange among themselves information acquired unless it is expressly required for the execution of their duties. Access to user data must always be consistent with the professional duties and only permitted for resolution of problems, detection of security issues, monitoring of resources and similar. Staff are liable for damage resulting from any infringement and can have access withdrawn and/or be subject to disciplinary or legal proceedings depending on seriousness of the infringement.

Zenodo allows users to upload files under closed access. Closed access means that zenodo.org users will not be able to access the files uploaded. The files are however stored unencrypted and may be viewed by Zenodo operational staff under specific conditions. This means that "closed access" on Zenodo is not suitable for secret or confidential data. Source: https://about.zenodo.org/infrastructure/

### PAC CINES:

The long-term archiving platform at CINES - PAC v3.0 has been in production since 2008. Capacity: 300 TB on 2 DELL storage bays of 150 TB each.

Arcsys archiving software (Infotel), Redundant virtualised architecture with 2 PowerEdge R730 hypervisors, 2 IBM TS-3500 tape libraries, with LTO4 and JAGUAR drives (use adapted to requirements), 1 Fiber channel interconnection network. cf. https://www.cines.fr/ressources/

## Data sharing and long-term preservation

### How will data be shared?
## Modalities of sharing

The sharing of data and research outputs from WP3 will follow open access principles, ensuring broad availability while respecting ethical and legal considerations. All datasets, including node and edge lists, similarity matrices, and network analysis results, will be made publicly available through a trusted open repository (e.g., Zenodo, institutional repository) upon project completion. Data will be accompanied by clear documentation, including metadata, a data dictionary, and a README file that describes the methodology, tools used (e.g., R, igraph), and any restrictions or terms of use (e.g., attribution). Network visualizations, reports, and related outputs will be made available in standard, non-proprietary formats (e.g., PDF, PNG, CSV) for easy access and reuse. Access to certain datasets may be restricted during the project if required for ongoing analysis, but these will be made publicly available as soon as feasible. Data sharing will be compliant with applicable data protection regulations (e.g., GDPR), and the project team will actively promote data reuse and collaboration within the archaeological and wider scientific communities.

## Reusability

Reuse for future research project

## How will data be long-term preserved? Which data?

## Justification

The long-term preservation of the SNA datasets is essential to ensure the continued accessibility, reproducibility, and scholarly value of the analytical results generated in WP3. As these datasets represent a novel and structured synthesis of technological traditions across archaeological sites—capturing complex patterns of similarity, transmission, and innovation—they provide a critical reference for future comparative studies, methodological refinement, and cross-disciplinary integration. Preserving node and edge lists, network metrics, and visualisations in interoperable formats (e.g., CSV, GraphML), along with detailed metadata and documentation, guarantees that the data can be reused and reinterpreted in light of new findings or theoretical developments. Furthermore, long-term preservation supports transparency and accountability in research, aligning with FAIR data principles and enhancing the impact and legacy of the project within the archaeological and digital humanities communities.

In accordance with the Code of Heritage, the archives produced by the UMRs within the scope of UAR3225 are managed by the archives department of MSH Mondes. At the end of the research project, the documents and data produced will be transferred to the archives department. Indeed, the department is responsible for managing the public, administrative, and scientific archives of the units at MSH Mondes, from their production (current archives) throughout their entire conservation period after transfer (intermediate archives), regardless of their format (textual, graphic, photographic documents, etc.) and their medium (physical documents, electronic documents) (address:

https://www.mshmondes.cnrs.fr/accompagnement/archives).

Once transferred, these data are classified, described, and inventoried. The inventory is published online (address: https://archives.mshmondes.cnrs.fr), and the archives are accessible to anyone who requests them, in compliance with the rules set out in the Code of Heritage and the Code of Intellectual Property.

A selection and, if necessary, regulatory destruction of the archives are carried out based on their administrative usefulness and scientific interest, with the approval of the Interministerial Archives Service of France (SIAF).

These operations are governed by a management table established in line with administrative and scientific needs. Finally, according to a schedule defined in agreement with the National Archives and the needs of the research, the project archives will, ultimately, be transferred to the National Archives for permanent conservation.

Extract of the Archive Department's management table :

<table><thead><tr><th>Activités et documents</th><th>DUA</th><th>Sort final</th><th>Observations</th></tr></thead><tbody><tr><td><strong>1. Direction d'équipe</strong></td><td></td><td></td><td></td></tr><tr><td><strong>1.1. Réunions internes et séminaires</strong><br>Ordre du jour, compte rendu de réunion et documents afférents, programme, support de présentation (texte, slide, vidéo...).</td><td>10 ans</td><td>C</td><td></td></tr><tr><td><strong>1.2. Suivi de l'activité des membres</strong><br>Dossier de membre (projet scientifique, rapport, attestation, demande de bourse),</td><td>10 ans</td><td>C</td><td></td></tr></tbody></table>
note interne.

## 2. Recherche

**2.1. Programme/projet** Le programme/projet peut être financé par des organismes extérieurs à l'unité (ANR, Labex, ministère des Affaires étrangères...) ou ne pas être financé. Le programme/projet génère des documents/données issus des activités scientifiques listées en 3.2-3.10.

Le programme/projet peut être financé par des organismes extérieurs à l'unité (ANR, Labex, ministère des Affaires étrangères...) ou ne pas être financé. Le programme/projet génère des documents/données issus des activités scientifiques listées en 3.2-3.10.

### 2.1.1. Direction et gestion

#### Direction des activités

Appel d'offres, appel à projet, texte de projet, dossier de candidature (accepté ou refusé), rapport d'activité, versions préliminaires (dossier de candidature, rapport), contrat de recherche, convention de collaboration, protocole d'accord, charte de sécurité, autorisation, permis, programme de travail, note d'information, plan de gestion de données, planning, agenda, lettre, courriel.

Durée du projet scientifique + 5 ans

T

Détruire les versions préliminaires (rapport, projet). Conserver les courriels les plus significatifs.

#### Gestion financière

#### Gestion par le responsable de projet

Budget prévisionnel, budget réalisé, notification de crédits, facture, justificatif de dépenses, bilan des dépenses, relevé de compte, attestation, lettre, courriel.

10 ans

D

C'est le cas par exemple des missions archéologiques françaises à l'étranger. Les budgets et les bilans de dépenses sont éliminés car ils figurent dans les rapports.

#### Gestion par l'unité ou une autre institution

Les documents sont des copies. Les documents
<table><tr><td>Budget prévisionnel, budget réalisé, notification de crédits, facture, justificatif de dépenses, bilan des dépenses, relevé de compte, attestation, courriel.</td><td>Validité</td><td>D</td><td>originaux sont archivés par la cellule gestion financière de l'unité ou de l'institution.</td></tr><tr><td>Gestion des personnels (CDD, stagiaires)</td><td></td><td></td><td></td></tr><tr><td>Gestion par le responsable de projet</td><td></td><td></td><td></td></tr><tr><td>CV, lettre de motivation, bulletin d'inscription, attestation, convention de stage (copie), demande et ordre de mission (copie), demande de visa (copie), document relatif aux assurances (copie), courriel.</td><td>10 ans</td><td>D</td><td></td></tr><tr><td>Gestion par l'unité ou autre institution</td><td></td><td></td><td></td></tr><tr><td>CV, lettre de motivation, contrat (copie), convention de stage (copie), documents relatifs aux missions (copies), courriel.</td><td>Validité</td><td>D</td><td>Les documents sont des copies. Les documents originaux sont archivés par la cellule gestion financière de l'unité ou de l'institution.</td></tr><tr><td>Gestion de locaux, d'équipement</td><td></td><td></td><td></td></tr><tr><td>Inventaire d'équipement, documents d'organisation de la vie quotidienne, documentation technique, documents relatifs à la gestion et à l'entretien de véhicule, documents relatifs à la location de locaux.</td><td>10 ans</td><td>T</td><td>Cette rubrique concerne par exemple les missions archéologiques françaises à l'étranger. Détruire les documents relatifs à la gestion et à l'entretien de véhicule et la documentation technique. Conserver les inventaires d'équipement et les documents d'organisation de la vie quotidienne.</td></tr><tr><td>2.1.2. Participation (documents de gestion)</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td>Les tri porte sur les notes et les courriels : conserver selon l'intérêt.</td></tr><tr><td>Texte de projet, rapport, programme de travail, notes, courriel.</td><td></td><td></td><td></td></tr><tr><td>2.1.3. Réunions scientifiques internes (équipe projet, partenaires)</td><td>Durée du projet scientifique + 5 ans</td><td>C</td><td></td></tr><tr><td>Ordre du jour, compte rendu de réunion et documents afférents, programme, support de présentation (texte, slide, vidéo...).</td><td></td><td></td><td></td></tr><tr><td>2.2. Collecte et analyse de documents/données</td><td></td><td></td><td></td></tr><tr><td>Carnet/cahier/journal de terrain, notes d'enquête, notes d'entretien, transcription d'entretien oral, guide d'entretien, questionnaire, fichier d'enregistrement, fiches individuelles, inventaire, document graphique (relevé de terrain, plan, coupe, restitution, dessin d'objet...), document cartographique, photographie, photographie aérienne, image satellitaire, modèle 3D, base de</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td>Il s'agit de tout type de données (issues de fouilles archéologiques, d'une enquête sociologique, historique, géographique...) quelles que soient leurs formes (textes, images, sons...) et leurs supports. Lorsqu'il y a obligation de gestion des archives intermédiaires au sein d'un autre service, les documents/données ne sont pas pris en compte (par exemple, pour l'archéologie, les services régionaux de</td></tr></table>
<table><tr><td>données, système d'information géographique, enregistrement sonore, produit audiovisuel et multimédia (film, vidéo...), échantillons, moulages, maquettes, rapport d'analyse, étude préliminaire, transcription et traduction de textes, guide/note méthodologique, documentation, programme de travail, notes, courriel.</td><td></td><td></td><td>l'archéologie, l'Ecole française d'Athènes...). Conserver la version achevée des documents. Certaines versions préparatoires peuvent être conservées en fonction de l'expertise du chercheur. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé.</td></tr><tr><td><b>2.3. Préparation de publication (ouvrages, article, compte rendu...)</b><br>Texte préliminaire, illustration originale, épreuves, documentation préparatoire, compte rendu de réunion et documents afférents, vidéo de visioconférence, convention de collaboration, contrat de recherche, avis des rapporteurs, lettre, courriel.</td><td>Durée de la préparation + 5 ans</td><td>T</td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, courriel : conserver les documents les plus significatifs.</td></tr><tr><td><b>2.4. Congrès, colloque, journée d'étude (organisation ou participation)</b><br>Support de communication (texte/illustration, slide, vidéo...), résumé, texte et illustration préliminaires des actes, épreuves, poster scientifique, affiche, plaquette, documentation, documents d'organisation (programme, circulaire, résumés des communications...), ordre du jour, compte rendu de réunion et documents afférents, lettre, courriel, copies de documents relatifs à la gestion financière et aux missions.</td><td>10 ans</td><td>T</td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, lettres, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions.</td></tr><tr><td><b>2.5. Sites Web (carnets de recherche, blogs...)</b><br>Texte de projet, cahier des charges, compte rendu de réunion, texte et illustration préparatoires, courriel.</td><td>Validité</td><td>D</td><td>Depuis 2006, la BNF assurer le dépôt légal de l'internet français.</td></tr><tr><td><b>2.6. Documentation</b><br>Photographies, dessins, cartes, enregistrements sonores, produit audiovisuel et multimédia, publications électroniques ou papier, rapport, notes de travail, notes de lecture, courriel, lettre, photothèque, collections de cartes, plans, dessins, collections de référence ou de comparaison (objet fabriqué), base de données.</td><td>Durée d'exploitation + 5 ans</td><td>T</td><td>Conserver les documents selon l'intérêt. Seule la version finale de la base de données sera conservée. Publications : conserver seulement les textes lorsqu'ils participent à la cohérence scientifique d'un dossier contenant d'autres documents.</td></tr><tr><td><b>2.7. Médiation scientifique</b><br>(Exposition, conférence, atelier grand public, émission de radio, émission de télévision, produit pédagogique...) Produit audiovisuel et multimédia (film, vidéo...), podcast, site Web, support de communication (catalogue, livret, programme, affiche, slides de présentation, vidéo...), poster, rushes, master, autorisation, invitation,</td><td>Durée du projet + 5 ans</td><td>T</td><td>Documentation, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé.</td></tr></table>
<table><tr><td>documentation, courriel, document financier et de mission (copies).</td><td></td><td></td><td>Les podcasts et sites Web ne sont pas pris en compte.</td></tr><tr><td>2.8. Correspondance<br/>boîte aux lettres électronique, lettre.</td><td>10 ans</td><td>T</td><td>Le tri porte sur les courriels : conserver les courriels et pièces jointes selon l'intérêt. Détruire les courriels privés.</td></tr><tr><td>2.9. Enseignement et formation<br/>2.9.1. Enseignement dispensé<br/>Programme, support de cours (texte/illustration, slide, vidéo...) et documents afférents, plaquette pédagogique, documentation, notes, lettre, courriel.</td><td>10 ans</td><td>T</td><td>Le tri porte sur la documentation, les notes, lettres et courriels : conserver selon l'intérêt.</td></tr><tr><td>2.9.2. Direction et suivi de travaux d'étudiants<br/>Travaux d'étudiants (thèses, mémoires), rapport (sur les mémoires et sur les soutenances), procès-verbal de soutenance, convocations, courriel, lettres, notes.</td><td>10 ans</td><td>T</td><td>Travaux d'étudiants : les thèses sont archivées par le CINES (Arrêté du 25 mai 2016 fixant le cadre national de la formation et les modalités conduisant à la délivrance du diplôme national de doctorat, titre IV, art. 24-25). Les mémoires (master 1 et 2) sont archivés par les universités. Toutefois, certains documents peuvent être versés en fonction de l'expertise du chercheur et de leur apport au fonds. D pour les autres documents qui sont gérés par les universités.</td></tr><tr><td>2.9.3. Accueil de chercheurs et de stagiaires<br/>Dossier de chercheur invité (candidature (copie), projet de recherche, attestation (copie), rapport scientifique, lettre, courriel.<br/>Dossier de stagiaire (convention de stage (copie), rapport de stage).</td><td>10 ans</td><td>T</td><td>Conserver les documents scientifiques en fonction de l'expertise du chercheur. Détruire les candidatures, conventions, attestations, lettres, courriels.</td></tr></table>

The precise data selection and archiving process will be developed in close collaboration with the archives department of MSH Mondes, which has already been contacted.

Estimated volume of data 10

Unit MB

Start date

End date

Final dispositions

## Demography analysis WP3

### Data description and collection or re-use of existing data
## Research output description

**Name** Demography analysis_WP3

**Description** The primary research output of Task 3.1 (WP3) will be the demographic dataset modeling population density and its influence on social and cultural dynamics in the studied regions. This dataset will be derived using the Cologne Protocol, which combines Geographic Information System (GIS) analysis of site distribution with computational upscaling procedures of population data. The demographic dataset will include spatially explicit population density models, capturing fluctuations in population across different time periods and geographic regions, as well as migration and mobility patterns. Additionally, the dataset will provide insights into the correlation between demographic attributes (e.g., population size, density, mobility) and cultural phenomena, such as changes in social structures or technological practices. This output will be structured to facilitate integration with other datasets, particularly the technological analysis (WP2) and Social Network Analysis (SNA-WP3 Task 3.2), enabling a comprehensive understanding of how demographic factors shape technological networks, social structures, and cultural evolution. The dataset will be accompanied by metadata detailing the data sources, methodology, and analytical protocols used in the demographic modelling process.

**Type** Dataset

**Workpackage** WP3

**Keywords (free-text)** demography

**Language** eng

**Issued Date**

**May contain personal data?** No

## Will existing data be reused?

**Justification**

The decision to reuse existing data from the Aldenhoven Platte in Germany is based on its robust and well-documented application of the Cologne Protocol, which is directly applicable to the objectives of WP3. This dataset provides a valuable foundation for modeling population density and migration patterns, as it has already undergone rigorous spatial analysis and demographic modeling, yielding high-resolution site distributions and population data. Reusing this data ensures consistency in applying the Cologne Protocol methodology across multiple regions, facilitating comparative analysis between different geographic areas and time periods. However, to extend the scope of our research, we will also generate new data to cover adjacent regions not yet included in the Aldenhoven Platte dataset. This will involve applying the same Cologne Protocol approach to newly identified archaeological sites, enabling us to model population dynamics and migration patterns across a broader geographical area. By combining the existing Aldenhoven Platte data with newly collected data from surrounding regions, we aim to create a more comprehensive dataset that reflects the full spatial and temporal complexity of demographic trends, offering valuable insights into the interregional connections and cultural evolution across the study area.

The reuse of existing data, complemented by the creation of new data, will provide a unified and extended dataset that enhances the project's ability to model mobility, migration, and demographic factors, and how they relate to technological and social network dynamics.

## How new data will be collected or produced?
<table><tr><td>Name of the method</td><td>Cologne Protocol</td></tr><tr><td>Description</td><td>The Cologne Protocol for demographic analysis provides a geostatistical approach to estimating prehistoric population size and density, which will be applied in WP3 to model population dynamics and migration patterns. This method involves several key steps:<br>1. Geospatial Analysis of Site Distribution: The first step in applying the Cologne Protocol is the collection of geospatial data on archaeological sites. This involves mapping the spatial distribution of sites across the study area using GIS tools (e.g., MAPINFO, ARCGIS, QGIS, or SAGA). Existing data from sites such as the Aldenhoven Platte will be integrated with newly collected site data from adjacent regions to expand the geographical scope.<br>2. Population Density Modeling: The Cologne Protocol uses upscaling transfer functions to estimate population density across various spatial scales, from individual site areas to larger regional landscapes. These transfer functions allow for the extrapolation of site-specific data (such as site number, site size, or occupation duration) to broader population density estimates for different regions and time periods.<br>3. Ethnohistorical and Proxy Data Integration: The protocol also incorporates ethnohistorical accounts and demographic proxies (e.g., site numbers, dates as data) to refine and cross-check population estimates. These proxies allow researchers to position the demographic models within a broader theoretical context of prehistoric population dynamics, ensuring the estimates are grounded in a wider range of evidence.<br>4. Statistical and Computational Methods: The data collection process involves statistical methods for modeling Core Areas of population density, which are based on spatial data of site distributions. Tools like R are used to implement the modeling procedures, facilitating the generation of population estimates that are spatially explicit and temporally accurate. The protocols for upscaling and modeling are clearly outlined in the Cologne Protocol, which provides manuals for using various GIS software platforms.</td></tr><tr><td>Data Nature</td><td>Simulation data</td></tr><tr><td>Costs</td><td><ul><li>Personnel cost: 60 000 EUR</li></ul></td></tr></table>

## Documentation and data quality

What metadata and documentation (for example way of organising data) will accompany the data?
<table>
   <thead>
    <tr>
     <td>Description</td>
     <td>The data organisation and structuration for WP3-Demograpgy will ensure that all demographic data (in English) is systematically organised, easily accessible, and properly documented for transparency and reproducibility. The process will be structured as follows:
      <ol>
       <li>
        <strong>Data Organisation:</strong>
        <ul>
         <li>
          <strong>Geospatial Data:</strong> All geospatial data (including site locations, maps, and spatial distributions) will be organised in GIS-compatible formats (e.g., shapefiles). These will be stored in a central directory, organised by region and time period to allow for efficient retrieval and comparison across the study area.
         </li>
         <li>
          <strong>Population Density Models:</strong> Population density models derived from the Cologne Protocol will be stored as structured datasets in formats such as CSV or tabular formats (e.g., Excel) to allow for easy manipulation and analysis. The datasets will be divided by spatial scale (e.g., site-level, regional-level) and time period, ensuring clear delineation between different phases of the demographic model.
         </li>
         <li>
          <strong>Supporting Data:</strong> Any additional supporting data (e.g., ethnographic accounts, site number records, proxy estimates) will be organised in supplementary files, linked to the core demographic datasets for cross-referencing.
         </li>
        </ul>
       </li>
       <li>
        <strong>Data Structuration:</strong>
        <ul>
         <li>
          <strong>Hierarchical Structuring:</strong> The data will be organised hierarchically, with primary folders for different regions (e.g., Aldenhoven Platte, adjacent regions) and subfolders for different data types (e.g., GIS data, population density models, site distribution data). Within each subfolder, files will be named consistently to reflect the content (e.g., "Mobilit WP3 population density model Aldenhoven 5000 BC.csv").
         </li>
         <li>
          <strong>Version Control:</strong> All scripts, models, and datasets will be managed using version control software such as Git. This ensures that every modification to the data or analysis scripts is tracked, and older versions can be recovered if needed. This will be particularly important for maintaining the integrity of the Cologne Protocol's demographic models and for keeping a record of any methodological adjustments.
         </li>
         <li>
          <strong>Metadata Structure:</strong> Each dataset will be accompanied by metadata describing the variables, sources, units of measurement, and any transformations applied. The metadata will follow standardised formats (e.g., Dublin Core, ISO 19115) to ensure consistency and easy integration with other datasets. The metadata will also include detailed descriptions of how the data was collected, processed, and modelled.
         </li>
        </ul>
       </li>
       <li>
        <strong>Data Documentation:</strong>
        <ul>
         <li>
          <strong>Methodological Documentation:</strong> Full documentation of the data collection methods will be included in the project repository. This will outline the specifics of the Cologne Protocol application, including descriptions of the upscaling transfer functions, GIS techniques, and the integration of proxies such as ethnographic data. The documentation will explain the assumptions and decisions made during the demographic modelling process.
         </li>
         <li>
          <strong>Analysis Documentation:</strong> Alongside the demographic models, analysis scripts (e.g., R scripts) will be included to allow for full reproducibility of the analysis. These scripts will be thoroughly commented to explain each step of the modeling and analysis process. Additionally, flowcharts or diagrams may be included to provide a visual overview of the data processing pipeline.
         </li>
         <li>
          <strong>Data Access and Sharing:</strong> All documentation will be made publicly available via an open data repository, ensuring that anyone can access, understand, and use the data. The repository will contain a README file that provides an overview of the project, data structure, and the methodology, as well as guidelines on how to access and cite the data.
         </li>
        </ul>
       </li>
       <li>
        <strong>Quality Control and Validation:</strong>
        <ul>
         <li>
          The data organisation structure will also include procedures for quality control, including data validation checks for accuracy and consistency. Any discrepancies or anomalies identified during the demographic modelling process will be documented, with records of how they were resolved or adjusted. Additionally, the metadata will include information on the data's limitations, such as known issues with certain proxies or uncertainties in population estimates.
         </li>
        </ul>
        By adhering to these data organisation, structuration, and documentation procedures, WP3 will ensure that the demographic datasets are not only reliable and easy to use but also transparent and reproducible for future research and validation.
       </li>
      </ol>
     </td>
    </tr>
   </thead>
   <tbody>
    <tr>
     <td>Metadata/data standards</td>
     <td>
      <ul>
       <li>Dublin Core: https://rdamsc.bath.ac.uk/api2/m15</li>
      </ul>
     </td>
    </tr>
    <tr>
     <td>Metadata language code</td>
     <td>eng</td>
    </tr>
   </tbody>
  </table>
## What methods will be used to ensure their scientific quality?

<table><thead><tr><th>Description</th><th></th></tr></thead><tbody><tr><td></td><td>The quality control procedures for the demographic data collected and processed in WP3 will ensure the accuracy, consistency, and reliability of the datasets and analyses. These procedures will be implemented at various stages of the data workflow, from data collection to analysis and sharing:</td></tr><tr><td>1. Data Validation:</td><td><ul><li><strong>Geospatial Data Accuracy:</strong> All GIS data (site locations, spatial distributions) will undergo a series of validation checks to ensure the accuracy of coordinates and site boundaries. This includes cross-referencing site locations with existing databases and literature, ensuring proper alignment of spatial data layers, and verifying that sites are correctly mapped in the project's study area.</li><li><strong>Population Density Models:</strong> Population density models will be validated using multiple data points, including ethnographic proxies, historical records, and previously validated population estimates (e.g., from the Aldenhoven Platte). Any discrepancies between the models and existing data will be identified and addressed, ensuring that the demographic estimates are as accurate as possible.</li></ul></td></tr><tr><td>2. Consistency Checks:</td><td><ul><li><strong>Cross-checking Datasets:</strong> Demographic data derived from the Cologne Protocol will be cross-checked with other datasets from WP2 (technological analysis of lithics) and WP3 (social network analysis) to ensure consistency in the findings. For example, population density models will be compared with technological data to ensure that the population estimates align with known technological transitions and patterns of mobility.</li><li><strong>Temporal Consistency:</strong> Temporal consistency will be verified by ensuring that demographic models reflect chronological accuracy. This includes checking that population density estimates and migration patterns match the chronological framework established by the archaeological record.</li></ul></td></tr><tr><td>3. Error Detection and Correction:</td><td><ul><li><strong>Outlier Detection:</strong> Statistical techniques will be used to identify outliers or anomalous values in the demographic models. For example, unusually high or low population density estimates will be flagged for review. These outliers will be carefully examined to determine whether they result from data entry errors, modelling assumptions, or legitimate variations in the data.</li><li><strong>Model Sensitivity Testing:</strong> Sensitivity tests will be conducted to assess how small changes in the input data (e.g., population size, site distribution) affect the demographic models. If the models are highly sensitive to certain variables, these will be documented and adjusted to ensure the robustness of the findings.</li></ul></td></tr><tr><td>4. Data Provenance and Documentation:</td><td><ul><li><strong>Detailed Metadata:</strong> Comprehensive metadata will be created for each dataset, including information about data sources, methodologies, and any limitations. This metadata will be regularly reviewed and updated to reflect any changes or improvements in the data collection or modeling process. The documentation will include detailed descriptions of the Cologne Protocol's application, assumptions, and limitations, ensuring full transparency.</li><li><strong>Version Control:</strong> All analysis scripts and data models will be version-controlled using platforms like Git. This ensures that any updates or modifications to the demographic models are tracked, and previous versions can be revisited for comparison and validation.</li></ul></td></tr><tr><td>5. Peer Review and External Validation:</td><td><ul><li><strong>Internal Review:</strong> Throughout the process, all datasets and analysis results will be reviewed by team members for internal validation. Regular meetings and discussions will ensure that the results align with the project's objectives and expectations.</li><li><strong>External Validation:</strong> If applicable, external experts or collaborators may be invited to validate key demographic models or assumptions, particularly when extending the analysis to new regions or applying the Cologne Protocol in novel contexts. Feedback from external experts will be incorporated to further refine and improve the models.</li></ul></td></tr><tr><td>6. Reproducibility:</td><td><ul><li><strong>Reproducible Analysis:</strong> All analysis scripts, models, and datasets will be shared along with clear instructions on how to reproduce the analysis. This will include the use of open-source software (e.g., R, QGIS) and detailed documentation that allows other researchers to replicate the results. Reproducibility is a key quality control measure, ensuring that the findings can be independently verified by others in the field.</li></ul></td></tr></tbody></table>
### 7. Regular Data Audits:

* Periodic audits will be conducted to assess the integrity of the data and the effectiveness of the quality control procedures. Any issues identified during these audits will be addressed promptly, ensuring that the project maintains high standards of data quality throughout its duration.

By applying these quality control procedures, WP3 will ensure that the demographic data collected, modeled, and analyzed is accurate, consistent, and reliable, providing a solid foundation for understanding prehistoric population dynamics and their relationship with technological and social structures.

## Legal and ethical requirements, codes of conduct

**How will other legal issues, such as intellectual property rights and ownership, be managed? What legislation is applicable?**

<table><tr><td>Description</td><td>The project data are public archives within the meaning of the Code du patrimoine, article L211-4. This status was reiterated by the directive issued by CNRS and Archives de France in 2007 (Instruction No. DAF/DPACI/RES/2007/002 of January 15, 2007. Traitement et conservation des archives des délégations du CNRS et des archives des unités de recherche et de service). Public archives are freely accessible, except for information subject to communication deadlines defined by the Code du patrimoine, in article L.213-2.<br/>The disclosure, reuse, and dissemination of public archives that qualify as a work of the mind, as defined by the Code de la propriété intellectuelle, are regulated by the same code. Researchers and teacher-researchers, as public servants, retain their intellectual property rights (article L.111-1 of the Code de la propriété intellectuelle).</td></tr></table>

**What ethical issues and codes of conduct are there, and how will they be taken into account?**

<table><tr><td>Description</td><td>The Code de la recherche establishes a link between scientific integrity and the preservation of scientific data, in accordance with the Code du patrimoine. In the long term, the archives department of the MSH Mondes will be responsible for the preservation and regulatory communication of the data, in line with the provisions set out in both codes.</td></tr></table>

## Data processing and analysis

**How and with what resources will the data be processed / analyzed?**
<table><thead><tr><th>Description</th><th></th></tr></thead><tbody><tr><td></td><td>Data processing for WP3 will follow a series of steps:</td></tr><tr><td>1. Geospatial Analysis: GIS tools (e.g., QGIS, ARCGIS) will be used to map and analyze site distributions and spatial patterns, ensuring consistent georeferencing and accurate site locations.</td><td></td></tr><tr><td>2. Population Density Modeling: Using the Cologne Protocol, population density will be estimated by applying upscaling transfer functions to site data, incorporating ethnohistorical proxies and archaeological records.</td><td></td></tr><tr><td>3. Statistical Analysis: Statistical methods, including sensitivity testing and model validation, will ensure robust and reliable population estimates, with R used for scripting and computational modeling.</td><td></td></tr><tr><td>4. Data Integration: Demographic data will be integrated with technological and social network data, ensuring cross-discipline coherence and facilitating comprehensive analysis.</td><td></td></tr></tbody></table>

# Storage and backup during the research process

## How will data be stored and backed up during the research?

### Storage needs

During the project, data will be stored and backed up in multiple secure environments to ensure both accessibility and protection against loss:

* **Primary Storage:** Data will be stored on the professional, institutionally managed computer of Solène Denis, with access restricted to authorized project personnel.

* **Secondary Backup:** A monthly backup of project data will be saved to a dedicated external hard drive maintained by the project team.

The project's shared workspace on RESANA (a secure platform provided by the French Direction Interministérielle du Numérique - DINUM) will serve as an additional storage and collaboration space. Résana hosts data on nationally managed secured servers, ensuring institutional compliance and reliability.

A ShareDoc (CNRS IN2P3) project-specific file manager for MOBILITH will be set up, with weekly backups, providing robust redundancy and automated version control.

The use of at least three independent storage spaces - local, institutional online, and external managed backup - ensures the ability to recover data in the event of hardware failure, accidental deletion, or other incidents. In case of data loss or corruption, the most recent backup from ShareDoc or the external drive will be restored, with coordination from institutional IT support if needed.

Access to project data during the research phase will be restricted to MOBILITH project members and designated external experts. Controlled access is managed through institutional credentials for Résana and ShareDoc platforms. FileSender, the institutional secure file transfer service, will be used for any sensitive file exchanges between partners, ensuring encrypted transmission.

While the project does not involve highly sensitive personal data, appropriate data protection measures will be observed. In cases where potentially sensitive information is handled (e.g., site locations or unpublished archaeological findings), access will be limited, and data will be pseudonymized or aggregated as appropriate.

Data management and protection practices will comply with institutional and national policies, in alignment with GDPR and best practices for handling research data securely.

Perennial archiving costs are covered by the MSH Mondes archive service (CNRS servers) and, for definitive archiving, by the French National Archives and the Centre informatique national de l'enseignement supérieur (CINES), under the supervision of the Ministry of Higher Education.

The cost of storing and sharing the data that will be made public will be borne by the institutions for which the project participants work (data on portable PCs, by the IR* Huma-Num (storage on Sharedocs and dissemination via the SHS Nakala data warehouse), under the supervision of the CNRS, Aix Marseille University and the Condorcet campus, by the French government's Direction du Numérique (document sharing via the Resana collaborative platform), by CERN for the Zenodo generalist warehouse, and by the Centre de la Communication Scientifique Directe (CCSD) under the supervision of CNRS, INRIA and INRAE for the distribution of open access publications.

Processing will be carried out by those responsible for the research products, using tools already funded by the institutions (e.g. Excel) or free open-source tools such as OpenRefine and Calc, or QGIS.
**Estimated volume of data** 10

**Unit** GB

**Measures taken for data security**

Data security will be ensured through a combination of physical, digital, and procedural safeguards. All digital data will be stored on secure, institutionally managed servers with regular automated backups and controlled access based on user roles (see below). Sensitive or unpublished data will be protected by password-restricted folders, and encryption will be used when transferring data between devices or collaborators.

**Resana :**

Resana is hosted in Outscale's SecNumCloud 3DS in data centres in France. The operator is responsible for the availability of the service and for maintaining it in operational and security condition. The integrity and confidentiality of the information circulating are ensured by encryption mechanisms (HTTPS protocol). RESANA is not considered a "critical" service, in the sense of continuity of government action. In nominal mode, the service is available 24/7/365. However, it may be interrupted in the event of a technical incident or maintenance operation. DINUM aims to guarantee a maximum downtime of 4 hours and a maximum data loss time of 24 hours. RESANA is an information system that has been security-approved (RGS) by the qualified authority (Interministerial Digital Directorate) for the sharing of standard data. The information system takes into account the needs of confidentiality, integrity and availability of the service. All content uploaded to the platform is encrypted (AES 128 bit) and hosted on the Outscale SecNumCloud 3DS with 24/7 facilities management. However, its use is not authorised to convey sensitive information or information marked "Restricted Distribution", in accordance with II901 (NOR: PRMD1503279J).

Cf : https://resana.numerique.gouv.fr/public/utilisateur/afficherPageConnexionAnnexe? page=apropos

**Sharedocs :**

ShareDocs is a file manager implemented by IR* Huma-Num, on its own servers, which can be used via a web browser, a WebDAV client or file synchronisation software. The platform is based on the FileRun application. It provides remote online storage on the French research network (similar to tools such as DropBox, which are hosted on the public cloud). Hosted data can be easily encrypted using tools such as ZED encrypt.

ShareDocs is designed for research projects that want to store, exchange, share and work on file-type data (sets of photos, transcribed texts, etc.). For example, ShareDocs can be used to prepare files for online publishing or for distribution in NAKALA.

A ShareDocs project account facilitates data sharing and collaborative work between several members of a project or research team in the social sciences and humanities. The project account is adapted to collaboration via collaborative editing and file versioning tools, as the project account is accessible to several members of a team (unlike an individual account). It allows the creation of a tree structure of folders and it is necessary to define access and editing rights in detail, as soon as they have been created and for a list of identified collaborators. The principle is to create a folder and file tree when a project account is opened, and then to grant different access and editing rights depending on the role of each team member.

For the 2023-2025 forecasts, the volume of a project account is 300 GB of storage.

A project account can only be accessed by a list of people who have been declared and registered with Huma-Num by the project account manager.

The data stored on Sharedocs is hosted and backed up at the IN2P3 computing centre in Lyon, on Huma-Num servers. In the event of data loss, Huma-Num assures us that it will be possible to contact their helpdesk to recover it, via one of its backups.

https://documentation.huma-num.fr/sharedocs-stockage/

**Nakala :**

The data deposited in NAKALA is stored on servers managed by Huma-Num and hosted at the IN2P3 computing centre. This centre was set up to manage data produced in particle physics, nuclear physics and astroparticle physics.

This major national centre is secure from a hardware point of view (e.g. redundant power supply, network devices, cooling systems).

NAKALA data is stored on a NAS-type network storage device. A snapshot of the data is taken at regular intervals, enabling data to be restored quickly in the event of problems. In addition, a tape backup is made daily on the CCIN2P3 backup robot using TSM software published by IBM. NAKALA's metadata are stored in a SQL database (MariaDB) which is backed up daily on Huma-Num's infrastructure. The metadata is also exposed in RDF format via a Triple-Store (GraphDB) which is also backed up daily on the Huma-Num infrastructure. Continuity of the NAKALA¶ service

The NAKALA service is hosted on the Huma-Num infrastructure, which has a general disaster recovery plan. More specifically, the redundancy of the NAKALA service is ensured by :

- the NAKALA application is redundant on two different machines using a distribution tool (HAProxy), which avoids service interruptions in the event of a breakdown;
- the data is stored on a NAS-type device, so that data can be restored quickly. In addition, backups are made on magnetic tapes on a daily basis;

- Metadata is stored in a 'classic' relational database, which is backed up daily. This metadata is also stored in RDF format in a Triple-Store, which is backed up daily.

Source: https://documentation.huma-num.fr/nakala-faq/#comment-sont-sauvegardees-les-donnees

### Zenodo:

Zenodo is powered by CERN Data Centre and the InvenioRDM and is fully run on open source products all the way through.

Physically, Zenodo's entire technical infrastructure is located on CERN's premises which is subject to CERN's legal status (see above).

Zenodo servers are managed via OpenShift which itself runs on top of CERN's private cloud which is using OpenStack and Puppet configuration management system. Servers are monitored via CERN's monitoring infrastructure based on Logstash, OpenSearch, and Hadoop. Application errors are logged and aggregated in a local Sentry instance. Traffic to Zenodo frontend servers is load balanced via a combination of DNS load balancing and HAProxy load balancers.

Zenodo I running on three independent systems: one production system, one quality assurance system, and one development system. This ensures that all changes, whether at infrastructure level or source code level, can be tested and validated on the quality assurance system prior to being applied to our production system. Zenodo frontend servers are responsible for running the InvenioRDM repository platform application which is based on Python and the Flask web development framework. The frontend servers are running nginx HTTP server and uwsgi application server in front of the application and nginx is in addition in charge of serving static content. All files uploaded to Zenodo are stored in CERN's EOS service in an 5 petabytes disk cluster. Each file copy has two replicas located on different disk servers. A daily incremental backup is performed of the EOS storage cluster into a Ceph storage cluster located in a different geographical location (~3.5 km apart). The backup retention policy keeps the last 7 daily backups, last 5 weekly backups and last 6 monthly backups. For each file we store two independent MD5 checksums. One checksum is stored by Invenio, and used to detect changes to files made from outside of Invenio. The other checksum is stored by EOS, and used for automatic detection and recovery of file corruption on disks. EOS is the primary low latency storage infrastructure for physics data from the Large Hadron Collider (LHC) and CERN currently operates multiple instances totalling 1+ exabyte of data. Metadata and persistent identifiers in Zenodo are stored in a PostgreSQL instance (with a master-slave setup) operated on CERN's Database on Demand infrastructure with 24-hourly backup cycle with one backup sent to tape storage once a week. Metadata is in addition indexed in an OpenSearch cluster for fast and powerful searching. Metadata is stored in JSON format in PostgreSQL in a structure described by versioned JSONSchemas. All changes to metadata records on Zenodo are versioned, and happening inside database transactions. In addition to the metadata and data storage, Zenodo relies on Redis for caching and RabbitMQ and python Celery for distributed background jobs. Zenodo uses self-hosted versions of Zammad for helpdesk management, listmonk for newsletter management, PgBouncer for database connection pooling, and IIPServer for our image zoom serving. CERN Data centre is located on CERN premises and all physical access is restricted to a limited number of staff with appropriate training and who have been granted access in line with their professional duties (e.g. Zenodo staff do not have physical access to the CERN Data Centre). Servers are managed according to the CERN Security Baseline for Servers, meaning e.g. remote access to the servers are restricted to Zenodo staff with appropriate training, and the operating system and installed applications are kept updated with latest security patches via the automatic configuration management system Puppet. Team runs both host and network based intrusion detection systems and monitors the traffic flow, pattern and contents into and out of CERN networks in order to detect attacks. All access to zenodo.org happens over HTTPS, except for static documentation pages which are hosted on GitHub Pages. Data: Zenodo stores user passwords using strong cryptographic password hashing algorithms (currently PBKDF2+SHA512). Users' access tokens to GitHub and ORCID are stored encrypted and can only be decrypted with the application's secret key. Application: The CERN is employing a suite of techniques to protect the sessions from being stolen by an attacker when logged in and run vulnerability scans against the application. CERN staff with access to user data operate under CERN Operational Circular no. 5, meaning among other things that staff should not exchange among themselves information acquired unless it is expressly required for the execution of their duties. Access to user data must always be consistent with the professional duties and only permitted for resolution of problems, detection of security issues, monitoring of resources and similar. Staff are liable for damage resulting from any infringement and can have access withdrawn and/or be subject to disciplinary or legal proceedings depending on seriousness of the infringement.

Zenodo allows users to upload files under closed access. Closed access means that zenodo.org users will not be able to access the files uploaded. The files are however stored unencrypted and may be viewed by Zenodo operational staff under specific conditions. This means that "closed access" on Zenodo is not suitable for secret or confidential data. Source:

https://about.zenodo.org/infrastructure/

### PAC CINES:
The long-term archiving platform at CINES - PAC v3.0 has been in production since 2008.
Capacity: 300 TB on 2 DELL storage bays of 150 TB each.

Arcsys archiving software (Infotel), Redundant virtualised architecture with 2 PowerEdge R730 hypervisors, 2 IBM TS-3500 tape libraries, with LTO4 and JAGUAR drives (use adapted to requirements), 1 Fiber channel interconnection network. cf https://www.cines.fr/ressources/

# Data sharing and long-term preservation

## How will data be shared?

### Modalities of sharing

The sharing of data and research outputs from WP3 will follow open access principles, ensuring broad availability while respecting ethical and legal considerations. All datasets, including node and edge lists, similarity matrices, and network analysis results, will be made publicly available through a trusted open repository (e.g., Zenodo, institutional repository) upon project completion. Data will be accompanied by clear documentation, including metadata, a data dictionary, and a README file that describes the methodology, tools used (e.g., R, igraph), and any restrictions or terms of use (e.g., attribution). Network visualizations, reports, and related outputs will be made available in standard, non-proprietary formats (e.g., PDF, PNG, CSV) for easy access and reuse. Access to certain datasets may be restricted during the project if required for ongoing analysis, but these will be made publicly available as soon as feasible. Data sharing will be compliant with applicable data protection regulations (e.g., GDPR), and the project team will actively promote data reuse and collaboration within the archaeological and wider scientific communities.

### Reusability

Reuse for future research project

## How will data be long-term preserved? Which data?

### Justification

Long-term preservation of the demographic dataset from Task 3.1 is crucial to maintain the integrity, accessibility, and reusability of a foundational resource for understanding population dynamics in past societies. As the dataset combines spatially explicit population models, mobility patterns, and their correlations with cultural and technological change, it provides unique empirical insights that are not only valuable for the current research but also for future studies in archaeology, anthropology, and historical demography. Preserving this dataset in standardized, interoperable formats (e.g., GeoTIFF, CSV, shapefiles), along with comprehensive metadata and detailed documentation of the Cologne Protocol and GIS-based methodologies, ensures that the data can be effectively reanalyzed, integrated with other research outputs, or applied to new regions and research questions. This supports the transparency and longevity of the project's contributions, aligns with FAIR principles, and maximizes the potential for interdisciplinary reuse and scientific advancement.

In accordance with the Code of Heritage, the archives produced by the UMRs within the scope of UAR3225 are managed by the archives department of MSH Mondes. At the end of the research project, the documents and data produced will be transferred to the archives department. Indeed, the department is responsible for managing the public, administrative, and scientific archives of the units at MSH Mondes, from their production (current archives) throughout their entire conservation period after transfer (intermediate archives), regardless of their format (textual, graphic, photographic documents, etc.) and their medium (physical documents, electronic documents) (address: https://www.mshmondes.cnrs.fr/accompagnement/archives).

Once transferred, these data are classified, described, and inventoried. The inventory is published online (address: https://archives.mshmondes.cnrs.fr), and the archives are accessible to anyone who requests them, in compliance with the rules set out in the Code of Heritage and the Code of Intellectual Property.

A selection and, if necessary, regulatory destruction of the archives are carried out based on their administrative usefulness and scientific interest, with the approval of the Interministerial Archives Service of France (SIAF).

These operations are governed by a management table established in line with administrative and scientific needs. Finally, according to a schedule defined in agreement with the National Archives and the needs of the research, the project archives will, ultimately, be transferred to the National Archives for permanent conservation.
Extract of the Archive Department's management table :

<table><thead><tr><th>Activités et documents</th><th>DUA</th><th>Sort final</th><th>Observations</th></tr></thead><tbody><tr><td><strong>1. Direction d'équipe</strong></td><td></td><td></td><td></td></tr><tr><td><strong>1.1. Réunions internes et séminaires</strong><br>Ordre du jour, compte rendu de réunion et documents afférents, programme, support de présentation (texte, slide, vidéo...).</td><td>10 ans</td><td>C</td><td></td></tr><tr><td><strong>1.2. Suivi de l'activité des membres</strong><br>Dossier de membre (projet scientifique, rapport, attestation, demande de bourse), note interne.</td><td>10 ans</td><td>C</td><td></td></tr><tr><td><strong>2. Recherche</strong></td><td></td><td></td><td></td></tr><tr><td><strong>2.1. Programme/projet</strong> Le programme/projet peut être financé par des organismes extérieurs à l'unité (ANR, Labex, ministère des Affaires étrangères...) ou ne pas être financé. Le programme/projet génère des documents/données issus des activités scientifiques listées en 3.2-3.10.</td><td></td><td></td><td>Le programme/projet peut être financé par des organismes extérieurs à l'unité (ANR, Labex, ministère des Affaires étrangères...) ou ne pas être financé. Le programme/projet génère des documents/données issus des activités scientifiques listées en 3.2-3.10.</td></tr><tr><td><strong>2.1.1. Direction et gestion</strong></td><td></td><td></td><td></td></tr><tr><td><strong>Direction des activités</strong><br>Appel d'offres, appel à projet, texte de projet, dossier de candidature (accepté ou refusé), rapport d'activité, versions préliminaires (dossier de candidature, rapport), contrat de recherche, convention de collaboration, protocole d'accord, charte de sécurité, autorisation, permis, programme de travail, note d'information, plan de gestion de données, planning, agenda, lettre, courriel.</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td>Détruire les versions préliminaires (rapport, projet). Conserver les courriels les plus significatifs.</td></tr></tbody></table>
<table><tr><td>Gestion financière</td><td></td><td></td><td></td></tr><tr><td>Gestion par le responsable de projet</td><td></td><td></td><td></td></tr><tr><td>Budget prévisionnel, budget réalisé, notification de crédits, facture, justificatif de dépenses, bilan des dépenses, relevé de compte, attestation, lettre, courriel.</td><td>10 ans</td><td>D</td><td>C'est le cas par exemple des missions archéologiques françaises à l'étranger. Les budgets et les bilans de dépenses sont éliminés car ils figurent dans les rapports.</td></tr><tr><td>Gestion par l'unité ou une autre institution</td><td></td><td></td><td></td></tr><tr><td>Budget prévisionnel, budget réalisé, notification de crédits, facture, justificatif de dépenses, bilan des dépenses, relevé de compte, attestation, courriel.</td><td>Validité</td><td>D</td><td>Les documents sont des copies. Les documents originaux sont archivés par la cellule gestion financière de l'unité ou de l'institution.</td></tr><tr><td>Gestion des personnels (CDD, stagiaires)</td><td></td><td></td><td></td></tr><tr><td>Gestion par le responsable de projet</td><td></td><td></td><td></td></tr><tr><td>CV, lettre de motivation, bulletin d'inscription, attestation, convention de stage (copie), demande et ordre de mission (copie), demande de visa (copie), document relatif aux assurances (copie), courriel.</td><td>10 ans</td><td>D</td><td></td></tr><tr><td>Gestion par l'unité ou autre institution</td><td></td><td></td><td></td></tr><tr><td>CV, lettre de motivation, contrat (copie), convention de stage (copie), documents relatifs aux missions (copies), courriel.</td><td>Validité</td><td>D</td><td>Les documents sont des copies. Les documents originaux sont archivés par la cellule gestion financière de l'unité ou de l'institution.</td></tr><tr><td>Gestion de locaux, d'équipement</td><td></td><td></td><td></td></tr><tr><td>Inventaire d'équipement, documents d'organisation de la vie quotidienne, documentation technique, documents relatifs à la gestion et à l'entretien de véhicule, documents relatifs à la location de locaux.</td><td>10 ans</td><td>T</td><td>Cette rubrique concerne par exemple les missions archéologiques françaises à l'étranger. Détruire les documents relatifs à la gestion et à l'entretien de véhicule et la documentation technique. Conserver les inventaires d'équipement et les documents d'organisation de la vie quotidienne.</td></tr><tr><td>2.1.2. Participation (documents de gestion)</td><td></td><td></td><td></td></tr><tr><td>Texte de projet, rapport, programme de travail, notes, courriel.</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td>Les tri porte sur les notes et les courriels : conserver selon l'intérêt.</td></tr><tr><td>2.1.3. Réunions scientifiques internes (équipe projet, partenaires)</td><td></td><td></td><td></td></tr><tr><td>Ordre du jour, compte rendu de réunion et documents afférents, programme, support de présentation (texte, slide, vidéo...).</td><td>Durée du projet scientifique + 5 ans</td><td>C</td><td></td></tr></table>
<table><tr><td>2.2. Collecte et analyse de documents/données<br/>Carnet/cahier/journal de terrain, notes d'enquête, notes d'entretien, transcription d'entretien oral, guide d'entretien, questionnaire, fichier d'enregistrement, fiches individuelles, inventaire, document graphique (relevé de terrain, plan, coupe, restitution, dessin d'objet...), document cartographique, photographie, photographie aérienne, image satellitaire, modèle 3D, base de données, système d'information géographique, enregistrement sonore, produit audiovisuel et multimédia (film, vidéo...), échantillons, moulages, maquettes, rapport d'analyse, étude préliminaire, transcription et traduction de textes, guide/note méthodologique, documentation, programme de travail, notes, courriel.</td><td>Durée du projet scientifique + 5 ans</td><td>T</td><td>Il s'agit de tout type de données (issues de fouilles archéologiques, d'une enquête sociologique, historique, géographique...) quelles que soient leurs formes (textes, images, sons...) et leurs supports. Lorsqu'il y a obligation de gestion des archives intermédiaires au sein d'un autre service, les documents/données ne sont pas pris en compte (par exemple, pour l'archéologie, les services régionaux de l'archéologie, l'Ecole française d'Athènes...). Conserver la version achevée des documents. Certaines versions préparatoires peuvent être conservées en fonction de l'expertise du chercheur. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé.</td></tr><tr><td>2.3. Préparation de publication (ouvrages, article, compte rendu...)<br/>Texte préliminaire, illustration originale, épreuves, documentation préparatoire, compte rendu de réunion et documents afférents, vidéo de visioconférence, convention de collaboration, contrat de recherche, avis des rapporteurs, lettre, courriel.</td><td>Durée de la préparation + 5 ans</td><td>T</td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, courriel : conserver les documents les plus significatifs.</td></tr><tr><td>2.4. Congrès, colloque, journée d'étude (organisation ou participation)<br/>Support de communication (texte/illustration, slide, vidéo...), résumé, texte et illustration préliminaires des actes, épreuves, poster scientifique, affiche, plaquette, documentation, documents d'organisation (programme, circulaire, résumés des communications...), ordre du jour, compte rendu de réunion et documents afférents, lettre, courriel, copies de documents relatifs à la gestion financière et aux missions.</td><td>10 ans</td><td>T</td><td>Le tri porte principalement sur les textes préliminaires et illustrations : conserver uniquement la première version soumise. Détruire les épreuves. Documentation, lettres, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions.</td></tr><tr><td>2.5. Sites Web (carnets de recherche, blogs...)<br/>Texte de projet, cahier des charges, compte rendu de réunion, texte et illustration préparatoires, courriel.</td><td>Validité</td><td>D</td><td>Depuis 2006, la BNF assurer le dépôt légal de l'internet français.</td></tr><tr><td>2.6. Documentation<br/>Photographies, dessins, cartes, enregistrements sonores, produit audiovisuel et multimédia, publications électroniques ou papier, rapport, notes de travail, notes de lecture, courriel, lettre, photothèque, collections de cartes, plans,</td><td>Durée d'exploitation + 5 ans</td><td>T</td><td>Conserver les documents selon l'intérêt. Seule la version finale de la base de données sera conservée. Publications : conserver seulement les textes lorsqu'ils participent à la cohérence</td></tr></table>
<table><tr><td>dessins, collections de référence ou de comparaison (objet fabriqué), base de données.</td><td></td><td></td><td>scientifique d'un dossier contenant d'autres documents.</td></tr><tr><td>2.7. Médiation scientifique<br/>(Exposition, conférence, atelier grand public, émission de radio, émission de télévision, produit pédagogique...) Produit audiovisuel et multimédia (film, vidéo...), podcast, site Web, support de communication (catalogue, livret, programme, affiche, slides de présentation, vidéo...), poster, rushes, master, autorisation, invitation, documentation, courriel, document financier et de mission (copies).</td><td>Durée du projet + 5 ans</td><td>T</td><td>Documentation, courriels : conserver les documents les plus significatifs. Détruire les copies de documents financiers et de missions. Conserver les masters en format compressé ; détruire les rushes et les masters en format non compressé. Les podcasts et sites Web ne sont pas pris en compte.</td></tr><tr><td>2.8. Correspondance<br/>boîte aux lettres électronique, lettre.</td><td>10 ans</td><td>T</td><td>Le tri porte sur les courriels : conserver les courriels et pièces jointes selon l'intérêt. Détruire les courriels privés.</td></tr><tr><td>2.9. Enseignement et formation<br/>2.9.1. Enseignement dispensé<br/>Programme, support de cours (texte/illustration, slide, vidéo...) et documents afférents, plaquette pédagogique, documentation, notes, lettre, courriel.</td><td>10 ans</td><td>T</td><td>Le tri porte sur la documentation, les notes, lettres et courriels : conserver selon l'intérêt.</td></tr><tr><td>2.9.2. Direction et suivi de travaux d'étudiants<br/>Travaux d'étudiants (thèses, mémoires), rapport (sur les mémoires et sur les soutenances), procès-verbal de soutenance, convocations, courriel, lettres, notes.</td><td>10 ans</td><td>T</td><td>Travaux d'étudiants : les thèses sont archivées par le CINES (Arrêté du 25 mai 2016 fixant le cadre national de la formation et les modalités conduisant à la délivrance du diplôme national de doctorat, titre IV, art. 24-25). Les mémoires (master 1 et 2) sont archivés par les universités. Toutefois, certains documents peuvent être versés en fonction de l'expertise du chercheur et de leur apport au fonds. D pour les autres documents qui sont gérés par les universités.</td></tr><tr><td>2.9.3. Accueil de chercheurs et de stagiaires<br/>Dossier de chercheur invité (candidature (copie), projet de recherche, attestation (copie), rapport scientifique, lettre, courriel. Dossier de stagiaire (convention de stage (copie), rapport de stage).</td><td>10 ans</td><td>T</td><td>Conserver les documents scientifiques en fonction de l'expertise du chercheur. Détruire les candidatures, conventions, attestations, lettres, courriels.</td></tr></table>

The precise data selection and archiving process will be developed in close collaboration with the archives department of MSH Mondes, which has already been contacted.
Unit MB

Start date

End date

Final dispositions