Advanced entities merge feature #23
Replies: 2 comments
-
Merci pour ces réflexions! J'ai déjà deux questions:
|
Beta Was this translation helpful? Give feedback.
-
Questions additionnelles, qui surviennent lors de merge manuels: Comment gérer les dupplicatas de valeur mais pas d'entités: Exemple 0: (facile) Exemple 1: (moins facile) Exemple 2: (plus difficile) Quelle stratégie adopter? |
Beta Was this translation helpful? Give feedback.
-
Discussion between @gaetanmuck and @valamercery about Entities merge (in French).
@valamercery - J'ai créé un projet Doublons pour repérer les entités redondantes.
@gaetanmuck - Pourquoi les mettre dans un projet dédié?
V - parce qu'on est obligé de rattacher les deux entités à un projet pour ajouter cette propriété. Donc cela peut apporter de la confusion. Là on pourra ajouter toutes les entités concernées au projet et choisir celle qui doit être préférée en utilisant la propriété. Par exemple, j'ai trouvé quatre entités pour Naples : je les ai toutes ajoutées au projet Doublons, j'ai cherché quelle entité était la plus utilisée et je l'ai reliée aux autres via "should be prefered to"
G - Ok, et comment les projets sauront que leur entités sont dupliquées (le projet qui a la "fausse" entité)?
V - comme c'est conçu aujourd'hui, les projets n'en sauront rien. Il faudrait pour cela développer une fonctionnalité spéciale.
G - Oui tout à fait. Et ajouter à cette fonctionnalité:
Ne pas montrer dans les recherches les entités qui on la proriété sortante
Merge les informations des "filles" dans les entités "mères"
V - oui c'est ça, on pourra merge une fois qu'on aura repéré un certain nombre de doublons
G - Mais tout ça nécessite pas mal de travail d'abord de spécification, pour savoir ce qu'on fait (par ex avec les URI des "fausses" entités sur GV public, une redirection?) , et ensuite l'implémentation de tout ça. On dirait que c'est un gros gros morceau cette feature.
V - tout à fait, c'est pour cela que je propose d'abord qu'on travaille sur le repérage. Et dans les formations, il faudra insister sur ce point : chercher d'abord si l'entité existe avant de la créer.
G - Dans l'idéal, tout se passerait automatiquement lorsque cette propriété est mise (trigger sur l'id de la propriété; merge des infos; redirections de l'URI, remplacement des fausses entités)
V - ça serait génial
G - Parce que sinon on va résoudre le problème que temporairement à chaque fois
V - oui dans mon idée, on faisait tourner un script de temps en temps mais la fonctionnalité automatique est bcp mieux. en revanche il faudrait limiter l'utilisation de cette fonction aux admins data pour éviter les utilisations erronées
G - Je vois le problème si tous les utilisateurs ont accès à cette fonction
V - encore mieux : pour lier deux entités d'un même projet, on autorise les membres du projet à utiliser la propriété de merge. Mais si les entités appartiennent à deux projets différents, seuls des utilisateurs autorisés peuvent le faire
G - pas mal ça. ça pourrait aussi être utile pour les projets qui ont ces problématiques, par exemple avec solidamin, on aurait pu ajouter tout le monde, et puis ensuite au fur et à mesure qu'on identifie des gens, on rajoute les has to be merged with, et les données se nettoient d'elles meme. Mais qu'est ce qu'il se passe si l'entité créée dans mon projet est importée dans un autre projet, et ensuite je merge
V - en ce cas : pour lier deux entités d'un même projet qui n'appartiennent qu'à ce seul projet, on autorise les membres du projet à utiliser la propriété de merge. Mais si les entités appartiennent à deux projets différents ou si une entité appartenant à mon projet est déjà associée à un autre projet, seuls des utilisateurs autorisés peuvent le faire
G - Je vois tellement de travail avant d'arriver à là. déjà dans GV il n'y a pas différent rôle
V - on peut gérer les rôles par l'appartenance à un projet. Et l'association entre deux entités à merge peut se faire dans un projet particulier
G - Oui, un work around
Beta Was this translation helpful? Give feedback.
All reactions