eracerre

je comprend pas exactement l'objectif de cette exercice!
pouvez vous rajoutez quelques commentaires à ce propos!

Projet Système de classement de fichier



Introduction
Il est parfois difficile de retrouver dans une arborescence de plusieurs dizaines de dossiers, un fichier dont on ne connaît ni le nom, ni la date… Ce problème se pose de la même manière lorsqu’il s’agit de classer un fichier nouvellement créé. Comment classer, par exemple, ce fichier image angkor.tif ?
Dois-je lÂ’enregistrer dans :
- /donnees/images/auteur/Sreijbov/Charles/date/
- /donnees/images/theme/architecture/
- /donnees/images/theme/pays/cambodge/
- /donnees/auteur/ Sreijbov /images/
- /donnees/theme/architecture/image
- /donnees/theme/auteur/ Sreijbov /Â…
Un utilisateur organisé peut aisément structurer son arborescence autour d’une idée force : par exemple un classement par auteur, un classement par thème, un classement par type de fichier, etc. Mais tous ses classements ne font que déplacer le problème d’un ou deux niveau dans l’arborescence. (Dois-je en effet classer mon précédent angkor.gif dans /themes/architecture ou dans /themes/pays ? Me rappellerai-je de l’avoir classé dans /Auteur/ Sreijbov (un illustre inconnu dont l’orthographe prête d’autant moins à la mémorisation) ?)

Les systèmes de fichiers sont en effet limités à stocker des fichiers selon des critères peu élaborés :
- le lieu dÂ’enregistrement du fichier ;
- le nom du fichier augmenté de quelques informations assez pauvres.
[Note : Cela s’explique probablement par une volonté d’analogie avec le monde réel qui range par exemple physiquement les livres d’une bibliothèque selon ce principe : on range selon la cote et le nom de l’auteur. Et c’est encore sans nul doute cette volonté d’analogie qui a poussé les fabricants d’OS à parler de « dossiers » ou « répertoires » qui sont des concepts imagés faciles à comprendre.]



Solution actuelles
Quelques techniques connues permettent actuellement de répondre partiellement ce problème :
- liens symbolique Unix ou raccourcis sous Windows hélas propriétaires à leurs systèmes respectifs et vites ingérables ;
- outils ou moteurs de recherche : ces outils ne traitent que des fichiers à base de texte (pas les images, sons, vidéos ou autres) ; ces outils ne sont pas très efficaces (parfois beaucoup de bruit dans leur réponse - essayer donc de faire un grep linux *) ; en outre ces solutions ne gèrent pas le problème du classement ;
- base de données qui permettent de classer manuellement des fichiers comme pourrait le faire, par exemple, un documentaliste pour des livres : solution coûteuse en temps ; lourd à gérer ; relativement statique ; etc.


Comment donc remédier à ce problème ?

Quelques pistes de recherches avancées
[OWL.]


Oracle a récemment proposé une solution à ce problème mais entièrement propriétaire : le ….


