Guide Monuments Historiques

Il s'agit ici principalement du sectionnement des documents, comment il peut se faire dans un logiciel de traitement de texte bien utilisé (i.e. produisant des documents semi-structurés grâce entre autres à l'utilisation des styles).

La plupart des documents qui interviennent dans le système d'informations documentaire des Monuments Historiques sont des documents rédactionnels, c'est-à-dire que les logiciels normalement utilisés pour les éditer sont des traitements de texte. Le schéma SDAPA permet de traiter ces documents aussi bien en respectant les notions de blocs de texte et d'enrichissement typographique. Il permet aussi d'insérer des illustrations, des tableaux, traiter les index et les tables des matières. Avec un éditeur XML correctement configuré, l'édition de documents suivant le schéma SDAPA ne sera pas très différente du travail dans un traitement de texte utilisé avec les notions de stylage (insertion de style de texte pour gérer la mise en forme du document et générer des tables des matières).

Autre chose, contrairement à un traitement de texte, il n'y pas de séparation du document en page, inutile dans un contexte de dossier électronique appelé à de multiples sorties (HTML, PDF, papier). Et de toute manière, cette préoccupation relève de la mise en forme. Il faut donc repenser sa manière de concevoir les documents et les sectionner en plusieurs fichiers afin que l'on évite d'avoir des fichiers au kilomètre.

Comme déjà discuté dans la documentation au sujet du schéma lui-même, toute la problématique du passage au dossier électronique dépend de l'architecture schématique adoptée pour représenter les relations entre les différents documents d'un processus d'affaires. Cependant, l'un semble plus réaliste à mettre en place et particulièrement dans le cas des MH. Il s'agit du schéma réseautique. Dans ce cas, les métadonnées communes à tous les documents sont celles relatives à l'objet protégé (donc un immeuble ou objet).

Schéma d'un dossier électronique dans le cas des MH

L'idéal serait en effet de n'avoir qu'une seule occurrence des métadonnées relatives à un monument historique reliée à chacun des documents qui s'y rapportent plutôt que de les répéter dans chaque document. Seulement cela sous-entend que tous les intervenants aient accès à ces métadonnées (base de données des MH) ou au moins à leur identifiant. L'autre modèle possible est que chacun des documents comporte en plus de ses propres métadonnées celles du MH auquel il se rapporte, comme c'est la cas actuellement : tous les documents contiennent au moins le nom du monument historique concerné, sa localisation. Il est possible de combiner ces deux approches.

Le tableau ci-dessous montre la structure en SDAPA que pourrait avoir les documents produits pour les Monuments historiques. Il ne s'agit que de suggestions de structure qui montrent entre autres que ces types de documents peuvent être traités mais ce n'est pas la seule manière dont ils peuvent l'être. D'après la terminologie des documents des Monuments historiques, un grand nombre de cas est couvert avec peut-être principalement le traitement des dossiers et des enregistrements. Dans le cas des premiers, documents complexes par définition, leur structure peut varier suivant le niveau d'éclatement en fichiers que l'on souhaite adopter et aussi suivant l'importance du contenu :

• 1ère méthode : on peut considérer qu'un dossier est un ensemble de sous-dossiers ou parties, ce qui se traduit par l'usage d'un élément part pour chacune des parties identifées. Le contenu de ces parties peut se trouver dans le document ou dans des fichiers vers lesquels il suffit de pointer par l'intermédiaire de l'attribut uri de part.

• 2ème méthode : un dossier peut aussi être un agencement de documents ordonnés (fichiers externes) et dans ce cas content est plus approprié avec un lien vers les documents subordonnés au niveau de l'attribut uri des part ou summary.

• 3ème méthode : le dossier est traité comme un livre et tout le contenu est structuré en sections dont le contenu peut se trouver là ou dans des fichiers externes dont l'URI représente alors la valeur de l'attribut uri.

<!--Dans le cas d'une collection de documents figurés-->

Afin de pouvoir gérer les documents dans un environnement structuré, un certain nombre d'informations sont nécessaires. Il s'agit par exemple de la cote dans un catalogue bibliographique. Quelles sont les informations essentielles pour repérer et gérer les documents dans le contexte des Monuments historiques ?

Il existe deux niveaux de métadonnées :

• celles relatives au document lui-même

• celles relatives au monument historique. Elles servent entre autres à identifier tous les documents se rapportant à un même monument historique.

Les secondes sont communes à un ensemble de documents tandis que les premières dépendent de chaque document.

L'organisation des fichiers et les relations entre eux est cruciale dans le contexte des MH où une partie des documents d'un processus d'affaires n'est pas créée par une institution DAPA mais par des intervenants extérieurs. Dans ce cas, on ne peut pas obliger les gens à suivre des structures trop strictes et nécessitant des outils trop particuliers. La seule chose essentielle est de disposer des informations minimales pour identifier à quel objet documentaire, ici quel MH, se rapporte le document. Or ceci se fait déjà par des métadonnées rappelées dans chaque document, à savoir le nom du MH et sa localisation. Pour relier les documents d'un même processus de gestion, il suffirait à l'entrée d'un document dans l'institution d'ajouter un lien vers le fichier contenant les métadonnées plus complètes et disposant lui d'une URl pérenne.

La structure des documents MH (voir ci-dessus) reflètent la manière dont les documents physiques sont traduits à l'aide d'éléments SDAPA. On voit ainsi que la notion de dossier ou de chemise (contenant physique) est traduite par l'élément book. Celui-ci n'est souvent constitué que d'une table des matières ou de parties (ie les sous-dossiers) vers lesquelles il ne fait que pointer. Il ne paraît pas concevable de faite d'un dossier un seul document XML mieux faut faire un ensemble de fichiers reliés.