Projet IDAPA

Accueil > Ressources > OpenOffice et Perl > XML 4 KDD

XML 4 KDD

Rapport final de projet de Master

mardi 6 janvier 2009, par Fadel

Document sans titre

XML 4 KDD


Présentation :

L’importation/ exportations de données d’un système vers un autre est une tache d’autant de plus difficile que les fichiers exportés ou importés seront inconnus et éventuellement inexploitables, il faut donc avant tout penser à régler ce problème et répondre aux questions de l’interopérabilité entre les système. Qui pourront prendre plus du temps que le traitement de données même.
L’objectif principal de cette partie est d'étudier l'adaptabilité du standard d'Open Office dans le cadre de notre projet IDAPA, ce standard doit décrire la structure de donnée à respecter pour garantir la fiabilité et l’efficacité de l’échange.
Dans un premier temps on s'intéresser à l'étude du standard d'Open Office et voir s’il répond bien à la question, et dans un second temps on va voir les difficultés qui pourront être rencontrés, et comment peut on les contourner y’a-t-il des moyens à employer ?
Avant de donner une réponse à la question, on va tout d’abord étudier le format afin de pouvoir sortir avec des conclusions pour bien répondre.

Processus KDD :
Le but de ce paragraphe n’est pas de rentrer dans les détails du processus KDD, étant donné que qu’on se penche sur une définition de standard pour tel processus, il nous est nécessaire de le p??Rrésenter sans entrer dans les détails.
KDD désigne l'ensemble du processus d'extraction de connaissances utiles à partir des données
Ce processus a pour but de transformer des données (volumineuses, multiformes, stockées
Sous différents formats sur des supports pouvant être distribués) en connaissances. Ces
Connaissances s’exprimer comme un modèle Mathématique ou logique pour la prise de décision. Les modèles explicites, quelle que soit leur forme, peuvent alimenter un système à base de connaissances ou un système expert.
Ie processus se fait en plusieurs étapes commençant par les sélections de données et finissant par la validation.


Format Open Office
Un document Open Office est en réalité un fichier ZIP contenant un ensemble de fichiers ou le travail bureautique est inséré, cet ensemble de fichiers décrit le standard pour le voir il suffit de changer l’extension en .ZIP et le décompresser. La raison de cette compression de fichier en est que le fichier XML est stockée dans plusieurs fichiers, et ceux-ci sont compressés pour économiser de l'espace.
Le nombre de fichiers zippés constituants le document open office n'est pas limité a priori, mais, on s’intéresse à 3 entre eux qui représente le contenu nécessaire et minimal pour obtenir un document complet et qui sont d’ailleurs omniprésents « content », « styles » et « meta ».sont des fichiers XML, donc que chacun d'eux possède une structure arborescente qu’on peut considéré comme une base de données à laquelle, via l’interface OpenOffice::OODoc, les programme??Rs se connectent et faire de requettage. Pour la plupart des opérations relatives au contenu et à la présentation des documents, l'interface d'accès privilégiée est l'objet « Document », créé par la fonction d'initialisation ooDocument(), tandis que les accès aux méta données relèvent de l'objet « Meta » créé par la fonction ooMeta().

Structure de fichiers

Parmi les fichiers XML constituant l’archive, on trouve content.xml qui est le fichier du contenu, ou tout les contenus du document texte, images seront stockés sauf que pour les images, il existe un dossier image qui contient toutes les images, dans le contenu c’est seul le chemin qui est noté dans le fichier.
<text:h text:style-name="Heading_2">Projet IDADA</text:h>
<text:p text:style-name="Text_body"/>
<text:p text:style-name="Text_body">
Ceci est un paragraphe. L'information de mise-en-page
est stockée à part dans le style "Text_body" (Corps de texte).
La balise vide text:p au-dessus correspond à un paragraphe
vide, c'est-à-dire à un saut de ligne.
</text:p>
- un fichier XML pour le style (style et contenu sont présentés de façon séparée) la mise en forme du document.
- un fichier pour les meta-informations (auteur...) c’est le fichier meta.xml, Ce fichier contient les métadonnées associées au document. Une liste de champs prédéfinis fait partie du standard: application, titre, description, sujet, mots-clés, auteur initial, auteur, imprimé par, date de création, date de dernière modification, date de dernière??R impression, durée d'édition, modèle utilisé, rechargement automatique, comportement url (??), langue, nombre d'éditions, durée totale d'édition, statistiques sur le document. Ce sont les deux fichiers qui vont nous intéresser par la suite, pour définir notre standard à partir de celui de l’Open Office parmi les fichiers extraits du document de l’open office on trouve également :
- un fichier pour les choix applicatifs (zoom, imprimante...)
- un fichier d'informations sur la sauvegarde elle-même (type mime, méthode de chiffrement.)
- un répertoire conservant les fichiers binaires (images...)
- un répertoire conservant les formulaires inclus dans les macros
un répertoire conservant les macros
- un répertoire conservant les objets issus d'autres applicatifs.

