1. Avancées du projet inist-ul (TP) Présentation Voir le ppt diffusé par Thomas le 3 juillet. Echanges
télécharger 59.29 Kb.
|
GTSU 2 juillet 201220120702 AMUE, 10h-16h30 Présents : Didier Gazeau (DG), Monique Joly (MJ), Henriette de Daran (HdD), Dominique Rouger (DR), Christine Musso (CM), Thomas Jouneaux (TJ), Thomas Porquet (TP), Laurence Renou (LR), Dominique Lechaudel (DL), Magaci Colin (MC), Agnès Raymond-Denise (ARD), Laurent Baudy (LB), Marie-Laure Bretin (MLB), Catherine Morge (CM), Dolorès Dardaine (DD), Thierry Fournier (TF) 1.Avancées du projet INIST-UL (TP)1.1.PrésentationVoir le ppt diffusé par Thomas le 3 juillet. 1.2.Echanges« Nécessité de refonte du socle technique pour pouvoir partager l’outil. » MC : refonte ? DC : oui refonte, mais conservation de la base de connaissance. DG : possibilité pour les EPST de déployer ezPAARSE, ou de se déployer dans Analog’IST ? Réponse : Pas de problème, c’est en open source TF : Etudier le cas Raptor http://iam.cf.ac.uk/trac/RAPTOR/wiki/Software/Overview pour voir s’il ne peut pas être utile pour ne pas avoir à couper le Shibboleth direct ? Réponse : non car pas de logs finement parsables sur un fournisseur d’IdP, qui se contente de faire l’authentification HdD : utiliser SISE pour qualifier les étudiants ? TF : excellente idée, à voir si l’info est dans les LDAP. SISE permettrait une approche plus macro que la qualification par les composantes locales. DR : L’analyse des statistiques est entre ezPAARSE et MESURE. Il manque une brique qui transforme un fichier log nettoyé (sortie d’ezPAARSE) en XML importable dans MESURE. MC : L’Inist fait l’analyse des statistiques avec Omniscope. Conclusion : il faut rajouter dans la vision négative d’ezPAARSE qu’il n’est pas un logiciel d’analyse des statistiques. DR : partager c’est bien, mais la mutualisation ça ne marche pas toujours. Il faudra des gens de l’ombre pour tester, nettoyer les parsers. Et les métiers de l’ombre ne sont pas toujours reconnus. DL a l’air confiant là-dessus : avec un bon système d’alerte ça lui parait gérable ; si le fonctionnement en réseau ne marche pas, il y a toujours la possibilité d’assigner la tâche à quelqu’un. Il est important de tester les parsers a priori car cela prend beaucoup de temps de réparer des erreurs. TF : relation entre ezPAARSE et BiblioPAM, solution de gestion de reverse proxy de la société Alixen qui permet de générer des statistiques simples (connexions, sessions) par type d’utilisateurs. [Enquête menée par TP, il apparaît que « BiblioPAM utiliserait "IDX reverse proxy". C'est un reverse proxy open source, développé en 2002-2003 par Idealx. Cette société s'appelle désormais OpenTrust et ne semble plus maintenir IDX reverse proxy. »] Springer (et en fait Metapress) ne sont absolument pas parsables. LB rappelle que l’on doit toujours écrire une recommandation pour l’écriture des url. Discussion sur le niveau article Conclusion : calendrier Signature de la convention Couperin / INIST en cours : développement d’ezPAARSE, hébergement de MESURE. 2 IGE informaticiens vont travailler à l’INIST au développement d’ezPAARSE la rentrée, un contractuel Couperin (6 mois) et un agent de l’INIST. Réunions régulières et redéfinition des priorités au fil de l’eau. La première instance sera déployée à l’UL. 2.Avancées de MESURE (TP)2.1.PrésentationVoir le ppt diffusé par Thomas le 3 juillet. Clauses d’utilisation des données d’usage :
2.2.EchangesLes accès seront ouverts quand la signature de la convention Couperin INIST sera effective. Le transfert technique ne prendra qu’une demi-journée. Après discussion, le GTSU est favorable à la création d’un compte anonymisé ouvert à tout le monde, comme le fait le JUSP Est-ce que l’on développe les fonctionnalités d’analyse de MESURE ? Réponse après échanges : plutôt non, on peut faire quelques améliorations, mais le plus important est avant tout de charger des rapports en déployant de nouveaux éditeurs compatibles SUSHI et de nouveaux établissements, en essayant de charger aussi des book reports et des database reports. Les fonctionnalités d’analyse seront mieux gérées avec un outil à part (type Omniscope utilisé à l’Inist) acquis par les établissements ou le consortium. Dans ce cadre-là il faut peut-être monter une négociation Couperin autour de ce type d’outil. 3.Counter V43.1.Différences entre la v4 définitive et la pre v4 (TF).3.1.1RésuméRajout de GOA (Gold Open Access) dans la liste des nouveaux termes Suppression de la notion d'Institutional Identifier Les GOA ne seront pas comptés dans les JR1 at JR1a mais dans un JR1 GOA dédié JR5 obligatoire, mais à la demande, pas forcément chaque mois DR3 devient PR1 (Platform Record 1) Suppression du BR6, remplacé par PR1 New reports covering usage on mobile devices Suppression de "A new protocol to ensure that usage of full-text items that is initiated by automatic or semiautomatic bulk download tools, such as Quosa or Pubget) does not inflate the usage reported in the COUNTER reports." .3.1.2SushiRemplacement de CSV par TSV Ajout de : "COUNTER and NISO partner with other organizations to provide tools that facilitate the implementation of the COUNTER standards. COUNTER also encourages the development of Open Source tools, such as the SUSHI Harvester for Consortia (http://www.niso.org/workrooms/sushi/tools/#harvester ). Further information on these tools may be found on the NISO/SUSHI website." Et de : "3.1 SUSHI Server Response Times A SUSHI Server must respond to the SUSHI Request from a client within 120 seconds. SUSHI Servers that are unable to consistently deliver a completed usage report within this timeframe should adopt an architecture that allows for background processing of usage data – the server can respond to the initial request with a “Server Busy” exception while queuing the request for background processing. Since most SUSHI clients will wait minutes or hours before retrying the request, the report will be ready to be delivered on the subsequent request. .3.1.3Usage reports
.3.1.4Autres pointsLivraison des rapports: passage du CSV au TSV; l'e-mail qui prévient de la disponibilité du rapport devient optionnel Ajout d'un paragraphe sur les navigateurs web (web browsers): "Usage statistics reported in the COUNTER reports must be consistent and not dependent on the browsers used by customers. As a minimum vendors must support current versions, compliant with World Wide Web Consortium (WC3) standards, of the following web browsers: Google Chrome, Internet Explorer and Mozilla Firefox. » Data processing: pas de changement par rapport à la pre-v4 (qui introduisait la distinction logfiles analysis / page tagging) Return codes and time filters: pas de changement par rapport à la pre-v4 Protocol for federated searches and automated search agents Search : pas de changement par rapport à la pre-v4 Protocol for internet robots and crawlers: idem Suppression de Protocol for LOCKSS caches et du paragraphe sur SCONUL Audit: pas de changement majeur par rapport à la pre-v4 (qui introduisait la notion de compatibilité partielle) 3.2.Suites des travauxTF doit faire une synthèse des principales nouveautés v4 / v3, en s’appuyant sur la présentation ci-dessus, sur la présentation de Peter Shepherd du 23 mars et sur la présentation de DR au GTSU de janvier [Pas eu le temps de la faire à ce jour 12/07/12] Synthèse qui devra être relue par le GTSU avant mise en ligne Il faut aussi que le petit groupe Couperin ayant traduit la pre-v4 effectue la traduction de la v4. Idée de LB : tirer une dizaine de points de la norme Counter pour la présenter de manière synthétique aux éditeurs, avec un préambule à destination des nouveaux responsables docelec. On rediscute de la recommandation sur les url (comptage, liens profonds). Il faudrait au minimum la mettre dans la lettre de cadrage. 4.Recommandations pour la licence type Couperin et les licences nationalesCf. le document de Laurent Baudy diffusé au GTSU le 14/05/12 Lettre de cadrage : on prend la formulation proposée par TP, en inversant JR1a et JR5 Demander aussi à ce que les statistiques soient explicitées Dans la licence-type on ne bouge pas fondamentalement, LB remet à jour en fonction de Counter la partie consortium Pour les licences nationales
TF répond à Benjamin Bober (ABES) en ce sens [ce sera fait dans l’après-midi de ce jour 12 juillet 2012] 5.Point divers5.1.Suite des travaux du GTSUA l’avenir le GTSU peut : Etre un soutien fonctionnel pour MESURE Emettre des avis à certains moments du développement d’ezPAARSE Il nous faut continuer le travail de veille sur COUNTER, à bien mettre à jour les pages sur le site Couperin. Au vu des retours positifs sur la journée d’étude du 23 mars on pourrait renouveler l’exercice sur un rythme annuel ou bisannuel. 5.2.Statistiques d’utilisation des UMRC’est automatisable, et sans avoir encore automatisé, MC a tout fait pour que sa successeur Cécilia Fabry puisse automatiser en septembre. En attendant il faut surtout formuler la demande politique au directeur de l’INIST. TF réécrit à Grégory Colcanap en ce sens [c’est fait] |
similaire:
 |  | «Phase de définition ou pré-étude» du projet et permet, après validation par le Comité de Pilotage, de lancer le projet | |
| «experts» d’un côté, chefs d’équipes et ouvriers de l’autre, et on sait combien la hiérarchie statutaire peut aussi affecter la qualité... | | «texte» acceptés : pdf, PostScript, Word, rtf, html, txt, Latex, zip, Excel, ppt, Email (divers formats), code source, etc |
| | ||
| «dossier de présentation – appel à projets». A noter que le jury se réunira mi-mars pour valider les manifestations qui seront intégrées... | | |
| «rideau de fer» (selon l’expression de Churchill) émerge, coupant l’Europe en deux. Les alliés de la Seconde Guerre mondiale, Américains... | | Sont tirés du précédent projet de Valorisation du Château de Montespan, réalisé par le sivom de la Région de Salies du Salat, en... |