davidbgk
/
larlet-fr-david


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509
							<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>★ Architecture web moderne et agile — Biologeek — David Larlet</title>
  <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  <meta name="viewport" content="width=device-width, initial-scale=1"/>
  <!-- Fake favicon, to avoid extra request to the server -->
  <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  <link rel="manifest" href="/manifest.json">
  
  <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  
  <noscript>
    <style type="text/css">
      /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
      body {
        font-family: 'EquityTextB', serif;
      }
      h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
        font-family: 'EquityCapsB', sans-serif;
        font-variant: normal;
      }
    </style>
  </noscript>
  
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20080604-architecture-web-moderne-et-agile">

</head>
<body>
  <div>
    
    <header>
      <nav>
        <p>
          <small>
            Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
          </small>
        </p>
      </nav>
    </header>
    
    
  <section>
    <h1 property="schema:name">★ Architecture web moderne et agile</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/architecture_web_couchdb.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>Pour rebondir sur <a href="http://www.christian-faure.net/2008/06/01/dataware-et-metadataware/">les propos de Christian</a> qui essaye de combiner <abbr title="REpresentational State Transfer">REST </abbr> et <abbr title="Resource Description Framework">RDF</abbr>, 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 <a href="https://larlet.fr/david/biologeek/archives/20080112-ma-killer-app-pour-le-web-semantique/">la killer app sémantique</a> et qui fait partie des trois points bloquants actuels avec l'ergonomie et la confidentialité des données.</p>
<h2>Avant la ressource, il y a la donnée</h2>
<p>Comme le souligne Christian, <a href="https://larlet.fr/david/biologeek/archives/20070413-pour-ne-plus-etre-en-rest-comprendre-cette-architecture/">REST</a> s'adresse à des ressources et non directement à des données, d'où le problème lorsqu'on essaye de construire une <a href="https://larlet.fr/david/biologeek/archives/20070629-architecture-orientee-ressource-pour-faire-des-services-web-restful/">application RESTful</a> qui tape directement sur des triplets <a href="https://larlet.fr/david/biologeek/archives/20080425-le-point-sur-rdf-et-rdfa/">RDF</a>. Commençons par étudier le stockage, on verra l'accès plus tard.</p>
<p>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 <strong>laisse aujourd'hui généralement place au modèle non-structuré et distribué</strong> (CouchDB, Hadoop, BigTable, etc) qui a fait ses preuves grâce à Google.</p>
<p>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 !</p>
<p>Dans l'idéal, il faudrait avoir une base performante qui soit développée spécifiquement pour stocker du RDF, en pratique <strong>je crois plus en un mapping RDF sur une base structurée existante</strong>, il y a des projets comme <a href="http://wiki.apache.org/hadoop/HRDF">HRDF pour Hadoop</a> qui tentent justement d'arriver à ça. On arriverait au schéma suivant :</p>
<pre><code>Données (RDF)
    ↑
    | MapReduce + TODO
    |
Données sérialisées (CouchDB, Hadoop, etc)
</code></pre>
<p>Les opérations de <a href="http://hadoop.apache.org/core/docs/current/mapred_tutorial.html">MapReduce</a>, <a href="http://www.michael-noll.com/wiki/Writing_An_Hadoop_MapReduce_Program_In_Python">possibles en Python</a> et <a href="http://blog.last.fm/2008/05/29/python-hadoop-flying-circus-elephant">automatisables grâce aux générateurs</a>, 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 (?)</p>
<h2>Mais on veut manipuler des ressources !</h2>
<p>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 <strong>RRM pour Resource RDF Mapping</strong>, c'est ce que fait par exemple <a href="http://www.openvest.com/trac/wiki/RDFAlchemy">RDFAlchemy</a> qui est le pendant à SQLAlchemy qui est un <abbr title="Object Relational Mapping">ORM</abbr> classique.</p>
<p><em>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.</em></p>
<pre><code>Ressources sémantiques (objets Python)
    ↑
    | RDFAlchemy
    |
