Compte-rendu de réunion

Groupe de travail sur les archives ouvertes

Compte-rendu de réunion

11 avril 2008

Université Paris Descartes, Centre Universitaire des Saint-Pères.
Etaient présents :

• 
  Claude Bagnol, CRI, Montepellier-I
  
• 
  Thierry Bédouin, CRI, Rennes-I
  
• 
  Anne-Claire Bernaudin, SCD, Rennes-I
  
• 
  Céline Bissler, CRI, Nancy-I
  
• 
  Fabrice Blondeau, BIUP
  
• 
  Rachel Creppy, SDBIS
  
• 
  François Dubosclard, SCD, ENS Lyon
  
• 
  Camille Espiau, SCD, Lyon-II
  
• 
  Hélène Garriaux, SCD, Paris-V
  
• 
  Anne Giraudon, SCD, ENSSIB
  
• 
  Guillaume Hatt, Ecole des Chartes
  
• 
  Nolwen Huet, SCD, INSA Lyon
  
• 
  Jean-François Lutz, SCD, Metz
  
• 
  Annaïg Mahé, URFIST Paris
  
• 
  Eric Messant, CRI, Lille-I
  
• 
  Axel Pfalzgraf, SCD, INSA Lyon
  
• 
  Laurent Pilet, CRI, Clermont-Ferrand
  

• 
  Martine Pochard, SCD, Franche-Comté
  
• 
  Marie-Luce Rauzy, SCD, Nice
  

• 
  Florence Rivière, ENPC
  
• 
  Gaid Thirion, SCD, Rennes-II
  
• 
  David Varenne, CRI, ENSMSE
  
• 
  Jean-Baptiste Vu Van, SCD, Troyes
  
• 
  
  

• 
  Etaient excusés : Emilie Barthet (Couperin), Daniel Bourrion (Angers), Marie-Claire Bres (AMUE), Caroline Bruley (Lyon-I), Sophie Desseigne (Bourgogne), Claire Douady (Limoges), Vincent Hachard (Strasbourg-III), Jean-François Jal (Lyon-I), Jérôme Kalfon (Paris-V), Jean-Marie Le Béchec (INP Toulouse), Yann Nicolas (ABES), Laurent Perrillat (Grenoble), Marie-Thérèse Rebat (SDBIS), Emilie Romand-Monnier (Clermont-Ferrand), Anne Texier (ENSMSE), Nathalie Watrin (Versailles).
  

Début de la réunion à 9 h 40

A. Informations générales :

1. 
   Nouveau participant au GTAO :
   

• 
  Jean-Baptiste Vu Van, bibliothécaire à l’Université de Technologie de Troyes, rejoint le GTAO.
  

2. 
   Fonctionnement du GTAO :
   

• 
  Dates de réunion.
  

Trois dates sont à retenir d’ici les vacances d’été :

• 
  14 mai : réunion du groupe Communication ;
  
• 
  10 juin : réunion du groupe Métadonnées ;
  
• 
  11 juin : réunion de l’ensemble du GTAO.
  

• 
  Réunion du comité de pilotage
  

Le comité de pilotage du GTAO s’est réuni le 15 février dernier afin de

• 
  définir le calendrier et les objectifs du GTAO pour le reste de l’année 2008
  
• 
  mettre au point les propositions de Couperin en vue de la continuation du protocole d’accord.
  

Le compte-rendu est en ligne sur le wiki.

• 
  Besoins du groupe Communication
  

Camille rappelle que le groupe Communication souhaite disposer de documents provenant des plusieurs établissements pour alimenter le guide pour un projet d’Archive Ouverte coordoné par Florence Rivière.

3. 
   Divers :
   

• 
  Progrès de l’Open Access.
  

• 
  Les quinze premiers jours d’avril ont vu deux universités britanniques décider, à l’échelle de l’institution, d’une obligation de dépôt en archive ouverte des publications scientifiques : Southampton et Stirling.
  

• 
  A signaler un document « politique » de première importance publié conjointement par SPARC et Science Commons intitulé « Open Doors and Open Minds: what faculty authors can do to ensure Open Access to their work through their institution ».
  

