8768 sujets

Développement web côté serveur, CMS

[Résolu] Gérer des terminologies (thésaurus ou listes hiérarchisées)

Bonsoir,

J'ai besoin de vos lumières :
Dans le cadre de mon projet, je dois réaliser une liste hiérarchisée (ou mieux, un thésaurus), avec une série de concepts qui, donc, ont un lien sémantique spécifique ou générique (parent/fils) entre eux.

Représentez-vous cette liste comme digne d'un dictionnaire (on est loin d'envisager un menu déroulant à optgroup pour solutionner le problème), de ce goût-là : http://www.exploredge.com/

Ma question : de quelle manière élaborer cela?
Dans un logiciel documentaire, il me semble que le thésaurus était géré avec des fichiers TXT (ASCII) qui étaient tabulés pour signifier leur lien de parenté entre eux. Comme ceci :

Développement web
_ Langages
_ _ PHP
_ _ _ Framework PHP
_ _ _ _ Zend Framework
_ _ _ _ Symfony
_ _ _ _ Laravel
_ _ JavaScript
_ _ _ Ajax
_ _ _ Framework JS
_ _ _ _ JQuery
_ _ _ _ Dojo

...

Grâce à ce fichier, les liens sémantiques des descripteurs (mots-clés) étaient automatiquement reconnus par le logiciel.
Mais il s'agit dans ce cas-là d'un logiciel client.
Je ne sais donc pas s'il est sécure d'opter pour ce genre de solution (un TXT peut être effacé ou corrompu en un tour de main, après tout)...

J'imagine qu'il vaudrait mieux passer par un système de bases de données.
D'opter pour un développement en PHP + SQL avec des autojointures, qui réfèrent au parent ou au fils, en fonction.

Mais vous avez peut-être eu à gérer ce genre de problématique?
Peut-être existe-t-il des outils libres et gratuits qui aident à ce type de réalisation? (comme Elasticsearch, par exemple, mais je ne pense pas que cet outil soit compatible avec mon problème)
Comment feriez-vous ça? Avec quel langage? Quelles éventuelles applis? Quelles méthodes?

Merci pour votre aide...
Modifié par Reka (25 Feb 2014 - 02:47)
Hello,

Si tu décides d'opter pour une base de données, il y a beaucoup mieux que des structures récursives pour gérer une arborescence. Tu peux rechercher "représentation intervalaire" sur ce forum, ça a déjà été discuté, ou sur le web où tu trouveras quelques tutoriels.

Par contre, si ton truc est plus un graphe qu'un arbre, je ne pense pas que la base de donnée, ou du moins pas dans sa forme classique, soit le meilleur moyen. J'en ai jamais utilisé, mais je sais qu'il y a des soft beaucoup plus adaptés pour traiter les données qui s'organisent sous forme de graphes, avec des algorithmes bien plus performants pour la recherche de chemins, de noeuds adjaçants au nième degré, de composantes connexes, d'arbres couvrants, etc. que ce que tu trouveras dans un SGBD générique, où ça passera très probablement par des implémentations et adaptations maison qui seront à coup sûr moins efficaces.



Quant à la solution fichier texte, c'est peut-être une bonne solution pour débuter rapidement sans trop se prendre la tête, mais ça devient assez vite ingérable et peu efficace à mesure que le volume de données augmente. Ca peut être viable si tu n'ajoutes pas souvent des données et s'il y en a pas trop (pas plus de quelques dizaines de noeuds). Pour plus, il va te falloir au moins SQLite (SQLite est le SGBD générique le plus minimaliste qui existe).
Merci Quentin, je vais voir ce qu'on dit à propos des représentations intervalaires. Je n'avais pas connaissance de ce concept, donc merci pour cette piste.

Il s'agit bien d'un arbre, dans mon cas.

Et la solution texte, je ne comprends pas bien en quoi elle pourrait devenir ingérable (à supposer que je sois seule à l'alimenter) ? Ca reste un fichier super léger, donc à quel niveau identifies-tu qu'il y aurait d'éventuelles complications?

J'ai par ailleurs vu que la liste de sujets RAMEAU (système d'indexation propre à la Bibliothèque nationale de France) était mise à disposition en RDF/XML : http://data.bnf.fr/semanticweb#Ancre2.
Bon, le fichier est hyper lourd (73 Mo sous dossier compressé), mais je ne retiendrais peut-être qu'un dixième ou un centième de son contenu après nettoyage.

Ma question : est-il compliqué de gérer conjointement un fichier de type RDF avec du PHP?

J'ai vu qu'il existait un outil appelé EasyRDF qui se vend comme "
A PHP library designed to make it easy to consume and produce RDF".
Connaissez-vous cette librairie? S'agit-il d'un outil classique, reconnu, efficace?

Encore merci pour vos réponses Smiley cligne
Salut,

J'ai un peu entendu parler des bases de données orientée graphe avec neo4j. Comme le nom l'indique ça permet de gérer des graphes, du coup sans doute aussi des arbres Smiley smile
Globalement ça avait l'air de permettre de faire des trucs sympa à partir du moment où les données collent bien au niveau du format, et qu'il faut parfois savoir un peu se déshabituer du raisonnement des bases de données classiques.

