Ce billet est petite pierre à ajouter à la série de Got :
– les carcans de la pensée documentaire (1) et (2)
– l’antilope sur le Web
Que vous trouverez brillamment résumés chez Hubert.

Dans le Web sémantique, on décrit le monde sous forme de triplets sujet – prédicat – objet. Chaque triplet est indépendant : ce qui veut dire qu’il doit pouvoir être compris sans avoir besoin de contexte, ou du moins, d’autre contexte que la connaissance des entités qui sont représentées par les URI.
Plus j’avance dans ma connaissance du Web sémantique, plus je suis persuadée que les identifiants – les URI – sont la clef de tout. Une fois qu’on a conçu correctement ses URI, tout le reste coule de source.

URI abstraites, URI concrètes
Quand j’ai commencé à travailler sur les identifiants ARK, nous avons introduit dans la notion d’identifiant une différence entre ressource abstraite et concrète.
Une ressource que nous considérions comme abstraite, intellectuelle, par exemple un document numérique comme celui-là, était potentiellement mouvante : bien que son contenu soit toujours le même, sa présentation, sa forme, et les fonctionnalités associées pouvaient changer.
Au contraire, une ressource concrète correspondant à ce document dans un certain format (mode texte ou mode image, tiff ou jpeg…), dans une certaine qualité (par exemple haute et basse résolution), ou dans un certain contexte de visualisation (en pleine page, avec sa table des matières, sous forme de vignettes…) était définie comme stable.
Dès le départ, nous avons donc défini que chaque objet numérique aurait une URI abstraite, en l’occurrence ark:/12148/bpt6k28585w, et plusieurs URI concrètes permettant d’appeler ses formats, résolutions, contextes etc. Par exemple : http://gallica.bnf.fr/ark:/12148/bpt6k28585w.texte pour le visualiser en mode texte dans Gallica, ou http://catalogue.bnf.fr/ark:/12148/bpt6k28585w/f46 pour visualiser la 46e image dans le contexte du catalogue.

Ce choix (qui n’avait rien à voir avec le Web sémantique à l’époque) m’a bien aidée à comprendre ensuite certaines notions liées à l’utilisation des URI dans le Web sémantique, qui est décrite dans la note du W3C « URIs sympas pour le Web sémantique » (déjà évoqué succinctement ici).

Dans Gallica, l’URI abstraite ne correspond à rien d’autre qu’à une page Web qui est la représentation que nous avons décidé de donner, à un instant T, de ce document dans Gallica. Si je ne vous avais pas dit qu’il y avait une URI abstraite, vous n’auriez aucun moyen de le savoir.
Dans le Web sémantique, au contraire, on utilise effectivement l’URI abstraite d’une ressource pour effectuer un certain nombre d’assertions sur cette ressource : les fameux triplets.

La matérialisation des triplets
Évidemment, ces triplets sont comme tout en ce monde : ils ont une matérialisation. C’est-à-dire que si on veut en faire quelque chose, il va falloir les faire passer du monde de la pensée abstraite au monde physique, et pour cela les exprimer d’abord en terme de modèle (je choisis comment je formule ma phrase, ou mon triplet), puis les manifester en termes de support (j’inscris ma phrase ou mon triplet sur un support, fut-il numérique). J’emploie à dessein les termes d’exprimer et manifester, je suis sûre qu’il y en a qui me suivent ;-)
Pour des raisons de commodité évidente, on n’exprime pas chaque triplet sur un support indépendant du triplet voisin. On les regroupe dans des … documents (ou dans dans une base de données, mais vous noterez que Got assimile, très justement à mon avis, l’enregistrement dans une base de données qu’est une notice bibliographique à un document). Cela permet d’alléger un peu la syntaxe (RDF étant quand même pas mal verbeux) en ne répétant pas tout le temps l’URI dont on parle, et de regrouper dans un même support, comme un fichier RDF/XML, un ensemble de triples qui concernent la même ressource (par exemple).

Ce qu’il est important de comprendre, c’est que ce regroupement des triplets dans un document est, en principe, non signifiant : on peut, en théorie, choisir de manière libre et arbitraire quels triplets on regroupe dans un fichier, et quels triplets on met ailleurs. Je dis bien en théorie, car en pratique, et c’est là que je rejoins JMS dans son dernier commentaire, l’inscription des données dans un document n’est pas juste un hasard. Elle correspond généralement à une formalisation suivant un protocole défini et qui permet aux gens (les machines, elles, s’en foutent) de reconnaître la structure de l’information qui leur est proposée et d’en faciliter la manipulation.