Partant de la récente décision prise par Harvard, ce « white paper » définit un modèle optimal de politique d’établissement : obligation stricte de dépôt dans une archive ouverte institutionnelle + obligation (à laquelle il est possible de déroger exceptionnellement) pour l’auteur de signer une « licence d’université » transférant un certain nombre de droits à l’établissement.

• 
  Devenir du protocole d’accord.
  

• 
  Il est certain que le protocole d’accord ne sera pas reconduit. La CPU souhaitait s’engager plus fortement dans le dispositif en vue d’aboutir à un réel co-pilotage de la plateforme nationale. Le CNRS n’a pas donné suite à cette proposition.
  

Une réunion du CoST est prévue le 16 mai pour procéder à un bilan du fonctionnement des instances mises en place par le protocole.

• 
  Les formations à HAL organisées par l’AMUE se poursuivent.
  

• 
  La journée d’étude de la CPU sur les archives ouvertes, initialement prévue au mois de mars, a été reportée au 18 juin. Elle s’adresse en priorité aux présidents d’universités et aux VP recherche.
  

B. GRAAL.
Profitant de la présence de trois collègues du GIS GRAAL (Céline Bissler, Eric Messant et Laurent Pilet) qui ont répondu à l’invitation du GTAO, le reste de la matinée est consacré à la présentation du logiciel de gestion de la recherche GRAAL et à des échanges sur ses fonctionnalités de recensement des publications scientifiques.

1. 
   Commentaire de la présentation (disponible sur le wiki).
   

Diapositive 5

• 
  Comité de pilotage en cascade :
  
  • 
    GIS
    
  • 
    GIS + AMUE
    
  • 
    GIS + AMUE + autres partenaires
    
• 
  Comité de projet (dirigé actuellement par Grenoble 1)
  
• 
  Equipe fonctionnelle : constituée des gestionnaires des services de recherche des six établissements du GIS.
  
• 
  Equipe opérationnelle : une équipe par membre du GIS.
  

Depuis le 1^er janvier 2008, gestion du support (doc et déploiement) par l’AMUE. Support géré par les groupes fonctionnels et techniques à partir de la plateforme mise en place à l’AMUE.

Diapositive 10

La base de données de GRAAL et l’application peuvent être mono ou multi établissement (encouragement des développeurs à gérer en multi établissement si plusieurs établissements d’un même réseau souhaitent installer GRAAL ; actuellement c’est le cas à Grenoble et à Clermont-Ferrand).

La recherche est affectée dans GRAAL, il n’y a pas de reprise d’une saisie dans une autre application ou d’automatisation possible (les structures d’HARPEGE ne sont pas correctes et ne peuvent pas être réutilisées : leur structure est en arborescence descendante : une université, des UFR, des labos, alors qu’un labo peut également appartenir à des UFR de différents établissements ou à des organismes de recherche).
Il n’existe pas de webservices proposés par Apogée ou Harpege pour les données des thèses.
Diapositive 11

En vert : structures administratives

En bleu : structures de recherche
Remarque : dans la structure proposée, les écoles doctorales peuvent être rattachées aux PRES en parallèle du rattachement des unités de recherche aux établissements.

Diapositive 12

* : un accès particulier est proposé aux Directeurs et aux secrétaires identifiés dans les données saisies.

Le système d’affectation du personnel est différent selon les établissements, la gestion d’équipe est peu (ou pas) présente dans HARPEGE, d’où la reprise d’information d’HARPEGE mais un traitement manuel pour déplacer les personnes.
Les échanges avec les applications HARPEGE et APOGEE se font par webservices, les informations sont récupérées en direct (à part quelques unes qui sont stockées pour améliorer les temps d’affichage des listes).
Diapositive 15

L’authentification peut se faire sur 3 niveaux

• 
  annuaire GRAAL
  
• 
  annuaire LDAP
  
• 
  authentification CAS
  

à terme elle fonctionnera également avec un ENT
Diapositive 16

Le CNRS et l’INSERM sont fournisseurs d’information sur les personnels pour GRAAL

