Participants

Participants

• Fabio Mancinelli
• Denis Teyssou
• Eric de la Clergerie
• Etienne Coumont
• Guillaume Lazzara
• Thierry Geraud
• Stéphane Lauriere

Terminologie

Pendant la première partie du meeting il y a eu une petite discussion concernante la terminologie utilisée. Apparemment, il y a des ambiguïtés dans l'utilisation de certains termes, surtout pour par rapport aux personnes qui ne sont pas expertes du domaine de la linguistique ou du NLP (moi, Fabio, par exemple)

• Ontologie : une définition de types qui nous permettent de classifier tout ce qui "existe" dans un domaine et aussi de définir les relations entre ces types. D'un point de vue pratique une ontologie est un modèle RDF qui décrit des classes et des propriétés associées à ces classes. Elle est domain-dependent.
• Annotation : une annotation est une structure qui lie une partie d'un document (normalement identifié par un span (offset, length)) à d'autres entités. Ces entités peuvent être des objets qui appartiennent au domaine ou des relations entre ces objets. D'un point de vue pratique, une annotation est une ressource RDF qui a le type Annotation (voir le modèle précédemment proposé basé sur Annotea http://www.w3.org/2000/10/annotation-ns# et https://hg.nuxeo.org/sandbox/scribo/file/b48c1d2ca18f/scribo-knowledge-model/src/main/resources/rdfs/scribo-annotation-ns.rdf.xml) et est mise en relation avec d'autres ressources RDF qui existent dans une knowledge base et qui représentent toutes les entités connues à un moment donné. Les annotations sont produites par les analyseurs.
• Entités nommées : sont les entités qui représentent des objets qu'on retrouve dans un domaine. Les entités nommées ont un type qui est défini dans une ontologie et qui fournit aussi les propriétés pour les décrire et caractériser. Les annotations référencent ces entités nommés et sont, de ce point de vue, des occurrences d'entités nommées dans les documents. D'un point de vue pratique, une entité nommée est une ressource RDF qui a un type défini dans une ontologie. Les entités nommés sont extraites elle aussi par les analyseurs.
• Relations : une relation établit un lien entre des objets de la base de connaissance. Par exemple une citation met en relation une phrase avec celui qui l'a prononcée. D'un point de vue pratique, une relation est une ressource RDF qui a son type "subclassOf" Relationship (e.g., https://hg.nuxeo.org/sandbox/scribo/file/35d08ec8d2e1/scribo-knowledge-model/src/main/resources/examples/citation-ns.rdf.xml). Comme pour les annotations, les entités nommées, les analyseurs sont en charge d'extraire les relations.
• Annotateur : synonyme de analyseur. Un composant qui est capable d'examiner des documents et de produire à la fois des annotations mais aussi la connaissance à laquelle ces annotations font référence (e.g. entités nommées et relations)

Etat actuel

Le meeting s'est ouvert avec un rappel sur l'état actuel du projet qui a accumulé un retard considérable et qui est quantifié en 6 mois. Ca veut dire que que à la date de la revue annuelle qui correspondra à T0+14 on sera censé être obligatoirement en phase avec tout ce qui était prévu à T0+8.

Par contre, il y a eu des développement qui sont en cours et qui devront aboutir à des prototypes qui seront prêt pour septembre. Ces prototypes seront présentés lors de la revue.

Denis Teyssou faisait remarquer qu'il faudrait rédiger un GANTT pour décrire plus clairement et justifier l'effort mis jusqu'à maintenant par les partenaires dans les différentes activités. En fait, il faudrait prévoir aussi un nouveau planning pour montrer comment on va récupérer le retard.

SP1

SP1 est, pour l'instant, le sous-projet dont on a le moins d'information. Eric nous a expliqué un peu mieux comment le composant d'extraction d'ontologies va fonctionner et que sa sortie sera, finalement, une proposition de candidats à ajouter à une ontologie, que l'utilisateur devra valider.

Il reste a comprendre comment cette validation va influer sur SP3 (comment les analyseur vont prendre en compte les candidats qui ont été validés). Eric et Etienne ont discuté un peu sur des possibles stratégies et collaboreront pour les développer dans le prochain mois.

La discussion sur SP1 a aussi donné l'occasion pour parler d'ontologies, un sujet centrale qui n'a jamais été bien abordé. Actuellement chaque analyseur référence une ontologie:

• L'analyseur de l'INRIA utilise l'ontologie ??? (dans la sortie de l'analyse on voit des entités dont le type peut être, par exemple, "person", "np", "organization", "location", mais je ne sais pas où ces types sont définis)
• L'analyseur WebContent utilise l'ontologie http://www.webcontent.fr/ontologies/namedEntities.owl
• L'analyseur de Proxem utilise l'ontologie ??? (Etienne ou François m'avait dit que c'était une version modifié de celle de OpenCalais, mais je ne suis pas sur)