Mais je m’éloigne de mon propos.

La fixation des triplets dans un document n’est qu’une des représentations possibles de l’information qu’ils contiennent, et c’est ça qui est intéressant dans le Web sémantique. Pour une même ressource abstraite, je vais pouvoir proposer différentes représentations, qui varieront suivant la forme (je peux décrire une seule ressource dans un fichier, ou plusieurs), la qualité (je peux retenir 10 triplets concernant cette ressource ou en retenir 100) ou encore le contexte (choisir certains triplets plutôt que d’autres) que je souhaite donner à mon information.
A cette étape là on définit ce qu’on appelle le « generic document » ; qui équivaut à la manifestation des triples qu’on a choisis sur un support et qui a lui-même une URI, différente de celle de l’entité abstraite.

Le Web de données et ses documents
Le travail sur le <a href="http://linkeddata.orglinked data a été à l’origine de réflexions importantes concernant la représentation des données en RDF sous forme de documents. L’objectif du linked data étant de rendre des données disponibles sur le Web, il a paru rapidement utile de pouvoir les fournir sous forme de données (pour les machines) mais aussi sous forme de pages Web, c’est à dire de documents (pour les humains).

C’est là qu’entre en scène le mécanisme de négociation de contenu, qui est décrit justement dans la note en question du W3C. La négociation de contenu sert à gérer le passage de l’URI abstraite au document. En gros (je caricature), on envoie à un serveur une URI abstraite, il en déduit l’URI du generic document, puis il regarde si vous êtes un humain ou une machine avant de vous renvoyer soit une page Web, soit un ficher RDF.
Ce dernier niveau, le niveau technique, visible, pratique, c’est ce qu’on appelle le « Web document » ; qui correspond à une formalisation précise du « generic document », une représentation dans un format particulier.

Le Web de données vu comme une publication
Là je vais tordre un peu le cou à nos concepts bibliothéconomiques habituels, mais imaginons que nous essayions de qualifier le Web de données comme une publication, ou un ensemble de publications.

En terme de modèle documentaire, si je prends une idée (une œuvre par exemple) et que je la mets en RDF, son expression est à la fois atomisée (sous forme de triplets) et illimitée (de par les liens avec d’autres triplets). Le nombre de manifestations, ou documents, que je peux en tirer est potentiellement infini. Et il peut y avoir plusieurs items ou documents techniques qui représentent chaque manifestation de façon appropriée au mode technique d’accès.

Ainsi, même dans le Web sémantique, tout n’est pas de la donnée. Il y a forcément du document quelque part, et même s’il faut réussir à l’ignorer pour sortir du « carcan de la pensée documentaire », je trouve qu’il est excessif de nier son existence. Pour des gens comme nous qui sommes habitués à manipuler des concepts documentaires, cette négation est même contre-productive. Les documents existent, on peut les voir dans l’espace du Web, et en tant que bibliothécaires il nous sera nécessaire de les identifier et les qualifier pour pouvoir nous approprier le Web sémantique.

Dans un de mes derniers billets, je vous parlais de LIBRIS, le catalogue collectif suédois, développé en méthode agile. Il s’avère aujourd’hui, d’après un article sur Nodalities (blog Talis), que Libris serait aussi le premier catalogue de bibliothèque intégralement disponible dans le Linked data.

Sur cette page technique on peut voir que leur préoccupation de rendre le catalogue « machine-readable » a pris une diversité de formes : une API spécifique nommée Xsearch, à laquelle s’ajoutent OpenSearch, unAPI, Z3950 et SRU, et OpenURL-Coins.
Mais dans l’article ils expliquent bien que tout cela, pour passionnant que cela soit, ne va pas aussi loin que le Linked Data qui permet de relier les données avec d’autres ressources disponibles sur le Web, et qu’ils « sont tombés amoureux de SPARQL » (je cite).

Tout est expliqué sur un blog spécifique. En anglais, pas en suédois ;-) Je leur tire une nouvelle fois mon chapeau. A l’heure où LCSH.info a été débranché pour des raisons institutionnelles, il était temps que d’autres bibliothèques se positionnent sur le Linked Data et montrent qu’elles n’ont pas peur de rendre leurs données plus visibles et plus accessibles.

