Le processus de détection des doublons repose sur la création d’un vecteur de déduplication pour chaque notice Alma. Ce vecteur inclut une ou plusieurs clefs qui sont construites à partir des métadonnées bibliographiques.
Les notices marquées comme doublons sont alors affichées comme un seul enregistrement dans les résultats de recherche. Les métadonnées sont extraites de la première notice dans la liste des résultats.
Articulation du Dedup et du FRBR
Les processus Dedup et FRBR sont similaires, mais utilisent différentes clés. Le système recherche d’abord les doublons, puis les groupes FRBR. Ainsi, des notices fusionnées peuvent être également « FRBRisé ».
Flux de Traitement Dedup/FRBR
1. Calcul des clés :
Le système extrait des champs de la notice Alma (comme l’auteur, le titre, l’ISBN, etc.) et crée des clés en combinant et normalisant ces données. Ces clés sont utilisées pour identifier les enregistrements similaires.
2. Recherche des clés existantes :
Le système compare les clés nouvellement calculées avec celles déjà présentes dans la base de données. Si une correspondance est trouvée, cela signifie que la notice en cours de traitement pourrait avoir un doublon. Le système associe donc à la clef nouvellement créée l’identifiant du groupe déjà présent dans Alma.
En cas de correspondances multiples, le système sélectionne l’identifiant de groupe associé à la clé de priorité la plus élevée. On ne connait malheureusement pas le niveau de prorité affecté à chaque clef.
Si plusieurs clés ont la même priorité, l’identifiant de groupe est choisi de manière aléatoire.
En l’absence de clé existante, le système utilise la clé de priorité la plus élevée pour créer un nouvel identifiant de groupe et l’associé à la notice.
3. Stockage de l’identifiant de Groupe :
Une fois l’identifiant de groupe sélectionné, il est stocké pour toutes les clés calculées à l’étape 1.
Transitivité du Dedup
Le processus de fusion n’est pas entièrement transitif, ce qui signifie que si une notice A correspond à une notice B, et que la notice B correspond à une notice C, A ne correspondra pas nécessairement à C. Cela peut se produire en raison de la manière dont les clés sont calculées et priorisées. En effet, l’ordre dans lequel les enregistrements sont traités peut influencer les groupements.
Voici un exemple :
- Ajout de la noticeB :
- B est ajoutée à la base de données.
- Aucune correspondance n’est trouvée, donc B est considéré comme unique.
- Ajout de la noticeC :
- C est ajoutée à la base de données.
- Aucune des clés de C ne correspond à celles de B.
- C est également considéré comme unique.
- Ajout de la notice A :
- A est ajoutée à la base de données. Il a des clefs qui correspondent avec B et C
- Une des clés de A correspond à une clé de B.
- Le système arrête de traiter A dès qu’il trouve une correspondance avec B, car il a trouvé un groupe existant.
- A est donc ajouté au groupe de B, formant le groupe AB.
Calcul des clés
Type de Clé
Chaque clé dans le système Primo VE possède un type qui indique au système quelles définitions de clé utiliser pour une notice donnée. Ce type est crucial pour déterminer comment les enregistrements sont traités dans les processus de déduplication.
Le champ match/t
définit ainsi le type de clé pour le processus de déduplication :
- Valeur
1
: Indique que la notice n’est pas une notice de publication en série. - Valeur
2
: Indique que la notice est une notice de publication en série.
Construction des champs dédiés : mapping des champs Alma en clés Dedup
Champs prédéfinis
Clé | Contenu du champ | Type | Champ MARC 21 | Champ DC | Champ UNIMARC | Champ BIBFRAME |
---|---|---|---|---|---|---|
C5 | Numéro de contrôle | 1+2 | 035 a,z | N/A | 035 a,z | bf:identifiedBy – bf:Local – rdf:value |
F1 | LCCN | 1+2 | 010 a | dcterms:identifier dcterms:LCCN | N/A | bf:AdminMetadata – bf:identifiedBy – bf:Lccn |
F3 | ISBN | 1 | 020 a,e | dcterms:identifier dcterms:ISBN | 010 a | bf:identifiedBy – bf:Isbn |
F3 | ISSN | 2 | 022 a,e | dcterms:identifier dcterms:ISSN | 011 a | bf:identifiedBy – bf:Issn |
F4 | ISBN_invalid | 1 | 020 z | N/A | 010 z | bf:identifiedBy – bf:Isbn – rdf:value – bf:status- bf:Status |
F4 | ISSN_invalid | 2 | 022 y | N/A | 011 y | bf:identifiedBy – bf:Issn – rdf:value – bf:status- bf:Status |
F5 | Titre abrégé | 1 | 245 a,b,n,p | dc.title, dcterms.title | 200 a | bf:title – bf:Title |
F5 | ISSN_cancelled | 2 | 022 z | N/A | 011 z | bf:identifiedBy – bf:Issn – rdf:value – bf:status- bf:Status |
F6 | Année de début de publication | 1+2 | 008 (positions 7-10) | dc.date, dcterms.date | 210 d, 100 a (positions 9-16) | bf:provisionActivity – bf:Publication – bf:date |
F7 | Titre complet | 1+2 | 245 a,b,n,p | dc.title, dcterms.title | 200 a,e,d,h,i | bf:title – bf:Title |
F8 | Pays de publication | 1 | 008 (positions 15-17) | N/A | LDR position 7 = m ou c AND MARC is « 102 ». »a » | bf:provisionActivity – bf:Publication – bf:place |
F8 | Titre abrégé | 2 | 245 a | dc.title, dcterms.title | LDR position 7 = a, i, ou s AND MARC is « 200 ». »a » | bf:title – bf:Title |
F9 | Pagination | 1 | 300 a | N/A | LDR position 7 = m ou c AND MARC is « 215 ». »a » | N/A |
F9 | Pays de publication | 2 | 008 (positions 15-17) | N/A | LDR position 7 = a, i, ou s AND MARC.control is « 102 » « a » | bf:provisionActivity – bf:Publication – bf:place |
F10 | Éditeur | 1 | 260 b, 264 b | dcterms.publisher, dc.publisher | LDR position 7 = m ou c AND MARC is « 210 ». »c » | bf:provisionActivity – bf:Publication – bflc:simpleAgent |
F10 | Lieu de publication | 2 | 260 a, 264 a | N/A | LDR position 7 = a, i, ou s AND MARC is « 200 ». »a » | bf:provisionActivity – bf:Publication – bflc:simplePlace |
F11 | Entrée principale (auteur, organisme, réunion) | 1 | 100 a,b,c,d,q, 111 a,c,d,e,n,q | dc.creator, dcterms.creator | LDR position 7 = m ou c AND 700 a,b,c,d,f, 710 1st ind. = 1 a-h | bf:contribution – bf:PrimaryContribution |
F11 | Entrée principale (auteur, organisme, réunion) | 2 | 110a ,b,c,d,e,n, 111 a,c,d,e,n,q, 130 a,d,l,m,n,o,p,r,s,t | dc.creator, dcterms.creator | LDR position 7 = a, i, ou s AND 710 1st ind. = 0 a,b,c,g,h, 710 1st ind. = 1 a-h, 500 a,b,h,i,k,l,m | bf:contribution – bf:PrimaryContribution |
F13 | Numéro de contrôle | 1+2 | 001 | N/A | 001 | MMSID (bf:adminMetadata – bf:AdminMetadata – bf:identifiedBy – bf:Local – rdf:value – bf:source « ALMA ») |
F50* | URI de l’œuvre | 1+2 | N/A | N/A | N/A | bf:Work – RDF:about |
Champs locaux
Clef | Format | Champ | Description |
L1 | Unimarc | 902 | Numéro de partie + Titre de partie (200$h_200$i) : permet d’éviter les regroupements des monographies en plusieurs volumes partageant le même ISBN |
L2 | Marc21 | 902 | Numéro de partie + Titre de partie (245$n_245$p) : permet d’éviter les regroupements des monographies en plusieurs volumes partageant le même ISBN |
L3 | Unimarc | 903 | PPN en 035, 452, 455, 456 |
L4 | Marc21 | 903 | PPN en 035 et 776 |
Création des clefs
Les champs de données sont ensuite normalisés et combinés pour créer les clés de Dedup.
Concaténation des Champs
La concaténation des champs permet de créer des clés en combinant plusieurs champs de données. Si un champ a plusieurs entrées, le système crée plusieurs clés en combinant toutes les entrées possibles des champs.
Explication pour la définition de la Clé : match/f1 + match/f7
- f1 : Contient les entrées :
a
,b
- f7 : Contient les entrées :
c
,d
- Clés Créées :
ac
,ad
,bc
,bd
Méthodes de Normalisation
Les méthodes de normalisation sont appliquées aux valeurs des champs pour standardiser les données et améliorer la correspondance des enregistrements. Voici les méthodes utiisés :
- FUZZY_STRING : Utilise les cinq premiers mots de la valeur du champ. Cela aide à ignorer les petites différences dans les titres ou descriptions.
- ROUND_NUMBER : Arrondit le dernier chiffre de la valeur du champ à 0.
- Exemples :
11
devient10
199
devient190
- Exemples :
- REMOVE_COMMON_WORDS : Supprime certains mots courants qui peuvent ne pas être pertinents pour la correspondance, tels que « annual report », « bulletin », « proceedings », etc.
- SPLIT : Lorsqu’un enregistrement a plusieurs identifiants (comme ISSN/ISBN), cette méthode crée des clés séparées pour chaque identifiant. Cela permet de faire correspondre des enregistrements qui partagent au moins un identifiant commun.
Champs Optionnels
- Définition : Lors de la création d’une clé à partir de plusieurs champs, certains champs peuvent être optionnels. Ils sont indiqués par des crochets ([]).
- Exemple :
match/f1 + [match/f7]
signifie quematch/f7
n’est pas obligatoire pour créer la clé.
Définitions des clés Dedup
Clefs prédéfinnies
Clé complète | Type | Description |
---|---|---|
match/c5 | 1 | Numéro de système externe |
match/f1 + match/f5 + match/f6 | 1 | LCCN + titre abrégé + année |
match/f1 + FUZZY_STRING(match/f7) + match/f6 | 1 | LCCN + titre flou + année |
match/f1 + match/f7 + match/f6 | 1 | LCCN + titre complet + année |
match/f3 + match/f5 + match/f6 | 1 | ISBN + titre abrégé + date |
match/f3 + match/f7 + match/f9 | 1 | ISBN + titre complet + pagination |
SPLIT(match/f3) + match/f5 + match/f6 | 1 | ISBN1 + titre abrégé + date, ISBN2 + titre abrégé + date |
SPLIT(match/f3) + FUZZY_STRING(match/f7) + match/f6 | 1 | ISBN1 + titre flou + date, ISBN2 + titre flou + date |
SPLIT(match/f3) + match/f7 + match/f9 | 1 | ISBN1 + titre complet + pagination, ISBN2 + titre complet + pagination |
match/f4 + match/f7 + match/f6 | 1 | ISBN incorrect + titre complet + date |
match/f4 + match/f7 + match/f9 | 1 | ISBN incorrect + titre complet + pagination |
SPLIT(match/f4) + match/f7 + match/f6 | 1 | ISBN incorrect1 + titre complet + date, ISBN incorrect2 + titre complet + date |
SPLIT(match/f4) + match/f7 + match/f9 | 1 | ISBN incorrect1 + titre complet + pagination, ISBN incorrect2 + titre complet + pagination |
match/f7 + match/f11 + match/f6 + match/f9 | 1 | Titre complet + entrée principale + date + pagination |
match/f7 + match/f11 + match/f6 + ROUND_NUMBER(match/f9) | 1 | Titre complet + entrée principale + date + pagination floue |
match/f7 + match/f6 + match/f10 + match/f9 + [match/f11] | 1 | Titre complet + date + éditeur + pagination + [entrée principale] |
match/f7 + match/f6 + match/f10 + ROUND_NUMBER(match/f9) + [match/f11] | 1 | Titre complet + date + éditeur + pagination floue + [entrée principale] |
match/f7 + match/f6 + match/f9 + [match/f11] | 1 | Titre complet + date + pagination + [entrée principale] |
match/f7 + match/f6 + ROUND_NUMBER(match/f9) + [match/f11] | 1 | Titre complet + date + pagination floue + [entrée principale] |
match/f7 + match/f6 + match/f10 + [match/f11] | 1 | Titre complet + date + éditeur + [entrée principale] |
match/c5 | 2 | ID MMS |
match/f1 + match/f8 | 2 | LCCN + titre abrégé |
match/f3 + match/f8 | 2 | ISSN + titre abrégé |
SPLIT(match/f3) + match/f8 | 1 | ISSN1 + titre abrégé, ISSN2 + titre abrégé |
REMOVE_COMMON_WORDS(match/f7) + match/f10 + match/f9 + [match/f11] | 2 | Titre complet (non dans la liste des titres courants) + lieu de publication + pays de publication + Entrée principale conditionnelle |
REMOVE_COMMON_WORDS(match/f7) + match/f10 + match/f9 + [match/f11] + [SPLIT(match/f3)] | 2 | Titre complet (non dans la liste des titres courants) + lieu de publication + entrée principale (conditionnelle) + ISSN1 conditionnel, Titre complet (non dans la liste des titres courants) + lieu de publication + entrée principale (conditionnelle) + ISSN2 conditionnel |
REMOVE_COMMON_WORDS(match/f7) + match/f6 + match/f11 | 2 | Titre complet (non dans la liste des titres courants) + date + entrée principale |
match/f7 + match/f6 + match/f11 + match/f10 | 2 | Titre complet (peut être dans la liste des titres courants) + date + entrée principale + lieu de publication |
REMOVE_COMMON_WORDS(match/f7) + match/f6 + match/f11 + match/f10 | 2 | Titre flou (non dans la liste des titres courants) + date + entrée principale + lieu de publication |
Clefs adaptées ou créees localement
Clef complète | Type | Descrition |
SPLIT(match/f3) + FUZZY_STRING(match/f7) + match/f6 + [localKey/L1] + [localKey/L2] | 1 | ISBN + fuzzy Full title + Start publication year + Numéro de partie_Titre de partie + Numéro de partie_Titre de partie (Marc21) : permet d’éviter les regroupements des monographies en plusieurs volumes partageant le même ISBN. |
[localKey/L3] + [localKey/L4] | 1/2 | Clef PPN 035 et 452 + Clef PPN 035 et 776 : regroupement sur la base des PPNs |
Affichage des notices
Primo VE est configuré pour privélégier les données de la notice du document physique. Mais, à la différence de Primo BO, le système détermine en amont des identifiants de regroupements et fusionne les notices au moment de l’affichage. Ainsi, en cas de fusion de deux notices, le système affichera la notice en fonction des métadonnées qui répondent à la recherche :
- Affichage de la notice de l’imprimé si les métadonnées qui répondent sont communes aux deux notices ou proviennent de la notice de l’imprimé. Exemple : recherche au titre d’un périodique
- Affichage de la notice de l’électronique, si les métadonnées qui répondent proviennent de la notice électronique. Exemple : recherche d’un titre via l’ EISSN du même titre
Recalculer les clefs de Dedup
Configuration > Decouverte > Autre > Utilitaire de test Dedup et FRBR
L’option Recalculer les groupes FRBR et Dedup permet de forcer recalcul des groupes FRBR et Dedup.
Date de publication
Mis à jour le
Attention ! Certains établissements utilisent parfois de procédures complémentaires