Schéma DAPA – version 1.0 – Une structure documentaire pour le patrimoine (2004-06-15)

[ Accueil | Éléments | Groupes | Attributs | Guides d'implémentation | Source du schéma ]

Guides d'implémentation accompagnant le schéma   >>   Guide pour un usage du schéma à la DAPA

[Télécharger la version XML de ce document]

Date (created) : 2004-05-27
Date (modified) : 2004-06-07
Creator :Bougoüin, , Christine
Description (abstract) :

Principes de base du schéma dans le contexte DAPA : il s'agit des principes qui régissent l'application du schéma dans le contexte de la DAPA. Dans ce guide, se retrouvent tous les éléments communs à tous les métiers de la DAPA dans l'usage du schéma SDAPA. Qu'est-ce qu'un dossier électronique et dans ce contexte quel est l'objet documentaire de base, i.e. celui sous lequel tous les documents qui s'y référent peuvent être regroupés ? Quelle est la structure-type d'un document suivant le schéma SDAPA ?

Guide pour un usage du schéma à la DAPA

Table des matières

Le schéma SDAPA a été créé dans le cadre du projet général de mise en place du dossier électronique au sein de la DAPA. Il a plutôt une vocation rédactionnelle et généraliste mais avec une facette documentaire non négligeable. Certains points sont plus particulièrement développés du point de vue sémantique.

Au début du projet, il était question de créer un schéma pour chacun des métiers de la DAPA avec des facettes transversales. Mais très vite, il est apparu qu'un seul schéma généraliste pouvait répondre à tous les besoins exprimés et ainsi mettait en avant les points communs entre les métiers, points communs qui sont donc apparus plus importants qu'à première vue.

1. Le dossier électronique <^>

Le dossier électronique est une notion à la fois abstraite par le concept et simple à comprendre dans le principe. Ces termes parlent à tout le monde ; le problème est que cela semble une belle idée difficile à mettre en place. D'abord qu'entend-on par dossier électronique ? Cela doit être une entité qui permette de mettre en relation des documents intervenant dans une chaîne documentaire et de les organiser. Que ces documents soient créés par une même personne ou non, qu'ils soient conservés au même endroit ou non, il doit être possible de trouver au moins une référence à chacun d'eux.

Il y a de ce fait deux schématisations possibles d'un dossier électronique :

  1. Un schéma hiérarchique avec comme document principal les métadonnées de l'objet documentaire dont il est question en relation avec tous les sous-documents qui interviennent dans son processus d'affaires, eux-mêmes en relation avec d'autres documents, mais cette relation étant d'un autre type (voir aussi, précédent/suivant, contient/est_contenu, etc.). Cette vision est un peu utopique à mettre en place surtout dans un contexte d'éclatement de la localisation des documents et la diversité des auteurs (notamment pour les monuments historiques).

  2. Un schéma réseautique sans réel document principal. Dans ce cas, tous les documents doivent contenir les métadonnées nécessaires pour permettre d'identifier l'objet documentaire, de manière univoque, au processus duquel il intervient. Ainsi chaque document serait accompagné de deux types de métadonnées : celles relatives à l'objet documentaire auquel il se rapporte et les siennes (celles qui le décrivent). Pour retrouver tous les documents intervenant dans la vie d'un objet documentaire, il est nécessaire d'identifier tous les documents qui ont les mêmes métadonnées de niveau "objet documentaire".

Dans le cadre de la DAPA et de ses différents métiers et d'un point de vue patrimonial, l'objet documentaire de base est ce qui fait l'objet d'une étude ou d'une protection : monument ou objet dans le cas des Monuments historiques et de l'Inventaire (objet d'étude), objet archéologique dans le cas de l'Archéologie (site ou entité archéologique), des Espaces protégés dans le cas éponyme (secteur sauvegardé, abords MH, ZPPAUP).

1.1. Architecture <^>

Dans ce contexte de dossier électronique, l'objet patrimonial se retrouve au coeur du système de documents et autour de lui "gravitent" tous les documents qui s'y rapportent.

L'utilisation du dossier électronique repose sur la définition d'une architecture schématique représentant les relations entre les différents documents du système documentaire. L'architecture proposée est fondée sur la mise en réseau des documents par un système de liens non hiérarchisés [Note : Ces liens permettent éventuellement de recréer une hiérarchie a posteriori.]. Dans ce contexte, les métadonnées relatives à l'objet d'étude se retrouvent dans tous les documents relatifs à cet objet d'étude.

Les graphiques suivants illustrent différentes architectures mais pour bien les comprendre en voici les clés :

  • Les dossiers électroniques sont illustrés par un dossier de type papier. Ces dossiers sont titrés pour montrer leur origine métier.

  • Les documents sont représentés par des icônes qui montrent bien la variabilité de leurs contenus. Lorsqu'ils sont situés à l'intérieur d'un dossier électronique, cela signifie qu'il y a un lien implicite de type « fait partie de ». Il y a aussi des documents qui ne font partie d'aucun dossier électronique.

  • Les carrés bleus illustrent des objets patrimoniaux. Trois propriétés leur sont attribués : un titre, un lieu et un identifiant.

  • Trois types de liens sont exprimés : « à propos de » pour les liens depuis les dossiers ou documents vers l'oeuvre qu'ils documentent ; « fait partie de » au sens des œuvres pour indiquer les relations entre carrés bleus ; « voir aussi » pour des liens génériques qui illustrent des relations entre documents ou dossiers.

Schéma de la situation actuelle

Identifier :A.gif
Creator :Arvers, , Jean-Luc

Ce graphique exprime la réalité des dossiers électroniques actuels. Les dossiers en question sont réalisés par les différents métiers de la DAPA, et il n'y a pas de réels liens entre ces dossiers. De plus, les dossiers peuvent faire référence à une même œuvre du patrimoine, mais celle-ci sera représentée par plusieurs carrés bleus.

Ces carrés bleus n'existent pas vraiment dans les système d'information actuels, mais il est intéressant de les placer tout de suite. Sur ce graphique, nous avons mis en lumière les problèmes potentiels suivants : deux œuvres identiques mais pas le même titre ; coordonnées géographiques différentes parce que ce n'est pas exactement la même œuvre, deux carrés bleus identiques, mais sans relation pour montrer une potentielle redondance. Tout cela permet de suggérer une évolution.

Une première évolution serait de n'avoir qu'une seule occurrence complète des métadonnées relatives à un objet patrimonial et reliée à chacun des documents et dossiers électroniques qui s'y rapportent pour éviter d'avoir à les répéter entièrement dans chaque document. Seulement cela sous-entend que les métadonnées ou au moins les identifiants des objets patrimoniaux soient accessibles et qu'il n'y ait plus qu'à créer un lien entre le document et l'objet patrimonial dont il traite. Sinon chacun des documents doit comporter en plus de ses propres métadonnées celles de l'objet patrimonial auquel il se rapporte. Entre ces deux visions idéales et réalistes, une solution médiane pourrait peut-être être mise en place.

Schéma de la situation idéale

Identifier :C.gif
Creator :Arvers, , Jean-Luc

Ce graphique illustre l'intégration et le décloisonnement possibles des métiers de la DAPA pour un meilleur partage des informations. Au niveau des carrés bleus, des liens de type « fait partie de » ont été ajoutés pour illustrer la problématique de la non-unicité des œuvres par rapport aux différents métiers ainsi que les relations entre ces œuvres. Ceci donne plus de partage de documents entre dossiers électroniques et introduit le concept d'un dossier électronique qui ne provient pas de l'un ou l'autre des métiers actuels de la DAPA.

2. Structure <^>

Conformément à l'architecture générale du schéma SDAPA, la plupart des éléments peuvent être à la racine d'un document et acceptent un bloc local de métadonnées (info).

Quelle que soit la vision schématique adoptée, les documents suivant le schéma SDAPA se présentent sous la forme suivante :

<element-racine uri="" id="ancre">
      <info> <!-- Bloc de métadonnées --> </info>
      <!-- Modèle de contenu de l'élément-racine -->
      </element-racine>

Le bloc info contient les métadonnées du document ou de la partie du document dans lequel il apparaît. Les métadonnées sont constituées par une série d'éléments Dublin Core complétée de paires property / value, d'un choix d'éléments enfants ou du texte. Suivant l'élément racine choisi, le modèle de contenu (soit ce que peut contenir l'élément) est différent.

Dès lors deux types de métadonnées sont à considérer :

  • celles relatives au document

  • celles relatives à l'objet patrimonial concerné

En plus de ces métadonnées, la structure d'un document dépend de sa nature. Or dans l'environnement Inventaire, comme précisé ci-dessus, il existe une certain nombre de documents et notamment de dossiers normalisés. Il importe de déterminer de quelle manière ceux-ci peuvent être traités avec le schéma SDAPA suivant la nature des informations qu'ils contiennent. Cela revient notamment à déterminer l'élément de plus haut niveau qui va les représenter. Voici des exemples de choix de l'élément générique du schéma SDAPA en fonction du type de document traité :

  • pour une notice ou un enregistrement issu d'une base de données, record

  • pour un ensemble de notices, set

  • pour un dossier : dans ce cas, on peut considérer qu'il s'agit d'un document complexe, l'élément book paraît le plus approprié. Il contiendra notamment une table des matières qui pointe vers les différents documents constituant articles, notices, bibliographie ou sous-dossiers.

  • pour des documents rédactionnels simples, article

  • pour une bibliographie, bibliography

En général, on peut considérer qu'article s'applique pour des documents rédactionnels, book pour un ensemble de documents ordonnés (l'agencement des documents se fait par l'intermédiaire d'une table des matières, élément contents, et l'ordre est fixé par celui des éléments summary) et record pour des séries de métadonnées.

3. Régles générales <^>

Les documents produits par les services de la DAPA sont de plusieurs types :

  • notices, enregistrements de base de données

  • illustrations

  • dossiers documentaires normalisés

  • documents éditoriaux (publications).

Le schéma SDAPA permet de traiter tous ces documents en apportant en plus la possibilité d'un enrichissement sémantique (pour la réalisation d'index particuliers par exemple). Il permet évidemment d'insérer des illustrations, des tableaux, et de traiter les index et les tables des matières.

Ponctuation

Tout comme la casse, la ponctuation en fin d'éléments est gérée par la restitution. C'est-à-dire que le contenu d'un élément ne doit en principe pas se terminer par un signe de ponctuation, à l'exception bien sûr de l'élément para. En effet, il est plus facile d'ajouter la ponctuation nécessaire entre les éléments que de devoir normaliser tous les cas possibles et imaginables de ponctuation qui auraient pu être saisis.

3.1. enrichissement typographique <^>

Le schéma SDAPA est un schéma rédactionnel, donc il dispose d'éléments pour gérer l'enrichissement typographique; soit le gras, l'italique, les indices et les exposants comme on peut le faire dans un logiciel de traitement de texte. Néanmoins, comme dans tout document XML , structuration et mise en forme sont indépendants. Ainsi ce n'est pas parce qu'une chaîne de caractères est balisée avec <emphasis role="bold"> qu'il apparaîtra toujours en gras à la sortie. Tout dépend du traitement appliqué. Bien sûr, un esprit tordu peut vouloir attribuer des traitements différents que ceux induits par la valeur de l'attribut role.

La mise en forme d'un document XML est défini par des feuilles de style qui permettent de définir comment et sous quelle forme afficher les éléments. Il s'agit d'outils puissants et extrêment paramétrables. Et surtout, avec cette technique , il est possible d'avoir des mises en forme différentes suivant les média de sortie et même des affichages personnalisés.

3.2. enrichissement sémantique <^>

Le schéma SDAPA est aussi un schéma documentaire. A ce titre, la structuration sémantique est poussée très loin et permet plusieurs niveaux. Ainsi, dans la perspective d'une exploitation documentaire, il n'est pas suffisant d'utiliser l'élément creator pour spécifier qu'il est question d'un auteur. S'agit-il d'une personne morale ou physique ? Ou alors d'une manifestation ? Si cette précision est connue et notifiée, des outils pourront l'exploiter et offrir des index de noms de personnes ou des classsifications des ressources.

Exemple 1. De l'enrichissement sémantique dans du texte
<para>
Les archives nous renseignent en premier lieu sur l’évolution de la propriété. La Corrée passe de la famille Savornin à la famille <persname>
<family value="Girard">Girard</family>
</persname>un peu après le tournant du siècle. Désirant fonder une chapellenie dans l’<geoname>
<placename>hôpital de Cadenet</placename>
</geoname>, dépendant de l’<geoname>
<placename>hôpital général Saint-Jacques d’Aix-en-Provence</placename>
</geoname>, Françoise de Beaumont lègue ses biens, dont la Corrée, à un de ses amis avec obligation pour lui de les vendre au profit de l’hôpital. <persname>
<given value="Henri">Henri</given>
<family value="Girard">Girard</family>
</persname> acquiert la Corrée le <event>
<date>
<day>20</day>
<month code="11">novembre</month>
<year>1709</year>
</date>
<description css="display:none">
<para>Henri Girard devient propiétaire de la Corrée.</para>
</description>
</event><resource role="archives">
<publisher>
<organization>
<orgname>
<orgtitle value="A.D. Bouches-du-Rhône">A.D. Bouches-du-Rhône</orgtitle> ; <orgdiv value="dépôt d’Aix-en-Provence">dépôt d’Aix-en-Provence</orgdiv>
</orgname>
</organization>
<collection>
<title>
<proper value="Fonds de l’hôpital général Saint-Jacques">Fonds de l’hôpital général Saint-Jacques</proper>
</title>
</collection>
</publisher>
<description role="notes">
<para>Acte reçu par Maître de Regina, notaire à Aix. Le testament de Mme de Beaumont, daté du 11 janvier 1707 est conservé en 20 H / B 64</para>
</description>
</resource>.
</para>

La notion de structuration sémantique en tant qu'élément filial découle de la structure hiérarchique des documents XML mais on peut encore aller plus loin et le schéma SDAPA en fait le pari. En effet, SDAPA est appelé à s'appliquer à des documents en grande partie rédactionnel. Or dans ce cas-là, la plupart de l'information est contenue dans des éléments de niveau bloc, du type paragraphe.

Les principaux éléments utilisables pour faire de l'enrichissement sémantique sont ceux du groupe Name : persname, orgname, geoname, event, term, topicname, markup.

3.3. référence <^>

Le schéma fournit tout un ensemble d'éléments pour gérer les références. Qu'il s'agisse de référence bibliographique ou à des documents figurés, notes de bas de page, ou des liens internes ou externes, ou encore vers d'autres parties du dossier électronique (index, glossaire). (voir guide sur les relations section références)

4. Les métadonnées <^>

4.1. Principe <^>

Le schéma SDAPA est en partie basé sur le Dublin Core<1>, modèle descriptif pour les métadonnées. Ses éléments sont donc utilisés pour codées ces informations particulières qui portent non sur la ressource décrite mais sur le document qui contient cette description. (voir la section métadonnées du guide du schéma)

4.2. Les éléments Dublin Core <^>

Les éléments Dublin Core<2> sont importants dans l'application du schéma SDAPA et donc il parait important d'éclaircir leur emploi. D'autant plus que le Dublin Core<3> étant un standard généraliste, son emploi n'est pas forcément évident pour tous les domaines. En effet, en dehors des définitions fournies par le Dublin Core pour chacun des éléments, leur application est en grande partie laissée à la libre appréciation des usagers. Aussi, dans la plupart des cas, l'usage de Dublin Core est-il accompagné d'un manuel qui définit plus précisément les règles d'utilisation, illustrées d'exemples.

Bibliographie

Quam, Eileen ; Minnesota Department of Natural Resources . - Minnesota Metadata Guidelines for Dublin Core Metadata. - August 2000 . - http://bridges.state.mn.us/bestprac/training.pdf.
AVEL - Metadata. - http://avel.edu.au/mdmanual/dcrelation.html.

Dans le cadre de la rédaction des guides, un certain nombre de problèmes ont été rencontrés, ce qui explique les raisons de ce développement. Les éléments litigieux du Dublin Core sont traités dans les sous-sections suivantes.

4.2.1. Coverage <^>

C'est à ce niveau que s'effectue le lien entre document et objet patrimonial décrit. En effet, l'élément coverage<4> permet de notifier la couverture de l'objet documentaire décrit, c'est-à-dire, dans le cas d'un document, ce sur quoi il porte. Or dans le contexte de la DAPA, un document se rapportera toujours à un objet patrimonial. Le lien est réalisé par l'intermédiaire de l'attribut uri, attribut commun dans le schéma, de coverage.

Exemple 2. Lien entre un document et un objet patrimonial
<coverage uri="meta_IA17000551.xml">
<place>
<geoname>
<placename>Raffinerie de sucre de la famille Creagh</placename>
<location>
<region role="region" scheme="index-region">Poitou-Charentes</region>
<region code="17" role="departement" scheme="index-departement">Charente-Maritime</region>
<locality code="17300" role="commune" scheme="insee">La Rochelle</locality>
<locality role="aire d'étude">La Rochelle centre</locality>
<locality role="cadastre">1976 EM 52 à 55</locality>
<addrline>29 à 37 rue Chef-de-Ville</addrline>
</location>
</geoname>
</place>
</coverage>
<type>dossier d'ensemble</type>

4.2.2. Source vs Relation <^>

Quelle est la différence entre les éléments source<5> et relation<6> du Dublin Core<7> ? Source n'est-il pas une relation particulière ? D'après les définitions des éléments fournie par le Dublin Core, cette thèse n'est pas absurde. Toute la nuance vient de l'appréciation de la force du lien entre la ressource décrite et la ressource secondaire.

Element Name: Source Label: Source
          Definition: A Reference to a resource from which the present
          resource is derived. Comment: The present resource may be
          derived from the Source resource in whole or in part.
          Recommended best practice is to identify the referenced
          resource by means of a string or number conforming to a
          formal identification system.
Element Name: Relation Label: Relation
          Definition: A reference to a related resource. Comment:
          Recommended best practice is to identify the referenced
          resource by means of a string or number conforming to a
          formal identification system.
Dublin Core Metadata Element Set, Version 1.1: Reference Description.

En fait, l'élément source offre la possibilité de donner les métadonnées d'une autre ressource que celle décrite, avec pour seule contrainte que les deux ressources soient liées par un lien de type dérivation, ce qui implique un lien fort. Mais du coup, quelle est la différence avec une relation du type isPartOf / hasPart ou isBasedOn / isBasesFor ?

Une solution consisterait à boycotter l'élément source au bénéfice de relation. Ou au contraire de valoriser l'usage de source pour mettre en valeur une ressource secondaire dont on souhaiterait que les métadonnées soient associées à celles de la ressource décrite. Ainsi, source serait l'élément utilisé pour préciser des métadonnées tandis que relation serait utilisé uniquement pour indiquer l'existence d'un lien entre deux ressources, lien que l'on peut qualifier, sorte de voir aussi. L'intérêt d'utiliser l'élément source est de pouvoir retrouver avec la ressource décrite aussi celles de la ressource "parent". Par exemple, il est intéressant de retrouver la description d'un périodique avec celle d'un article, d'un livre avec un de ses chapitres. Dans l'absolu, il faudrait utiliser conjointement les deux éléments source et relation, l'un pour les métadonnées et l'autre pour spécifier le lien. Et dans le doute, privilégier l'emploi de relation.

Dans les guides d'usage des éléments Dublin Core, les principaux usages recommandés pour l'élément source sont l'indication du document original numérisé ou alors le fait que les métadonnées notifiées apportent un plus lors d'une recherche.

En conclusion, chaque environnement d'utilisation doit définir ses propres règles en essayant néanmoins de respecter les conventions internationales pour favoriser l'interropérabilité.

4.2.3. Relation <^>

L'élément relation<8> permet de créer un lien ou de notifier un lien existant entre deux ressources. Un objet et son contenant, une oeuvre et sa copie... Dans le schéma, il est obligatoire de qualifier une relation, c'est-à-dire de préciser la nature de la relation existant. Cette contrainte est indispensable dans un contexte de gestion électronique de documents qui découle de l'utilisation d'un schéma pour l'édition et l'échange de documents. En effet les relations sont un élément essentiel. Or ce point n'est pas toujours suffisamment pris en compte et du coup ne permet pas facilement tout ce qu'il devrait. Le seul fait de dire qu'il existe une relation entre deux documents ne suffit pas. De quelle relation s'agit-il ? Connaître la nature de la relation permet d'appliquer le traitement adéquat. Image du terme relation dans le contexte des individus : "c'est une de mes relations" est une expression bien vague. Ne serait-il pas plus efficace de dire "c'est un de mes oncles ou l'un de mes collègues de travail, mon patron, un ami"; cette précision traduit plus précisément la nature et le dégré de relation. Car toutes les relations ne sont pas à mettre sur un même plan.

Or si l'on s'en tient au Dublin Core simple, on peut juste dire qu'il existe une relation entre deux ressources mais aucune indication sur la nature de ce lien. Le Dublin Core qualifié vient ajouter une couche en caractérisant la relation. Néanmoins, il appartiendra au métier d'établir sa propre liste de qualifiants, le schéma n'en contenant pas (voir la section sur les listes d'autorité du guide du schéma)

4.3. Usage du schéma <^>

4.3.1. Métadonnées <^>

4.3.1.1. Métadonnées d'un document <^>

Ces métadonnées apportent de l'information sur un document et non pas sur l'objet patrimonial auquel il se rapporte. Il s'agit notamment d'informations de gestion (date de création, auteur, type de document, droits, lien avec d'autres documents comme des voir aussi). Une grande partie de ces métadonnées pourra être générée automatiquement à partir du logiciel d'édition ou de génération des documents XML.

Avec le schéma SDAPA, les métadonnées d'un document sont contenues dans l'élément info, premier sous-élément de l'élément racine. Cet élément est disponible pour un certain nombre d'éléments du schéma SDAPA, il permet d'apporter des précisions de gestion ou d'indexation. Les métadonnées générales du document font l'objet du premier bloc info.Celui-ci est constitué d'une série d'éléments Dublin Core et éventuellement d'autres propriétés property. Les éléments Dublin Core<9> sont facultatifs et répétables à l'infini, tout comme dans la norme Dublin Core<10>.

4.3.1.2. Métadonnées d'un objet patrimonial <^>

Dans ce document, seules les métadonnées générales d'un objet patrimonial vont être présentées, celles-ci peuvent varier suivant la nature de l'objet patrimonial considéré. Ainsi cette section pourra se retrouver dans les guides métiers avec quelques variantes ou précisions.

Quelles sont les métadonnées relatives à un objet patrimonial et communes à tous les documents qui s'y rapportent ?

4.3.2. Rôle des attributs <^>

Le schéma comprend un certain nombre d'attributs dont quelques-uns sont particulièrement importants dans le cadre de la DAPA :

4.3.3. Traitement de certains types d'informations <^>

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 fonctions de feuilles de style (insertion de style de texte pour gérer la mise en forme du document et générer des tables des matières).

La première des règles d'application du schéma est de structurer les documents, c'est-à-dire répartir le texte dans des éléments sémantiquement signifiants dont la structure est fixée par le schéma :

  • de premier niveau : book | chapter | article | section | colophon | info | record | figure | bibliography | set

  • de second niveau ou de niveau bloc de texte : para | formalpara | literallayout | code | table | example | excerpt | figure | enumeration | sequence | set | glossary | calendar | procedure | faq | bibliography

Contrairement à un traitement de texte, le document n'est pas découpé en pages ; ceci est inutile dans un contexte de dossier électronique appelé à des restitutions variées (HTML, PDF, papier). La manière de concevoir les documents doit être repensée pour les répartir dans une arborescence de plusieurs fichiers afin d'éviter d'avoir des fichiers trop volumineux.

Voilà pour le traitement du texte, quant aux autres types d'informations, ils sont détaillés dans des guides particuliers :

4.3.4. Reprise de l'existant <^>

Une des grandes interrogations de l'utilisation du schéma SDAPA est comment va-t-il prendre en compte l'existant.

4.3.4.1. Cas des bases de données <^>

Dans le cas des bases de données, pour reprendre ou exploiter leur contenu, plusieurs solutions sont possibles :

  • un export simple : tous les champs de la base d'origine et leur contenu sont transférés vers les éléments name et value de property.

    Exemple 7. Exemple d'utilisation
    <property remap="fr/mcc/merimee:remp">
    <name>REMP</name>
    <value>{REMP}</value>
    </property>

  • un export "intelligent" qui nécessite l'intervention d'un humain au moins pour établir un tableau de correspondance entre les champs de la base et les éléments de métadonnées du schéma SDAPA. Le contenu de la base bénéficie donc de la structuration et de la sémantique offertes par le schéma.

  • un export rédactionnel qui fournit une vision sous la forme d'un article du contenu de la base de données. Cette méthode permet notamment la création de modèle de documents ou de documents prêts à diffuser directement ou après relecture.

    Exemple 8. Exemples d'utilisation

    • en Archéologie

    • pour les Espaces protégés

4.3.4.2. Documents numériques non XML <^>

Il est impensable de croire que tous les documents vont devoir être transformés en documents XML conformément au schéma SDAPA. Mais ces documents peuvent quand même être inséré dans un dossier électronique suivant différents niveaux de traitement :

4.3.4.3. Documents non numériques <^>

Dans le cas de documents n'existant pas en version numérique, il n'est évidemment pas possible de créer un lien vers le document. En fait, on se retrouve dans la même situation que dans un environnement tout papier. La seule manière de prendre en compte un document non numérique est une référence bibliographique qui contient toutes les informations nécessaires pour retrouver le document.

Voir le guide sur les références bibliographiques

5. Les relations <^>

Les relations étant un point particulièrement important dans le principe du dossier électronique, elles font l'objet d'un guide particulier.

La question des relations soulève un certain nombre de problèmes :

  • Qui dit relation entre des fichiers, dit problématique d'URL pérenne et donc organisation rigoureuse des fichiers et dossiers.

  • Qu'en est-il quand les documents sont créés par différents agents (institutions, acteurs diverses)? Est-il concevable de prévoir à la livraison d'une partie d'un dossier électronique par un agent extérieur que l'on rajoute des informations (url, métadonnées) ?

Certains éléments recoupent directement de la notion de relations. Ce sont link, relation, source, resource, note. De même, chaque élément disposant des attributs uri et id peut devenir cible ou origine d'un lien.

<1> http://www.dublincore.org/ (Dublin Core)

<2> http://www.dublincore.org/documents/dces/ (éléments Dublin Core)

<3> http://www.dublincore.org/ (Dublin Core)

<4> http://www.dublincore.org/documents/dcmi-terms/#coverage (l'élément coverage)

<5> http://www.dublincore.org/documents/dcmi-terms/#source (source)

<6> http://www.dublincore.org/documents/dcmi-terms/#relation (relation)

<7> http://www.dublincore.org/ (Dublin Core)

<8> http://www.dublincore.org/documents/dcmi-terms/#relation (L'élément relation)

<9> http://dublincore.org/documents/dcmi-terms/ (Les éléments Dublin Core)

<10> http://www.dublincore.org (norme Dublin Core)