Bon après je reste très au conditionnel car je n'ai pas tester moi même et qu'il s'agit juste des vagues souvenir que j'ai des retours qu'un collègue m'a fait au bout de quelques jours de test, il y a de ça déjà un petit moment...
a écrit :
Et la solution texte, je ne comprends pas bien en quoi elle pourrait devenir ingérable (à supposer que je sois seule à l'alimenter) ? Ca reste un fichier super léger, donc à quel niveau identifies-tu qu'il y aurait d'éventuelles complications?

Deux grandes contrindications aux fichiers texte, à mon avis :
1 - Intégrité - Le fichier est trop rapidement corrompu; à chaque ajout/modification tu as des risques, et ne parlons même pas du travail à plusieurs. Les bases de donnée disposent de locks et de contrôles d'intégrité qui font que c'est quasiment impossible de corrompre une base si elle fonctionne normalement. Même SQLite a toute une série de protections, aussi simple soit-il.
2 - Les bases de données ont un extraordinaire système pour retrouver rapidement des enregistrements selon certains critères, les index. Pour les petites tables ça sert à rien, mais quand tu commences à arriver dans les centaines d'entrées, ça commence à être vachement utile (et quand tu en as des dizaines de milliers ou des millions, c'est juste vital) ! Avec un fichier texte, c'est quelque chose que tu vas t'amuser à recoder toi-même si tu en veux... mais effectivement, tant que tu n'atteins pas quelques dizaines, ça peut être de l'overkill.

Et maintenant tu viens parler des formats basés sur XML. Pour tout te dire, je l'avais complètement oublié celui-là !
Mon point de vue sur XML c'est que
1 - C'est ultra verbeux et pas particulièrement facile à éditer à la main (on a vite fait de faire une erreur de syntaxe)
2 - C'est rapidement volumineux pour pas grand chose, tu le dis toi-même... 70 Mo de XML, en base ça doit être genre au moins 20 fois moins pour conserver la même information.
3 - En plus, tu conserves grosso modo les inconvénients sur les fichiers texte cités précédemment en ce qui concerne l'intégrité, le travail à plusieurs, et les index
4 - Alors par contre oui, pour requêter des structures arborescentes, tu as des outils drôlement pratiques comme XPath et XQuery.
5 - Tu as aussi un certain bonus quand les propriétés de chaque neud ne sont pas toujours rigoureusement les mêmes; la structure d'un XML est beaucoup moins carrée que celle d'un ensemble de tables SQL.

Sur le plan du stockage et de la récupération, je pense sérieusement que ça n'a vraiment rien à envier à la représentation intervalaire sur SGBDR pour stocker des arbres.

Et question communication entre API et interopérabilité, les atouts principaux de XML, si tu prends JSON à la place, tu as la verbosité et le volume de données en moins tout en ayant des moyens similaires à XPath pour naviguer facilement dans la structure, et c'est plus simple et rapide à éditer à la main.

A mon sens, XML, donc, c'est complètement pourri à tous les niveaux.
Mais tout cela n'est qu'un point de vue... les gens qui sont à fond sur XML me diraient sûrement tout le contraire.
Modifié par QuentinC (25 Feb 2014 - 15:53)
Merci Quentin.
Je creuse la question des représentations intervallaires, tracasse Smiley cligne .
Mais je vais quand même aussi m'intéresser à l'XML et au RDF (quitte à rejoindre ton opinion sur leur pourritude Smiley langue ). Ils sont peut-être plus faciles à prendre en main, et comme le temps m'est compté...
A la louche, si c'est pour gérer entre 1000 et 3000 termes, j'imagine que le fichier ne pèsera pas des tonnes.
Modifié par Reka (25 Feb 2014 - 16:47)
a écrit :
Ils sont peut-être plus faciles à prendre en main

Sans doute, vu que le XML est perçu comme un genre de passe-partout quand on ne sait pas quoi prendre d'autre (en tout cas c'est mon impression).
Son avantage indéniable, c'est qu'à peu près tous les langages de programmation et frameworks du monde le supportent sans avoir grand chose à installer en plus.

Autre inconvénient des fichiers et du XML vis-à-vis des bases de données que j'ai oublié, c'est que les fichiers utilisés en interne par les bases de données sont tellement bien structurés et conjointement grâce aux index, qu'on peut ne les lire que partiellement, ou même que la partie précise demandée; c'est ce qui leur permet d'être très rapide même quand les enregistrements se chiffrent en millions. VA indexer un fichier texte de ton cru, ou un fichier XML... il y a de bonnes chances pour que tu sois quoi qu'il arrive obligé de lire l'intégralité du fichier quelque soit la requête. Par exemple, l'arbre doit être chargé entièrement en mémoire, en un seul tenant, pour que XPath ou les API DOM classiques soient capables de taper n'importe où après. Du coup, ton beau XML grossit très, très, très, très mal. Ton fichier de 70 Mo, là, c'est 70 Mo à charger en RAM.

La représentation intervalaire, c'est sans nul doute effectivement plus compliqué à appréhender: il y a une petite théorie derrière qu'il faut comprendre avant de pouvoir utiliser.

Attention quand même, c'est pas toujours mentionné, mais la représentation intervalaire a le gros inconvénient face à une représentation récursive/auto-référente d'être plus complexe à l'insertion/déplacement/suppression. Si tu insères/déplaces/supprimes souvent par rapport à ce que tu accèdes en lecture, ce n'est pas un bon plan.
Sujet clos
Aller à