Schéma AI - Spécifications fonctionnelles

Avertissement : Cette page est un espace de travail pour la mise en forme des spécifications fonctionnelles du schéma AI (Archives Institutionnelles).

Auteurs : Jean-François Lutz (Université Henri Poincaré - Nancy 1) et Axel Pfalzgraf (INSA Lyon)

Dates : Juillet-Octobre 2008

Introduction

  • A quoi servent les spécifications fonctionnelles ?

Dans le cadre de la mise au point d’un profil d’application du DC le rôle des spécifications fonctionnelles (functional requirements) est de « décrire les fonctions pour lesquelles est conçu le profil d’application et celles qui n’entrent pas dans son champ d’application. Les spécifications fonctionnelles constituent la base sur laquelle évaluer le profil d’application pour sa cohérence interne et pour donner une indication sur sa pertinence pour un usage donné »

Si l’on se réfère au schéma du DCAP, les spécifications fonctionnelles constituent le socle sur lequel doivent se construire tous les autres composants du profil d’application : modèle entités-relations ; description set profile (DSP) et recommandations d’usage. Il convient donc d’y apporter une attention particulière dans la mesure où elles déterminent la suite du travail.

Les spécifications fonctionnelles permettent également de revenir à tout moment, si nécessaire, à l’expression des besoins de l’établissement et de l’usager final (chercheur, étudiant) : il s'agit donc d'un ensemble de principes directeurs suffisamment souples pour être adaptables à divers contextes.

  • Quelle méthodologie ?

1. Le « socle » de SWAP (Scholarly Work Application Profile)

Plutôt que de mettre au point une lourde méthodologie de recueil des besoins, il a semble plus judicieux de nous fonder sur le constat qui avait été dressé en Grande-Bretagne au courant de l’année 2006 alors que le SWAP était en projet.

L’équipe du projet SWAP est partie du constat, assez largement partagé, des limites du format Dublin Core non qualifié pour l’échange de métadonnées entre systèmes hétérogènes ainsi que le spécifie le protocole OAI-PMH. Ces limites sont patentes pour plusieurs types d’informations :

  • termes normalisés, utilisation de vocabulaires contrôlés et autres listes d’autorité,
  • homonymie des auteurs,
  • dates,
  • versionnage des documents…

2. Une adaptation au contexte et aux besoins français.

Le SWAP a été conçu dans un contexte bien particulier : il s’agissait originellement d’une commande du JISC qui souhaitait pouvoir disposer de données descriptives uniformisées afin d’enrichir le portail académique Intitute. Certaines des spécifications fonctionnelles sont donc directement liées à cette finalité d’agrégation des données, mais elles peuvent conserver leur pertinence dans le contexte français d’interaction entre les archives institutionnelles et HAL.

S’il est possible de reprendre pour le compte d’AI une grande majorité des SF énoncées pour SWAP, certains ajustements, précisions ou compléments ont été nécessaires.#

  • Quels principes directeurs pour les spécifications fonctionnelles ?

Les spécifications fonctionnelles du profil AI ont été regroupées dans deux grandes parties :

  • les spécifications concernant la prise en compte de l'environnement institutionnel, informatique et technologique
  • les spécifications se rapportant directement au traitement ; à la recherche et à l'exploitation des documents numériques qui seront décrits à l'aide du schéma AI.

Par ailleurs, deux principes directeurs ont guidé la rédaction de ces spécifications :

  • la nécessité, pour le profil d'application, de fournir un jeu de métadonnées cohérentes enrichi par rapport au Dublin Core
  • la nécessité, pour le profil d'application, d'harmoniser les pratiques dans le choix des métadonnées à renseigner et dans la manière de les renseigner (recours à des listes d’autorité, cf. recommandations d'usage)

Spécifications fonctionnelles

Le Profil d'Application et son environnement

Interopérabilité.

1. Permettre des échanges ascendants et descendants avec HAL sans perte de qualité des données. Le schéma AI doit être structuré de telle manière à ce qu’il soit totalement compatible avec le format pivot AO.fr qui doit servir à l’interconnexion entre HAL et les archives locales.

2. Favoriser l'intégration et l'interaction au sein du Système d'Information global de l'établissement Le schéma AI doit permettre un dialogue et des échanges de données avec les autres applications constituantes du SIG, par exemple les applications de gestion du personnel ou de la recherche.

Conformité aux standards

3. Recours aux espaces de nom existants Pour l'ensemble des métadonnées qui seront retenues, le recours à des espaces de nom existants et éprouvés devra être privilégié. La création de métadonnées propres ne doit intervenir qu'exceptionnellement.

4. Conformité au Singapore Framework

Adaptabilité

5. Ouverture aux évolutions du web Le schéma AI doit être compatible avec les évolutions potentielles du web à moyen terme. Cette compatibilité, notamment avec le futur "web sémantique" est en partie assurée par le fait que le Description Set Profile se fonde sur le modèle abstrait du Dublin Core, lui-même inspiré du format RDF.

Le Profil d'Application et les documents décrits

Fonctionnalités de recherche

6. Permettre un feuilletage « browse », une recherche ou un filtrage de la base à partir de n’importe lequel des éléments d’indexation (mot-clé, auteur, date, éditeur, titre de la revue, de la conférence ou de la publication, institution d’affiliation, type de ressource et statut scientifique (peer-review))

7. Permettre l’identification de la dernière version – ou de la version la plus adéquate – et faciliter la navigation entre les différentes versions d’un article ( n versions en préprint, postprint, corrections ultérieures…).

8. Etre compatible avec le format OpenURL Context Objects Cette compatibilité doit permettre l'utilisation de résolveurs de liens à partir de l'interface d'affichage des résultats de recherche.

9. Implémenter une méthode univoque pour identifier les ressources en plein texte.

10. Faciliter l’identification des ressources en accès libre. (Cf. spécification fonctionnelle n°16)

Identification des auteurs et des affiliations

11. Permettre l’identification des organismes financeurs et indiquer le code du projet financé.

12. Prévoir le recours à des formes d’autorité pour les noms propres présents dans la notice (auteur, institution, financeur…). Cela suppose entre autres de prévoir des champs spécifiques ainsi qu'un typage des identifiants numériques (Cf. recommandations d'usage).

13. Permettre l'expression de plusieurs niveaux d’affiliation de l’auteur. Ces divers niveaux, que le profil d'application n'a pas vocation à figer (cet aspect renvoie à la question des signatures institutionnelles), doivent permettre une exploitation fine des références d'affiliation, que ce soit pour la recherche documentaire ou pour le dialogue avec des applications de gestion de la recherche.

Gestion des dates

14. Etre en capacité de gérer quatre formes de dates. Date à partir de laquelle le document est librement accessible (available), date de modification pour l’identification de la dernière version (modified), date de publication (published), date de création pour les documents plus anciens et ajoutés dans l’archive de manière rétrospective (created).

Gestion des droits

15. Encadrer juridiquement les pratiques, et donc garantir le respect du droit d'auteur et des droits voisins.

16. Permettre une gestion souple des droits liés aux documents décrits. Cette gestion des droits s’applique à la fois à la description des entités détentrices des droits et aux usages autorisés ou proscrits.

Sauf mention contraire, le contenu de cette page est protégé par la licence Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.