Une demande de webservices a été faite au CNRS depuis 2004-05 sans concrétisation. La démarche actuelle est d’importer de Labintel dans HARPEGE le personnel CNRS pour l’inclure dans les labos.
Avec le MENESR  remontée SIREDO.
Avec HAL  les développeurs GRAAL sont en contact direct avec le responsable du développement (Laurent Capelli)

Remarque : les webservices proposés par HAL sont modifiés continuellement. Se pose également la question des nomenclatures utilisées.

Avec ORI-OAI  des contacts étroits ont été noués en vue d’un rapprochement des deux projets dans le cas d’établissements ayant retenu ces deux applications. Dans cette perspective l’apport de GRAAL porterait sur les données structurées issues du volet recherche du SI et l’apport d’ORI concernerait le workflow et la dimension de gestion du patrimoine numérique de l’établissement.

Plusieurs schémas d’interaction entre GRAAL, ORI-OAI et HAL sont actuellement à l’étude.

2. 
   Gestion des publications scientifiques dans GRAAL (diapositive 17).
   

La récupération des informations de HAL s’effectue par moissonnage des publications avec tables de correspondances pour les Unité de Recherche (UR) (dans HAL, la saisie de cette information est laissée libre à l’auteur, d’où la présence pour une même UR de plusieurs appellations).

Remarque : dans HAL, le champ auteur est un champ en texte libre qui liste les auteurs (structuration pour différencier nom et prénom et rattachement possible à des labos, mais pas de rattachement à une identification de la personne).
Le schéma présenté correspond à un nouveau développement qui proposera le dépôt de GRAAL vers HAL (livré dans la nouvelle version pour mi-fin avril). Le moissonnage de HAL sera conservé, puisque les auteurs ont toujours la possibilité d’aller déposer directement dans HAL et restera la source d’information pour la gestion des publications.

Les métadonnées créées dans GRAAL sont conservées et rattachées à l’identifiant HAL. Il y a donc 2 stockages des métadonnées. Ce sont les données de GRAAL qui sont utilisées pour faire les indicateurs et non celles moissonnées de HAL.

GRAAL ne gère pas de système de workflow, il n’y a donc pas de validation des dépôts effectués par un labo par exemple. La seule différence entre HAL et GRAAL vient de la possibilité de revenir sur son indexation avant la validation finale.
Remarques :

• 
  Le dépôt d’une nouvelle version écrase les informations dans GRAAL (l’application ne gère toujours que la dernière version uniquement), HAL gère l’historique de son côté.
  
• 
  Toutes les publications présentes dans GRAAL sont déposées dans HAL
  

La chaîne de publication dans GRAAL :

• 
  saisie des métadonnées (1)
  
• 
  saisie des auteurs (2)
  
• 
  dépôt des fichiers associés (3)
  
• 
  récapitulation
  
• 
  envoi à HAL (4)
  

(1) Saisie des métadonnées

GRAAL propose un formulaire de saisie « unique » (pas de gestion de workflow ou de possibilités d’action par plusieurs acteurs, par contre GRAAL permet de revenir sur sa saisie avant validation (contrairement à HAL)), qui est dynamique (il propose différents champs selon le type de publication et le domaine de la publication). La construction de ce formulaire se fait en fonction de listes de champs envoyés par HAL.

Les référentiels proposés par HAL sont consultables et utilisables mais ne sont pas modifiables ou « complétables » à partir du formulaire.
(2) Saisie des auteurs

Cette saisie se fait à partir des référentiels de GRAAL. Les recherches proposées sont :

• 
  par nom (pour les personnes qui ont un labo déclaré dans HAL),
  
• 
  par labo,
  
• 
  par partenaire
  
• 
  ou par co-auteurs favoris.
  

L’attachement au laboratoire d’affectation est automatique à partir du choix d’un auteur (différence avec HAL, où la saisie de l’association auteur/labo est manuelle  possibilités de se tromper).
Un autre formulaire permet d’ajouter des co-auteurs n’appartenant pas à ce référentiel, avec validation de la non-existence de la personne ajoutée dans GRAAL.
Comme HAL le propose, GRAAL permet à un auteur d’être rattaché à deux labos.
GRAAL propose un formulaire de saisie pour créer de nouveaux labos dans HAL (en empêchant la saisie manuelle et en proposant ce formulaire, GRAAL évite de continuer les dérives sur les noms de labo). Cette demande de création est ensuite envoyée par webservice à HAL.

