# Moissonner les publications

> **En bref :**
> IKG demande un moissonnage pour une personne ; le moissonneur (svp-harvester) interroge les sources et renvoie des notices ; IKG les regroupe en publications.
> Statut : **Non exécuté** ; commandes, files et relations vérifiées dans le code. Inutile pour le POC de novembre.

## Pourquoi ce tutoriel

Une fiche de chercheur sans publications n'apporte rien. Ce tutoriel fait entrer les publications dans le graphe, à partir des identifiants de la personne (IdRef, ORCID, IdHAL).

Les sources réellement utilisées sont décrites dans le [catalogue des sources](/03-crisalid/01-donnees/catalogue-des-sources) ; le regroupement des notices dans [provenance, qualité et fusion](/03-crisalid/01-donnees/provenance-qualite-fusion). Étape 3 sur 4.

## Avant de commencer

- Des personnes chargées avec au moins un identifiant ([étape 2](./charger-structures-et-personnes)).
- Les profils `harvester` et `harvester-db` ajoutés à la commande de démarrage.
- Un accès réseau : les sources interrogées sont réelles.

## Étapes

### Étape 1 — Relever l'identifiant d'une personne

**Pourquoi :** le moissonnage se déclenche personne par personne, à partir de son `uid`.

```cypher
MATCH (p:Person) RETURN p.uid, p.display_name LIMIT 5;
```

### Étape 2 — Déclencher le moissonnage

**Pourquoi :** c'est IKG qui commande le moissonneur ; commencer par une seule source limite le volume.

```bash
docker compose exec crisalid-ikg python -m app.cli people fetch-publications "<uid>" --harvesters hal
```

La demande part sur l'échange `publications` (clé `task.entity.references.retrieval`) vers la file `svp-harvester-batch` ; les notices reviennent par `crisalid-ikg-publications-batch`.

### Étape 3 — Suivre les files

**Pourquoi :** un message bloqué ou rejeté se voit dans les files, pas dans le graphe.

Surveiller `svp-harvester-batch`, `crisalid-ikg-publications-batch` et leurs files de rebut dans l'interface de RabbitMQ.

### Étape 4 — Vérifier dans le graphe

**Pourquoi :** constater quelles publications ont été créées, et depuis quelle source.

La requête emploie le nom observé sur l'instance, `ScholarlyPublication` ; le code lu écrit aussi `Document` ([correspondance des noms](./verifier-le-graphe-et-api#les-noms-du-code-et-ceux-de-linstance)).

```cypher
MATCH (p:Person {uid: $uid})-[:HAS_CONTRIBUTION]->(:Contribution)<-[:HAS_CONTRIBUTION]-(d:ScholarlyPublication)
OPTIONAL MATCH (d)-[:RECORDED_BY]->(sr:SourceRecord)
OPTIONAL MATCH (d)-[:HAS_TITLE]->(t:Literal)
RETURN d.uid, collect(DISTINCT t.value) AS titres, collect(DISTINCT sr.harvester) AS sources;
```

## Ce que vous devez obtenir

- Des publications rattachées à la personne, chacune reliée à au moins une notice source.
- Des files revenues à zéro et des files de rebut vides.
- Le nombre de notices par source, noté tel quel pour le comparer à HAL.

## Limites

- **Non exécuté** : aucun moissonnage n'a été fait ; aucun résultat n'est montré.
- Le format des notices échangées sur le bus est **à confirmer** sur une exécution réelle.
- La classification thématique (`TAXI_ENABLED`) est désactivée par défaut.

## Et ensuite

Étape 4 sur 4 : [vérifier le graphe et l'API](./verifier-le-graphe-et-api).

Révision lue : `crisalid-ikg` `ebdaae75`, `svp-harvester` `6898db85`.