Données (RDF)
    ↑
    | MapReduce + TODO
    |
Données sérialisées (CouchDB, Hadoop, etc)
</code></pre>
<p>Une fois nos ressources définies, <strong>il faut maintenant un outil pour y accéder via une interface RESTful</strong>, c'est seulement ici que <a href="https://larlet.fr/david/biologeek/archives/20070501-developper-une-application-restful-avec-django/">Django entre en jeu</a>. 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 <a href="http://code.google.com/p/django-rest-interface/">django-rest-interface</a>, je ne suis pas totalement satisfait et le projet est mort).</p>
<pre><code>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)
</code></pre>
<p>Vous pouvez terminer le millefeuilles en connectant un site, un widget ou votre <abbr title="Rich Internet Application">RIA</abbr> 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).</p>
<pre><code>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)
</code></pre>
<h2>Et pour quelques threads de plus...</h2>
<p>J'en ai rapidement parlé lors de ma <a href="https://larlet.fr/david/biologeek/archives/20080521-conferences-django-pour-pycon-fr/">présentation de Django</a>, 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.</p>
<p>Pour ça, <strong>Erlang semble former un <a href="http://humani.st/scalable-web-apps-erlang-python/">couple parfait</a> avec Python</strong> 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.</p>
<pre><code>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)
</code></pre>
<p>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. <strong>Le meilleur des deux mondes.</strong></p>
<h2>Quelques inconvénients évidents</h2>
<p><strong>À chaque mapping, on perd en performances</strong> et là on fait Document → RDF → Resource → Représentation ce qui fait quand même quelques étapes... bien sûr <strong>on gagne en standardisation et en pérennité</strong>, il sera possible de changer d'outils, voire de supprimer certaines transitions plus tard lorsque les avancées technologiques suivront. <strong>C'est le coût de l'agilité</strong> et à ce stade il serait difficile d'estimer si c'est vraiment pénalisant au final.</p>
<p>Le problème des outils innovants, c'est qu'ils <strong>manquent d'extensions et/ou n'ont aucun benchmark</strong> 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.</p>
<p>Enfin, ça demande de <strong>maîtriser un bon nombre de technos</strong>, 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 :-).</p>
<p>À 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.</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 04/06/2008</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20081008-critique-du-livre-designing-obvious/" title="Accès à Critique du livre Designing the obvious">Critique du livre Designing the obvious</a></li>
        <li><a href="/david/biologeek/archives/20080811-rdf-adn-de-notre-identite-numerique/" title="Accès à ★ RDF, l&#39;ADN de notre identité numérique ?">★ RDF, l&#39;ADN de notre identité numérique ?</a></li>
        <li><a href="/david/biologeek/archives/20080716-differences-entre-identification-autorisation-et-authentification/" title="Accès à Différences entre identification, autorisation et authentification">Différences entre identification, autorisation et authentification</a></li>
      </ul>
    </div>
  </section>
  <section>
    <div id="comments">
      <h3>Commentaires</h3>
      
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Mat</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Desole c&#39;est peut etre un peu HS :<br />En parlant de MapReduce/Hadoop, je trouve le principe genial mais j&#39;ai du mal a voir concretement dans quel cas de figure on peut l&#39;utiliser dans des applis web classiques.</p>

<p>Serait-il envisageable de faire un billet avec des exemples d&#39;utilisation possibles ? (ex: en partant de services web classiques, voir quelles parties pourraient etre deleguees a des taches MapReduce).</p>

<p>Enfin merci pour tes articles de tres bonne qualite, j&#39;ai pas encore eu l&#39;occaz de le dire :)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Olivier</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tu ne dispenserais pas par hasard des formations orientées sémantique dont RDF ? ou si tu en connais, je suis intéressé.</p>

