Supprimer des relations inverses
Opened this issue · 18 comments
La création systématique de relations inverses complique la maintenance de l'ontologie et sa compréhension.
Ce n'est pas une bonne pratique.
Je propose de supprimer des relations inverses:
-
dans les relations entre les "concepts" et les "sujets", garder seulement le sens sujet -> concept, donc supprimer:
- branchOf
- domainOf
- sectorOf
-
dans les relations entre les entités PAIR et les concepts, garder seulement le sens entité -> concepts, donc supprimer:
- topicOf
- typeOf et ses sous-propriétés
- ne pas introduire d'inverse pour "hasStatus"
-
dans les relations entre les sujets et le niveau "intentionel", garder seulement le sens sujet -> niveau intentionnel, donc supprimer:
- aimedBy
- challengeOf
- mobilizedBy
-
Supprimer les relations inverses sur les associations, en prenant comme règle d'avoir une structure "en étoile" où les propriétés sont portées par l'association. Donc supprimer :
- activityOfInvolvement
- actorOfInvolvment
- actorOfMembership
- organizationOfMembership
La suppression de ces relations inverses n'empêche pas le parcours du graphe; il y a peut-être par contre des contraintes que je ne connais pas dans SemApps et dont il faudrait qu'on discute.
Avec SemApps nous faisons un usage intensif des relations inverses, cela nous permet de créer automatiquement ces relations et de fournir des pages plus riches. Par exemple pair:topicOf nous permet de visualiser tous les sujets qui ont un Theme comme intérêt/sujet.
Je ne comprends pas quel est le problème. Si c'est juste une question de maintenance, je propose que nous soyons plusieurs à être formé à la mise à jour de l'ontologie, afin que ça ne repose pas que sur tes épaules.
Ping @simonLouvet
Avec SemApps nous faisons un usage intensif des relations inverses, cela nous permet de créer automatiquement ces relations et de fournir des pages plus riches. Par exemple pair:topicOf nous permet de visualiser tous les sujets qui ont un Theme comme intérêt/sujet.
0n est donc bien sur une question d'affichage et de navigation. Pourquoi ne pas faire une requête pour récupérer les liens entrants sur une ressource ? Vous partez du principe que l'information qui est affichée à l'écran doit être la même que la structure du graphe sous-jacent. C'est trop simple. Les 2 niveaux (structure du graphe et présentation à l'écran) doivent pouvoir être décorellés.
D'autant que sur un Topic par exemple, qui sert de pivot et qui va être référencé par plein d'objets, on va avoir beaucoup de liens entrants, donc une liste très longue qui ne sera pas utilisable au final.
Je ne comprends pas quel est le problème. Si c'est juste une question de maintenance, je propose que nous soyons plusieurs à être formé à la mise à jour de l'ontologie, afin que ça ne repose pas que sur tes épaules.
- Ca pose des petits soucis de maintenance (quand j'oublie des inverses, etc.)
- On double le nombre de relations à documenter, traduire, expliquer, etc.
- On risque de perdre les utilisateurs ("mais dans quel sens il faut que je mette la propriété")
- On va doubler le nombre de triplets dans le triplestore si on infère toutes les inverses
Pour les propriétés que je propose de supprimer, c'est parce qu'il me semble qu'elles sont toujours saisis dans le sens que je propose de conserver. Pour saisir un sujet, je pars du principe qu'on est sur une fiche d'entité et qu'on saisit son lien "hasTopic", on ne se met pas sur la page du Topic pour référencer toutes les entités dont ce Topic est le sujet.
Notez que je ne propose pas de supprimer toutes les inverses, mais les inverses entre des niveaux conceptuels différents.
0n est donc bien sur une question d'affichage et de navigation. Pourquoi ne pas faire une requête pour récupérer les liens entrants sur une ressource ? Vous partez du principe que l'information qui est affichée à l'écran doit être la même que la structure du graphe sous-jacent. C'est trop simple. Les 2 niveaux (structure du graphe et présentation à l'écran) doivent pouvoir être décorellés.
Pour l'interface SemApps, nous faisons surtout des requêtes LDP simples, qui permettent de retourner toutes les relations d'une ressources. S'il fallait doubler ça avec des requêtes SPARQL, cela compliquerait beaucoup le code. Et cela poserait des problèmes de performances, car pour le moment les ressources LDP utilisent un cache Redis et leur requête est hyper rapide, tandis que les SPARQL sont plus lentes et utilisent plus de ressources serveurs (ce qui peut poser un problème quand le nombre de visiteurs sur une instance augmente).
D'autant que sur un Topic par exemple, qui sert de pivot et qui va être référencé par plein d'objets, on va avoir beaucoup de liens entrants, donc une liste très longue qui ne sera pas utilisable au final.
Pas utilisable, pourquoi ? C'est juste une question de créer une interface adaptée.
En tout cas les longues listes ne posent pas de problème de performance puisque les ressources LDP sont mises en cache.
- Ca pose des petits soucis de maintenance (quand j'oublie des inverses, etc.)
- On double le nombre de relations à documenter, traduire, expliquer, etc.
- On risque de perdre les utilisateurs ("mais dans quel sens il faut que je mette la propriété")
- On va doubler le nombre de triplets dans le triplestore si on infère toutes les inverses
Aucun de ces problèmes ne me semblent insurmontables, surtout si on est plusieurs à assurer la maintenance. Et je ne trouve pas que les relations inverses posent un souci aux utilisateurs, au contraire si elles n'existaient pas et qu'il fallait les "deviner", cela deviendrait compliqué à expliquer.
Pour les propriétés que je propose de supprimer, c'est parce qu'il me semble qu'elles sont toujours saisis dans le sens que je propose de conserver. Pour saisir un sujet, je pars du principe qu'on est sur une fiche d'entité et qu'on saisit son lien "hasTopic", on ne se met pas sur la page du Topic pour référencer toutes les entités dont ce Topic est le sujet.
C'est pourtant ce qu'on fait sur plusieurs instances, et ça a du sens. Par exemple sur cette instance en cours de dev:
https://colibris-local-groups.vercel.app/Theme/https%3A%2F%2Fdev.colibris.social%2Fthemes%2Fculture/show
Pas utilisable, pourquoi ? C'est juste une question de créer une interface adaptée.
Parce qu'à un moment, un listing de centaines ou de milliers d'entités ne sert plus à rien.
C'est pourtant ce qu'on fait sur plusieurs instances, et ça a du sens. Par exemple sur cette instance en cours de dev:
https://colibris-local-groups.vercel.app/Theme/https%3A%2F%2Fdev.colibris.social%2Fthemes%2Fculture/show
Ca a peut-être du sens pour le genre de projets que fait l'AV, mais je vois au moins 2 raisons pour lesquelles on ne saisit pas une relation entre un Concept (au sens SKOS, cad une entrée dans une terminologie / un vocabulaire contrôlé) et une autre entité depuis la fiche du Concept:
- Le vocabulaire contrôlé... est contrôlé; donc n'importe qui n'y a pas accès en écriture en principe; on est sur des listes ou des vocabulaires qui servent de support à la description des autres entités dans le graphe.
- Le vocabulaire contrôlé peut venir de l'extérieur du système et être mis à jour de façon indépendante des autres données. Dans ce cas, typiquement on vient remplacer le graphe nommé qui contient le vocabulaire contrôlé.
Vos projets ont sans doute leurs spécificités mais je n'ai jamais vu aucun système à base de graphe où les indexations étaient exprimées depuis la fiche des Concepts.
Helloo !
Mince la discussion semble être arrêtée ... J'ai l'impression qu'il y a des arguments valables des 2 côtés.
Les problématiques liées à LDP / Sparql listées ci-dessous sont solubles à ton avis @tfrancart ?
"Pour l'interface SemApps, nous faisons surtout des requêtes LDP simples, qui permettent de retourner toutes les relations d'une ressources. S'il fallait doubler ça avec des requêtes SPARQL, cela compliquerait beaucoup le code. Et cela poserait des problèmes de performances, car pour le moment les ressources LDP utilisent un cache Redis et leur requête est hyper rapide, tandis que les SPARQL sont plus lentes et utilisent plus de ressources serveurs (ce qui peut poser un problème quand le nombre de visiteurs sur une instance augmente)"
Je me dis qu'il est sans doute judicieux que tu jettes un oeil à cette discussion @simonLouvet ;)
Bonjour à tous, alors que j'étais d'accord avec @srosset81 en première posture, je comprends la position de @tfrancart et je pense qu'il à raison dans l'absolue.
Concernant Semapps, je voie plusieurs possibilités :
- Possibilité 1 : les relations inverses existent dans l'ontologie : la version actuel de Semapps créé des relations inverses à partir de l'ontologie.
- Possibilité 2 : Les relations inverses n’existent pas dans l'ontologie : amélioration du moteur LDP. Le moteur LDP de Semapps pourrait être amélioré pour retourner les triplet qui ont comme objet le/les sujet retourné. Je voie encore un probleme à cette solution. Si aucune relation inverse n'est formalisé dans l’otologie, quel prédicat va être utilisé pour exprimer cette relation inverse? Il me semble que si nous ne pouvons pas exprimer cette relation inverse (par manque d'ontologie) la requête LDP get sur un sujet devra contenir d'autres sujets avec leur relation vers le sujet requêté. Cela n'est pas vraiment cohérent avec la logique LDP et va complexifier de dataProvider de l'interface web.
- Possibilité 3 Les relations inverses n’existent pas dans l'ontologie : configuration du dataProvier. Le dataProvider (react-admin) pourrait recréer les relation inverse par configuration. même probleme que pour la possibilité 2 concernant le nommage des relation inverse qui n'existent pas.
- Possibilité 4 : Les relations inverses n’existent pas dans l'ontologie : création de composant d'interface adaptés. C'est la solution qu'a mis en place @srosset81 pour le moment. C'est techniquement valable de faire comme cela mais cela va nécessiter la création de beaucoup de component d'interface en fonction des besoins il me semble.
... Si aucune relation inverse n'est formalisé dans l’otologie, quel prédicat va être utilisé pour exprimer cette relation inverse?
Aucun ! pourquoi vouloir absolument une relation inverse ?
Il me semble que si nous ne pouvons pas exprimer cette relation inverse (par manque d'ontologie) la requête LDP get sur un sujet devra contenir d'autres sujets avec leur relation vers le sujet requêté.
Oui !
Cela n'est pas vraiment cohérent avec la logique LDP
Je ne vois vraiment pas en quoi ce n'est pas cohérent.
La description d'une ressource en RDF n'est pas nécessairement constituée seulement des triplets dont cette ressource est le sujet. Prendre cette hypothèse est une erreur. Elle peut contenir :
- des triplets dont la ressource est l'objet
- les libellés (rdfs:label) des objets dont la ressource est le sujet
- tous les triplets dont le sujet est un noeud anonyme objet d'un triplet dont la ressource est sujet (et récursivement : tant qu'on trouve un noeud anonyme, on continue à suivre)
- etc.
On parle de Concise Bounded Descriptions (CBD) des ressource, et il y a plein d' implémentations possibles pour cela.
LDP spécifie seulement ceci :
4.3.1.4 LDP servers MUST provide an RDF representation for LDP-RSs.
The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response.
Donc on est complètement agnostique sur le contenu du RDF retourné.
et va complexifier le dataProvider de l'interface web.
Là, sur toute cette partie dataProvider, je ne peux pas avoir d'avis...
Même si je comprends que certaines relations inverses sont moins pertinentes que d'autres, je ne vois toujours pas pourquoi on ne pourrait pas laisser la liberté à chacun de choisir de les implémenter, ou pas.
En tout cas si on change ça, ça va casser le code de plusieurs instances SemApps, donc j'y suis opposé, sauf si quelqu'un veut passer plusieurs heures sur le sujet (j'ai de mon côté d'autres sujets qui sont largement plus prioritaires).
Ce sont des réflexions intéressantes, et on va y réfléchir, mais pour le moment je pense qu'il vaut mieux ne rien toucher à l'existant.
Je partage l'avis de seb.
Semapps n'est pas actuellement en capacité de faire autrement que d'avoir les relation inverses formalisés dans l'ontologie pour fournir l'interface et l'ergonomie attendu par les usages. Faire autrement va nous couter tu temps de réflexion / conception / R&D que nous n'avons pas encore le luxe d'avoir. Je suis donc pour créer et maintenir les relations inverses dans l'ontologie PAIR pour le moment (pas obligatoirement @tfrancart si tu n'en a pas l’énergie) et de mettre en place un chantier pour s'en passer.
je ne vois toujours pas pourquoi on ne pourrait pas laisser la liberté à chacun de choisir de les implémenter, ou pas.
Probablement parce qu'on ne fait pas que modéliser un domaine de connaissances dans l'absolu, mais on oriente également des usages.
Prend ActivityStream par exemple : aucune relation inverse n'est définie (je crois) On peut dire Activity -- actor --> Object mais pas Object -- ???? --> Activity (vous me corrigez si je me trompe). Parce que ActivityStream est orienté sur certains usages qui sont les descriptions d'activités.
Je suis donc pour créer et maintenir les relations inverses dans l'ontologie PAIR pour le moment (pas obligatoirement @tfrancart si tu n'en a pas l’énergie) et de mettre en place un chantier pour s'en passer.
Si on est d'accord sur le fond et l'objectif je n'ai aucun avis sur le planning et les priorités. Ma remarque n'avait pas de caractère d'urgence. On peut continuer à maintenir les relations inverses dans PAIR jusqu'à ce que SemApps sache prendre en compte ce cas de figure. Je n'ai pas de problèmes pour continuer à les maintenir.
Génial, vive les discussions constructives qui aboutissent à des points de vue convergents. On peut donc envisager de budgetter du temps homme pour adapter SemApps dans un temps ultérieur en vue de simplifier PAIR dans une release ultérieure :)
Voici l'issue SemApps dédiée ;) assemblee-virtuelle/semapps#741
@tfrancart Passerelle Normandie à toujours besoin de la relation réifiées bidirectionnelle inverse entre personne et organisation. Est ce que tu peux formaliser les relations inverse sur MembershipAssociation, Organisation et Actor? Je peux donner un cop de main si besoin.
Je remarque sur l'instance Colibris que la relation topicOf est non seulement inutile, mais qu'elle charge très lourdement les données. Voir par exemple https://colibris.social/themes/alimentation-et-agriculture
Je serai favorable à la suppression a minima des deux premiers groupes proposés par @tfrancart :
dans les relations entre les "concepts" et les "sujets", garder seulement le sens sujet -> concept, donc supprimer:
- branchOf
- domainOf
- sectorOf
dans les relations entre les entités PAIR et les concepts, garder seulement le sens entité -> concepts, donc supprimer:
- topicOf
- typeOf et ses sous-propriétés
- ne pas introduire d'inverse pour "hasStatus"
Qu'en penses-tu @simonLouvet ?
@srosset81 je comprends mais je trouve les relation inverse toujours aussi intéressante conceptuellement (otologie). La question est donc l’implémentation. On pourrait peut être configuré le service inférence pour ne pas générer certaines relations inverses?
Oui c'est faisable.
Qu'est-ce qui intéressant conceptuellement ?
il me semble intéressant de formaliser le concept de lien inverse entre 2 prédicat dans l'ontology pour ne pas perdre cette information mais de l'exploiter quand bon nous semble. Il est par exemple possible de ne pas calculer/stoker le lien inverse mais de réaliser une inférence à la lecture de données pour l'exprimer si besoin.