---
# System prepended metadata

title: Point RESIL 21/04/2023

---

# Point RESIL 21/04/2023

PJ mail 24/04

## format long

| Prénom(s) | Nom(s) | Nom de naissance | Commune de naissance | Source | Prénom(s) Cohabitant(s) | Nom(s) Cohabitant(s) |
|---------|------|-----|---|---|-----|----|
| Daffy | Duck | | | CAF | | |
| Mickey Alfredo Topolino  | Mouse | | Napoli | Fiscale | Minnie Daffy | Mouse Duck |
| Mickey | Mouse | | | CAF |  | |
| Minnie | Mouse | Boop | | CAF |  | |


## wide

| Prénom(s)_source_fiscale | Nom(s)_source_fiscale | Nom de naissance_source_fiscale | Commune de naissance_source_fiscale | Prénom(s) Cohabitant(s)_source_fiscale | Nom(s) Cohabitant(s) _source_fiscale| Prénom(s)_source_CAF | Nom(s)_source_CAF | Nom de naissance_source_CAF | Commune de naissance_source_CAF | Prénom(s) Cohabitant(s)_source_CAF | Nom(s) Cohabitant(s) _source_CAF|
|------|------|------|------|------|------|------|------|------|------|------|------|
| Mickey Alfredo Topolino  | Mouse | | Napoli | Minnie Daffy | Mouse Duck | | Mickey | Mouse | | |  | |


## Indexation Elastic


Fichiers utiles à préparer par l'équipe stat Résil pour l'évaluation de la qualité 
- fichier comportant les données des appariements Rapsodie comme benchmark (notamment ear 2020 - fideli 2020)  : (identifiant source 1, identifiant source 2, distance)
- fichier comportant l'ensemble des paires annotées pour les appariements déjà réalisés sur 2020  : (identitifant source 1, identifiant source 2, résultat de l'annotation)

<details>
<summary>
__OLD__ :point_down: 
</summary>
## Notes vrac

CSNS: seul champ pas flou est l'année
mais comment faire le flou ? +1/-1, inversion des chiffres ?

CSNS: nom, prenom(s), date et lieu de naissance
champ entier, premier prenom, n-gramme sur nom & prenom entre 2 et 5
lieu de naissance : y a de la synonmie sur la géographie (exemple arrondissements) et codification des pays en sicore
date de naissance: relaches sur les couples mois/jours et des trucs type (non réposne = 1er janvier ou 31/12)
=> probablement fait plutôt lors des requêtes pour ce dernier point

pour commencer on travaille à la commune
traitements équivalents commune résidence à commune ? + ajouter à un moment le blocage ou le boost
sur les adresses multiples: ça serait mieux en format long que wide

https://gitlab.insee.fr/Individus-et-logements/code-statistique-non-signifiant/csns/-/blob/master/csns-batch/src/main/resources/es-config/elastic-analyzer.json
https://gitlab.insee.fr/Individus-et-logements/code-statistique-non-signifiant/csns/-/blob/master/csns-batch/src/main/java/fr/insee/csns/batch/elastic/index/IndividuIndex.java
https://gitlab.insee.fr/Individus-et-logements/code-statistique-non-signifiant/csns/-/tree/master/csns-batch/src/main/java/fr/insee/csns/batch/elastic/query

pour les cohabitants: garder que les noms et prénoms uniques (en mode sac de mot)

rzegarder comment on gère les list dans elastic

https://www.elastic.co/guide/en/elasticsearch/reference/current/array.html


Dans l'ensemble indexé: conserver la source et l'année pour mettre ça dans l'index ?

Poser la question à long terme: préférez-vous un format long ou un array ?

Format long : n adresses par indiv, 1 colonne sac de mot nom de famille, 1 colonne sac de prénoms correspondant aux individus de cette adresse et cette source.


donc dans le rnipp, les identités sont en format long (une seule colonne nom, deux lignes pour moi; j'imagine que idem sur autres traits d'identité).
dans le pseudo résil on a.... une colonne nom de naissance et une colonne nom d'usage
qu'aura t on dans le vrai résil ? 
    
</details>