<p>Merci pour l&#39;article !</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Yoan</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Personnellement j&#39;enlèverais « Données RDF » qui sont à mon sens un format d&#39;échange et pas de travail, surtout en connaissant le princip de “leaky abstraction” et là il y en a dans trois cas -&gt;<br /> - stockage (CouchDB, HDFS, Mnesia, SimpleDB);<br /> - ressources Python<br /> - traitement asynchrones (Erlang?)</p>

<p>Données RDF est en entrée et sortie du stockage mais de l&#39;autre côté, l&#39;application interne travaillant avec son abstraction choisie. Ça n&#39;est pas très RDF-friendly, mais je peine à concevoir l&#39;autre cas comme étant viable (pour avoir joué avec ActiveRDF qui fait un mapping OO sur RDF).</p>

<p>La force d&#39;Erlang est le fait que tu puisses créer 10&#39;000 instances distribués sur toutes tes machines en un claquement de doigt et qu&#39;ils puissent tous communiquer entre eux simplement ensuite. Si tu n&#39;as pas la notion de distribution (le map/reduce de CouchDB) ou d&#39;évènementiel (le chat de Facebook pour ne citer que lui), je n&#39;en vois pas bien l&#39;usage.</p>

<p>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&#39;intru).</p>

<p>Donc oui, je suis contre mais l&#39;idée d&#39;une killer-app est intéressante. J&#39;avais pensé à un système de bookmarks, car il y a plétore d&#39;ontologies qui peuvent servir et le modèle est assez simple (FOAF + SIOC + SKOS + DC) Si ça t&#39;inspire ? J&#39;ai un bout de doigt à dédier à l&#39;idée.</p>

<p>-- Yoan</p>

<p>PS: nous sommes en &quot;june&quot; chez moi et saidoublementmal : français + anglais = impression bizarre, le mois de juin est en l&#39;honneur de la déesse romaine Junon (Juno en anglais, superbe film d&#39;ailleurs) et de ce fait prend la majuscule de rigueur en anglais.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&quot;laisse aujourd&#39;hui généralement place au modèle structuré et distribué&quot;</p>

<p>On aurait préféré un lien vers une référence plutôt que juste une mise en gras :-)<br />D&#39;autre part, la dernière fois que j&#39;ai regardé CouchDB, Hadoop et BigTable, ils travaillaient tous sur un modèle clef + valeur sans schéma. Ce n&#39;est pas franchement ce que j&#39;appelle un modèle structuré :-)</p>

<p>&quot;d&#39;où le problème lorsqu&#39;on essaye de construire une application RESTful qui tape directement sur des triplets RDF&quot;</p>

<p>Parler de triplet RDF, c&#39;est déjà se restreindre à une formalisation possible d&#39;un graphe. Mais en fonction de la complexité est de la structure de ton graphe, le triplet n&#39;est pas forcément la représentation la plus pertinente.</p>

<p>&quot;Personnellement j&#39;enlèverais « Données RDF » qui sont à mon sens un format d&#39;échange&quot;</p>

<p>Mais RDF n&#39;est pas un format ! RDF-XML est un format, N3 est un format. RDF est un modèle relationnel dans lequel (entre autre) l&#39;association est systématiquement qualifiée, contrairement aux modèles proposés par les SGDBR standard, où la qualification de l&#39;association se &quot;retrouve&quot; matérialisée par un attribut de l&#39;entité.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Christian Fauré</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Hello David, et merci d&#39;avoir si bien continué la discussion, également à Yoan et Damien pour leur éclairage :-)<br />Quelques remarques en passant :<br />- j&#39;ai eu une petite discussion avec Gautier (<a href="http://www.lespetitescases.net">http://www.lespetitescases.net</a>) précisément sur les différents modes de stockage RDF d&#39;où il ressort qu&#39;aujourd&#39;hui, et pour encore un bon moment, c&#39;est le triple Store sur une base relationnelle qui donne le plus de satisfactions (Got va publier un bench de Virtuoso allant jusqu&#39;à 3 milliards de triples effectués dans le cadre d&#39;un projet)<br />- 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&#39;est souvent ce pourquoi on met en place du RDF). Par contre si ton appli a des requêtes pas trop complexes, ç&#39;est plus adapté.<br />-Concernant les GUIs j&#39;ai la conviction qu&#39;il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l&#39;architecture des données en mode relationnel.</p>