La communauté présente à ISWC est quand même largement (mais pas exclusivement, j’en suis la preuve vivante ;-) composée de développeurs et d’informaticiens qui, très naturellement, cherchent la solution à leurs problèmes dans les outils. Or, l’un des problèmes majeurs du SemWeb est le suivant : comment rendre simple aux yeux des utilisateurs ce qui est, de toute évidence, compliqué, à savoir la structure complexe des données qui composent le SemWeb.

L’enjeu se situe à la fois du côté de la production et de l’usage. Commençons par la production.

Je classerais les outils d’aide à la production que j’ai vus en deux catégories : les assistants à la production d’ontologies, et les interfaces de type wiki.

Les premiers, auxquels une session était consacrée, ont principalement pour objectif de permettre à des « experts métier », c’est à dire des personnes qui ont d’importantes connaissances thématiques mais pas de compétences techniques en gestion des connaissances, de produire ou contribuer à la production des ontologies de leur domaine. Je ne vais pas rentrer dans les détails, cela allait du plug-in pour travailler en collaboratif dans Protégé à un outil qui transforme du pseudo langage naturel (des phrases simples comme « there are students, professors and universities ; ‘PhD Student’ is a type of student » etc.) en classes et propriétés dans une ontologie. On peut même générer des ontologies et des triples en utilisant des feuilles de calcul.
Ce qui m’a particulièrement frappé, c’est que quelle que soit l’ingéniosité déployée par les concepteurs de ces outils pour les rendre puissants, souples, attractifs, simples, riches et bien d’autres choses encore, leur constat final était toujours le même : l’ontologie résultant de ce processus n’est pas de qualité suffisante pour permettre de l’exploiter sans l’intervention préalable d’un « knowledge engineer », un expert en ontologies.

Un peu décevant, n’est-ce pas ? Alors tournons-nous vers l’autre hypothèse, celle des wikis (ou wiki-like) sémantiques. En fait, il existe toute une gamme d’outils qui permettent de générer des données en RDF de manière plus ou moins transparente pour l’utilisateur, dans la mouvance du Web 2.0. On peut citer par exemple Semantic Media Wiki (voir aussi ici). Dans la même veine, on nous a présenté divers outils de « semantic desktop » ou de « semantic knowledge management », comme par exemple K-now qui permet de créer des ontologies sous forme de formulaires puis de créer des triples en remplissant les formulaires.
Je me réfèrerai de nouveau à l’intervention de Mark Greaves (au passage, si vous voulez savoir ce qu’il a vraiment raconté, vous pouvez lire ces notes bien plus précises que les miennes). En étudiant les wikis sémantiques on peut tirer quelques leçons essentielles :
– l’importance des interfaces utilisateurs (il faut que ce soit joli et facile à utiliser)
– l’importance du « jardinage » (il faut des gens qui font sans arrêt du petit nettoyage, sinon ça devient du grand n’importe quoi)
– les ontologies créées par les utilisateurs (du wiki) sont médiocres (elles sont moins structurées et moins riches que ce qu’on pourrait attendre)
– on est obligés de compléter la structure RDF par du langage naturel.