Remarque : le nom du labo sert de clé d’identification dans HAL.

HAL propose (partie administration) de remplacer les instances de labo par un nom « unique » dans l’ensemble des publications.
(3) Dépôt des fichiers associés et (4) envoi à HAL

Un répertoire local doit être créé sur un serveur web (pour avoir accès au HTTP) pour le stockage des fichiers. Cette adresse est transmise à HAL en même temps que les métadonnées, par webservice. HAL vient ensuite récupérer par téléchargement HTTP la ressource.

Il est possible d’envoyer également les métadonnées vers ArXiv. HAL indiquait précédemment que ce n’était pas possible parce qu’il n’y aurait pas de communication directe à la 1^ère application en cas de refus du dépôt par ArXiv. Pour GRAAL, remontée supposée des retours d’ArXiv par l’intermédiaire de HAL.
Il est possible de déclarer un délai avant publication. Dans ce cas, les métadonnées et la ressource ne seront proposées à HAL qu’au bout de ce délai.
Les fichiers peuvent être gardés ou non au choix de l’établissement par GRAAL.
Lorsqu’un document est envoyé à HAL, une validation du document est faite par le CCSD. Celui-ci informe par webservice du résultat : il vient modifier par POST (webservice possible) les données informant la validation ou non du document.

3. 
   Discussions et échanges.
   

• 
  Que se passe-t-il, au moment de la saisie des informations sur l’article, lorsque l’un des auteurs est membre d’un laboratoire extérieur à l’établissement ? Il est nécessaire pour tous les auteurs d’être rattaché à une structure existante dans GRAAL.
  

• 
  Données conservées par GRAAL sur les publications :
  

• 
  titre
  
• 
  auteurs
  
• 
  type de publication
  
• 
  discipline et mots-clés éventuels
  
• 
  lien vers HAL
  

• 
  Pour les thèses, les informations sont récupérées depuis Apogée après saisie par les scolarités.
  

• 
  GRAAL ne dispose pas de liens avec les applications financières pour l’instant. La réflexion est en cours dans le cadre du déploiement de SIFAC.
  

• 
  Modèle économique de GRAAL : développement par six établissements et ticket d’entré demandé pour les établissements utilisateurs (aux environs de 10 000 €).
  

• 
  GRAAL ne dispose pas de fonctionnalités de gestion de workflow (validation à plusieurs niveaux…)
  

• 
  Dans la mesure où les développements de GRAAL sont orientés « services », l’application est capable de s’interconnecter avec des logiciels tiers. A l’heure actuelle des projets sont en cours d’une part avec ORI-OAI pour la partie de gestion des publications scientifiques et d’autre part avec des outils de valorisation de la recherche.
  

3. 
   Travaux des groupe thématiques :
   

Groupe « Communication »

Présents : Rachel Creppy, François Dubosclard, Camille Espiau, Nolwen Huet, Florence Rivière, Gaid Thirion, David Varenne, Jean-Baptiste VuVan
Excusés : Emilie Barthet, Monique Joly, Annaig Mahé, Daniel Bourrion, Marie-Claire Bres, Julien Sicot


Ordre du jour

• 
  Matin : présentation de GRAAL en groupe plénier
  
• 
  Après-midi :
  

1. FAQ juridique

2. FAQ stratégique

3. Site web AO et « guide pour un projet AO »

4. Organisation des travaux du groupe et calendrier

Préambule :

Rappel des prochaines dates du GTAO

• 
  14 mai : groupe communication seul
  
• 
  11 juin : groupe communication + métadonnées
  

1. 
   FAQ juridique
   

L'après-midi a été consacrée à la validation de la FAQ juridique. La FAQ avait déjà été amendée par les membres du groupe sur le Wiki du GTAO, pour alimenter la réflexion.
Elle sera prochainement mise en ligne sur le site Couperin/AO.