Manipulation de source de résultat

Il s’agit de traiter le format Open Office, essentiellement de travailler les contenues du fichier content.xml et data.xml pour lui rajouter des nouvelles données spécifiques au projet IDADA telles que :
Algorithme utilisé
Version de l’outil utilisé ainsi de suite.

Pour faire ces traitements, les interfaces suivantes ont été utilisées:

L’interface de programmation Perl / OpenDocument :

Ce module est une interface dédié au traitement les fichiers au format OASIS Open Document (ISO/IEC 26300), c’est une interface orientée objets et se base sur langage perl.
Elle totalement indépendant de l’environnement de développement Open Office. Via cette interface on peux accéder aux d??Rifférents fichier contenus dans l’archive ZIP de l’open office en vu de les mettre à jours (création, consultation, suppression, modifier de tous le document) tout en respectant le comportement du fichier autrement dit sans modifier le standard, et sans avoir recours aux logiciels bureautiques par exemple.
Brièvement, cette interface d’accès direct en mode lecture et écriture aux dans les documents d’Open Office.org, d’une manière très autonome sans passer par l’API d’OpenOffice.org. Elle fournit un certain nombre de méthodes agissant sur le contenu et la présentation, et permet même la génération complète de nouveaux documents. Après avoir installé le module on l’inclut en Perl comme les autres module use OpenOffice::OODoc;
Il est également à noter que toutes les méthodes de XML::Twig et d'Archive::Zip sont disponibles à travers OpenOffice::OODoc.

L’interface Perl DBI (DataBase Interface) :

Perl DBI (DataBase Interface) est l'interface de base de données le plus commun pour le langage de programmation Perl.
Les spécifications de l'API DBI perl définissent un ensemble de fonctions, de variables et de conventions d'accès à un SGDB cohérent et indépendant du SGBD utilisé.

Choix du standard Open Office?

Rappelons que l'objectif de l’Open Office est de réaliser les traitements en accédant directement aux fichiers, sans dépendre d'un logiciel bureautique quelconque c’est pour ce motif qu’on a choisi ce format, ce qui répond très bien à notre cas, à cela s’ajoute que Mysql reconnaît le format d’open office ainsi que R et nouvellement c’est SAS qui l’a ??Rintégré, on peut retravailler ce format pour l’adapter à notre projet.


Cycle de vie du projet

Voir fig1 dans le fichier joint.


Exportation de données sur serveur MySQL au format ODS
J’ai mis en place une interface permettant d’établir la connexion au serveur Mysql et détection automatique de toutes les bases de données présentes sur le serveur, les bases sont listées dans une ComboBox. Après avoir choisi une base et la valider une deuxième interface s’ouvre contenant toutes les tables de la base et en fin le choix de la table à exporter en ODS le processus suivant explique le fonctionnement général.

voir fig2

Trois fichiers résultes de programme contenant la description, le contenu et les requêtes exécutées:

Pour avoir une meilleure traçabilité de la procédure d’analyse de donnée, il est necessaire de faire de sorte qu’à chaque fois qu’une nouvelle étude est réalisée la description de cette dernière soit enregistrée dans le meta à titre d'example

Les méthode utilisées
L’auteur
La date.

Requête

Select Nom, produit from table1..
Content

Nom1 produit
Nom2 produit
Nom3 produit
Nom4 produit

Meta

- Author Monsieur
- Procédure utilisée
- Date

voir le fichier joint

Difficulté
Une grande difficulté pourra être un obstacle pour l’utilisation du standard de l’Open Office, c’est au niveau de la taille, il est d’une taille limité ce qui pourra engendrer une perte d’informations,si on prend le cas du Calc Open Office pour la version le nombre de lignes était l??Rimité à 32000 tandis que pour la version Calc 2.0 qui a connu une augmentation presque le double 65536 qui l’approche d’Excel de Microsoft Office avant la version de 2007 qui fait un record de ligne la limite est portée à 1 048 576 lignes. Ce qui montre bien qu’une éventuelle risque de perte de données est envisageable avec l’utilisation du standard sans lui apporter de modification.
Une solution à ce problème consiste à déclarer les ressources de données dans le fichier XML.

