Journal J'ai demandé le multi-database à Neo4J

Posté par  . Licence CC By‑SA.
16
20
août
2022

Pour ceux qui ne connaissent pas Neo4J est un système de base de donnée de type graphe populaire.

Pour un projet d'éditeur de taxonomies, j'ai proposé de l'utiliser car il semblait pleinement correspondre à notre besoin. Et de fait pour le moment ça marche bien.

Mais comme notre but est d'éditer différents graphes collaborativement (et différentes versions de celui-ci), j'aurais aimé utiliser une base de donnée pour chacun de ces graphes (dans mon cas pour chaque taxonomie, dans une déclinaison particulière, c'est à dire un ensemble d'améliorations).

Or au moment où je teste la création d'une nouvelle base de donnée en suivant la doc je me rends compte que la création de base de données distincts n'est possible que dans la version payante !

Je trouve ça un peu exagéré (surtout qu'il s'agit essentiellement d'avoir deux dossiers distincts avec les données). Je comprends bien le modèle freemium (édition communautaire vs édition d'entreprise) mais là le curseur me semble quand même un peu bas… si on peut avoir une seule base de donnée, ça ressemble plus à un produit de démo.

Je sais que j'ai la possibilité d'utiliser des labels pour "séparer les choses", mais tout de même ça ne me semble pas très sain (par exemple, là après une itération sur une taxonomie, j'aurais voulu pourvoir jeter la base et en créer une nouvelle, si j'ai plusieurs itérations en parallèle et une seule base, je ne pourrais jamais la "jeter").

Comme c'est un projet libre, je veux que ce soit réplicable par tout un chacun, donc il est pour moi hors de question de dépendre de manière centrale d'une fonction de la version entreprise.

Du coup j'ai ouvert une demande d'amélioration en espérant avoir gain de cause ! (qui sait).