<p>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 :-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Got</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Christian a déjà dit tout ce que je pouvais dire. Quelques précisions, alors :</p>

<p>- L&#39;avantage de se baser sur une BDR pour stocker du triples RDF est de disposer en natif d&#39;un certain nombre de fonctionnalités (backup, gestion des transactions, système d&#39;indexations voire système de réplication et procédure stockée...).</p>

<p>- Pour le bench, Christian a un peu exagéré (si peu ;-) ), puisqu&#39;il s&#39;agit de 2 milliards de triples, mais c&#39;est déjà très structurant :-) Je ne sais pas encore comment je vais diffuser ce bench, mais je le ferai d&#39;une manière ou d&#39;une autre.</p>

<p>- @Olivier, en guise d&#39;intro, ce diaporama pourra peut-être t&#39;aider : <a href="http://www.slideshare.net/lespetitescases/a-la-dcouverte-du-web-smantique/">http://www.slideshare.net/lespetitescases/a-la-dcouverte-du-web-smantique/</a> (David, j&#39;espère que tu m&#39;excuseras le petit coup de pub). Il existe quelques formations payantes et sinon, tu peux assister au prochain semantic Camp, on essaye d&#39;y faire des intros aux technologies.</p>

<p>- @Yoan, une petite question : en quoi RDF ne serait qu&#39;un format d&#39;échange et pas un format de travail ?? Comme l&#39;a dit Damien, ce n&#39;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&#39;avantage de disposer d&#39;un modèle et non d&#39;un format !), l&#39;important est de pouvoir utiliser SPARQL et pouvoir faire au moins un peu d&#39;inférences. Le principe de RDF est bien de séparer la donnée elle-même de l&#39;application ce qui est l&#39;inverse de ta proposition, me semble-t-il ?</p>

<p>- toujours pour Yoan : il existe déjà des systèmes de bookmarks utilisant les technologies du Web sémantique, par exemple : Semanlink, <a href="http://www.semanlink.net/sl/home">http://www.semanlink.net/sl/home</a> et gnizr, <a href="http://code.google.com/p/gnizr/">http://code.google.com/p/gnizr/</a></p>

<p>- @David (quand même ;-) ) Un autre ORM pour RDF à garder à l&#39;oeil : Topaz, <a href="http://www.topazproject.org/">http://www.topazproject.org/</a> qui fonctionne avec Mulgara et Fedora (pas la distribution, le repository) et merci pour ce billet très complet.</p>

<p>Finalement, j&#39;avais des choses à dire, désolé pour ce long commentaire !</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Christian Fauré</span> le <span class="comment-date" property="schema:commentTime">04/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Ah au fait, puisque tu regardes côté Erlang, il y a un repository special pour les applis en Erlang : <a href="http://www.erlang.org/documentation/doc-5.0.1/lib/mnesia-3.9.2/doc/index.html">http://www.erlang.org/documentation/doc-5.0.1/lib/mnesia-3.9.2/doc/index.html</a></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Mat : j&#39;y réfléchis et merci :-)</p>

<p>@Olivier : c&#39;est envisageable oui, par contre ça va me demander pas mal de temps de préparation !</p>

<p>@Yoan : le gros avantage de garder l&#39;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.</p>

<p>Quand je parle d&#39;Erlang c&#39;est effectivement pour traiter tout ce qui est crawling/notifications/etc.</p>

<p>&gt; J&#39;ai un bout de doigt à dédier à l&#39;idée.</p>

