Table des matières
14h à 17h, Hôtel de Vigny Comme chaque division de la DAPA, les Monuments Historiques ont leurs systèmes d'informations. Plusieurs bases coexistent, à différents niveaux de diffusion. Un effort important se conclut avec le modèle relationnel Agrégée. XML n'est pas envisagé pour l'instant comme format natif de conservation et de recherche, par contre, un schéma précis est attendu pour la diffusion. Partager des structures XML communes avec les autres services de la DAPA permettrait en effet de mutualiser le développement d'un module de présentation Internet.
Luc-Florent Lièvre
Christophe Dessaux
Geneviève Pinçon
Jean Davoigneau <jean.davoigneau@culture.gouv.fr>
Frédéric Glorieux
Valider la commande pour les monuments historiques (modélisation pour diffusion).
Présenter le modèle en élaboration de la base Agrégée.
Relever les structures communes avec les autres divisions de la DAPA.
Une discussion large a permis d’aborder de nombreux aspects d’XML, dépassant le strict cadre métier. Il a été admis qu'un dossier patrimonial puisse partager un même schéma textuel (sections, blocs, ...). Même si la perspective diffère (inventaire, monument historique, archéologie, protection ...), l'objet du discours (un monument, un objet ...) est comparable. Cette unité permettra de partager le même type d’outils de diffusion (voire de production). Ceci n'empêche pas bien sûr, de distinguer des conventions stylistiques, des thésauri, des structures métier.
Comment assurer la pérennité des liens en systèmes ouverts et évolutifs ?
La variété des relations entre pièces de dossier.
Les hiérarchies adoptées dans le modèle Agrégé
Ensemble / Immeubles / Parties / Constituants / Éléments
Ensemble / Objet / Partie
La qualification temporelle des relations.
Le concept de procédure est partagé par plusieurs divisions de la DAPA (Monuments Historiques, Espaces Protégés, Archéologie). Ils pourraient partager un schéma de type projet ou calendrier.
La plupart des modèles de données entretiennent des tables "personnes". Les contacts pourraient être modélisés dans un schéma compatible vCard.
Des liens en contexte de type "note" pourront pointer sur un bloc de références hors texte. Ces références pourront être renseignées avec des métadonnées multiples. En effet, un simple identifiant dépend de l'état du système au moment de la rédaction du dossier. Il ne permet pas de prévoir l'ajout de pièces nouvelles pouvant intéresser le dossier. Un lien renseigné par noms, sujets mots-clé, date, etc. permet de garder du sens au dossier hors système, de reconstruire des liens morts, de proposer automatiquement des cibles nouvelles... Des métadonnées standards pourront être fournies avec un identifiant reconnu. Il est entendu que chaque type de lien (relation entre pièces de dossier, illustrations...) sera identifié par un élément spécifique et ses qualifiants, avec la liste de métadonnées qui lui est propre. Il ne faut pas viser la complétude absolue des relations (comme dans un système relationnel fermé type SQL), mais une navigation intelligente, conçue, révisable et validée par les rédacteurs (à l'aide des systèmes).
Les auteurs (architectes, artisans, artistes ...) devront être représentés par des dossiers rédactionnels distincts. Leur oeuvre sera une liste de liens sur les œuvres qui leur sont attribuées. Un système pourra mettre à jour cette liste lorsqu'une œuvre lui est nouvellement attribuée. Les relations "auteur de", "attribuée à", pourraient être qualifiées avec des nuances de type "conjecture", "fautive" ...
L'utilisation d'un vocabulaire d'autorité (thesauri) prend son sens en contexte, dans le corps d'un dossier (comme un lien dans une page HTML). Le choix d'un schéma de texte riche dépendra pour beaucoup du support fourni pour baliser ces concepts.