FAQ juridique Version validée le 11/04/2008 1. Du point de vue juridique, que doit-on prendre en compte si l'on veut déposer un document dans des archives ouvertes? Vous devez impérativement : -Avoir l'accord de chaque co-auteur pour déposer le document dans une archive ouverte -Vous renseigner sur la politique de publication de votre organisme en particulier pour la confidentialité -Vous informer des règles retenues par l'archive ouverte pour le type de document que vous souhaitez déposer -Respecter le cas échéant les clauses des contrats que vous avez signés avec l'éditeur de la publication et les financeurs de votre recherche Attention ! soyez vigilants au moment du choix de votre éditeur et de la signature de votre contrat (lien vers la Toolbox de Surf et vers Sherpa). Vous pouvez aussi obtenir une autorisation spécifique des ayants-droits. 2. Je n'ai signé aucun contrat avec mon éditeur, puis-je déposer ma publication dans l'archive ouverte ? "Si aucun contrat écrit de cession de droits n’a été conclu, vous êtes libre de le déposer après la première publication. Néanmoins dans le cadre d’une relation loyale, informez votre éditeur." Source : CNRS - SG - DAJ : propriété intellectuelle - droits d'auteur, disponible sur : http://www.sg.cnrs.fr/daj/propriete/droits/droits7.htm 3.Le dépôt dans une archive ouverte modifie-t-il les droits des auteurs? Le dépôt dans une AO ne modifie pas les droits. Seul l'auteur décide s'il abandonne ou s'il transfère ses droits patrimoniaux par des contrats ou des licences d'utilisation (Creative Commons par exemple). 4.Quelle est la différence entre les droits de l'auteur et les droits de l'éditeur ? L'auteur a des droits moraux et matériels dits patrimoniaux; l'éditeur a des droits surtout patrimoniaux qui lui sont concédés par l'auteur ou qui naissent du travail éditorial réalisé sur l'article, par exemple sa mise en forme. Le cas échéant, L'auteur doit respecter les contrats qu'il a passés avec l'éditeur et la politique éditoriale de l'établissement dont il dépend. 5. Dans des archives ouvertes, quels droits et responsabilités ai-je sur mon document? L'auteur conserve tous ses droits et il s'engage à : -Ne pas demander le retrait du document déposé dans l'archive ouverte, afin qu'elle garantisse, entre autres, une citabilité fiable et pérenne -Respecter les clauses des contrats signés, par exemple avec l'éditeur. Pour connaître les droits conservés par les auteurs dans les contrats proposés par les éditeurs anglo-saxons: lien vers Sherpa/Romeo 6. Mon document déposé dans des archives ouvertes peut-il servir pour prouver l'antériorité de la découverte d'un résultat? - Lors d'un dépôt dans une AO, le système informatique va enregistrer automatiquement la date de ce dépôt. En cas de litige, le tribunal retiendra les éléments de preuve d'antériorité en fonction de règles complexes, notamment en ce qui concerne les preuves informatiques. Renvoi partie IV-question 2 7. Un co-auteur peut-il refuser que le document soit déposé dans l'archive ouverte? -Oui, car tout auteur détient un droit moral qui ne peut lui être enlevé. L'accord de chaque co-auteur est donc indispensable pour pouvoir déposer dans une archive ouverte. -Toutefois, le simple référencement est toujours autorisé.

2. 
   FAQ stratégique
   

Seules une ou deux questions ont pu être validées.

Il est convenu de procéder de la manière suivante d'ici la prochaine réunion : la version de travail de la FAQ stratégique reste accessible sur le Wiki du GTAO, et chaque membre doit l'amender avec ses initiales, en proposant (c'est à dire en reformulant entièrement, pour éviter trop d'annotations dans la version initiale) une nouvelle définition à la question, si cela est nécessaire.

Ce travail doit être effectué avant le 14 mai, date de la prochaine réunion du groupe communication.

3. 
   Site web AO et « guide pour un projet AO »
   

Ce point n'a pas pu être abordé.

Toutefois, nous avons à nouveau lancé un appel à l'ensemble des participants du GTAO pour récolter des documents qui serviront à alimenter le « guide pour un projet AO »

Florence Rivière proposera une synthèse des documents reçus lors de la prochaine réunion.

4. 
   Organisation des travaux du groupe
   

• 
  Chartes déontologiques :
  