Bon, je ne peux pas achever ce panorama des outils de production sans parler de Freebase. Freebase a fait l’objet d’une keynote assez largement reconnue comme excellente. Freebase est une sorte de Wikipedia, mais qui repose sur des données structurées modélisées sous forme de graphe. Dans Freebase, les utilisateurs peuvent ajouter des données mais aussi agir sur la façon dont elles sont organisées (il était question de « schéma » plutôt que d' »ontologie »).

Je passe sur la description détaillée et je saute directement à la conclusion : Freebase, est-ce ou non du Web sémantique ? John Giannandrea qui présentait la keynote a lui-même posé la question, en disant que oui (parce qu’elle repose sur des données modélisées sous forme de graphe et qu’elle apporte une importance toute particulière aux URIs) et non (parce qu’elle ne contient pas d’ontologie et n’implémente pas les aspects description logique). A quoi Ivan Herman, qui pilote l’activité SemWeb au W3C, a répondu que la logique n’était pas obligatoire et que, bienvenue dans le Web sémantique.
Je ne sais pas s’ils auraient été aussi bien accueillis s’ils n’avaient pas, il y a à peine un mois, mis en place un accès à Freebase en RDF qui permet d’exploiter les données de Freebase dans le Linked Data. Voir les réserves de Got exprimées il y a un an (il vous dirait qu’ils ne font toujours pas de SPARQL et que ça craint, mais autant que je sache, SPARQL n’est pas un critère de base pour être dans le linked data ;-).
Evidemment si on s’intéresse, une fois encore, à la qualité des données et de la modélisation, on obtiendra des réponses bien naturelles comme « il vaut mieux des données inexactes que pas de données » ou « cela ne peut que s’améliorer avec le temps ». Que celui qui n’a jamais renoncé à corriger un article dans Wikipedia leur jette la première pierre…

Bref bref : c’est pas demain que n’importe qui pourra faire des ontologies. En sortant de là, je me demandais pourquoi la question (de réussir à associer des « non experts » à la production des ontologies) n’était posée qu’en termes d’outils, et pas d’une façon plus large en termes d’organisation, de ressources humaines, de montée en compétences, etc.
Ca doit être un truc de bibliothécaire, en tout cas je ne suis pas surprise de constater que n’importe qui ne peut pas modéliser des données, même avec un super outil qui fait tout tout seul (même si je pense qu’on pourrait essayer d’aider les gens en les formant).
En tout cas, d’après ce que j’ai pu entendre à plusieurs reprises, que ce soit dans les conférences ou autour d’un repas, la modélisation des données reste un des problèmes majeurs du Web sémantique aujourd’hui.

L’initiative « Linked Data » est un des faits marquants du SemWeb ces dernières années et il est intéressant de voir qu’elle est complètement intégrée dans la « vie quotidienne » de la communauté SemWeb. Il y en a qui disent même qu’elle aurait sauvé le SemWeb d’une mort certaine ;-) En tout cas, tout comme l’observation des tendances du Web, le « linked data » est plutôt un thème omniprésent de la conférence mais cela me semble intéressant de faire un focus dessus car il intéresse particulièrement la communauté des bibliothèques.

Le linked data, c’est une des visions du Web Sémantique (pas la seule visiblement) dans laquelle l’objectif de base est de mettre en ligne le plus possible de données structurées en RDF (des « triples »). Pas d’inférence, pas de raisonnement logique ou d’intelligence artificielle à ce niveau : il s’agit déjà de mettre les données à disposition pour qu’elles puissent être réutilisées dans d’autres contextes. (On peut difficilement imaginer quelque chose qui soit plus dans l’esprit des bibliothèques, pas vrai ?)
Une consigne de base : mettre le plus possible de liens (je veux dire, d’URIs déréférençables – en savoir plus) dans les triples, pour faciliter la navigation dans le Web of data. Le linked data, c’est le mash-up ultime, c’est le « Web of data » qui constitue le matériau que pourront réutiliser les machines pour rendre des services, répondre à des questions, etc.

Donc en fait, à chaque fois que quelqu’un dit qu’il a créé des triples, on lui demande s’ils sont disponibles en linked data. La question a été sensible autour de Freebase (je reviendrai dessus) qui a récemment publié ses données dans le Web of Data.

Mais me direz-vous, qu’est-ce que ça va nous apporter de mettre nos données dans le linked data ? Je vous en citerai deux exemples qui m’ont particulièrement frappé.

Le premier est un projet réalisé par une équipe de recherche d’Amsterdam qui porte sur l’interopérabilité des informations d’actualité (« news items »). Le projet était (brillamment) présenté par Raphaël Troncy. Pour être exploitables, les actualités ont besoin d’être contextualisées, et homogénéisées entre des différents médias et leurs formats de métadonnées respectifs. Pour ce faire, le projet NewsML propose une modélisation en RDF des données d’actualités et des différents vocabulaires utilisés pour les écrire, attribue partout des URI déréférençables, puis fait une série de manipulations pour enrichir ces données.
Parmi les manipulations en question, on notera deux choses : la reconnaissance d’entités nommées (réalisée grâce à Open Calais), et l’utilisation du Linked data pour assigner aux entités nommées trouvées des URI correspondant aux ressources qui existent dans le Linked Data.
Donc : si mes données sont disponibles dans le Web of data, et que mes URI sont déréférençables, je pourrai grâce à ce système gagner en visibilité puisque mes données seront reliées à des faits d’actualité.