<p>Vu la qualité du doigt, je n&#39;hésiterais pas ;-)<br />Il faut que je me bouge là-dessus mais j&#39;ai d&#39;autres priorités actuellement.</p>

<p>@Damien B : <br />&gt; On aurait préféré un lien vers une référence plutôt que juste une mise en gras :-)</p>

<p><a href="http://labs.google.com/papers/bigtable.html">http://labs.google.com/papers/bigtable.html</a><br /><a href="http://hadoop.apache.org/core/docs/current/">http://hadoop.apache.org/core/docs/current/</a><br />Je n&#39;ai pas vraiment trouvé LE document qui permet vraiment de tout comprendre d&#39;un coup malheureusement.</p>

<p>&gt; Parler de triplet RDF, c&#39;est déjà se restreindre à une formalisation possible d&#39;un graphe.</p>

<p>Tout à fait, je voudrais m&#39;en tenir à ce choix car c&#39;est celui qui a été adopté par des personnes beaucoup plus compétentes que moi dans le domaine. Cela dit, la couche &quot;Données sérialisées&quot; permettrait justement d&#39;étendre le graphe derrière.</p>

<p>@Christian Fauré : merci pour tes précisions.</p>

<p>&gt; Concernant les GUIs j&#39;ai la conviction qu&#39;il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l&#39;architecture des données en mode relationnel.</p>

<p>Tout à fait, tant que l&#39;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.</p>

<p>@Got : ne t&#39;excuse pas de commentaires aussi intéressants malheureux !</p>

<p>J&#39;attends avec impatience ton bench car je trouve que c&#39;est quelque chose qui manque cruellement. À part un ou deux cas isolés et qui sont rapidement obsolètes, il n&#39;y a rien de suivi et pertinent.</p>

<p>Je ne connaissais pas Topaz, par contre c&#39;est en Java...</p>

<p>@Christian Fauré : oui je connaissais de nom, je n&#39;ai jamais eu le temps de m&#39;y intéresser plus que ça par contre, merci.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Luke Hoersten</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>I have no idea what you&#39;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!</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Got</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@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&#39;en avais relevé un certain nombre dans le billet suivant : <a href="http://www.lespetitescases.net/node/988">http://www.lespetitescases.net/node/988</a> (qui d&#39;ailleurs contient une référence qui pourrait intéresser Damien : &quot;The end of an architectural Era&quot;, <a href="http://www.mit.edu/people/dna/vldb07hstore.pdf">http://www.mit.edu/people/dna/vldb07hstore.pdf</a> ).</p>

<p>Virtuoso fait l&#39;effort (à son avantage d&#39;ailleurs...) de publier régulièrement les résultats des benchmarks qu&#39;ils effectuent (la dernière livraison : <a href="http://virtuoso.openlinksw.com/blog/index.vspx">http://virtuoso.openlinksw.com/blog/index.vspx</a> et <a href="http://www.openlinksw.com/weblog/oerling/?id=1368">http://www.openlinksw.com/weblog/oerling/?id=1368</a>). AllegroGraph, aussi, je crois.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@David<br />&quot;Je n&#39;ai pas vraiment trouvé LE document qui permet vraiment de tout comprendre d&#39;un coup malheureusement.&quot;</p>

<p>On s&#39;est mal compris, la référence que j&#39;aurais souhaité avoir c&#39;était l&#39;étude de marché qui montrait que les SGBDR traditionnels avaient montrés leurs limites et *qu&#39;en conséquence*  ils laissaient  aujourd&#39;hui *généralement* leur place aux &quot;modèle (non-)structuré et distribué&quot; :-) Sinon pour comprendre BigTable et le reste, c&#39;est assez rapide : c&#39;est un BerkeleyDB-like distribué (après la façon dont l&#39;aspect distribution est géré, on s&#39;en tape, c&#39;est l&#39;objectif).</p>

<p>@Christian Fauré</p>