J'ai posté ici pour savoir:

  • si certains veulent voter pour :-) et se manifester sur le bug
  • si certains ont des retours d'expérience sur ça, ou m'expliquent que je n'en ai pas besoin
  • si d'autres me conseillent de carrément utiliser autre chose (ça m'embêterait beaucoup, le fit étant très bon pour ce qu'on veut faire)
  • # Fuire l'open core

    Posté par  . Évalué à 10.

    C'est un modèle de plus en plus fréquent : un cœur libre, et des versions «étendues» (créer une base, quand même…) propriétaires payantes.
    Pour ma part, c'est simple : je fuis. No pasaran. Hors de question.
    Car il est alors impossible de contribuer au projet. Ben oui, tout dépend de la roadmap et des choix entre la version «open» et la version propriétaire. Impossible de savoir ce qui demain sera encore dans la version libre et ce qui sera dans la propriétaire.

    Je sais très bien qu'il est très difficile de trouver un modèle commercial sans passer par ce genre de solution. Mais pour ma part je n'accepte pas ce compromis là pour ma production. Après tout, des projets comme PostgreSQL n'ont jamais eu besoin d'un tel modèle pour vivre…

    • [^] # Re: Fuire l'open core

      Posté par  . Évalué à 6.

      Je suis d'accord que l'opencore est problématique. Mais c'est un peu facile comme réponse (c'est comme dire qu'il ne faut pas de firmware non-libre, ça empêche d'acheter un laptop un peu récent). Au final, ça ne résout pas le problème. Et d'ailleurs, il demande justement si tu as autre chose à proposer.

      Ensuite, dire "oui mais Postgres, ils y arrivent", c'est aussi une comparaison assez bancale, on parle déjà de projet qui ont presque 30 d'écart, ça fait une sacré différence pour bâtir une communauté de contributeur à une époque différente. De plus, le développement initial de Postgres a été financé par Berkeley si j'ai bien compris. Du coup, c'est plus facile de trouver des contributeurs sur un projet existant que de demander à plusieurs boîtes de se lancer sur projet pour le développer depuis le début. Et en plus, il y a de l'opencore avec Postgres, avec certains qui font un produit proprio basé sur Postgres.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Bienvenu au club…

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 21 août 2022 à 00:26.

    J’ai connu exactement la même chose il y a quelques mois quand j’ai voulu essayer Neo4J sur ma propre machine. Un des projets auxquels je contribue (Virtual Fly Brain) repose sur une base de données Neo4J et je voulais pouvoir expérimenter à ma guise, notamment pour apprendre le langage Cypher. Grosse déception au moment de me rendre compte que la version community est limitée à une seule base !

    Pour ce que ça vaut, un workaround (sale, mais qui fonctionne très bien avec la version community) est de lancer plusieurs instances du serveur, avec chacune son fichier de configuration et son dossier de données, et écoutant sur des ports différents. C’est loin d’être idéal, mais comme je ne m’en sers que pour expérimenter, ça fait l’affaire, faute de mieux.

    Néanmoins, j’évite au maximum de m’en servir — juste ce dont j’ai besoin pour faire ce que j’ai à faire sur VFB, qui est le seul projet sur lequel je travaille à utiliser Neo4J.

    Pour le reste, je me tourne plutôt vers des bibliothèques de manipulation de graphes RDF (et vers SPARQL comme langage de requête), comme Jena (Java) ou RDFLib et RDFLib-Endpoint (Python).

  • # « Taxonomies »

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 21 août 2022 à 02:03.

    Indépendamment de la question de Neo4J, un petit commentaire sur OpenFoodFacts et ses « taxonomies ».

    Ce que vous appelez une taxonomie, moi j’appelle ça une ontologie. Du coup je me demande si vous avez exploré les options existantes pour créer et manipuler des ontologies.

    Quand je vois par exemple que vous avez votre propre format de fichier pour stocker vos « taxonomies », je ne peux pas m’empêcher de penser que vous ré-inventez un peu la roue, alors qu’il existe déjà des formats standards comme OWL 2 (et ses différentes sérialisations), des bibliothèques dans plusieurs langages (OWL API en Java, Pronto en Python, Horned-OWL en Rust…), des éditeurs graphiques comme Protégé

    Outre la ré-utilisation de code et d’outils existants, une « taxonomie » sous la forme d’une ontologie standard favoriserait aussi la collaboration avec des projets comme la Food Ontology par exemple.

    Du coup je me demande :

    • Est-ce un oversight (pardon, mais ce ne serait pas la première fois qu’on se lance dans un projet en oubliant de regarder ce qui existe déjà¹) ?
    • Ou bien avez-vous bel et bien considéré les options existantes, mais conclu qu’elles ne convenaient pas (auquel cas je serais sincèrement curieux d’en connaître les raisons) ?

    ¹ Moi-même, je me suis déjà rendu coupable de ça… :D

    • [^] # Re: « Taxonomies »

      Posté par  . Évalué à 6.

      Comme ça m'a un peu intrigué comme questionnement, je me suis permis de regarder vite fait si c'était des concepts si étrangers.

      En fait, c'est pas pareil mais proche (je fais exprès pour le lien de 2013, y'en a des plus récents).

      Maintenant, comme tu le suggères, il y existe peut-être déjà des formats ouverts et interopérables pour le gérer leur stockage, ce n'était pas le but de ma recherche.

      Matricule 23415

      • [^] # Re: « Taxonomies »

        Posté par  . Évalué à 6.

        Les ontologies comportent généralement une composante de taxonomie, il s’agit de classer les concepts. Ça va généralement plus loin en permettant de spécifier des relations non taxonomiques également. Gégé est un être humain (taxonomie), il a un frangin (non taxonomique). Ou « l’homme est un animal » (taxonomie).

        Des langages comme RDF(S) et OWL permettent de relier les deux (un animal a une date de naissance). OWL permet d’aller plus loin et de faire des inférences logiques, par exemple si on considère que seuls les humains écrivent des romans on peut déduire que si machin a écrit un roman, c’est un être humain sans avoir à dire explicitement que c’est un humain.

        • [^] # Re: « Taxonomies »

          Posté par  . Évalué à 4. Dernière modification le 21 août 2022 à 12:02.

          La page wikipedia sur SKOS (un système de représentation des taxonomies indiqué dans l'autre page que je pointais) dit bien à la fin :
          SKOS is intended to provide a way to make a legacy of concept schemes available to Semantic Web applications, simpler than the more complex ontology language, OWL.

          Donc une ontologie décrite en OWL me semblerait vu cette description pouvoir représenter une taxonomie en SKOS. Je dirais que c'est surtout une question de besoin : a-t'on besoin de sortir l'artillerie ontologie dans le cas présent ? Ou est-ce qu'une taxonomie répond correctement au besoin initial ?

          Je ne peux pas répondre à cette question :)

          Matricule 23415

          • [^] # Re: « Taxonomies »

            Posté par  . Évalué à 4.

            C'est différent. Skos c'est pas uniquement les taxonomies précises mais aussi bien les thesauris donc tourné aussi vers les applications type vocabulaire contrôlé sans définition formelles mais avec des trucs plus vagues comme des relations de "ce concept se recoupe avec" sans trop expliquer formellement ce qui se recoupe ou ce qui se recoupe pas. Ça peut servir a annoter des documents avec les sujets qu'ils traitent. Après tu peux suggérer aux utilisateurs des documents sur des sujets proches par exemple, en terme d'application.

            Pour owl c'est des relations plus précises, en terme de hiérarchie "sous-classe de" comme dans humain sous classe de animal est une définition logique : tous les exemples d'humain (instances) sont aussi des exemples d'animaux. Tu peux définir des relations exclusion types "les animaux ne sont pas des plantes" et si quelqu'un introduit par erreur une instance des deux en mêmes temps, le système est capable de dire qu'il y a un souci quelque part. C'est utilisé dans des cas où on aurait pu utiliser des systèmes experts dans le temps, des ontologies gêne/protéines par exemple, https://fr.m.wikipedia.org/wiki/Gene_Ontology pour etre compatibles avec tout un efort plus général de données biologiques qu'on imagine pas simple a faire evoluer, garder cohérentes et expressives.

      • [^] # Re: « Taxonomies »

        Posté par  (site web personnel) . Évalué à 10.

        En fait, c'est pas pareil mais proche.

        Une taxonomie peut être vue comme un sous-ensemble d’une ontologie.

        Fondamentalement, une taxonomie, c’est un ensemble de termes reliés entre eux par des relations de type is-a, permettant d’organiser ces termes en une hiérarchie de super-classes et de sous-classes (ou de catégories et de sous-catégories).

        Une ontologie, c’est une généralisation du concept de taxonomie, où les relations entre les termes ne sont plus limitées aux seules relations de type is-a, mais sont elles-mêmes des termes de l’ontologie, ce qui permet de décrire des choses beaucoup plus complexe qu’une simple classification hiérarchique.

        Et quand je vois ce que semble faire OpenFoodFacts de leurs « taxonomies », il me semble que c’est bien d’une ontologie dont ils ont besoin.

        Par exemple, ils ont une « taxonomie » des ingrédients et une « taxonomie » des allergènes, avec la première qui contient des références vers la seconde, comme ici :

        <en:starch
        en:wheat starch
        allergens:en: :en:gluten
        

        Cela indique bien qu’ils ne peuvent se contenter d’une classification hiérarchique : une telle classification permet bien d’indiquer que l’amidon de blé est un type d’amidon, mais ne permet pas d’exprimer la relation avec le gluten. Dans une ontologie, ça se ferait naturellement avec une relation dédiée, qu’on pourrait appeler has-allergen par exemple.


        Disclaimer : Je suis ontologiste, alors forcément j’ai tendance à « ontologiser » à outrance — vous savez ce que c’est, quand on a un marteau, on voit des clous partout… :D

    • [^] # Re: « Taxonomies »

      Posté par  . Évalué à 5.

      En fait tu as peut être raison et c'est cool de creuser.

      Bon, pour le futur, car dans l'immédiat on est engagé avec du code historique (coté Perl) et un projet bien démarré (côté Python) !

      Le problème du monde des ontologies est peut être la complexité perçue de l'extérieur (je m'y suis un peu intéressé déjà).
      L'autre chose pour moi est qu'il me semble qu'on ne définit pas tant des concepts au niveau ontologiques (des classes de concepts) mais plus des instances (un catalogue).

      Ce qui me fait dire ça:
      1. on instancie des propriétés (par exemple le lien avec une instance de wikidata)
      2. on a pas des relations différentes à décrire à chaque fois, c'est très simple on a juste la notion d'héritage, mais les propriétés, ce qui est définit etc se répète partout pareil.
      3. si tu regardes bien tu verras qu'un des intérêt majeur pour nous est de traduire en plein de langue et de construire les "synonymes" (en les listant mais également grâce à une liste de synonymes généraux qui sont utilisés par inférence), je vois mal comment mettre ça simplement dans une ontologie.

      À noter d'ailleurs que ce n'est pas une hiérarchie au sens "arbre" mais plutôt un Graphe orienté acyclique

      Du coup, je ne vois bien qu'on pourrait définir une ontologie des composant d'une taxonomie (dire qu'il y a des synonymes, des parents, des propriétés) et définir la taxonomie comme un RDF, mais je ne vois pas bien ce que ça apporte ici (ça met juste un schéma sur ce qui existe, et ça n'apporte pas un fichier facile à éditer, alors que le format actuel est vraiment pensé pour une édition à la mano, donc compacte et assez facile à lire).

      En tout cas je trouve ça intéressant et un premier pas pourrait être de montrer à quoi ça pourrait ressembler une petite taxonomy en mode ontologie et voir quels outils éventuels ça unlock. Tu viens contribuer :-D ?

      • [^] # Re: « Taxonomies »

        Posté par  (site web personnel) . Évalué à 6.

        Bon, pour le futur, car dans l'immédiat on est engagé

        J’ai bien vu que le projet était déjà bien engagé. Je ne suis pas en train de dire « arrêtez tout et repartez à zéro en utilisant une ontologie ! ». ;)

        Le problème du monde des ontologies est peut être la complexité perçue de l'extérieur.

        C’est pas une perception je te rassure, c’est compliqué aussi vu de l’intérieur. Comment ça c’est pas rassurant ?

        L'autre chose pour moi est qu'il me semble qu'on ne définit pas tant des concepts au niveau ontologiques (des classes de concepts) mais plus des instances (un catalogue).

        Je n’ai pas cette impression, non.

        Si je prends un exemple au hasard sur openfoodfacts.org, l’eau de sources Cristaline 1,5 L, il s’agit bien d’une classe, non d’une instance. Une instance, c’est la bouteille que je pourrais éventuellement avoir en ce moment même dans mon frigo.

        un des intérêt majeur pour nous est de traduire en plein de langue et de construire les "synonymes" […] je vois mal comment mettre ça simplement dans une ontologie.

        Pour ce qui est des traductions, OWL permet l’utilisation de language tags, donc chaque terme peut très bien avoir un nom et/ou une définition dans autant de langues que tu veux :

        AnnotationAssertion(rdfs:label off:123456 "Glass container"@en)
        AnnotationAssertion(rdfs:label off:123456 "Bac à verre"@fr)
        

        Pour ce qui est des synonymes, ben il suffit d’avoir une AnnotationProperty prévue à cet effet, comme pour tout le reste. Dans les ontologies biomédicales on utilise (pour des raisons historiques, c’est pas forcément à suivre pour une nouvelle ontologie) http://www.geneontology.org/formats/oboInOwl#hasExactSynonym et ses variantes #hasNarrowSynonym, #hasBroadSynonym, #hasRelatedSynonym :

        AnnotationAssertion(oboInOwl:hasRelatedSynonym off:123456 "Cuboverre"@fr)
        

        ça n'apporte pas un fichier facile à éditer, alors que le format actuel est vraiment pensé pour une édition à la mano, donc compacte et assez facile à lire

        Là oui, si le but est que ce soit éditable avec un éditeur de texte, effectivement ça va coincer. Il y a bien le format OBO Flat File (qui de très loin est d’ailleurs similaire à votre format maison : c’est un format orienté ligne avec des clauses de la forme tag:valeur), mais c’est un gros héritage historique (il prédate OWL) et personnellement je n’aimerais rien de mieux que de m’en débarasser…

        Je connais quelques barbus qui éditent des fichiers en syntaxe fonctionnelle à la main dans Vim ou Emacs, mais à part ces énergumènes-là¹, en pratique travailler sur une ontologie OWL impose quasiment l’utilisation d’un éditeur spécialisé comme Protégé.

        un premier pas pourrait être de montrer à quoi ça pourrait ressembler une petite taxonomy en mode ontologie et voir quels outils éventuels ça unlock.

        Parmi les « outils que ça débloquerait », ça pourrait par exemple permettre l‘utilisation d’un raisonneur pour automatiser la classification des produits et/ou détecter automatiquement des entrées incorrectes.

        Par exemple, si l’ontologie définit un produit végétarien comme un produit ne contenant pas de viande, un raisonneur pourrait automatiquement classifier tous les produits dont aucun ingrédient n’est de la viande comme un produit végétarien, sans nécessiter une classification manuelle. Inversement, si un produit a été manuellement classé comme végétarien mais contient un ingrédient de type viande, le raisonneur détecterait automatiquement l’incohérence.

        Tu viens contribuer :-D ?

        J’ai peur d’avoir assez à faire avec mes ontologies drosophiliennes.

        (Mais c’est pas dit que j’essaye pas quand même. Évite juste de retenir ton souffle en attendant ! ;) )


        ¹ Énergumènes dont il se pourrait que je fasse partie, mais chut, je ne vous ai rien dit.

  • # AGE

    Posté par  (site web personnel) . Évalué à 8.

    Il existe une extension PostgreSQL qui supporte Cypher, AGE

    L'annonce de la version 1 au mois d'avril: Announcing the release of Apache AGE(incubating) 1.0.0

    Je n'ai pas encore eu l'occasion de la tester, ils ont fait le développement sur PG11 et ce sont d'abord concentré sur le support d'openCypher, le support de PG12 arrive et celui de PG13 devrait suivre.

    • [^] # Re: AGE

      Posté par  . Évalué à 2.

      Oh là là quelle bonne nouvelle !

      On sait au moins qu'on a un backup :-)

  • # Solution alternative: Arango

    Posté par  . Évalué à 4.

    As-tu considéré une solution alternative telle que Arango?
    J'ai avantageusement remplacé Neo4j par ça sur l'un de mes projets.

  • # Game over

    Posté par  . Évalué à 5.

    Comme on pouvait s'y attendre j'ai eu une fin de non recevoir: https://github.com/neo4j/neo4j/issues/12920#issuecomment-1226941038

  • # Containerisation

    Posté par  (site web personnel) . Évalué à 3.

    Bonjour, je connais que de très loin Neo4j, mais j'ai lu le thread sur github. Une réponse, celle-ci plus précisément: https://github.com/neo4j/neo4j/issues/12920#issuecomment-1226941038 explique que ce n'est pas dans leur roadmap, mais donne l'alternative d'utiliser des conteneurs pour avoir plusieurs instances.

    Je trouve cette solution d'utiliser des conteneurs plutôt élégante, et sûrement assez facile à mettre en place, si vraiment tu apprécie le produit, je ne peux que te recommander d'utiliser exactement cette solution là.

    Petite note perso, même si comme toi je trouve ça un peu démesuré de ne pas mettre le support des bases de données multiple dans la version communautaire, le produit leur appartient, je pense que tu as peu de chance d'avoir gain de cause.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.