Architectures logicielles pour articuler les traitements sur corpus

Le traitement des données textuelles articule, probablement pour encore quelques années, des données non structurées (texte "brut"), des données semi-structurées (formats d’entrée/sortie plus ou moins contraignants des logiciels utilisés) et données structurées (XML, graphes d’annotation...). Les outils traitent/produisent des données selon des formats variables et d’ailleurs évolutifs. La plupart des logiciels utilisent en outre des représentations internes des données textuelles, comme des index, qui permettent des réorganisations et des traitements plus efficaces de la chaîne textuelle (concordances, repérage des cooccurrences etc.) tout en constituant, du même coup, empiriquement, des unités textuelles aux statuts très variables. Enfin, ils offrent divers moyens de visualisation des données résultats ou intermédiaires en sollicitant des interfaces aux ergonomies très variables. Pour des projets d’envergure, des architectures ont été conçues pour articuler modules et formats hétérogènes. C’est le cas de GATE [Gaizauskas et al. 98] à l’université de Sheffield pour MUC. Ces architectures, trop lourdes, n’offrent pas une solution satisfaisante pour le quotidien. D’autres architectures font le choix de flux XML pour l’enchaînement des traitements (LT-XML et les flux SAX de Cocoon). La journée d’étude proposée abordera en particulier les points suivants :

• faut-il aller vers des architectures "tout XML" ou privilégier des moyens d’associer modules etformats hétérogènes ?
• quels moyens utiliser pour avancer dans la standardisation des formats d’annotation des données et la formalisation de la sémantique de ces annotations, de sorte à faciliter et à expliciter l’enchaînement des divers traitements (EAGLES, ISLE) ?
• quelles architectures utiliser pour articuler la gestion des entrepôts de données et l’application des divers outils d’enrichissement et d’analyse des données (client/serveur.) ?
• quels formats retenir pour faciliter l’annotation multiple et complexe de corpus (graphes d’annotation, annotation `déportée’ ou « stand-off » ...) ?
• quelle utilisation effective des en-têtes à la TEI (Text Encoding Initiative) ou XCES (XML Corpus Encoding Standard) ou d’aides au catalogage (OLAC) pour mémoriser la signalétique accompagnant les corpus ? quelle interaction avec les propositions du consortium W3C pour noter les méta-données (RDF, par exemple) ?
• l’histoire des traitements d’un corpus (son cycle de vie), de ses versions, de ses partitions est souvent impossible à reconstituer : on dispose de résultats (texte étiqueté/lemmatisé, analyse syntaxique en dépendances, couples d’information mutuelle, etc.) dont on ne sait plus avec quoi ils ont été obtenus et selon quels paramétrages.
• est-il possible de normaliser la description des traitements effectués afin de permettre la répétition des mêmes chaînes de traitement à des données diverses ?

Comité de lecture

• François Daoust (UQAM)
• Michel Jacobson (Lacito CNRS)
• Sylvaine Nugier (EDF R&D)
• Thierry Poibeau (LIPN)
• Laurent Romary (LORIA)
• Ludovic Tanguy (ERSS)
• Jean Véronis (DELIC - Aix)
• Pierre Zweigenbaum (DIAM-SIM AP-HP)

Les propositions de communication (de 1 à 5 pages) devront parvenir aux organisateurs pour le 1er décembre 2004.

Dates limites importantes :

• Proposition de communication : 1er décembre 2004
• Notification d’acceptation/rejet : 10 janvier 2005

Date de dernière mise à jour : 3 février 2005