<p>&quot;Concernant les GUIs j&#39;ai la conviction qu&#39;il y a de grandes choses à faire car nos interfaces utilisateurs actuelles sont souvent le masque de l&#39;architecture des données en mode relationnel.&quot;</p>

<p>Nooooooon !! Pas du MDA !! Pas çaaaaaaaaaa !!!</p>

<p>@Got</p>

<p>Tiens, je n&#39;avais pas suivi le lien à l&#39;époque sur le blog.<br />Concernant ce papier, on dirait des étudiants en zététique qui nous assène toutes leur morgue en n&#39;argumentant rien, et qui au final, nous refond le coup de MySQL 3 : <br />- &quot;Regardez, on est dix fois plus rapide, vous êtes obsolètes&quot;<br />- &quot;Oui, mais vous n&#39;avez pas ça, ça, ça et ça&quot;<br />- &quot;Mais c&#39;est parce que vous n&#39;en avez pas besoin ! Il faut être bête pour en avoir besoin ! Ce sont vos applications qui sont mal foutues !&quot;<br />On voit ce qu&#39;il en est devenu avec MySQL 5 (qu&#39;on peut toujours utiliser avec du MyISAM si effectivement on n&#39;a pas besoin de grand chose).<br />J&#39;espère qu&#39;il n&#39;a pas été publié dans une revue...<br />Exemple typique, sur la haute disponibilité :<br />&quot;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.&quot;</p>

<p>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&#39;étranger se seraient retrouvées sérieusement embêtée avec cette stratégie. La haute disponibilité, c&#39;est que faire quand tout crashe ? Avec eux ça devient : que faire si j&#39;ai une ou deux machines en panne mais que tout le reste (alimentation électrique, réseau) tourne parfaitement ?</p>

<p>Et un dernier extrait pour finir :<br />&quot;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&quot;</p>

<p>Si on considère un réseau d&#39;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&#39;exécution, et où toutes les opérations utiles sont effectuées en moins d&#39;une seconde, alors les conclusions suivantes deviennent évidentes :<br />votre usine est à jeter.</p>

<p>Donc oui, c&#39;est assez intéressant comme article, je me suis fait reprendre pour moins que ça pendant mes études :-)</p>

<p>(oups, encore un pâté, désolé)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Oh, j&#39;avais raté la fin :<br />&quot;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<br />stored procedure language.&quot;</p>

<p>Ca me laisse sans voix.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Luke Hoersten : it&#39;s about a web architecture which handles semantic content (and scales), thanks for your post ;-)</p>

<p>@Got : merci pour tous ces liens, un autre pour la route : <a href="http://www4.wiwiss.fu-berlin.de/benchmarks-200801/">http://www4.wiwiss.fu-berlin.de/benchmarks-200801/</a></p>

<p>@Damien B : ton dernier commentaire me laisse dans le même état :|</p>

<p>Concernant la preuve demandée, je n&#39;ai malheureusement aucun argument à avancer, c&#39;est plus une « intuition geek » résultant de mes lectures (pas très scientifique comme approche, je te l&#39;accorde).</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">05/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je continue sur le PDF de Got, c&#39;est décidément une mine :<br />&quot;At this point SQL is a legacy language with many known serious flaws, as noted by Chris Date two decades ago [Dat84].&quot;</p>

<p>&quot;[Dat84] Date, C. J. “A critique of the SQL database language.”In SIGMOD Record 14(3):8-54, Nov. 1984.&quot;</p>

<p>PDF en question que vous pouvez trouver ici : <a href="http://www.cs.duke.edu/%7Ejunyang/courses/cps216-2003-spring/papers/date-1983.pdf">http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/date-1983.pdf</a></p>

<p>Papier écrit donc fin 83, basé sur &quot;X3H2 (American National Standards Database Committee) Draft Proposed Relational Database Language. Document X3H2-83-152(August 1983).&quot; et l&#39;état de l&#39;art (principalement PL/1 en langage hôte). Je n&#39;irais pas jusqu&#39;à dire que certains lecteurs ici n&#39;étaient pas nés à l&#39;époque, et d&#39;autres ne savaient pas encore lire :-) Mais quand même.</p>

