Pour rebondir sur les propos de Christian qui essaye de combiner REST et RDF, je voudrais discuter de l'architecture « idéale » à laquelle je suis arrivé. C'est une problématique à laquelle je suis confronté aussi lors de ma réflexion pour la killer app sémantique et qui fait partie des trois points bloquants actuels avec l'ergonomie et la confidentialité des données.
Avant la ressource, il y a la donnée
Comme le souligne Christian, REST s'adresse à des ressources et non directement à des données, d'où le problème lorsqu'on essaye de construire une application RESTful qui tape directement sur des triplets RDF. Commençons par étudier le stockage, on verra l'accès plus tard.
Il existe plusieurs moyens de stocker une donnée, on a longtemps cru que le modèle relationnel (PostreSQL, MySQL, etc) était la solution à tout mais dès que l'on est confronté à un très grand nombre de données, celui-ci atteint ses limites et laisse aujourd'hui généralement place au modèle non-structuré et distribué (CouchDB, Hadoop, BigTable, etc) qui a fait ses preuves grâce à Google.
Malheureusement, aucun des deux n'est adapté au stockage du RDF, ce qui est à l'origine de performances assez catastrophiques lorsqu'on atteint plusieurs milliers de triplets (ce qui arrive assez rapidement). De plus le modèle de type document est puissant justement dans sa souplesse, il est possible d'ajouter des champs à la volée, il serait donc vraiment dommage de restreindre son usage à 3 champs !
Dans l'idéal, il faudrait avoir une base performante qui soit développée spécifiquement pour stocker du RDF, en pratique je crois plus en un mapping RDF sur une base structurée existante, il y a des projets comme HRDF pour Hadoop qui tentent justement d'arriver à ça. On arriverait au schéma suivant :
Données (RDF)
↑
| MapReduce + TODO
|
Données sérialisées (CouchDB, Hadoop, etc)
Les opérations de MapReduce, possibles en Python et automatisables grâce aux générateurs, permettraient de récupérer directement du RDF en sortie. De plus, mes problèmes de confidentialité, pourraient être nativement pris en compte à ce niveau (?)
Mais on veut manipuler des ressources !
C'est génial d'avoir du RDF mais ce que l'on souhaite généralement manipuler est à un niveau plus élevé que l'on pourrait appeler RRM pour Resource RDF Mapping, c'est ce que fait par exemple RDFAlchemy qui est le pendant à SQLAlchemy qui est un ORM classique.
J'ai essayé un moment de créer une API RESTful directement sur un TripleStore mais ça pose de toute façon ensuite un problème ergonomique car les utilisateurs manipulent nécessairement des ressources et non des triplets au final, cette abstraction est donc utile dans mon cas mais ça peut varier selon les usages.
Ressources sémantiques (objets Python)
↑
| RDFAlchemy
|
Données (RDF)
↑
| MapReduce + TODO
|
Données sérialisées (CouchDB, Hadoop, etc)
Une fois nos ressources définies, il faut maintenant un outil pour y accéder via une interface RESTful, c'est seulement ici que Django entre en jeu. J'aurais l'occasion d'en reparler car je suis en train de développer mon propre outil de vues afin de faciliter ceci (après avoir retourné dans tous les sens django-rest-interface, je ne suis pas totalement satisfait et le projet est mort).
Représentations standardisées (HTML, JSON, Atom, etc)
↑
| Django + TODO
|
Ressources sémantiques (objets Python)
↑
| RDFAlchemy
|
Données (RDF)
↑
| MapReduce + TODO
|
Données sérialisées (CouchDB, Hadoop, etc)
Vous pouvez terminer le millefeuilles en connectant un site, un widget ou votre RIA sur cette API qui est évidemment buzzword compliant (le titre original était « Architecture Foutaises! » mais j'avais peur que ce soit encore interprété comme un gros troll).
Utilisations (site, widget, RIA, etc)
↑
| REST/APP
|
Représentations standardisées (HTML, JSON, Atom, etc)
↑
| Django + TODO
|
Ressources sémantiques (objets Python)
↑
| RDFAlchemy
|
Données (RDF)
↑
| MapReduce + TODO
|
Données sérialisées (CouchDB, Hadoop, etc)
Et pour quelques threads de plus...
J'en ai rapidement parlé lors de ma présentation de Django, il est très important de pouvoir effectuer des tâches asynchrones lorsqu'elles pénalisent les performances de votre site et donc l'expérience utilisateur.
Pour ça, Erlang semble former un couple parfait avec Python puisqu'il permet une parallèlisation à moindre coût, ainsi qu'un communication via HTTP+JSON. Ça tombe bien car c'est l'un des format qui est servi par notre interface RESTful en Django ! On pourrait aussi imaginer que les traitements asynchrones puissent accéder directement aux données RDF selon les cas.
Utilisations (site, widget, RIA, etc)
↑
| REST/APP
|
Représentations standardisées (HTML, JSON, Atom, etc)
↑ |
| Django + TODO |
| ↓
Ressources sémantiques (objets Python) Traitements asynchrones (Erlang)
↑ ↑
| RDFAlchemy |
| |
Données (RDF) ------------------------------/
↑
| MapReduce + TODO
|
Données sérialisées (CouchDB, Hadoop, etc)
Vous cumulez ainsi la rapidité de développement offerte par Python (et Django) d'une part et les performances d'Erlang pour les travaux demandant un certain temps. Le meilleur des deux mondes.
Quelques inconvénients évidents
À chaque mapping, on perd en performances et là on fait Document → RDF → Resource → Représentation ce qui fait quand même quelques étapes... bien sûr on gagne en standardisation et en pérennité, il sera possible de changer d'outils, voire de supprimer certaines transitions plus tard lorsque les avancées technologiques suivront. C'est le coût de l'agilité et à ce stade il serait difficile d'estimer si c'est vraiment pénalisant au final.
Le problème des outils innovants, c'est qu'ils manquent d'extensions et/ou n'ont aucun benchmark permettant de valider un choix compte tenu du nombre de données estimées. De plus, coder chaque lib inexistante à la main est assez fastidieux et je trouve plus intéressant de consacrer mon temps à réfléchir au produit final.
Enfin, ça demande de maîtriser un bon nombre de technos, je suis en train d'apprendre Erlang pour compléter mon arsenal mais plus le domaine des compétences s'étend et plus vous perdez en efficacité, ça peut être préjudiciable si vous travaillez seul. Ou pas, si vous êtes un geek curieux :-).
À ce stade de ma réflexion c'est ce qui me semble le plus pertinent mais je suis loin d'être un expert sur la question. Idées et retours d'expériences bienvenus, comme toujours.
Commentaires
Mat le 04/06/2008 :
Desole c'est peut etre un peu HS :
En parlant de MapReduce/Hadoop, je trouve le principe genial mais j'ai du mal a voir concretement dans quel cas de figure on peut l'utiliser dans des applis web classiques.
Serait-il envisageable de faire un billet avec des exemples d'utilisation possibles ? (ex: en partant de services web classiques, voir quelles parties pourraient etre deleguees a des taches MapReduce).
Enfin merci pour tes articles de tres bonne qualite, j'ai pas encore eu l'occaz de le dire :)
Olivier le 04/06/2008 :
Tu ne dispenserais pas par hasard des formations orientées sémantique dont RDF ? ou si tu en connais, je suis intéressé.
Merci pour l'article !
Yoan le 04/06/2008 :
Personnellement j'enlèverais « Données RDF » qui sont à mon sens un format d'échange et pas de travail, surtout en connaissant le princip de “leaky abstraction” et là il y en a dans trois cas ->
- stockage (CouchDB, HDFS, Mnesia, SimpleDB);
- ressources Python
- traitement asynchrones (Erlang?)
Données RDF est en entrée et sortie du stockage mais de l'autre côté, l'application interne travaillant avec son abstraction choisie. Ça n'est pas très RDF-friendly, mais je peine à concevoir l'autre cas comme étant viable (pour avoir joué avec ActiveRDF qui fait un mapping OO sur RDF).
La force d'Erlang est le fait que tu puisses créer 10'000 instances distribués sur toutes tes machines en un claquement de doigt et qu'ils puissent tous communiquer entre eux simplement ensuite. Si tu n'as pas la notion de distribution (le map/reduce de CouchDB) ou d'évènementiel (le chat de Facebook pour ne citer que lui), je n'en vois pas bien l'usage.
Garde le pour faire ton système de notifications, un système de crawling/ping, des queues de traitement, voire même ton API JSON/REST/SOAP (biffez l'intru).
Donc oui, je suis contre mais l'idée d'une killer-app est intéressante. J'avais pensé à un système de bookmarks, car il y a plétore d'ontologies qui peuvent servir et le modèle est assez simple (FOAF + SIOC + SKOS + DC) Si ça t'inspire ? J'ai un bout de doigt à dédier à l'idée.
-- Yoan
PS: nous sommes en "june" chez moi et saidoublementmal : français + anglais = impression bizarre, le mois de juin est en l'honneur de la déesse romaine Junon (Juno en anglais, superbe film d'ailleurs) et de ce fait prend la majuscule de rigueur en anglais.
Damien B le 04/06/2008 :
"laisse aujourd'hui généralement place au modèle structuré et distribué"
On aurait préféré un lien vers une référence plutôt que juste une mise en gras :-)
D'autre part, la dernière fois que j'ai regardé CouchDB, Hadoop et BigTable, ils travaillaient tous sur un modèle clef + valeur sans schéma. Ce n'est pas franchement ce que j'appelle un modèle structuré :-)
"d'où le problème lorsqu'on essaye de construire une application RESTful qui tape directement sur des triplets RDF"
Parler de triplet RDF, c'est déjà se restreindre à une formalisation possible d'un graphe. Mais en fonction de la complexité est de la structure de ton graphe, le triplet n'est pas forcément la représentation la plus pertinente.
"Personnellement j'enlèverais « Données RDF » qui sont à mon sens un format d'échange"
Mais RDF n'est pas un format ! RDF-XML est un format, N3 est un format. RDF est un modèle relationnel dans lequel (entre autre) l'association est systématiquement qualifiée, contrairement aux modèles proposés par les SGDBR standard, où la qualification de l'association se "retrouve" matérialisée par un attribut de l'entité.
Christian Fauré le 04/06/2008 :
Hello David, et merci d'avoir si bien continué la discussion, également à Yoan et Damien pour leur éclairage :-)
Quelques remarques en passant :
- j'ai eu une petite discussion avec Gautier (http://www.lespetitescases.net) précisément sur les différents modes de stockage RDF d'où il ressort qu'aujourd'hui, et pour encore un bon moment, c'est le triple Store sur une base relationnelle qui donne le plus de satisfactions (Got va publier un bench de Virtuoso allant jusqu'à 3 milliards de triples effectués dans le cadre d'un projet)
- il semble que le problème des conlumn store à la Hadoop soit leur inadaptation face à des requêtes hétérogènes/complexes (or c'est souvent ce pourquoi on met en place du RDF). Par contre si ton appli a des requêtes pas trop complexes, ç'est plus adapté.
-Concernant les GUIs j'ai la conviction qu'il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l'architecture des données en mode relationnel.
Moralité : si on change le moteur il va falloir changer la carrosserie. En tout cas çà fait du bien de partir depuis les données elles-mêmes :-)
Got le 04/06/2008 :
Christian a déjà dit tout ce que je pouvais dire. Quelques précisions, alors :
- L'avantage de se baser sur une BDR pour stocker du triples RDF est de disposer en natif d'un certain nombre de fonctionnalités (backup, gestion des transactions, système d'indexations voire système de réplication et procédure stockée...).
- Pour le bench, Christian a un peu exagéré (si peu ;-) ), puisqu'il s'agit de 2 milliards de triples, mais c'est déjà très structurant :-) Je ne sais pas encore comment je vais diffuser ce bench, mais je le ferai d'une manière ou d'une autre.
- @Olivier, en guise d'intro, ce diaporama pourra peut-être t'aider : http://www.slideshare.net/lespetitescases/a-la-dcouverte-du-web-smantique/ (David, j'espère que tu m'excuseras le petit coup de pub). Il existe quelques formations payantes et sinon, tu peux assister au prochain semantic Camp, on essaye d'y faire des intros aux technologies.
- @Yoan, une petite question : en quoi RDF ne serait qu'un format d'échange et pas un format de travail ?? Comme l'a dit Damien, ce n'est pas un format, mais un modèle. Or, comment interroger en sparql si tes données ne sont pas stockées selon le modèle RDF, comment effectuer des inférences, comment exploiter toute la logique que tu as définie dans ton ontologie ? Il faut que le RDF soit stocké quelque part. Maintenant, il est vrai que peu importe que ce soit un column store, une BDR ou un triple store natif (l'avantage de disposer d'un modèle et non d'un format !), l'important est de pouvoir utiliser SPARQL et pouvoir faire au moins un peu d'inférences. Le principe de RDF est bien de séparer la donnée elle-même de l'application ce qui est l'inverse de ta proposition, me semble-t-il ?
- toujours pour Yoan : il existe déjà des systèmes de bookmarks utilisant les technologies du Web sémantique, par exemple : Semanlink, http://www.semanlink.net/sl/home et gnizr, http://code.google.com/p/gnizr/
- @David (quand même ;-) ) Un autre ORM pour RDF à garder à l'oeil : Topaz, http://www.topazproject.org/ qui fonctionne avec Mulgara et Fedora (pas la distribution, le repository) et merci pour ce billet très complet.
Finalement, j'avais des choses à dire, désolé pour ce long commentaire !
Christian Fauré le 04/06/2008 :
Ah au fait, puisque tu regardes côté Erlang, il y a un repository special pour les applis en Erlang : http://www.erlang.org/documentation/doc-5.0.1/lib/mnesia-3.9.2/doc/index.html
David, biologeek le 05/06/2008 :
@Mat : j'y réfléchis et merci :-)
@Olivier : c'est envisageable oui, par contre ça va me demander pas mal de temps de préparation !
@Yoan : le gros avantage de garder l'intermédiaire RDF (outre les arguments des commentaires précédents) est de pouvoir passer un jour (oui je suis optimiste) à une base dédiée à ça sans trop avoir à en pâtir.
Quand je parle d'Erlang c'est effectivement pour traiter tout ce qui est crawling/notifications/etc.
> J'ai un bout de doigt à dédier à l'idée.
Vu la qualité du doigt, je n'hésiterais pas ;-)
Il faut que je me bouge là-dessus mais j'ai d'autres priorités actuellement.
@Damien B :
> On aurait préféré un lien vers une référence plutôt que juste une mise en gras :-)
http://labs.google.com/papers/bigtable.html
http://hadoop.apache.org/core/docs/current/
Je n'ai pas vraiment trouvé LE document qui permet vraiment de tout comprendre d'un coup malheureusement.
> Parler de triplet RDF, c'est déjà se restreindre à une formalisation possible d'un graphe.
Tout à fait, je voudrais m'en tenir à ce choix car c'est celui qui a été adopté par des personnes beaucoup plus compétentes que moi dans le domaine. Cela dit, la couche "Données sérialisées" permettrait justement d'étendre le graphe derrière.
@Christian Fauré : merci pour tes précisions.
> Concernant les GUIs j'ai la conviction qu'il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l'architecture des données en mode relationnel.
Tout à fait, tant que l'on a du relationnel qui correspond au fonctionnel ça va mais il faut vraiment essayer de faire abstraction des données et des contraintes techniques pour approcher une interface utilisable par le commun des non-geeks.
@Got : ne t'excuse pas de commentaires aussi intéressants malheureux !
J'attends avec impatience ton bench car je trouve que c'est quelque chose qui manque cruellement. À part un ou deux cas isolés et qui sont rapidement obsolètes, il n'y a rien de suivi et pertinent.
Je ne connaissais pas Topaz, par contre c'est en Java...
@Christian Fauré : oui je connaissais de nom, je n'ai jamais eu le temps de m'y intéresser plus que ça par contre, merci.
Luke Hoersten le 05/06/2008 :
I have no idea what you're site says. I tried to use Google to translate the French but it made little sense. Anyway, thanks for citing my website in regards to Erlang + Python!
Got le 05/06/2008 :
@David : Je me disais bien aussi que tu serais moins intéressé par Topaz (ces petites bêtes ne sont pas trop ma tasse de thé ;-) ). Pour les bench, j'en avais relevé un certain nombre dans le billet suivant : http://www.lespetitescases.net/node/988 (qui d'ailleurs contient une référence qui pourrait intéresser Damien : "The end of an architectural Era", http://www.mit.edu/people/dna/vldb07hstore.pdf ).
Virtuoso fait l'effort (à son avantage d'ailleurs...) de publier régulièrement les résultats des benchmarks qu'ils effectuent (la dernière livraison : http://virtuoso.openlinksw.com/blog/index.vspx et http://www.openlinksw.com/weblog/oerling/?id=1368). AllegroGraph, aussi, je crois.
Damien B le 05/06/2008 :
@David
"Je n'ai pas vraiment trouvé LE document qui permet vraiment de tout comprendre d'un coup malheureusement."
On s'est mal compris, la référence que j'aurais souhaité avoir c'était l'étude de marché qui montrait que les SGBDR traditionnels avaient montrés leurs limites et *qu'en conséquence* ils laissaient aujourd'hui *généralement* leur place aux "modèle (non-)structuré et distribué" :-) Sinon pour comprendre BigTable et le reste, c'est assez rapide : c'est un BerkeleyDB-like distribué (après la façon dont l'aspect distribution est géré, on s'en tape, c'est l'objectif).
@Christian Fauré
"Concernant les GUIs j'ai la conviction qu'il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l'architecture des données en mode relationnel."
Nooooooon !! Pas du MDA !! Pas çaaaaaaaaaa !!!
@Got
Tiens, je n'avais pas suivi le lien à l'époque sur le blog.
Concernant ce papier, on dirait des étudiants en zététique qui nous assène toutes leur morgue en n'argumentant rien, et qui au final, nous refond le coup de MySQL 3 :
- "Regardez, on est dix fois plus rapide, vous êtes obsolètes"
- "Oui, mais vous n'avez pas ça, ça, ça et ça"
- "Mais c'est parce que vous n'en avez pas besoin ! Il faut être bête pour en avoir besoin ! Ce sont vos applications qui sont mal foutues !"
On voit ce qu'il en est devenu avec MySQL 5 (qu'on peut toujours utiliser avec du MyISAM si effectivement on n'a pas besoin de grand chose).
J'espère qu'il n'a pas été publié dans une revue...
Exemple typique, sur la haute disponibilité :
"A recent paper [LM06] argues that failover/rebuild is as efficient as redo log processing. Hence, there is essentially no downside to operating in this manner. In an HA world, one is led to having no persistent redo log, just a transient undo one. This dramatically simplifies recovery logic."
Avec ce magnifique exemple de haute disponibilité, quand les câbles sous-marins ont été endommagés au large de Taïwan en janvier 2007, les entreprises en Chine qui auraient compté uniquement sur des hot-backups à l'étranger se seraient retrouvées sérieusement embêtée avec cette stratégie. La haute disponibilité, c'est que faire quand tout crashe ? Avec eux ça devient : que faire si j'ai une ou deux machines en panne mais que tout le reste (alimentation électrique, réseau) tourne parfaitement ?
Et un dernier extrait pour finir :
"If one assumes a grid of systems with main memory storage, builtin high availability, no user stalls, and useful transaction work under 1 millisecond, then the following conclusions become evident"
Si on considère un réseau d'usines avec des stocks infinis, une haute disponibilité des ouvriers et de la chaîne de production assurée, sans garantie de respect de délai d'exécution, et où toutes les opérations utiles sont effectuées en moins d'une seconde, alors les conclusions suivantes deviennent évidentes :
votre usine est à jeter.
Donc oui, c'est assez intéressant comme article, je me suis fait reprendre pour moins que ça pendant mes études :-)
(oups, encore un pâté, désolé)
Damien B le 05/06/2008 :
Oh, j'avais raté la fin :
"Our current favorite example of this approach is Ruby-on-Rails. This system is the little language, Ruby, extended with integrated support for database access and manipulation through the “modelview-controller” programming pattern. Ruby-on-Rails compiles into standard JDBC, but hides all the complexity of that interface. Hence, H-Store plans to move from C++ to Ruby-on-Rails as our
stored procedure language."
Ca me laisse sans voix.
David, biologeek le 05/06/2008 :
@Luke Hoersten : it's about a web architecture which handles semantic content (and scales), thanks for your post ;-)
@Got : merci pour tous ces liens, un autre pour la route : http://www4.wiwiss.fu-berlin.de/benchmarks-200801/
@Damien B : ton dernier commentaire me laisse dans le même état :|
Concernant la preuve demandée, je n'ai malheureusement aucun argument à avancer, c'est plus une « intuition geek » résultant de mes lectures (pas très scientifique comme approche, je te l'accorde).
Damien B le 05/06/2008 :
Je continue sur le PDF de Got, c'est décidément une mine :
"At this point SQL is a legacy language with many known serious flaws, as noted by Chris Date two decades ago [Dat84]."
"[Dat84] Date, C. J. “A critique of the SQL database language.”In SIGMOD Record 14(3):8-54, Nov. 1984."
PDF en question que vous pouvez trouver ici : http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/date-1983.pdf
Papier écrit donc fin 83, basé sur "X3H2 (American National Standards Database Committee) Draft Proposed Relational Database Language. Document X3H2-83-152(August 1983)." et l'état de l'art (principalement PL/1 en langage hôte). Je n'irais pas jusqu'à dire que certains lecteurs ici n'étaient pas nés à l'époque, et d'autres ne savaient pas encore lire :-) Mais quand même.
Comme vous pourrez le voir partout, SQL est devenue une norme ANSI en 1986, et à connu des révisions majeures en 1992, 1999, 2003 et une autre révision est en cours. A l'heure actuelle, je pense qu'à peu près tous les SGBDR courants son compatible quasiment à 100% avec SQL-99.
Et là est le problème, c'est qu'avec ma connaissance de SQL, il y a quand même une bonne moitié du document de [Dat84] à oublier. Certains points sont par ailleurs toujours valides et c'en est d'ailleurs toujours gonflant (comme de devoir repréciser les jointures alors que le SGBDR a déjà la définition de la foreign key dans laquelle on tape).
Bref... ils se sont mis à 6 pour faire ce papier, et visiblement il n'y en a aucun qui a été choqué de baser leurs critiques majeures de SQL sur un papier d'il y a bientôt 25 ans, alors que SQL n'était pas normalisé à cette époque, et à connu trois révisions majeures entre (dont une pas vraiment encore assimilée il faut l'admettre), et surtout sans émettre le moindre avis critique là-dessus : "At this point SQL is a legacy language with many known serious flaws, as noted by Chris Date two decades ago [Dat84]." C'est proprement hallucinant ce niveau de bâclage.
Je reprendrais le titre et le sous-titre :
"The End of an Architectural Era"
Oui, c'est la fin de l'époque où les papiers a priori destinés à publication étaient architecturés correctement.
"(It’s Time for a Complete Rewrite)"
Parfaitement d'accord ! Qu'ils refassent leur torchon ! Ca devrait aller vite à 6.
Merci Got pour cette référence :-D
David, biologeek le 09/06/2008 :
@Damien B : tu devrais leur écrire, en prenant des pincettes, mais ton avis est plus que pertinent...
Damien B le 09/06/2008 :
Ecrire à 4 mecs du MIT et un de Microsoft ? Ils ont le pognon pour payer des relecteurs :-) Autant laisser ce papelard dans l'oubli...
Yoan le 11/06/2008 :
Tout à fait, avoir de l'inférence est important, c'est clair. J'ai juste un peu tendance à croire ce que je vois, et il me reste à explorer donc.
mapson le 22/06/2008 :
> Dans l'idéal, il faudrait avoir une base performante qui soit développée spécifiquement pour stocker du RDF
AllegroGraph de Franz Inc correspond exactement à cette description. La version Free est limitée à 50 000 000 de triplets, ce qui semble suffisant pour la tester. Je n'ai pas trouvé de tarif pour la version illimitée.
http://agraph.franz.com/allegrograph/
Ils ont d'ailleurs d'autres produits pour le web sémantique (en Common Lisp).
Personnellement, je ne crois pas trop aux promesses d'un web sémantique. J'ai l'impression qu'il force l'utilisateur à se plier aux contraintes de l'ordinateur au lieu de l'inverse, par exemple en le forçant à renseigner des méta-données genre Dublin Core (et à le faire correctement, ce qui n'est pas à la portée de tout le monde) pour faciliter le travail des moteurs de recherche.
NicolasChauvat le 27/02/2009 :
David, est-ce que tu pourrais mettre de côté un instant ton penchant naturel pour les langages de template et accepter de regarder plus en détail http://www.cubicweb.org ? L'architecture que tu décris est proche de celle que je t'ai présentée lors de pycon-fr il y a bientôt un an. Nous la développons depuis 2001. Elle marche déjà. Evidemment c'est un peu moins drôle que de tout refaire et ce n'est pas du django-que-tu-aimes, mais tu aurais de quoi jouer: c'est du Python, du twisted, ça utilise des données stockées dans des bases SQL, LDAP, subversion, etc. Elle est téléchargeable sous licence LGPL... allez, un bon geste ;)
David, biologeek le 01/03/2009 :
@NicolasChauvat : alors j'ai pris le temps de regarder en détail et déjà le premier point bloquant c'est la doc. Je ne peux pas miser sur un framework (aussi puissant soit-il) qui dispose d'aussi peu de doc.
C'est pas forcément pour la doc car je pourrais aller me plonger dans le code mais ça signifie que la communauté est réduite et malgré ses années d'avance le framework n'évoluera pas assez vite car la barrière d'entrée est trop élevée pour qu'il y ait de nouveaux utilisateurs.
Bon je fais abstraction du HTML dans du Python mais ça me donne des boutons :)
Passons à RQL, je lis dans la FAQ : « Except that SPARQL did not exist when we started the project. Having SPARQL has a query language has been in our backlog for years. »
Ça reste quand même un atout clé pour moi et je trouve dommage que cette migration à SPARQL n'ait pas eu lieue depuis *des années* (et on revient au point sur le manque d'utilisateurs).
Enfin ça me semble assez éloigné de l'architecture que j'ai proposé (ou alors je n'ai pas trouvé le store RDF). Et si c'est pour le développer, on revient à « c'est un peu moins drôle que de tout refaire ».
NicolasChauvat le 15/03/2009 :
Au moins tu as regardé... bon, je suppose que quand tu dis qu'il n'y a pas assez de doc, c'est que http://www.cubicweb.org/doc/en/ ne te suffit pas, ce qui est compréhensible si on compare à la quantité de doc des projets qui ont déjà une large communauté.
Pour ce qui est de SPARQL, il est probable que cela arrive dans les deux prochains mois, même s'il n'est pas prévu que SPARQL remplace RQL à l'intérieur de la plate-forme.
Pour ce qui est des langages de template, rien n'empêche d'en utiliser, c'est juste que ça ne fait que compliquer les choses à mon avis. Plusieurs développeurs en discutent et font des essais qvec du python qui génère du HTML (dans le genre de ce qui se fait avec lxml), on verra quelle sera leur conclusion.
Pour la base de triplets RDF, tu peux essayer Jena, puis comparer avec http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/ et constater que dans un cas ce n'est pas aussi efficace que du relationnel et que dans l'autre il manque de quoi faire une interface web facilement.
Je suis surpris que tu n'aies pas vu la similitude entre ce que tu te proposes de faire et ce qui existe déjà. Es-tu certain d'avoir lu http://www.cubicweb.org/doc/en/A030-foundation.en.html#concepts ? Peut-être que la documentation n'est pas assez claire sur l'architecture de la plate-forme.
* Utilisations (site, widget, RIA, etc) - REST/APP - cubicweb peut servir de bdd (serveur) ou de service web ou d'application RIA.
* Représentations standardisées (HTML, JSON, Atom, etc) - existe dans CubicWeb, grâce à la notion de vue applicable aux objets qui respectent une interface.
* Ressources sémantiques (objets Python) - existe dans CubicWeb, qui dispose d'objets pour toutes les entités définies dans le modèle de données.
* Traitements asynchrones (Erlang) - existe dans CubicWeb, qui utilise Twisted.
* RDFAlchemy - dans CubicWeb, c'est un ORM qui utilise RQL comme langage d'interrogation.
Données (RDF) - dans CubicWeb, c'est une bonne vieille base de données relationnelle qui peut être vue, grâce à RQL, comme un ensemble de triplets.
* CouchDB, Hadoop, etc - il n'est pas encore possible d'utiliser ces bases avec CubicWeb, mais le serveur sait déjà interroger plusieurs sources de données et fusionner les résultats, il est donc envisageable de rajouter des pilotes pour ces bases.
Pour la taille communauté, c'est la poule et l'oeuf, mais j'ai bien compris que tu ne feras pas partie des premiers à l'adopter :)
Bon courage pour tes développements et à bientôt.