Rachel Creppy et Axel Pfalzgraf feront une synthèse de leurs avancées sur ce point lors de notre prochaine réunion. Toutefois, il faudrait que d'autres collègues puissent se joindre à euxpour mener à bien ce travail : un nouvel appel à contribution a été lancé auprès des collègues des deux groupes.

• 
  Zoom établissement :
  

Le projet de « Zoom établissement » a dû être remanié en raison d'un manque de participants et d'un délai de mise en oeuvre trop court.

Il est convenu que le choix des établissements (au nombre de deux) ainsi que la méthodologie à suivre, devront être finalisés avant l'été. Le Zoom en lui-même devra être terminé à la fin de l'année civile 2008, afin de pouvoir présenter les résultats lors de la journée d'étude de janvier 2009.

En raison de diverses absences, le groupe enquête a impérativement besoin de collègues supplémentairespour travailler sur le « Zoom ».

Groupe « Métadonnées »

Le groupe a réfléchi au nom à donner au schéma en cours de définition. Le choix s’est porté sur « Archives Institutionnelles » (= AI) :

• 
  AI-L  pour le schéma présentant une structure linéaire,
  
• 
  AI-A pour le schéma présentant une structure arborescente.
  

I. Nature et vocation du schéma

Le début de la réunion a été consacré à une réflexion générale sur la nécessité de définir un schéma qui, tout en étant riche en métadonnées, réponde en permanence aux contraintes suivantes :

• 
  Etre adoptable par n'importe quelle application
  
• 
  Etre réductible à ao.fr
  
• 
  Etre réductible à oai_dc
  
• 
  Dialoguer avec EAP
  

Schématisation de ces contraintes :

AI

ao.fr

EAP

oai_dc

Fabrice Blondeau avance qu’en outre un schéma trop complexe sera plus difficile à maintenir.

 Il faut donc privilégier un schéma standard relativement simple qui pourra cependant être complété pour aboutir à une structure plus complexe, de type arborescent (cf. notions FRBR).

Yann Nicolas rappelle l’intérêt du Dublin Core Abstract Model (DCAM) qui nous aidera à résoudre un grand nombre de difficultés.

En outre, il met fortement l’accent sur la notion de profil d'application du DC qui repose en partie sur le DCAM.

Le principe du profil d'application est de permettre d'utiliser ensemble des métadonnées issues de plusieurs standards.

Par exemple : A propos de notre intention de gérer à 2 niveaux les mentions de responsabilité (cf. dc.creator du DC et notion de « marcrelator » dans EAP et dans MODS), ce n’est pas au niveau du schéma que cela se gère (ce n’est pas une question de syntaxe) mais dans le profil d’application, dans la définition des termes et des règles adoptées.

Nous avons ensuite discuté du niveau FRBR auquel le schéma linéaire pourrait se fixer. Yann nous a expliqué que le schéma linéaire ne décrirait qu'un seul niveau FRBR.

L'idée qui avait émergé était alors de se fixer au niveau de la manifestation, comme le fait le MARC. Mais compte tenu du fonctionnement de HAL (voir + bas), cela paraît moins évident...

Conclusion de la réflexion :

Pour AI-L, 3 axes doivent guider nos réflexions :

• 
  la liberté que nous procure le principe des profils d'application,
  
• 
  la description se situe comme dans HAL au niveau manifestation,
  
• 
  nous devons prendre en compte nos besoins supplémentaires par rapport à ao.fr.
  

Pour AI-A, des pistes :

Dans le groupe de travail ORI-OAI, le groupe technique a envisagé de ne construire l'arborescence qu'à l'aide d'un jeu de relations, chaque fiche de métadonnées, à quelque niveau FRBR qu'elle se situe, reprenant l'ensemble des métadonnées (pas de répartition des MD par niveau FRBR).

Mais Yann Nicolas pense que AI-A devrait pouvoir décrire un arbre FRBR complet, avec répartition des métadonnées suivant les différents niveaux FRBR.

Le schéma linéaire doit être « conscient » du schéma arborescent.  En contrepartie : le schéma FRBR doit pouvoir redescendre à 1 format linéaire. 

2. 
   Le vocabulaire
   