<p>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&#39;heure actuelle, je pense qu&#39;à peu près tous les SGBDR courants son compatible quasiment à 100% avec SQL-99.</p>

<p>Et là est le problème, c&#39;est qu&#39;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&#39;en est d&#39;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).</p>

<p>Bref... ils se sont mis à 6 pour faire ce papier, et visiblement il n&#39;y en a aucun qui a été choqué de baser leurs critiques majeures de SQL sur un papier d&#39;il y  a bientôt 25 ans, alors que SQL n&#39;était pas normalisé à cette époque, et à connu trois révisions majeures entre (dont une pas vraiment encore assimilée il faut l&#39;admettre), et surtout sans émettre le moindre avis critique là-dessus : &quot;At this point SQL is a legacy language with many known serious flaws, as noted by Chris Date two decades ago [Dat84].&quot; C&#39;est proprement hallucinant ce niveau de bâclage.</p>

<p>Je reprendrais le titre et le sous-titre :<br />&quot;The End of an Architectural Era&quot;</p>

<p>Oui, c&#39;est la fin de l&#39;époque où les papiers a priori destinés à publication étaient architecturés correctement.</p>

<p>&quot;(It’s Time for a Complete Rewrite)&quot;<br />Parfaitement d&#39;accord ! Qu&#39;ils refassent leur torchon ! Ca devrait aller vite à 6.</p>

<p>Merci Got pour cette référence :-D</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">09/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Damien B : tu devrais leur écrire, en prenant des pincettes, mais ton avis est plus que pertinent...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Damien B</span> le <span class="comment-date" property="schema:commentTime">09/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Ecrire à 4 mecs du MIT et un de Microsoft ? Ils ont le pognon pour payer des relecteurs :-) Autant laisser ce papelard dans l&#39;oubli...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Yoan</span> le <span class="comment-date" property="schema:commentTime">11/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Tout à fait, avoir de l&#39;inférence est important, c&#39;est clair. J&#39;ai juste un peu tendance à croire ce que je vois, et il me reste à explorer donc.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">mapson</span> le <span class="comment-date" property="schema:commentTime">22/06/2008</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>&gt; Dans l&#39;idéal, il faudrait avoir une base performante qui soit développée spécifiquement pour stocker du RDF</p>

<p>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&#39;ai pas trouvé de tarif pour la version illimitée.</p>

<p><a href="http://agraph.franz.com/allegrograph/">http://agraph.franz.com/allegrograph/</a></p>

<p>Ils ont d&#39;ailleurs d&#39;autres produits pour le web sémantique (en Common Lisp).</p>

<p>Personnellement, je ne crois pas trop aux promesses d&#39;un web sémantique. J&#39;ai l&#39;impression qu&#39;il force l&#39;utilisateur à se plier aux contraintes de l&#39;ordinateur au lieu de l&#39;inverse, par exemple en le forçant à renseigner des méta-données genre Dublin Core (et à le faire correctement, ce qui n&#39;est pas à la portée de tout le monde) pour faciliter le travail des moteurs de recherche.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">NicolasChauvat</span> le <span class="comment-date" property="schema:commentTime">27/02/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>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 <a href="http://www.cubicweb.org">http://www.cubicweb.org</a> ? L&#39;architecture que tu décris est proche de celle que je t&#39;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&#39;est un peu moins drôle que de tout refaire et ce n&#39;est pas du django-que-tu-aimes, mais tu aurais de quoi jouer: c&#39;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 ;)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">01/03/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@NicolasChauvat : alors j&#39;ai pris le temps de regarder en détail et déjà le premier point bloquant c&#39;est la doc. Je ne peux pas miser sur un framework (aussi puissant soit-il) qui dispose d&#39;aussi peu de doc.</p>