Autre exemple : DBPedia Mobile.
Il s’agit d’une application développée par (entre autres?) la Freie Universität de Berlin pour naviguer dans le Web of data sur un téléphone portable. L’idée est de géolocaliser automatiquement l’utilisateur, puis de lui proposer une carte sur laquelle il peut naviguer pour obtenir des informations sur les lieux remarquables, des photos, des services, etc. (démo) et également publier ses propres photos ou autres documents.
Le point de départ est DBPedia (pour tout savoir sur DBPedia, cliquez ici) mais ensuite l’idée est de se promener sur les autres sites du Web of Data.
Donc… si mes données sont sur le Web of Data, plus besoin de développer des interfaces compliquées pour favoriser la mobilité : elles seront accessibles à partir d’applications développées par d’autres.

Ce ne sont que quelques exemples, les applications exploitant la richesse du linked data étant chaque jour plus nombreuses.
Mais me direz-vous, c’est bien compliqué pour moi, bibliothèque, de mettre mes données sur le Web of data, je ne sais pas les convertir facilement en RDF… Et là aussi j’ai la réponse : si vous avez un entrepôt OAI, vous pouvez utiliser OAI2LOD.

Evidemment, pour que ce soit vraiment efficace il nous reste du boulot pour relier nos données avec d’autres. Mais ce serait déjà un bon début non ?

On pourrait penser qu’au bout de 7 ans de conférences ISWC, la communauté qui se retrouve ici n’aurait plus besoin de se justifier quant à l’utilité et l’importance de ses travaux. Ce n’est pas tout à fait le cas, d’ailleurs le dernier keynote speaker, Stefan Decker du DERI, a organisé sa conférence autour de l’idée que pour sauver le SemWeb, on avait avant tout besoin d’un message attractif et unifié (« appealing unified message »), aucun de ceux qui ont été proposés jusqu’à maintenant dans la communauté n’ayant le pouvoir nécessaire pour… lever des fonds.

De fait, j’ai trouvé intéressant le discours (un peu éparpillé dans la conférence) visant à replacer l’initiative du SemWeb dans le contexte plus large du Web, afin de voir comment il peut être utile aux « vrais gens ».

Le premier keynote speaker, Ramesh Jain (University of California, Irvine), a rappelé que l’objectif des technologies du SemWeb est de combler le « semantic gap » : c’est-à-dire le fossé qui existe entre les documents tels qu’on sait les représenter sur le Web (des trains de bits, des caractères alphanumériques, des fichiers, des listes, des images, des vidéos etc.) et les besoins qu’ont les utilisateurs de manipuler des concepts abstraits reposant sur des objets ou des événements.

Le fossé sémantique se situe entre les deux, mais la question reste ouverte : les technologies qui sont développées dans le cadre du SemWeb permettent-elles de combler le fossé, ou ne font-elles qu’améliorer la qualité technologique existante de chaque côté…

La réponse à cette question semble résider assez largement dans l’observation des tendances du Web, et ce qu’elles nous enseignent sur les moyens technologiques qui existent ou que nous devons développer pour améliorer l’expérience utilisateur.

Sur ce sujet, j’ai beaucoup apprécié la présentation du projet Theseus par SAP research (pour ceux qui n’auraient pas suivi, Theseus est la branche allemande qui s’est détachée de Quaero).
L’objectif est limpide : il faut simplifier la technologie pour l’apporter aux gens.
Nous nous situons dans un contexte où la notion de services est devenue clef. Nous sommes passés d’un système où les processus répondant à des besoins spécifiques étaient codés « en dur » dans les applications, à un système reposant sur de multiples services combinés entre eux pour constituer une chaîne de valeurs (« value chain »). Il s’agit d’une tendance lourde du Web d’aujourd’hui qui oblige les entreprises à être plus « agiles » : on n’achète plus une machine ou un logiciel, on achète le service que rend la machine ou le logiciel. Si la machine a un problème, quelqu’un vient la réparer. C’est le règne du SAS (Software as a service).
Dans ce contexte, que nous enseigne l’observation des entreprises qui ont véritablement réussi sur le Web ? L’intervenant a pris l’exemple d’Amazon et de iTunes pour montrer que le secret de leur réussite c’est le fait de couvrir toute la chaîne de valeur, de la création des contenus jusqu’à leur utilisation finale, tout en intégrant un écosystème de partenaires dans leur plateforme via des services à valeur ajoutée.
L’objectif de Theseus est de créer justement une plateforme de services à valeur ajoutée qui puisse être réutilisée dans la chaîne de valeur de différents acteurs, y compris des petits entrepreneurs du Web, avec un faible ticket d’entrée technologique.
Globalement, le discours était vraiment très séduisant. On ne voit juste pas trop comment le SemWeb s’intègre dans cette vision ;-) si ce n’est par la conclusion : « semantics are a key enabler ».

