search

assemblee-virtuelle / pair

Ontologie PAIR: Projets, Acteurs, Idées, Ressources
http://www.virtual-assembly.org/
GNU Affero General Public License v3.0
23 stars 6 forks source link

Supprimer des relations inverses #173

Open tfrancart opened 3 years ago

tfrancart commented 3 years ago

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:

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.

srosset81 commented 3 years ago

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

tfrancart commented 3 years ago

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.

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.

srosset81 commented 3 years ago

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

tfrancart commented 3 years ago

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:

  1. 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.
  2. 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.

GuillaumeAV commented 3 years ago

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)"

tfrancart commented 3 years ago

Le lun. 19 avr. 2021 à 09:59, Guillaume @.***> a écrit :

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 https://github.com/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.

Je pense qu'il ne s'agirait pas de doubler un appel LDP avec une requête SPARQL depuis le client. Il s'agirait d'enrichir ce que retourne la requête LDP pour y inclure les relations inverses (tout ce qui pointe sur le sujet en question). Cette enrichissement se ferait sur la base d'une requête SPARQL ou pas, je ne connais pas l'implémentation.

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,

L'enrichissement du flux LDP côté serveur permettrait une mise en cache.

J'ajoute un point à la discussion pour insister sur l'importance de ces vocabulaires contrôlés : pour maximiser l'interopérabilité entre projets, c'est non seulement l'ontologie PAIR qui sera importante, mais également les vocabulaires contrôlés : types d'organisation, statuts de documents, sujets, etc... l'importance de pouvoir échanger et mettre à jour ces vocabulaires contrôlés depuis l'extérieur du système, pour partager certains référentiels communs, sera importante. A ce titre 1/ les vocabulaires contrôlés devraient être isolés du reste des données 2/ il devrait être possible de mettre à jour ces vocabulaires contrôlés depuis l'extérieur 3/ il y a sûrement des questions de droits d'accès à ces vocabulaires contrôlés pour que tous les utilisateurs n'aient pas le droit de les éditer / créer 4/ le vocabulaire contrôlé a une existence autonome du reste des données. Donc les liens d'indexation sont mis vers les concepts des vocabulaires contrôlés, et non pas depuis les fiches des concepts vers les instances.

Thomas

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)"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/assemblee-virtuelle/pair/issues/173#issuecomment-822259445, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU2H4KDFWND56XOAPC5BALTJPPEZANCNFSM42I4FSMQ .

--

Thomas Francart - SPARNA Web de données | Architecture de l'information | Accès aux connaissances blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas

GuillaumeAV commented 3 years ago

Je me dis qu'il est sans doute judicieux que tu jettes un oeil à cette discussion @simonLouvet ;)

simonLouvet commented 3 years ago

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 :

tfrancart commented 3 years ago

... 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 :

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...

srosset81 commented 3 years ago

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.

simonLouvet commented 3 years ago

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.

tfrancart commented 3 years ago

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.

GuillaumeAV commented 3 years ago

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 ;) https://github.com/assemblee-virtuelle/semapps/issues/741

simonLouvet commented 3 years ago

@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.

srosset81 commented 2 years ago

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 ?

simonLouvet commented 2 years ago

@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?

srosset81 commented 2 years ago

Oui c'est faisable. Qu'est-ce qui intéressant conceptuellement ?

simonLouvet commented 2 years ago

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.