Rasterman mentionne sur <http://www.us.rasterman.com/e17.html> que la prochaine version d’Enleightenment (0.17 - licence GPL) intègrera une couche d’abstraction pour la gestion des fichiers. Cette couche, appelée Efsd, aura notamment une fonction de recherche de métadonnées des fichiers.
“Efsd is the filing system abstraction layer. It is a library and a daemon process that the library communicates with for the calling process (in this case E17). It handles all filing system interaction in an asynchronous manner, so E17 isn't ever left blocking on basic IO requests. It handles copying, renaming and deleting of files. Also listing of directories, monitoring for changes in directories, retrieving stat information on files, as well as meta-data retrieval and modification for files. All of this is done in an asynchronous request/event system thus keeping E17 free to handle user interaction as much as possible while efsd does the nasty IO work. cK is currently busy working on this.”
Cette couche est actuellement développée par Christian Kreibich (cK@whoop.org <mailto:cK@whoop.org> ou kreibich@aciri.org <mailto:kreibich@aciri.org>).
Elle repose notamment sur FAM (File Alteration Monitor), un démon développé par SGI (licence GPL et LGPL) qui est lui-même une couche d’abstraction entre le système de fichier et les applications. (Voir le lien : <http://oss.sgi.com/projects/fam/>.)


Piste de recherche proposée
Nous proposons tout simplement d’élaborer une solution qui permette de classer et retrouver chaque fichier grâce à un système de métadonnées, simple, ouvert, extensible et qui perturbe le moins possible la manipulation des fichiers.

Voyons quels sont les principaux besoins pour traiter ce problème :
- cœur du problème : catégoriser chaque fichier par des métadonnées : auteur, nom, mots-clefs, langue, etc.
- offrir une solution qui s’adapte à n’importe quel système de fichier et donc à n’importe quel OS ;
- offrir une solution qui conserve la souplesse de manipulation des fichiers. Un fichier doit pouvoir être déplacé, renommé, etc., sans perdre ses métadonnées ;
- tout fichier nouvellement créé doit pouvoir jouir de métadonnées automatiques.


Éventuellement :
- on doit pouvoir créer un nouveau système de fichier qui gère ce problème de façon transparente ;
- Â…


Solution proposée

A. - Principe général
Chaque fichier <nom_de_fichier.xxx> de l’arborescence est accompagné d’un fichier <nom_de_fichier.xxx.xml> qui contient les métadonnées relatives à ce fichier, soit :
- au minimum : auteur, titre, type de fichier, mots-clefs, ressource, date ;
- à déterminer : d’autres métadonnées à la discrétion de l’utilisateur ;
- à déterminer : éventuellement des métadonnées normalisées (Dublin Core, autres).

Une application est chargée de gérer ces couples de fichiers :

• 1. - gestion des métadonnées relatives à chaque fichier via une petite interface ;
• 2. - manipulations des fichiers « normaux » (copie, déplacement, création, etc.)

Sachant que ces dernières fonctionnalités peuvent être complètement inutiles. En effet quel intérêt de déplacer un fichier puisque qu’on peut lui attacher des objets à la place…

• 3. - éventuellement offrir des outils de reprise de lÂ’existant, etc.

Avantages :

• faible espace disque ;
• les fichiers .xml peuvent être lus, écrits, transformés par nÂ’importe quelle application ;
• lors dÂ’une copie du couple sur un autre système, les métadonnées ne sont perdues ;
• on peut ajouter ses propres métadonnées ;
• Â…

Inconvénients : …


B. - Mise en oeuvre

1. - Interface de gestion des infos relative à chaque fichier (le fichier .xxx.xml).
L’interface est chargée :
- de créer, modifier, supprimer les infos contenues dans chaque fichier .xxx.xml ;
- d’effectuer des recherches multicritères sur les fichiers ;
- éventuellement de reproduire graphiquement les arborescences virtuelles créées par les métadonnées ;



2. - Application de manipulation des fichiers
Cette application doit être capable de gérer les couples de fichiers pour chaque opération effectué sur le système de fichiers [faut il définir un périmètre d’action de cette application (le répertoire où sont sauvées les données ?) ?] :

• création ; avec création de métadonnées par défaut ; avec le recours automatique éventuel à lÂ’interface de gestion des métadonnées ;
• copie ; [lister tous les problèmes de la copie : lien avec original ? recréation de la ressource, etc.]
• renommage ;
• déplacement ;

3. - Â…
- de valider les fichiers .xml au cas où ceux-ci ont été créé à la main ou avec un autre logiciel ;
- de réunir tous les fichiers en une seule base de données ;
- valider que chaque fichier à un homologue .xml ;
- (pb des fichiers .xml qui ont un .xml.xml)

Création Recherche Manipulation Options

Recherche

Auteur [ ] (DC.Creator)

Titre [ ] (DC.Title)

Type de fichier [indifférent / texte / image / sonore / video]

Format [Â… ] (DC.Format)

Focale logique [ ] (DCÂ…)

Focale spatiale [ ]

Focale tempor. [ ]

Date [ ] (DC.Date)

Langue [ ] (DC.Language)

Ressource [ ] (DC.identifiant)

Publicité [ ] (DC.rights)


Question importante :
1. - doit-on conserver une arborescence de fichier classique (à la discrétion de l’utilisateur)
2. - ou bien doit-on gérer l’arborescence à la place de l’utilisateur.


Solution (1)
Avantages : - on est dans quelque chose de familier ;
Inconvénient : - on retrouve le problème du choix du classement a priori d’un fichier


Solution (2)
Avantages : - on supprime le problème du choix inhérent au classement à deux dimensions ;
Inconvénients : - l’arborescence risque d’être déroutante pour quelqu’un qui ne connaît pas ce système de classement.









Comment mettre (2) en Âœuvre ?
- classement automatique en fonction de la date : facile à mettre en œuvre ;
- classement automatique auteur + date : améliore le pb de la confidentialité des données ou du droit d’accès
- classement automatique auteur + taille des dossier + rareté de modif : permet de faire des sauvegardes incrémentales intelligentes en copiant le moins de dossiers possibles ;

<xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<objet>

• <fichier>

• <nom>Systeme_de_classement_de_Charles_Nepote0.3.0.rtf</nom>
• <auteur>Charles Nepote</auteur>
• <type_documentaire>note</type_documentaire>
• <publicite>privé</publicite>
• <etat>En cours</etat>
• <date_derniere_sauvegarde> </date_derniere_sauvegarde>
• <date_derniere_consultation> </date_derniere_consultation>

• <mot-clef>classement</mot-clef>
• <mot-clef>fichier</mot-clef>
• <mot-clef>rangement </mot-clef>
• <mot-clef>documentation</mot-clef>
• <mot-clef>bibliothèque</mot-clef>
• <mot-clef>cote</mot-clef>
• <mot-clef>document</mot-clef>

• <arborescence>
  • <grand_pere>logique</grand_pere>
  • <pere>bibliothéconomie</pere>
  • <individu>classement
  • <fils>document
    • <petit_fils>fichiers</petit_fils>
  • </fils>
    • <fils>chose</fils>
  • </individu>
• </arborescence>

• <thesaurus>
  • <terme>cousin
  • <terme_generique>parenté</terme_generique>
  • <terme_specifique>cousin germain</terme_specifique>
  • <terme_specifique>cousin à la mode de Â…</terme_specifique>
  • <employe_pour> </employe_pour>
  • <terme_associe> </terme_associe>
  • <equivalent_linguistique

valeur="réelle|partielle|sans"
type="meme_etymo|etymo_diff|meme_contruction_semantique>

• <anglais> </anglais>
• </equivalent_linguistique>
• </terme>
• </thesaurus>

• </fichier>

</objet>



Doit-on choisir la solution « arborescence » ou « thesaurus » ?



Avantages :
- lors d’une sauvegarde ou de la copie d’un répertoire, les attributs de chaque fichiers sont également sauvegardés ;
- Â…
Bibliographie


- Anne-Marie Vercoustre, Inria (traduction) : Eléments de métadonnées du Dublin Core, Version 1.1: Description de Référence.

<http://www-rocq.inria.fr/~vercoust/METADATA/DC-fr.1.1.html>

---