Il y a aussi d'autres ontologies qui peuvent être exploités comme IPTC, etc.

Ca a un impact sur le processus de feedback et l'architecture: 1) Est-ce que les analyseurs sont agnostiques par rapport à l'ontologie? Si la réponse est non, le framework devra rendre explicite le lien entre analyseur/ontologie dans le descripteur du composant SCRIBO qui représentera cet analyseur.

2) Est-il possible de donner comme feedback le changement de type d'une entité nommées extraite par, disons, WebContent avec un type de l'ontologie IPTC? Si la réponse est non, les interfaces devront être plus intelligentes et proposer à l'utilisateurs seulement des choix "acceptables".

Les questions restent encore ouvertes.

SP1 doit compléter le livrable prévu à T0+6 Spécification du service d'extraction supervisée d'ontologies

SP2

L'état des travaux est correct. Il y a des questions d'intégrations et packaging à résoudre.

SP3

SP3 est en train de développer différents analyseurs qui devront pouvoir être utilisé pas les autres sous-projet. Actuellement on en a 3

1) INRIA 2) WebContent 3) Proxem

Le problème commun est l'intégration, car à l'état actuel seulement Proxem a fourni un wrapping UIMA qui pourra être utilisé pour créer des composants SCRIBO.

L'analyseur de Proxem est, de toute facon, basé sur OpenCalais, et cela c'est pas souhaitable d'un point de vue diplomatique. On pourra bien l'utiliser, comme Denis le faisait remarquer, comme benchmark pour tester l'efficacité des autres annotateurs, mais pas pour le packager avec SCRIBO.

