From Open Clip Art Library Wiki

This section is deprecated. You can help by updating it, or possibly deleting it..

Cette page a besoin d'être revue et certains mots en sont pas encore traduits. Merci pour votre aide (this page have just come to be translate and need to be reviewed) --Patricia.fidi

Pour « Open Clip Art Library » - OCAL - nous essayons d'entretenir un grand nombre de documents SVG, de faire des mises à jour faciles et d'en garder trace. Cette page donne un aperçu de ce qu'est un système de gestion de documents, les caractéristiques par rapport à d'autres systèmes et le travail fait à OCAL pour développer une solution correspondant à nos besoins.

Documents

Quest-ce qu'un document ?

Un document est un ensemble d'un ou plusieurs fichiers comme : Un rendu SVG en fichiers WMF, PNG, etc. Une présentation avec traduction dans 5 autres langues Un rapport HTML avec plusieurs garphiques HTML 10 documents textes qui font 10 chapitres d'un livre

Les documents exigent une capacité à : Identifier les métadonnées comme le titre, le sujet, l'auteur, etc. Suivre les anciennes versions afin de pouvoir les changer à temps Fermer un document afin qu'un seul auteur puisse le changer lorsque nécessaire Retirer et archiver un document depuis son éditeur préféré

Qu'est-ce qu'un système de gestion de documents ?

Un système de gestion de documents N'EST PAS : Un fichier système comme JFS Un système de gestion des codes sources comme CVS Un système de gestion de contenu comme Plone

Tous ces précédents systèmes sont intéressants pour gérer de modestes (<1000) collections de documents, mais un système dédié de documentation commode lorsque vous avez besoin de : Archiver des millions de documents ou téraoctets de données Archiver et accéder à des fichiers de façon aléatoire Faire des recherches au hasard et rapidement sélectionner un ensemble de documents basés sur des mots clés ou des sujets Fermer des documents à des auteurs particuliers Faire de grosses opérations sur de « nouveaux » documents : faire des vignettes, indexer, traduire, scanner en OCR, etc.)

Quels sont les systèmes de gestion de documents qui existent déjà ? Pourquoi un nouveau ?

Le site de Fresmeat montre qu'ils y a eu de nombreuses tentatives pour créer un système de gestion de documents (de même pour un de mes programmes EIDETIC. Un bon nombre ne sont que des « web wrapper » entourant un système de fichiers hiérarchisés avec un téchargement de fichiers. Et la plupart sont orientés web (Ex : plusieurs sont en cgi ou php) et donc ne peuvent être facilement accessibles aux scripts. C'est une limite car si vous gérez une dizaine de millers de documents, vous ne voulez pas indéfiniment cliquer sur des formulaires web pour soumettre tous les fichiers ou même un par un.

Ce dont nous avons besoin actuellement, c'est quelque chose de facilement utilisable en script API. Quelque chose qui tourne avec un service démon pourrait très bien marcher car ce service pourrait juste s'occuper de gérer l'énorme collection de fichiers et laisser l'interface (web GUI, cmdline ou autre) à d'autres programmes clients

Qu'est-ce que « dms » ou « Document::Manager » ?

« dms » est un système avec un service démon qui encapsule le système de gestion de documents. Pensez à un serveur de mèls : au lieu d'envoyer des mèls avec des entêtes à/de/objets, vous envoyez des documents avec des métadonnées. Ceci est invoqué par le démon « dmsd » qui tourne sans cesse, acceptant les connections des clients, traitant les requêtes et entretenant l'archivage de documents.

Le protocole utilisé pour communiquer avec « dmssd » est - SOAP - « Simple Object Access Protocol ». SOAP est un protocole XML et reconnu par une grande majorité de languages. Cela veut dire que vous pouvez contruire des interfaces clients en Perl, php, Java, Python, C++ ou n'importe quel autre langage qui implémente SOAP. L'implementation de SOAP dans Perl est appelé « SOAP::Lite » et il est utilisé pour créer de simples outils de commandes en ligne.

« dmsd » est actuellement très petit avec une interface sommaire autour du module perl « Document::Manager ». Ce module définit (programmatic? please translate) l'API que les clients utilisent. Il est capable d'interagir avec les métadonnées et intègre les fonctionnalités hautes du système qui fournissent le (wrapper ? please translate) autour des fonctionnalités basses. Ces fonctionnalités basses du système sont intégrées dans « Document::repository » qui contient la logique de maintenance du dépôt de document et qui vérifie en entrée et sortie les fichiers individuels. « Document::Repository » ne s'occupe pas des métadonnées.

Quelle différence entre la gestion de document et la gestion de ressources, de contenus ?

Les systèmes de code source comme CVS ou Subversion sont utiles pour gérer les collections de fichiers sources pour construire une application. Ils permettent à un utilisateur de suivre et gérer les changements faits à travers d'autres fichiers à l'intérieur d'une hiérarchie. Par contre ces systèmes tendent à ne pas fournir de fonctionnements pour opérer sur les métadonnées des fichiers individuels ; pour le moment, ils n'ont pas de fonctionnements pour sélectionner un ensemble de fichiers avec un sujet donné ou un mot clé. Ils ont tendance à avoir la structure hiérarchique de leur contenu codé en dur ; avec des codes sources dont vous avez rarement besoin pour soudainement réorganiser tous les fichiers à afficher par auteur ou titres, pourtant c'est un besoin habituel pour les collections de documents.