<p>C&#39;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&#39;avance le framework n&#39;évoluera pas assez vite car la barrière d&#39;entrée est trop élevée pour qu&#39;il y ait de nouveaux utilisateurs.</p>

<p>Bon je fais abstraction du HTML dans du Python mais ça me donne des boutons :)</p>

<p>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. »</p>

<p>Ça reste quand même un atout clé pour moi et je trouve dommage que cette migration à SPARQL n&#39;ait pas eu lieue depuis *des années* (et on revient au point sur le manque d&#39;utilisateurs).</p>

<p>Enfin ça me semble assez éloigné de l&#39;architecture que j&#39;ai proposé (ou alors je n&#39;ai pas trouvé le store RDF). Et si c&#39;est pour le développer, on revient à « c&#39;est un peu moins drôle que de tout refaire ».</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">NicolasChauvat</span> le <span class="comment-date" property="schema:commentTime">15/03/2009</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Au moins tu as regardé... bon, je suppose que quand tu dis qu&#39;il n&#39;y a pas assez de doc, c&#39;est que <a href="http://www.cubicweb.org/doc/en/">http://www.cubicweb.org/doc/en/</a> 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é.</p>

<p>Pour ce qui est de SPARQL, il est probable que cela arrive dans les deux prochains mois, même s&#39;il n&#39;est pas prévu que SPARQL remplace RQL à l&#39;intérieur de la plate-forme.</p>

<p>Pour ce qui est des langages de template, rien n&#39;empêche d&#39;en utiliser, c&#39;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.</p>

<p>Pour la base de triplets RDF, tu peux essayer Jena, puis comparer avec <a href="http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/">http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/</a> et constater que dans un cas ce n&#39;est pas aussi efficace que du relationnel et que dans l&#39;autre il manque de quoi faire une interface web facilement.</p>

<p>Je suis surpris que tu n&#39;aies pas vu la similitude entre ce que tu te proposes de faire et ce qui existe déjà.  Es-tu certain d&#39;avoir lu <a href="http://www.cubicweb.org/doc/en/A030-foundation.en.html#concepts">http://www.cubicweb.org/doc/en/A030-foundation.en.html#concepts</a> ? Peut-être que la documentation n&#39;est pas assez claire sur l&#39;architecture de la plate-forme.</p>

<p>* Utilisations (site, widget, RIA, etc) - REST/APP - cubicweb peut servir de bdd (serveur) ou de service web ou d&#39;application RIA.<br />* Représentations standardisées (HTML, JSON, Atom, etc) - existe dans CubicWeb, grâce à la notion de vue applicable aux objets qui respectent une interface.<br />* Ressources sémantiques (objets Python)  - existe dans CubicWeb, qui dispose d&#39;objets pour toutes les entités définies dans le modèle de données.  <br />* Traitements asynchrones (Erlang) - existe dans CubicWeb, qui utilise Twisted.<br />* RDFAlchemy - dans CubicWeb, c&#39;est un ORM qui utilise RQL comme langage d&#39;interrogation.<br />Données (RDF) - dans CubicWeb, c&#39;est une bonne vieille base de données relationnelle qui peut être vue, grâce à RQL, comme un ensemble de triplets.<br />* CouchDB, Hadoop, etc - il n&#39;est pas encore possible d&#39;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.</p>

<p>Pour la taille communauté, c&#39;est la poule et l&#39;oeuf, mais j&#39;ai bien compris que tu ne feras pas partie des premiers à l&#39;adopter :)</p>

<p>Bon courage pour tes développements et à bientôt.</p>
    </div>
</div>

    </div>
  </section>

    
    <footer>
      <nav>
        <p>
          <small>
            Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
          </small>
        </p>
      </nav>
    </footer>
    
  </div>
  
  <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  
  <script data-no-instant>InstantClick.init()</script>
  
</body>
</html>