Il faudrait soit wrapper un autre annotateur ou en produire un nouveau (François mentionnait des travaux en cours dans un précèdent mail mais je ne sais pas s'il vont dans ce sens là)

SP3 devra aussi collaborer avec SP1 pour prendre en compte correctement l'extraction d'ontologie.

Reste un point d'interrogation sur la définition de "feedback". Quels sont les "feedback" acceptables et comment les spécifier pour qu'ils soient pris en compte. Pour l'instant on avait prévu deux propriétés "humanValidation" et "replacedBy" pour les annotations. Ca c'est clairement insuffisant pour la validation des entités nommées (e.g., si le feedback consiste dans le changement de type).

SP3 doit compléter le livrable prévu à T0+6 sur les algorithmes de gestion des entêtées nommées (détection et typage)

SP4

SP4 commence à bâtir des prototypes qui pourront être utilisés par des utilisateurs finals. Comme Eric faisait remarquer ces prototypes serviront pour "expliquer" qu'est-ce que SCRIBO car, l'expliquer en termes abstraits et architecturaux ne marche pas trop bien.

La difficulté consiste surtout dans la fait que on n'a pas d'architecture sous-jacent et un framework à appeler. En fait ce framework est en train d'etre conçu au fur et à mesure qu'on développe les ateliers.

Pour l'instant on a commence avec le wrapping des analyseurs de WebContent comme base pour avoir du contenu, et on est en train d'avancer avec les interface graphiques.

SP5

SP5 est en retard. Il y a eu plusieurs proposition d'architecture mais elle n'ont jamais été validé à fond. Dans les slides en attachement il y a une proposition plus détaillée qui liste explicitement les API qui seront nécessaires.

Coté intégrations, XWiki et XWiki Watch commencent à avoir des systèmes pour annoter à la mains des documents. Il manque l'intégration pour récupérer les annotations générées par les analyseur. En général il manque la framework de base à appeler pour "utiliser" SCRIBO. Ce framework devra être développé dans SP5 également.

SP5 doit compléter le livrable prévu à T0+6 Document de spécification de l'architecture à composant cible

Note: Dans les slides attachés le diagramme d'architecture mentionne OSGi… Avec toute probabilité ce n'est pas possible de l'utiliser car j'ai vu que appeler OSGi de dehors est presque impossible. Donc vu que SCRIBO devra etre utilisé par des produits qui ne sont basé sur OSGi (e.g., XWiki) ce choix n'est pas faisable.

SP6

SP6 attends des prototypes de SP5 pour mettre en place le cas d'utilisation et collaborera avec SP1 pour des taches de validation.

SP7

Mandriva a beaucoup avancé sur le desktop sémantique, mais le problème est que finalement il n'utilise pas SCRIBO. Donc en collaborant avec SP4 et SP5 il faudra intégrer SCRIBO dans leur architecture.

SP8

?

SP9

La dissémination a été correcte avec la participation à plusieurs conférences et manifestations.

Vision Globale

Dans le projet il manque une vision globale car à l'instant on n'a que des composant indépendants qui sont bricolés de façon arbitraire à chaque fois. Ce qu'il manque est un framework et une architecture bien définis qui pourraient repondre aux questions:

• Qu'est-ce que SCRIBO?
• Qu'est-ce que ça veut dire "installer SCRIBO"?
• Qu'est-ce que ça veut dire "utiliser SCRIBO"?

Bref, le résultat final du projet.

Afin de répondre à ces question il faut développer un framework qui fournit aux applications des API qui permettent d'accéder aux fonctionnalités de SCRIBO.

Il y a aussi beaucoup de problèmes d'intégration (voir le slide à page 15 de l'attachement), de gestion des formats d'entrée, et de formats communs pour rendre les composant inter-opérables.

Next steps

• Terminer tous les livrables prévu pour T0+6 (SP1, SP3, SP5)
• Définir les APIs et une implémentation initiale du framework SCRIBO (SP5)
• Fournir les composants SCRIBO deployables dans ce framework (SP1, SP3). Il s'agit de produire des wrappings avec UIMA qui produisent correctement leurs sorties et interagissent correctement avec les autres composants.
• Intégrer le framework dans
  • L'atelier Eclipse
  • KDE
  • Produits des partenaires

Pour les deadlines et l'avancement ça serait opportun adopter une stratégie agile et faire des points semaine par semaine au lieu de fixer une deadline loin. De cette façon on pourra corriger as-soon-as-possible les problèmes éventuels.

Divers et variés

On a remarqué que la communication est un peu lente. On se demandait si l'on pouvait faire quelque chose pour améliorer cette situation.

Il a été proposé de faire des confcall périodiques (une par semaine) de 30 minutes vu que pas tout le monde peut utiliser skype.

C'est aussi urgent de mettre en place une forge commune avec des outils de bug tracking pour avancer plus vite et avoir une vision globale plus complète.

On a déjà un repository mercurial chez Nuxeo, mais on se demandait si ce n'était pas mieux d'utiliser un service comme BitBucket, GitHub ou autre pour gérer le tout et se décharger de l'administration. Le désavantage d'un tel choix pourraient etre :

• Proprieté des données (est-il possible de récupérer toutes les données de ces sites?)
• Limitations (BitBucket est limité à 150Mb pour la version gratuite. GitHub n'a pas de limites mais il n'a pas d'outils intégrés pour le bugtracking)
• Question d'image

En général on mettra en place des outils de communication temps-réel pour ceux qu'il veulent les utiliser (e.g., jabber)