Les relations

Une solution mise en pratique dans le traitement des exemples consiste à mettre en place une arborescence de fichiers sur le modèle suivant :

• un répertoire par dossier électronique, qui peut éventuellement contenir d'autres répertoires (cas où un dossier électronique est composé de dossiers)

• dans chaque répertoire, un fichier index.xml qui est en fait le sommaire des parties constituantes du dossier électronique, soit un document XML avec pour élément-racine contents

• un fichier meta.xml ou autre qui contient les métadonnées de l'objet patrimonial concerné. Cette structure n'est pas nécessairement réalisable pour tous les domaines et pour toutes les échelles. Dans le cas où cette solution se s'appliquerait pas, il faudrait que chaque document contienne de l'information sur l'objet patrimonial décrit (métadonnées minimales = nom, localisation, etc.) ce qui est déjà le cas actuellement pour les documents papier.

Mais à plus grande échelle, ceci ne tient plus sous cette forme. Par contre, l'idée d'avoir regroupées à un seul endroit et accessibles (ou du moins dont la référence univoque est accessible) des notices descriptives d'objet patrimonial est à retenir (entrepôts de notices d'objets patrimoniaux). En effet, pour être capable d'identifier tous les documents relatifs à un même objet patrimonial, il faut que celui-ci soit univoquement identifié (un identifiant, une URI, un nom et une localisation pour la lisibilité par l'humain, des descripteurs) et que chaque document ou dossier électronique qui s'y rapporte entretienne un lien avec lui (par l'attribut uri de coverage). Chaque notice principale d'un objet patrimonial (id_objetpatrimonial.xml) doit donc disposer d'une URI pérenne. Pour relier chaque dossier électronique ou document isolé à l'objet patrimonial dont il traite, il suffit de connaître un identifiant unique de cet objet et mieux l'URI (construit si possible à l'aide de l'identifiant unique). Ainsi tous les documents qui traiteront (information contenue dans coverage) d'un même objet seront identifiables.

A l'intérieur même d'un dossier, constitué de plusieurs parties et documents, et donc de plusieurs fichiers XML, un certain nombre de relations peuvent être définies :

• relations constitutives, principalement du document principal vers ses sous-documents constituants. On peut considérer qu'un dossier électronique est constitué d'un fichier principal qui joue le rôle de sommaire (équivalent de la chemise englobante du dossier) et qui annonce notamment ce que l'on va trouver à l'intérieur. Ce sommaire permet notamment d'ordonner les sous-parties.

  <contents>

  <!--l'ordre des sous-documents est fixé par celui des éléments <summary>-->

  <summary uri="uri du ss-doc1">

  <title>

  <proper value="{Titre du premier sous-document}">{Titre du premier sous-document}</proper>

  </title>

  </summary>

  <summary uri="uri du ss-doc2">

  <title>

  <proper value="{Titre du second sous-document}">{Titre du second sous-document}</proper>

  </title>

  </summary>

  </contents>

• navigation, liens entre les sous-parties : est-il intéressant de créer des relations précédent - suivant entre les sous-documents pour les ordonner ? De quelle pratique est-il plus intéressant de s'affranchir ? L'obligation de créer un sommaire ou de lier les sous-documents entre eux ? Dans le cas d'une modification de l'ordonnancement des fichiers (insertion, suppression d'une partie, inversion), il est plus facile de modifier l'ordre des entrées dans un table des matières contents que de devoir modifier, plusieurs fichiers sont à modifier les liens de navigation dans chacun des fichiers.

• renvois vers des index, autres parties du document principal (voir plus haut, voir cette section, etc.)

• mise en relation de ressources

Il est aussi possible de faire référence à des ressources externes (autres dossiers électroniques, documents). Ces relations sont d'un autre type :

• voir aussi

• relation du type reference pour pointer vers des ressources de référence

Dans un document, on peut vouloir naviguer entre ses différentes parties ou suivant le propos renvoyer directement à tel ou tel endroit du document. Ceci peut se faire par l'intermédiaire de l'attribut id au niveau de la cible (extrémité du lien ou ancre), présent dans tous les éléments, et de l'élément link et de l'attribut uri, autre attribut commun.

Exemple 1. Principe des liens internes

<!--Plus loin dans le document...-->

Les liens internes ne concernent pas uniquement des parties de texte. On peut aussi renvoyer à une illustration ou une ressource grâce aux éléments figure et resource qui peuvent s'utiliser comme link. Cela permet entre autre de faire des références ou des citations bibliographiques à la suite d'un propos ou de traiter les "voir fig. N". Toutefois, au lieu de faire uniquement des renvois qui supposent la réutilisation des références, il est aussi possible d'intégrer directement les métadonnées.

Exemple 2. Une référence bibliographique

<!--A un autre endroit dans le document, soit dans le texte, soit dans une biliographie, on devrait trouver...-->

Plusieurs types de références peuvent être faites dans un contexte rédactionnel : des références à des illustrations, des citations, des notes ou encore des références bibliographiques.

Les notions présentes dans le Dublin Core pour le traitement des relations se retrouvent dans de nombreux standards. Elles sont basées sur une typologie des relations qui semble capable de traiter un grand nombre de relations car très génériques. D'ailleurs elles constituent la liste de références pour qualifier les relations dans le schéma SDAPA et sont utilisés pour traiter les exemples. Aucune liste d'autorité n'est comprise dans le schéma, la seule contrainte imposée est qu'il faut qualifier la relation. Toute liberté est donnée aux utilisateurs de définir suivant leur contexte d'utilisation des listes particulières.

Type de relations de base

1. relation de type "historique", évolution de la ressource

2. tout/partie

3. références, citations

4. dépendance

Les qualifiants proposés pour l'élément relation du Dublin Core^<1> offrent une bonne base pour une liste d'autorité. Néanmoins certains termes supplémentaires seront sans doute nécessaire pour être plus précis. Voici la liste des termes qui peut servir de liste d'autorité générique, comme c'est le cas dans les exemples, pour l'attribut role de l'élément relation.

• isPartOf / hasPart pour préciser les parties physiques ou logiques.

• isVersionOf / hasVersion pour donner des informations sur l'évolution de la ressource. Exemple : autre édition d'une ressource.

• isFormatOf / hasFormat pour indiquer des ressources qui sont une autre représentation de la ressource décrite, même contenu intellectuel mais autre format.

• references / isReferencesBy pour des ressources associées, notion de renvoi.

• isBasedOn / isBasesFor pour des ressources dérivées du contenu intellectuel de la ressource décrite. Exemple : traduction, adaptation.

• requires / isRequiresBy pour indiquer la dépendance entre deux ressources

• conformsTo pour préciser un modèle de références

Voici des références d'autres listes dre'autorité possibles suivant le contexte.