Parallèlement se pose la question du choix du vocabulaire  de base. Le Dublin Core qualifié sera privilégié mais la référence à d’autres espaces de noms permettra de recourir également à des éléments issus d’autres schémas (EAP, MODS, METS, etc.).

Là encore, le profil d’application permettra d’exprimer l’intégralité des éléments dans le DC.

III. Relecture du tableau

Voir la dernière version mise à jour par Fabrice Blondeau.
Quelques points cependant méritent un développement ici :

1. 
   Bibliographic Citation :
   

Pour décrire les références bibliographiques des document dans lesquels sont hébergés les ressources (journals, revues), le groupe a retenu le DCTERM « Bibliographic Citation » du Dubin Core (repris dans EAP). Les DCTERMS ne sont pas autorisés dans l’OAI-PMH. Mais on pourra le traduire en OAI-DC. Voir la documentation sur le mapping de EAP vers le DC simple, pour « Bibliographic Citation » :

• 
  « Use the value string as the value string in a dc :relation statement in the simple DC description about the ScholaryWork ».
  
• 
  “Use the value string as the value string in a dc :relation statement in the simple DC description about each of the copies associated with this expression”.
  

http://www.ukoln.ac.uk/repositories/digirep/index/Mapping_the_Eprints_Application_Profile_to_Simple_DC)

2. 
   Modèle FRBR et HAL :
   

En abordant la MD « identifiant de l’œuvre », la question s’est posée du niveau auquel se situe HAL pour son « unité documentaire ». L’expression choisie semble évoquer « l’œuvre ». Mais en fait, HAL se situe plutôt au niveau de l’expression avec de surcroit une confusion entre d’une part œuvre / expression et d’autre part entre expression et manifestation…

Par exemple, impossible de distinguer une version qui serait une traduction de la ressource (niveau expression) d’une version qui ne changerait de la 1^ère que par son format (niveau manifestation : 1 PDF et 1 HTML).
HAL attribue à chaque unité documentaire un identifiant unique formé d’un préfixe dépendant de l’interface ayant servi au premier dépôt et d’un suffixe composé d’un série de chiffres (par exemple : hal-00150206 ou bien halshs-00149992) auquel on ajoute le N° de version : ex. hal.archives-ouvertes.fr:halshs-00261709_v1.

L’identifiant HAL porte à priori sur un objet « œuvre / expression confondues » :

S’il faut se calquer sur HAL  dans notre schéma, c’est donc à ce niveau que l’identifiant de l’œuvre devra être renseigné.
Précisions sur les fichiers déposés dans HAL 

• 
  Au cours d’un même dépôt, on peut joindre jusqu’à 5 fichiers. Ces fichiers peuvent recouvrir différentes réalités :
  

1. 
   Un PDF très lourd scindé en plusieurs fichiers,
   
2. 
   Des fichiers de différentes natures : un PDF et une vidéo,
   
3. 
   Plus rarement à priori : plusieurs formats d’un même document (PDF, HTML, LateX, etc.).
   

• 
  Dépôt ultérieur d’une nouvelle version : il s’agit apparemment le plus souvent d’une version mise à jour, augmentée du premier document déposé. Dans ce cas, le déposant doit renseigner l’identifiant du 1^er dépôt.
  
• 
  HAL ne diffuse que la dernière version déposée !
  

(Cette partie sera approfondie par Anne, Marie-Luce et Axel).
Un certain nombre de questions n’a pas trouvé de réponse immédiate et nécessite des investigations que les membres du groupe se partagent :

• 
  Etude du DC Abstract Model : Guillaume et Anne-Claire,
  
• 
  Mise à jour du tableau des métadonnées et présentation EAP : Fabrice,
  
• 
  Mentions de responsabilité : possibilité de retrouver dans le modèle EAP la finesse de MODS : Fabrice,
  
• 
  Liaison de l’éditeur commercial et de son adresse URL : quelle possibilité dans « Bibliographic Citation » ? Jean-François va contacter la spécialiste Ann Apps,
  
• 
  Essais dans HAL de dépôts avec plusieurs versions : Axel, Anne et Marie-Luce.
  

Afin d’avancer le travail, une réunion téléphonique intermédiaire est prévue le 6 mai à 9h30