Projecte

General

Perfil

Accions
Historial

Wiki »

Perquè apostem per Muscat?

Guió per a la reunió interna de la UAB
Ferran Jorba
Cristina Azorín
16 febrer 2021

Introducció: com és que hàgim arribat fins aquí?

A la reunió d'usuaris d'Invenio del març del 2017 el Cern ens va fer una primera presentació del que havia de ser la nova versió d'Invenio, Invenio 3 (Presentació) indicant que seria força difererent del que havia estat fins aleshores. Això es va confirmar el març del 2019 (Presentació). La incompatibilitat era tan gran que ens obligava a mirar si hi havia alguna alternativa millor, o que ens estalviés la feinada que implicaria adaptar Invenio 3 al que havia estat fins aleshores.

Com que en aquesta situació no estem sols, vam acordar amb el grup s'usuaris alemany d'Invenio Join2 (https://join2.de/) avaluar les diferents opcions disponibles. De la reunió que vam tenir a Hamburg el maig del 2019 vam acordar crear un wiki de treball (https://wikis.bib.uab.cat/projects/invenio-3-or-not/wiki/), fer una llista comuna dels requeriments (necessaris o opcionals, Common_requirements_for_UAB_and_JOIN2), fer una avaluació sistemàtica de totes les opcions que existeixen en software lliure, i triar la que millor ho complia.

El resum és que no n'hi ha cap aplicació que ofereixi la funcionalitat d'Invenio 1 amb els nostres requisits, però algunes s'hi apropen més que d'altres. En qualsevol dels casos cal aportar-hi feina d'adaptació. En alguns és més de configuració i en altres cal escriure programa. I Tots estem d'acord que és important que les nostres aportacions siguin acceptades pels líders del projecte i formin part del paquet estàndard, de manera que el que tinguem instal·lat s'aparti com menys millor de l'aplicació original, preferiblement només en temes de configuració.

Per què descartem Invenio 3?

No queda ningú de l'equip de persones que va desenvolupar Invenio 1, i els objectius originals també han desparegut. No existeix en Invenio 3 cap dels motius principals que inicialment ens van fer triar Invenio:

  • Format bibliogràfic natiu Marc21
  • Agrupació flexible de registres en col·leccions, incloses les jeràrquiques i les virtuals
  • Flexibilitat per tenir tot tipus de registres en una sola instància

A més a més, la complexitat de la seva instal·lació ha crescut moltíssim. Té molts requisits (peces externes) imprescindibles, uns quants de recomanables i la pròpia instal·lació no té gens de trivial. De fet, Invenio 3 ara mateix no és una aplicació completa per a gestionar repositoris, sinó una plataforma per a desenvolupar-ne. No hi ha interfície final acabada, cadascú ha de fer-se-la a mida.

Finalment, hi ha un motiu d'actitud: el nou equip ha decidit ignorar d'una manera explícita i reiterada les demandes dels usuaris que feia anys que teníem Invenio. Potser perquè són tan grans i tan especials, han decidit anar a la seva encara que això impliqui quedar-se sense comunitat d'usuaris i sense col·laboradors externs.

Darreres notícies del progrés del consorci alemany Join2

En el darrer correu del 10 de febrer d'enguany, el meu col·lega Alexander Wagner ho ha descrit així:

There we are on a full stop, indeed.

Too many comments of "not yet finished", "wait for RDM to be released" or no answers at all. I have to admit that I also can hardly share Lars excitement for the "user experience" (I hate even this very buzz word; I don't have any experiences if I use some sort of software, it's just there to get stuff done) of author input (https://invenio-software.org/blog/2021-02-01-january-release/) Imagine this dialogue for the Atlas collaboration. But even if you have "only" the average 10 authors, you'll spend quite some time there... Still, they are in Alpha(!) now while it should have been GA some 2 years(?) ago. So: we just observe its progress casually.

TIND took about 9 months to respond at all and did not yet come back to us again. As for RERO it seems similar. Doesn't sound like they want to do any business with us. Point taken at least on my personal end.

I learned however, that the CERN library is migrating their ILS these days. However, I also learned that this is not the migration of CDS. As far as I understood they end up with at least 3 independent systems (+ videos.cern.ch) that can not interchange data easily. So, they catalogue for the CERN library, then catalogue again for INSPIRE and if it's a CERN paper yet another incarnation for the new CDS. (I was not aware that they have so many catalougers...) I am also not entirely clear: from their web page I get the impression that Invenio ILS is the RERO implementation. So they binned the stuff they showed us in Geneva again? (I'd really like to have some real world coffee with Tullio or Jens to talk about this.)

Pel que fa al grup alemany que està intentant construir alguna cosa amb peces ja existents:

What I understand from our group is in short:

  • Progress is pretty slow
  • They currently evaluate options for a stand alone submission system. Sort of a mini service. This is pretty much along the lines we use websubmit for years now and the general idea is to use it with whatever is the actual backend. It was the part that used up most resources for invenio1 implementation. (The rest was not only peanuts, but comparatively easy.)
  • What they do now:
    • build a web form (currently they use some Flask-based python and feed in our ancient JS code by means of a slightly modernized version of our submission mask generation program)
    • hook up http callbacks and retrieve data in JSON, to get the authority control right (at the moment the idea is to just use our invenio, but it should be easily replaceable)
    • spit out some format (most likely some JSONish structures as we use it right now)
    • submit the result to the final backend system by some http call
  • As backend systems they currently evaluate
    • Koha, as there are some instances that have it running as an ILS and it seems capable to handle our records including the many authors and there is some poor mans approach for full texts.
    • DSpace CRIS where the important part is the CRIS add-on
  • They ruled out FOLIO, as they found it to be
    • not yet production ready at all (they struggled quite a bit to get it running in the first place, even though they got some help from the experts)
    • it is felt to be way to complex. To do anything at all they had 50-60 docker containers up and running (invenio3 looks like childs play ;) and I understand they were still not able to load any of our Marc records. Which is strange, given Folio is an ILS it should speak MARC on all channels, regardless their inner model. (BTW: FOLIOs metadata model called `Codex` sounds at first glance like a promising option for a JSON based data model in Invenio3 or the like.)

Hi trobareu més detalls a la pàgina específica per a Invenio3.

Què estem cercant?

Una aplicació web que ens permeti fer, i si pot ser, fer-ho millor, el que fins ara estàvem fent amb Invenio, i que compleixi amb els requisits que vam establir amb el consorci Join2 (Common_requirements_for_UAB_and_JOIN2). Això vol dir:

  • Compatibilitat amb el que tenim:
    • Conservar totes les nostres urls permanents
    • Conservar tots els nostres registres
    • Mantenir tots els programes d'importació i exportació actual
  • Registres:
    • Gestionar registres bibliogràfics en Marc21, de tot tipus i tamany
    • Preferiblement amb registres (control) d'autoritats
    • Capaç de gestionar centenars de milers de registres
    • Documents adjunts, locals i remots, de tot tipus
    • Indexacions personalitzables
    • Diferents formularis d'entrada segons el tipus de document
  • Gestió d'usuaris:
    • Diferents tipus d'usuaris, rols i permisos
    • Diferents tipus d'autenticacions
  • Estàndards d'interoperabilitat:
    • Bibliogràfics: Marc21, Dublin Core, EDM, Openaire4, BibTex, citació, etc.
    • Protocols: OAI-PMH (client i servidor)
    • Importació i exportació, tant per al personal del SdB com pels usuaris finals
  • Interfície d'usuari:
    • Multilingüe
    • Adaptat a diferents tipus de pantalles
    • Que compleixi els requisits d'accessibilitat
    • Que compleixi els requisits de seguretat
  • Desenvolupament
    • Programari lliure
    • Que hi hagi garanties de continuïtat de l'aplicació
    • Que siguin oberts i acceptin contribucions i millores

Per què apostem per Muscat?

Sense haver pres la decisió final, perquè no és el moment encara, nosaltres creiem que l'aplicació que més s'acosta al que ens cal, i que amb menys esforç pot fer el que feia Invenio 1 és Muscat. Les raons estan explicades a bastament en diferents pàgines d'aquest wiki. En tot cas, entenem que del que es tracta és d'avaluar què li manca i fer una estimació d'esforç i temps.

Muscat, com que és una aplicació Ruby on Rails, es pot aprofitar de molts paquets estàndards que ja existeixen de Ruby o de Rails. I més concretament, com que Ruby és especialment popular entre els informàtics de biblioteques de les grans universitats nord-americanes (des de Harvard fins a Stanford, passant per Yale, Princeton, Duke i tantíssimes altres), moltes de les funcionalitats específicament per biblioteques que no té Muscat, ja estan desenvolupades (com l'OAI) i només cal integrar-les i parametritzar-les. De fet, l'existència d'aquest ecosistema bibliotecari en Ruby on Rails fa que la tria de Muscat es pugui convertir també en una tria estratègica (Why_our_next_software_has_to_be_a_Ruby_on_Rails_application).

D'altra banda, hem pogut constatar que Muscat és una aplicació lleugera, amb pocs requisits, relativament fàcil d'instal·lar, gens instrusiva, i que pot conviure amb altres aplicacions en el mateix servidor.

Les nostres aportacions a Muscat, com les de qualsevol programari lliure, cal fer-les amb gràcia i de manera que aquestes millores siguin acceptades pels responsables de Muscat. En el cas del Cern ja vam aprendre que això era molt difícil; tenen les seves dinàmiques i són tan especials que ni els centres de recerca alemanys del Join2 ni la UAB vam trobar la manera de fer-hi grans aportacions. Afortunadament, en el cas de Muscat, ja hem pogut constatar que és molt més fàcil (és cert que una plataforma com Github ho facilita molt). Tot i que la seva resposta de vegades és més lenta del que ens agradaria, a hores d'ara ens han acceptat una bona colla d'aportacions que ja formen part del Muscat estàndard (https://github.com/rism-ch/muscat/graphs/contributors). A més a més, la majoria consisteix en petits retocs o aportacions francament menors. Del que manca a Muscat, creiem que majoria continua en aquesta línia. Cal saber què tocar, o incorporar funcionalitats ja existents en algun paquet estàndard, però no fer grans desenvolupaments. Tot i que el RISM i el Cern són equivalents en molts aspectes (RISM_vs_CERN), el fet que el RISM sigui més una organització entre iguals i no tingui un centre tant macrocefàlic hi deu ajudar. El fet que a hores d'ara siguem pocs ens dona més possibilitats d'influir en la línia futura de l'aplicació.

A final de l'any 2020 es va constituir el RISM Digital Center (https://rism.digital/) que és un projecte d'infraestructures de recerca de la Fundació Nacional Suïssa per a la Ciència. Entre d'altres tasques s'encarrega de gestionar el desenvolupament de Muscat (https://rism.digital/tools/muscat.html), i té la responsabilitat de garantir el bon funcionament de la comunitat RISM a nivell internacional i millorar contínuament la infraestructura digital del projecte.

Etapes i tasques

Tal com ho veiem, el que tenim al davant són dues etapes:

En primer lloc, cal que Muscat, com a paquet estàndard, sigui capaç de gestionar alguns aspectes que feia Invenio i dels que hi depenem absolutament, i que bàsicament serien:

Creiem que l'ordre hauria de ser aquest, perquè uns depenen dels altres: per exemple, en Invenio, els oaisets d'OAI es defneixen com les col·leccions, i segurament és una bona estratègia, de manera que fins que no tinguem les col·leccions no podem començar amb l'OAI.

Només si ens en sortim podem decidir que triem Muscat. Aleshores, hi intervindria la segona fase, específica per la UAB, de personalització i adaptació específica per a nosaltres:

  • Personalització de formularis i tipus de documents.
  • Personalització de la visualització de la informació bibliogràfica d'usuari finak (registres breus i complets). Això ho podríem contribuir al paquet Muscat, però com que forma part de la personalització, no és tan segur que ens ho acceptin.
  • Personalització dels formats bibliogràfics professionals i d'intercanvi (DC, EDM, BibTex, Openaire4, etc.).
  • Personalització dels índexos i facetes.
  • Personalització dels rols i permisos.
  • Personalització dels fluxes de treball.
  • Personalització dels colors, logos, tipografia i aspecte general.
  • Formació interna.

A grans trets, podríem dir que cadascuna d'aquestes fases duraria un any, tot i que algunes de la segona fase es poden començar a pensar o treballar abans, en paral·lel.

Igualment, si finalment ens decidim per Muscat, creiem que l'ordre d'implementació hauria de ser del més petit al més gran: IFMuC, Traces i DDD.

Altres consideracions

Muscat és programari lliure com Invenio, per tant no hi ha un cost específic per a la seva compra. Sí necessitarem suport per a la seva implementació i sobretot per a poder migrar les funcionalitats actuals. No voldríem confiar aquestes tasques a una empresa externa però la seva consecució a dins dels Serveis Informàtics de la UAB ha de comportar, necessàriament, un augment de recursos humans disponibles. Fins i tot en casos recents, com la implementació del programari Pure per a Egreta, hem vist que el fet de subcontractar els serveis de migració a l'empresa també ha comportat un augment de personal.

Creiem que el DDD és, hores d'ara, una infraestructura important per a la gestió de la producció científica de la UAB, imprescindible per a garantir el compliment de les clàusules d'accés obert dels projectes espanyols i europeus. Però també és imprescindible per a complir amb el reial decret que obliga a la publicació de les tesis doctorals, o per a la difusió dels treballs de recerca. A nivell de l'administració també és una eina bàsica en quant a preservació dels materials digitals de la universitat, el lloc on es dipositen les guies docents (necessàries per a les convalidacions), les memòries de titulació, documents institucionals com: memòries, honoris causa, reglaments, guies d'alumnes, butlletins...
També és fonamental per a visibilitzar el fons patrimonial de la universitat, amb nombrosos fons personals i convenis de digitalització (amb el Liceu com a col·laborador més important).

Actualitzat per Ferran Jorba fa aproximadament 5 anys · 31 revisions