Essayons d’aller plus loin…

Finalement, ainsi que l’a décrit Mark Greaves de Vulcan Inc. dans sa présentation sur les « semantic wikis », ce qu’apporte le SemWeb au monde de l’information aujourd’hui se divise en deux branches : une branche « entreprise » (au sens large du terme, c’est-à-dire que cela consiste à utiliser les technologies du Web sémantique dans un contexte métier, très contrôlé et structuré), et une branche qui consiste à essayer d’améliorer l’expérience utilisateur sur le Web, la question étant de savoir où et comment ces deux branches se rencontrent. En fait, le profit qu’elles apportent l’une à l’autre va dans les deux sens :
– de la 1e branche vers la 2e, on a besoin de données « expertes » créées dans un contexte métier pour alimenter le « Web of data » ;
– de la 2e branche vers la 1e, on a besoin d’outils qui fluidifient les processus de création des données structurées.
A suivre…

Me voici à Karlsruhe pour assister à ISWC 2008, conférence internationale sur le Web sémantique.

Visiblement, certains s’attendaient à ce que Got et moi bloguions la conférence en direct, mais c’était sans compter sur des conditions matérielles parfois insuffisantes et surtout, sur le fait que je suis une blogueuse libre : si c’est important pour moi de pouvoir mûrir un peu ce que je vois avant d’en rendre compte, vous êtes obligés de faire avec ;-)

D’abord quelques impressions générales : je m’y attendais, mais la conférence est assez technique et j’ai un peu l’impression d’être un extra-terrestre (beaucoup de chercheurs, quelques boîtes comme par exemple Talis mais pas de librarians !) Pourtant il y a eu des précédents où on était sans doute plus représentés en tant que profession, comme en 2006 ce cultural heritage Workshop.
En tout cas, cet éclairage sur l’ambiance générale peut être utile pour comprendre certaines de mes remarques sur ce que j’ai pu voir ici. Parfois j’adopte un peu le point de vue de l’utilisateur qui, s’étant glissé discrètement dans la salle, observe comment les informaticiens comprennent son besoin et ont l’intention d’y répondre…

Autre précision importante, j’ai beaucoup de mal avec le fait de bloguer la conférence « telle quelle » c’est-à-dire dans l’ordre où j’assiste aux « papiers ». Cet ordre a sans doute un sens pour les organisateurs, mais pas pour moi car déjà je ne vois pas tout (il y a des sessions parallèles) et le compte-rendu a aussi pour objectif de tout remettre dans une perspective qui réponde à mes intérêts spécifiques. Finalement, cela m’oblige à réorganiser tout ce que j’ai entendu autour des grands thèmes saillants de la conférence.

En l’occurrence, voici ce que j’ai identifié :

1. le positionnement global des acteurs du Semantic Web dans le paysage actuel, à la fois en termes d’objectifs de recherche, de développement logiciel, de positionnement commercial, etc.

2. la rencontre entre le SemWeb et les utilisateurs : visiblement une grosse difficulté, comment va-t-on réconcilier les besoins des « vrais gens » avec une technologie assez complexe ? Cette préoccupation est intéressante car elle reflète le mûrissement du SemWeb comme technologie qui commence à être utilisée dans la « vraie vie », hors du contexte de la recherche

3. les outils : visiblement une réponse importante (quantitativement au moins) au problème précédent

4. la normalisation : l’autre réponse au problème 2 ! mais pas une sinécure non plus.

Il va falloir que vous attendiez que j’aie une vue d’ensemble (et une prise de courant) pour rentrer dans le détail sur chacun de ces thèmes. Je ne parlerai pas des cas d’utilisation dans un domaine métier particulier sauf éventuellement pour illustrer mon propos sur les thèmes précédents. Je ne peux pas vous dire si j’aurai quelque chose d’intéressant à raconter sur le « Semantic Web challenge » et le « billion triple challenge » car ils n’ont pas encore eu lieu ;-) Enfin je ne vous décrirai pas la « poster & demo session », que j’ai passée avec Got, collés à notre propre poster sur lequel je ferai un billet spécifique plus tard si je suis de bonne humeur…