samedi 10 décembre 2011

Mise en correspondance de vues via un Aggregate pour interconnecter des composants UIMA (view et sofa name mapping)

Après avoir rappelé quelques notions (que le lecteur averti peut ne pas lire), le post expose brièvement le problème et présente avec un exemple la mise en oeuvre d'une solution de mise en correspondance de vues au sein d'un Aggregate.

Bref rappel de quelques notions
Les chapitres 5 et 6 de la documentation UIMA tutorials_and_users_guides [1;2] rappellent les définitions des notions d'Artifact, Sofa et View.
Brièvement l'Artifact est la chose non structurée que l'on souhaite analyser. Le Sofa (Subject of Analysis) est une représentation de l'Artifact (e.g. HTML). Une annotation metadata est de l'information associée à un Sofa particulier pour en décrire une sous région. La notion de View simplifie les choses quand plusieurs versions de l'Artifact sont nécessaire à différentes étapes de l'analyse (e.g. une version sans balise d'un document XML). Les notions de Sofa et de CAS View sont liées. Dans l'implémentation Apache actuelle (2.4), à chaque Sofa est associé une seule View et à chaque View un seul Sofa. Le nom qui désigne une vue particulière est Sofa name pour des raisons historiques mais cela s'applique indifféremment à View aussi.
L'analyse d'un composant UIMA (AE - Analysis Engine) porte toujours sur une vue. Il peut y en avoir plusieurs. L'AE peut en créer. Les résultats d'analyse peuvent être associés sur les vues traitées ou bien sur les vues créées.
Un AE qui travaille seulement sur une seule vue est appelée "single-view component" et dans le cas contraire "multi-view/multi-sofa component".
Par défaut, si rien n'est spécifié il y a qu'une seule view et celle-ci a le sofa name de "_InitialView".

Problème d'interopérabilité pour interconnecter des composants développés indépendamment
Le développeur d'AE est libre de choisir le nom qu'il souhaite pour désigner ses vues d'entrée et ses vues de sortie.
Cela conduit naturellement à quelques petits soucis lorsque l'on veut interconnecter des composants ayant des noms de vue différents.

Le mécanisme de mise en correspondance des vues au niveau d'un Aggregate
La section 6.4 de la documentation explique et présente différentes situations de mises en correspondance : au sein d'un Aggregate, d'un CPE, d'une application UIMA, pour des services distants. Je rapporte et illustre la solution au sein d'un AE Aggregate.

Pour cela, j'utilise deux composants : l'XmlDetagger présent dans les exemples fournis avec Apache UIMA [4] et le Whitespace Tokenizer des addons de la Sandbox d'Apache UIMA [5].

L'XmlDetagger est un composant multiple vues qui retire les balises d'un document XML. Il lit l'XML d'une vue input nommée "xmlDocument". Le contenu textuel est écrit dans une nouvelle vue output appelée "plainTextDocument".
Le Whitespace Tokenizer est un composant simple vue qui travaille sur la vue par défaut (i.e.  "_InitialView") et qui ajoute à celle-ci des annotations de phrases et de tokens.

Rapidement, je mets en place un projet Java sous Eclipse. J'y ajoute la UIMA Nature, déclare les répertoires desc et resources dans le build path ainsi que les bibliothèques de UIMA [6]. Je rajoute au  le build path les bibliothèques uima-examples [10] et addon whitespace tokenizer [9] qui vont servir pour notre chaîne.

Je crée un descripteur d'AE Aggregate [7] et j'y ajoute by name en pipeline : d'abord l'XmlDetagger  puis le Whitespace Tokenizer (je déclare les bons types à produire en output dans les capabilities).

A la sauvegarde le message suivant s'affiche
Error in AE Descriptor
The Descriptor is invalid for the following reason:
ResourceInitializationException: The output Sofa "plainTextDocument" in component "XmlDetagger" is not mapped to any output Sofa in its containing aggregate, "demoSofaNameMappingAAE". (Descriptor path ...) 

Ce n'est pas réellement une erreur si l'on sait ce que l'on fait. Une vue qui n'est pas utilisée par exemple n'a pas besoin d'être mise en correspondance dans l'Aggregate.
En l'état si on exécute cet AE avec le DocumentAnalyzer [8] sur un document XML quelconque, on obtiendra l'erreur suivante :
org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator processing failed. Caused by: org.apache.uima.cas.CASRuntimeException: No sofaFS with name xmlDocument found. 
Vraissemblablement ici il y a des vues qui requièrent d'être mise en correspondance et cela va se faire au niveau de l'Aggregate.

La première chose à faire est d'indiquer que la vue sur laquelle travaille en entrée XmlDetagger, à savoir xmlDocument, correspond à _InitialView dans l'Aggregate. Autrement dit, la vue d'entrée par défaut de l'Aggregate,  _InitialView, doit être mise en correspondance avec la vue d'entrée, xmlDocument, de l'XmlDetagger.
Au sein du descripteur de l'Aggregate, c'est dans la section capabilities que l'on déclare les vues sur lesquelles on travaille (sous section component capabilities) et celles entre lesquelles on réalise des mises en correspondance (sous section sofaMappings).
On ajoute d'abord la vue xmlDocument comme input (entrée) en faisant un add sofa dans la component capabilities.
Ensuite on indique dans la sous section sofaMappings que pour le composant (componentKeyXmlDetagger sa vue (componentSofaNamexmlDocument correspond à la vue dans l'aggregate (aggregateSofaName_InitialView.
Par les éléments componentKey et componentSofaName on désigne le composant et la vue souhaitée chez celui-ci comme devant intervenir dans un mapping. L'élément aggregateSofaName est la clé partagée entre les éléments sofaMapping.
Cette dernière opération doit se faire pour partie à la main en éditant le source (personnellement je n'y arrive pas via l'éditeur du formulaire). Cela donne
<capability>
...
  <inputSofas>
    <sofaName>xmlDocument</sofaName>
  </inputSofas>
  ...
et
  <sofaMappings>
    <sofaMapping>
      <componentKey>XmlDetagger</componentKey>
      <componentSofaName>xmlDocument</componentSofaName>
      <aggregateSofaName>_InitialView</aggregateSofaName>
    </sofaMapping>
  </sofaMappings>
Si on réexécute l'AE on se rend compte que ce n'est pas encore l'idéal car le Whitespace Tokenizer travaille sur l'_InitialView par défaut et traite donc ce qui correspond à l'xmlDocument au lieu du plainTextDocument.
On rajoute dans l'élément inputSofas
<sofaName>_InitialView</sofaName>
et l'élément suivant
  <sofaMapping>
      <componentKey>WhitespaceTokenizer</componentKey>
      <componentSofaName>_InitialView</componentSofaName>
      <aggregateSofaName>plainTextDocument</aggregateSofaName>
    </sofaMapping>
La vue plainTextDocument du XmlDetagger n'a pas été redéfinie dans l'Aggregate, il n'y a pas d'ambiguité. Ce que produit le XmlDetagger au sein de sa vue output plainTextDocument est accessible sous ce même nom au sein de l'Aggregate qui le met en correspondance avec la vue input du
WhitespaceTokenizer.   
L'exécution fonctionne comme attendu finalement.  

Quelques commentaires supplémentaires

Au niveau de l'Aggregate après mise en correspondance, le nom de la vue du componentSofaName
sera renommé en le nom de la vue déclarée dans aggregateSofaName.
Les vues avec leur nom précédent ne seront plus accessibles. Une fois sérialisée en XMI, on constatera sela en cherchant la valeur de l'attribut sofaID.
Les composants d'Apache OpenNLP sont des composants multiples vues et requièrent en général l'usage de mises en correspondance.


Liens

[1] 5. Annotations, Artifacts & Sofas
[2] 6. Multiple CAS Views
[3] 6.4. Sofa Name Mapping
[4] UIMA_HOME/examples/descriptors/analysis_engine/XmlDetagger.xml
[5] http://uima.apache.org/sandbox.html#whitespace.tokenizer
[6] Créer un projet Eclipse pour le développement d'un composant UIMA
[7] Construire une chaîne de traitement UIMA à partir de composants existants
[8] Exécuter un traitement ou une chaîne de traitement sous UIMA (avec UIMAJ et en local)
[9] UIMA_HOME/addons/annotator/WhitespaceTokenizer/lib/uima-an-wst.jar
[10] UIMA_HOME/lib/uima-examples.jar

mercredi 7 décembre 2011

Création d'un portail collaboratif "Texte, Discours et Document"

Partisan du travail collaboratif au niveau scientifique, je tente la création d’un (Google) document publié sur le Web et visible en édition par tous (sans nécessité de compte) pour construire un portail de ressources ayant trait à l’étude, la modélisation, la reconnaissance automatique et les exploitations applicatives des mécanismes d’organisation de l’information au niveau du ”Texte, Discours et Document”.
Cette page est avant tout un outil personnel. Peut être cela servira t elle à d’autres ? J’invite dans tous les cas toute personne intéressée à contribuer !  
Par ressources, j’entends appels à communication, journaux majeurs, (web|bibli)ographie, personnes, équipes, projets, outils, corpus, etc.
Les objectifs sont la veille au niveau national et international et la cartographie du domaine selon les disciplines (traitement automatique des langues, linguistique, psycholinguistique, ingénierie des documents...) et courants théoriques.
Les approches ayant une visée de traitement automatique seront privilégiées.


Le portail se trouve ici !

Ajouter un dépot (repository) Maven à votre forge Google Code grâce à Subversion


Discutés aux deux adresses ci-dessous mais l'alternative d'utiliser un dépot public est conseillée

  1. http://stackoverflow.com/questions/1280470/maven-repository-for-google-code-project
  2. http://www.thewebsemantic.com/2009/04/11/your-very-own-google-code-maven-repo/

Mesurer le nombre de visites sur votre projet hébergé sous Google Code grâce à Google Analytics

Ce post décrit la procédure pour "track visits to Google code projects in Google Analytics".
  1. Anyone may sign up for a free Google Analytics account. Once you have an account
  2. Add a profile for a new domain and specify URL http://code.google.com/
  3. Edit the profile that you just created to change its Website URL to http://code.google.com/p/votre-nom-de-projet/ 
  4. Paste your Google Analytics profile's Web Property ID below and save changes. 
  5. About 24 hours after you add your Web Property ID, your profile should begin to indicate that it is receiving data.

    Publier une Javadoc sous forge Google Code

    La procédure est la suivante
    1. Récupérez la racine du projet
      • svn checkout https://votre-nom-de-projet.googlecode.com/svn/ votre-nom-de-projet --username votre.username
      • cd votre-nom-de-projet
    2. Ajoutez un répertoire javadoc au versionning
      • svn mkdir javadoc 
    3. Réalisez l'export de la javadoc via Eclipse se sera plus simple
    4. Ajoutez les fichiers javadoc au versionning
      • svn add javadoc/*
    5. Ajoutez les propriétés adéquates pour que svn interprète les fichiers de la javadoc  avec le bon type mime
      • find  javadoc -name "*.html" -exec svn propset svn:mime-type text/html  {} + ;
      • find  javadoc -name "*.css" -exec svn propset svn:mime-type text/css  {} + ;
      • find  javadoc -name "*.jpeg" -exec svn propset svn:mime-type image/jpeg  {} + ;
    6. Commitez vos ajouts
      • svn commit javadoc/ -m "ajout de la javadoc"
    7. Votre javadoc devrait être désormais accessible via l'url http://votre-nom-de-projet.googlecode.com/svn/javadoc/index.html ; ajoutez ce lien dans la section de links de Administer > Project Summary

    Publier sur le Web et partager les droits d'édition à tous d'un Google document

    Dans la quête de la recherche d'outils facilitant le travail collaboratif je tente d'utiliser un Google Document qui désormais offrent des fonctionnalités de partage des droits d'édition à tous (sans nécessité de posséder un compte) ainsi que de publication Web.

    La procédure ci-dessous est légèrement différente de celle trouvée sur des réponses officielles (publication de vos documents et publication sur le web). Peut être est ce dû à un retard de mise à jour de la documentation ?

    La procédure a été testée avec un Google Document, mais reste valable a priori pour tout type de documents (document, feuille de calcul, présentation...). Ici vous trouverez un exemple de Google Document publié et ouvert à l'édition (il s'agit d'un site sérieux merci de ne pas le modifier à moins que vous souhaitiez y contribuer).

    Les deux actions, partage de la visibilité et publication sur le web, supposent que vous venez d'ouvrir ou de créer votre Google Document.

    Pour partager la visibilité (notamment en édition) 
    1. Cliquer sur l'icone "Share". Une fenêtre de configuration intitulée "Share settings" apparaît.
    2. Cliquer sur "Change"  au niveau de la première ligne du tableau "Who has access" (par défaut l'accès est limité : "Private - Only the people listed below can access"). Une fenêtre intitulée "Visibility options" apparaît
    3. Sélectionner  "Public on the web. Anyone on the Internet can find and access. No sign-in required."
    4. Et enfin changer l'accès de "Can view" à "Can edit" au niveau de la ligne "Access:Anyone (no sign-in required)" qui a dû apparaître.
    Pour publier sur le Web un Google document
    1. Dans le menu File, cliquer sur "Publish to the Web". Une fenêtre "Control publishing" s'affiche.
    2. Laisser coché "Automatically republish when changes are made".
    3. Cliquer sur "Start publishing" et confirmer. Vous obtiendrez un lien vers le document publié
    4. Par ailleurs, le lien par lequel vous éditiez votre document est désormais public. Vous pouvez le faire circuler.
    Remarques
    • Attention, il est important de noter que la publication sur le Web et sa visibilité sont deux concepts indépendants. 
    • Les contributeurs du Web n'auront pas accès aux options de partage mais pourront intervenir sur la publication.
    • Ils n'auront pas non plus accès à l'historique des modifications ("File > Revision history")
    • Ils pourront télécharger le document dans divers formats (notamment PDF)
    • Ils ne pourront pas changer les notifications qui sont propres à un compte à moins qu'ils ne soient connectés.