Spécifications techniques :

Voici un certain nombre de ressources (Modules) utiles pour le bon fonctionnement de l’application :
- L’interface de programmation Perl / OpenDocument
- L’interface Perl DBI (DataBase Interface).
- Compilateur Perl - Serveur MySQL
- Perl/Tk. Interfaces graphiques avec PERL.

Gestion de Projet

Evaluation de SPIP pour gestion de projets informatiques

SPIP (Système de Publication pour l’Internet Partagé) est un logiciel libre destiné à la production de Web, de type système de gestion de contenu (CMS Content Management System). Cet Open Source était à l’origine conçu pour la publication telles que les magazines et n’a pas vocation d’être destiné aux projets techniques, cependant il peut être utilisable dans le cadre de projets informatiques ce qu’on a essayé dans le cadre de notre projet, on a eu un certain nombre de difficultés avec son utilisation, par la suite un résumé de ses inconvénients, avantages m??Rais aussi des solutions préconisées pour le bon fonctionnement de l’application dans le cadre de gestion de projets.

SPIP vs. WIKI
WIKI et SPIP sont tous deux des systèmes de gestion de contenu de site web. La singularité du WIKI réside dans le fait que ses pages web sont librement modifiables par tous les visiteurs ayant ouverts des comptes. L’intérêt du WIKI est donc sa réactivité, c’est aussi son inconvénient lorsqu’il s’agit de mettre en place un processus de rédaction de documents de référence. Un site type SPIP offre la possibilité de mettre en place un système de relecture et de validation du contenu avant publication sur l’intranet ou l’internet.
Contenu technique
A noter que SPIP n’ayant pas été directement conçu pour l’édition de contenu technique, sa version de base offrait peu de facilités d’édition de contenu technique. L’utilisation de SPIP pour éditer des journaux et des cours en ligne de mathématiques a induit l’ajout de modules permettant l’insertion de toute formule LaTex [1]], ce qui permet de publier tout contenu technique aussi complexe soit-il à condition de maîtriser ce langage.
Pièces jointes
SPIP est cependant destiné à l’édition d’articles relativement courts pouvant se lire facilement et rapidement à l’écran. Le reste du contenu doit être relié au document en pièce jointe. Deux formats de pièce jointe sont gérés : fichiers pdf et dossiers compressés. Dans le cadre de gestion d’un projet informatique, les annexes techniques et la documentation sont à joindre en pdf et les éventuelles sources de programmes peuvent être j??Rointes en fichiers compressés. Il apparaît aussi nécessaire de joindre en fichier compressé la source des documents pdf, de manière à faciliter leur mise à jour..
Espace privé
Seul le chef de projet était autorisé à valider et publier les documents, la publication est soumise à la contrainte de disponibilité du chef de projet ou de la personne à qui cette tache a été déléguée. Ce peut causer des retards dans la publication de l’article, voire des dépassements de délais dans la publication et rendre le document caduque.
L’alternative qui consistant à donner à tous le monde l’habilité de publier leur documents sans être révisé revient à mettre en place un solution de types Wiki.
La solution consiste plutôt à exploiter au maximum les possibilités de discussion de relecture d’un article. Tout article soumis est directement lisible par les participants du projets dans la partie privée du site. Un forum de discussion est automatiquement ouvert à chaque soumission d’article. Un flux RSS permet d’être informé en temps réel de l’ouverture d’un nouveau forum et un menu spécial permet de suivre l’ensemble de ceux ouverts.
On d’autre part à disposition une messagerie avec gestion automatiques des archives permettant de lancer des discussions générales.
Enfin la fonction de calendrier permet non seulement de gérer l’agenda du projet mais d’y joindre aussi des documents des comptes rendus.
Cela suppose cependant la disponibilité de l’ensemble des participants au projet pour réagir rapidement aux documents qui leur sont proposés. On demande aussi la disponibilité de l’auteur pour??R intégrer les suggestions faîtes dans le forum. Nous restons ici dans le schéma un article, un auteur. Ce schéma peut être contourné en intégrant des auteurs génériques. Il n’en reste pas moins que la décision de publication dans la partie publique du site peut être trop lente à prendre. Une alternative est de conserver une version du site en intranet.
Notes
[1] [http://www.spip.net/en_article3563.html->http://www.spip.net/en_article3563.html