Au point de vue pratique, les systèmes de gestion de code source tendent à être plutôt technique par nature car par définition leurs utilisateurs sont des gens assez techniques. Malheureusement pour les utilisateurs non techniques comme les artistes et les gens d'affaires, cette complexité peut être une barrière majeure. Depuis que plusieurs genres de documents (comme les binaires ou formats XML) ne sont pas vraiment accomodants pour la diffusion en ligne, la puissance des systèmes de gestion de code source n'est pas présente et tende à être exterminée.

Les système de gestion de contenu sont similaires d'une certaine façon aux système de gestion de code source. Ils entretiennent des parties individuelles de contenus dans une hiérarchie, suivent les changements et permettent la présentation de la collection comme un tout. Ils se différencient d'un système de gestion de code source par le fait qu'ils incluent un état pour une partie du contenu - il peut être publié, retiré ou fixer la manière dont un utilisateur sera présenté avec une collection d'information - Ex: à travers un navigateur web.

Les systèmes de gestion de code source et de contenu ont peut-être été utilisés pour gérer des documents pour certaines applications elles sont très utiles. Par contre, dans d'autres circonstances elles sont exterminées ou impropre au besoin demandé. Pour le moment, les demandes dans le monde des affaires pour rassembler des millions de documents pour de la réglementation, formulaires et procédures peuvent trouver un système de gestion de code source ou un système de gestion de contenu par site web trop encombrant ou trop complexe pour leurs besoins.

Les systèmes de gestion de documents fonctionnent pour ce genre de niches. Pour le moment, une société peut avoir besoin de gérer plusieurs téraoctets de documents scannés jusqu'aux microfilmes ou des fichiers d'enregistrement de milliers de patients.

Idées d'interface

Listing de fichier basique

doc_id   title    size    date    author

Ajouts récents

Cette page liste les dernières soumissions et leur statut. Nous faisons les images immédiatement pour donner à l'artiste une réponse rapide indiquant que son image a bien été chargé avec succès et pour encourager les visiteurs à faire des commentaires et des estimations sur les nouvelles soumissions. Les images mal notées en dessous d'un certain niveau seront supprimées de la liste.

title    status

« title » est un lien vers la page d'info détaillée

Le plus téléchargé du mois

Liste de tous les SVG par ordre décroissant de nombre de téléchargements

title    num_downloads  [dl]

« title » est un lien vers la page d'info détaillée. Ce rapport pourrait être affiché comme un petit tableau sur un côté de la page d'accueil.Il se remettra à zéro lui-même au début de chaque mois.

Liste des auteurs artistes

Le centre de l'écran est une liste des soumissions de SVG par un artiste donné, ordonné par X téléchargements décroissants ou par âge (le plus récent en premier) :

thumbnail    status   title    num_views    num_downloads

Le panneau sur le côté contient :

Un tableau à propos de l'auteur bio (en optionl) liens vers le blog, la page d'accueil, art différent, etc (en option) contact (en option) Membre depuis...

Statistiques Nbre total de soumissions Nbre total de vues Nbre total de téléchargement Nbre total de SVG dans chaque état

Page détaillée de document SVG

Cette page affiche un seul SVG et ses détails. Dans le centre de la page, se trouve un aperçu de l'image. Il y a une liste de commentaires et un petit formulaire pour ajouter des commentaires à propos de l'image. Le but n'est pas de faire un système sophistiqué de commentaires mais juste de rapides brouillons ou notes sur l'image.

Autres infos contenant : Métadonnée (auteur, titre, mots clés, etc.) Nbre de téléchargements Recherche par termes conduisant à l'affichage de ce détail Tests de validation (pour lesquels les outils SVG marchent très bien) Commentaires et descriptions du style Wiki

Liens vers ces actions : Notifier un problème Changer de statut Évaluer Ajouter/enlever/éditer les mots clés Ajouter des actualisations (auteur seulement)

Demandes de cliparts

La page actuelle de notre wiki semble pas mal marcher mais quelque chose de plus structuré serait peut-être plus agréable ? Cela semble une priorité basse pour le moment. Idées...

• Inclure une demande « âge» et par défaut afficher la demande la plus récente en début de page.
• Actualiser les demandes afin que les demandeurs puissent réactualiser leur demande et les faire migrer vers le haut de page
• Vote pour que des gens puissent indiquer leur désire pour la même chose
• Chaque demandeur aura le droit d'activer une fois leur actualisation par demande
• Liste séparée des fichiers récemment demandés peut-être par une petite liste sur la page d'accueil.
• Possibilité donnée au demandeur d'indiquer si sa demande a été bien remplie
• Peut-être autoriser les expirations (doit se faire après X jours sinon aucun besoin pour les autres)

Formulaires

Formulaires de recherche : par mots clés par auteurs par date par évaluation

Formulaire de chargement : Chargement rapide (nécessite des métadatas valides et complètes dans les SVG) Chargement avancé (permet l'ajout de métadata) Gros chargement (soumettre un fichier « zip » ou « tarball » de plusieurs fichiers SVG)

Formulaire pour générer des archives : Filtrage du stock de fichiers (pas de choses NAZI, ni nudité, etc.) Filtres personnalisés (seulement animaux, seulement par auteur XYZ, etc.) Format d'archive (« zip », « tgz », etc.) Structure interne (symlinks, no-symlinks, etc. please translate if possible)

Où puis-je trouver un « DMS » ?

Actuellement, le plus récemment développé est le module « dms » dans le CVS de « Open Clip Art Library » :

cvs -d :ext:USERNAME@freedesktop.org:/cvs/clipart co dms

Voir les instructions pour avoir de l'aide sur notre CVS

Les parties affiliées de « dms » les plus récentes sont disponibles ici à travers ces modules :

svg_metadata
dms-client-cgi

Également, « DMS » et d'autres partie du système sont disponibles sur CPAN mais les versions disponibles ne sont pas toujours à jour.