Annexe Web Lab

1. Annexe Web Lab

2. Web Lab: Présentation • le WebLab-Core est un socle technique «open source» développé par EADS et fournissant une infrastructure technique de communications entre les services, des mécanismes d'orchestration de ces services, un modèle d'échange d’informations entre les services ainsi que des mécanismes de composition d'IHM basés sur une technologie de type portail • Les services WebLab désignent les modules fonctionnels qui réalisent un traitement spécifique sur des documents ou sur des données «métier». • Les applications WebLab, sont dédiées à un besoin «métier» particulier et sont construites par composition de services WebLab.

3. Modèle d’échange: Chaine de traitement A chacune des étapes du processus ainsi défini, les documents sont annotés par les services mis en œuvre et leurs descriptions s’enrichissent progressivement au fur et à mesure de la progression dans la chaîne. Chaque service ajoute donc de nouveaux éléments de connaissance qu’il attache au document traité.

4. Décomposition d’une ressource Chaque ressource (ou chaque document) utilisé par un service web lab pourra être découpé en média-units ou en segments.

5. RDF • Afin de pouvoir échanger les métadonnées spécifiques du domaine sans qu’il soit nécessaire de remettre en cause la structure XML du format pivot, les éléments de connaissance WebLabsont exprimés selon le modèle RDF • RDF est composé d’un ensemble de triplet (« piece of knowledge »): • Sujet • Prédicat • Objet Le modèle WebLab propose d’exprimer ces métadonnées en se référant à l'ontologie Dublin Core

6. Dublin Core • Cette ontologie permet, par exemple, d'annoter les éléments de documents (éléments simples et composites, segments ou autres ressources) pour indiquer qui les a créés ou modifiés (dc:creator, dc:contributor), à quelle date (dc:date) ou encore des liens entre deux documents (dc:relation). • Exemple d’annotation Dublin Core: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" > <rdf:Descriptionrdf:about="weblab://myWS/myDocument"> <dc:creator>EADS</dc:creator> <dc:title>my Document</dc:title> </rdf:Description> </rdf:RDF> Ici creator et title font partie de l’ontologie DublicCore

7. Les requêtes • Peu d’informations • SPARQL, XQuery…

8. UML et WSDL ? • Le XML-Schéma du modèle pivot pourra être importé (wsdl:import) dans les descriptions WDSL des services. La technologie Web Service permettra ensuite de disposer des API Java qui permettront d'accéder aux objets du modèle de référence traduit dans le langage cible. • Traduction des interface UML et WSDL

9. Interface • L’interface «SourceReader» sera utilisée pour définir les services qui collectent des ressources et qui en fournissent une première représentation pour injection dans une chaîne de traitement. Les sources de données pourront être définies par une configuration associée à un contexte d’utilisation. • L’interface «ResourceProvider» sera utilisée pour définir les services qui fournissent des représentations de ressources comme si elles étaient lues dans une file d'attente pour être consommées une à une par une chaîne de traitement. • L'interface «Analyser» sera utilisée pour définir les services procédant à l'analyse d'une Ressource, cette analyse se traduisant, le plus souvent, par l'ajout d'annotations ou la création de nouvelles vues sur la Ressource. Une configuration pourra être associée au contexte d’utilisation précisé en paramètre de l’analyse. • L'interface «ReportProvider» sera utilisée pour définir les services pouvant produire des rapports ou des comptes-rendus. Ces services seront, dans la plupart des cas, paramétrables (ils réaliseront également l'interface «Configurable» et leur mise en oeuvre sera dépendante du contexte d'utilisation). • L'interface «Indexer» sera utilisée pour définir les services d'indexation de ressources. Elle ne sera réalisée que pour les services permettant une indexation « on-line ». • L'interface «Searcher»sera utilisée pour définir les services de recherche de ressources. • L'interface «ResourceContainer» sera utilisée pour définir les services pouvant gérer la persistance de ressources. • L'interface «Configurable» sera utilisée pour définir les services dont le comportement est fonction d'un contexte d'utilisation donné, ce contexte correspondant à un jeu particulier de paramètres. Pour un certain nombre de services, l'interface «Configurable» est optionnelle et elle ne sera pas obligatoirement réalisée dans toutes les implémentations. • L'interface «Trainable» sera utilisée pour définir les services dont le comportement évolue dynamiquement par apprentissage. L'interface devra permettre de fournir au service des ressources à partir desquelles il pourra apprendre un modèle comportemental. Ce modèle pourra éventuellement être dépendant d'un contexte d'utilisation. Elle ne sera réalisée que par les services donnant accès «en ligne» au modèle (dans certains cas l'apprentissage sera réalisé «off-line»).