Outils pour utilisateurs

Outils du site


lectures:ltr-lsp

Library Technology Reports : Library Services Platform

Référence

BREEDING, Marshall, 2015. Library Services Platforms: A Maturing Genre of Products. Library Technology Reports. 5 juin 2015. Vol. 51, n° 4, pp. 38. Disponible à l'URL suivante : http://search.ebscohost.com/login.aspx?direct=true&db=lih&AN=110072912&site=ehost-live

PDF - Zotero

Notes

Introduction

LSP = dernière vague de systèmes automatiques pour bib. Très différents de ce qui a existé.

But du rapport : permettre de comprendre LSP. LSP n'a pas encore remplacé ILS. Besoin de données pour décider si ILS ou LSP.

Rapport ne fais pas de recommandations pour les produits présentés, vision neutre. Description générale et données empiriques sur nombre et types de bib. sur LSP. Source : stats, graph. proposés par vendeurs, libraries.org, le //Library Automation Perceptions Survey// de 2014.

Donne des descr. gen. des produits, pas détail des caractérisitques, fonctionnalités.

Champ : les solutions les plus utilisées en Amérique du Nord :

  • OCLC WorldShare Management Services
  • Ex Libris Alma
  • Innovative Interface Sierra
  • ProQuest Intota
  • Kuali OLE

Mentionné :

  • SirsiDynix BLUEcloud Suite

Non-traité :

  • Spydus 9 de Civica, pas présent aux USA, pourtant peut être pertinent.

Qu'est-ce qu'un LSP ?

Diffère substanc.mnt des ILS, qui ne répondent plus aux besoins. LSP = catégorie qui contient des solutions corresondant à différentes caractérisitiques (concept, technique, fonction). Pas de def. univoque, fermée.

Ressource management system = tout produit majeur utilisé par une bib. pour gérer tout ou partie de ses collections. Inclut : LSP, ILS, digital collections management system, etc.

Proposition de def. en 2011, par l'auteur : spécifique aux bib., permet aux bib. de produire ses services, à l'interne comme à l'externe, via l'outil ou via des services Web.

Puis ajoute : répond aux changmts fondamentaux ds domaine bib. → contenu numérique. Se sépare de l'époque où les modèles d'automatisation étaient centrés sur l'imprimé (ILS). Jusqu'ici, on ajoute des modules à l'ILS : link resolvers, bibliothèques numériques, systèmes de gestions des actifs numériques, archives institutionnelles… But des new produits : plateforme qui intègre le tout.

Besoin d'avoir une def. neutre → LSP. Chaque vendeur proposait sa def. pour son produit :

  • Unified Resource Management par Ex Libris
  • Web-Scale Management Service par OCLC

Désormais accepté par communautés des bib. et des vendeurs.

Perspective historique : consolidation des fonctionnalités

Mission des bib. constante : dev les collections en fonction des intérêts des communautés d'utilisateurs, et y donner accès. Par contre, les collections ont changé de nature, format, méthode de stockage, d'accès… À chaque changement, les bib. ont développé les outils et tech. dont elles avaient besoin pr remplir mission.

[histoire des tech. bib.]

Informatisation : améliore gestion (circulation, catalogage, acquisitions) et accès. Unification des divers programmes → ILS, basés sur une DB centralisée. Développement a suivi les tech. dispo : mainframe, client-serveur, cloud et techno Web.

Tendance constante vers la consolidation, unification dans 1 solution, integrated or unified platforms. 70s : ILS résultat de cette unification (circulation, acquisition…).

Augm. de la doc numérique : besoin de nouveaux outils pour acquisition, gestion, accès du numérique. Début 21e, nouvelle période de fragmentation des outils pour le numérique :

  • ILS pour l'imprimé, rôle de moins en moins central
  • OpenURL link resolvers, début 2000s, aide les bib. pour une solution gérable pour lier les citations (ou référence) au full text → le rendre accessible aux utilisateurs. Offre un lien, selon le contexte, vers le full-text sur le serveur de l'éditeur auquel la bib. est abonné. Résolvait problème des liens en dur, impossible à maintenir, à cause trop grande masse des ressources électroniques et leur évolution.
  • KB : DB qui décrit le contenu des bouquets auxquels la bib. est abonnée. Liste actualisée de chaque revue électronique contenue dans les bdd, les années couvertes (embargo ou pas…), la syntaxe nécessaire pour faire un lien vers l'article individuel, et autres. Support le protocol OpenURL. KB décrit l'ensemble du contenu potentiellement accessible, le link resolver permet de savoir si on y accède et y donne accès.
  • liste AtoZ
  • Electronic resource management system : acquisition, description, gestion des bdd, revues électroniques, bouquets. Se base sur une KB.
  • archives institutionnelles, ou collections numérisées
  • plateformes d'archivage à long terme de contenu numériques.

LSP → consolidation de plusieurs catégories de fonctionnalités. [ah ?]. Vont remplacer plusieurs produits, y compris ILS, gestion des ressources électroniques, KB. Peut-être aussi link resolver, en lien avec discovery.

LSP ne suffit pas, aussi discovery, même si souvent intégrés dans la même offre. Pas de plateforme de publication, archives institutionnelle, gestion des données, actifs numériques…

Garder en tête l'élargissement des fonctions lors de la comparaison des coûts : ILS + gestion des ressources électroniques + link resolver + infrastructure, ressources humaines…

Définition et caratéristiques

LSP :

  • permet bib de acquérir + gérer ses collections
  • quel que soit le format, au moins des contenu physiques et numériques
  • différents processus d'acquisition : achat, abonnements, licences, OA
  • gestion des différents schémas de métadonnées nécessaires pour chaque format
  • famille MARC
  • dublin core
  • ~ discovery ou connexion vers un discovery, grâce aux APIs
  • cloud multi-tenant
  • client Web, pour l'admin comme pour utilisateur final
  • KB

Caractéristiques fonctionnelles

Gestion des formats imprimés et électroniques de contenus

Unifie leur gestion : des ensembles, workflows communs. Devrait inclure à l'avenir les archives, archives institutionnelles, gestion des données.

Remplacement des différents outils
Gestion étendue des métadonnées

Support de plusieurs formats : MARC, Dublin Core, standards XML. Linked data, BIBFRAME ne sont pas encore implémentées…

Workflows d'acquisition

Achat, abonnement, licence, dans le même logiciel. À la différence des ILS.

KB

Le fournisseur construit la KB à la place des bib : c'est un dépôt de métadonnées inclus. KB à la fois des contenu imprimés et numériques. Donc une KB qui dépasse de loin les collections possédées par la bibliothèque.

Stats

Promesses de meilleures stats. Parce que le fournisseur dispose de plus de données… et ? Il les donne ? Il les vends ? Comme les éditeurs commerciaux ?

Organisation conceptuelle

?

Discovery

S'y intègre. LSP ne proposent pas d'interface de recherche. OPAC était intégré à ILS. Discovery considéré comme produit différent du LSP. Pour un LSP, la notion d'OPAC ne s'applique pas, plutôt via APIs. [Quelle qualité ?].

Caractéristiques techniques

Au delà de l'architecture client - serveur

Passage de l'architecture client lourd / serveur à client léger (navigateur) / serveur. Éviter d'installer et de mettre à jour un client lourd. [À la place, on utilise une sorte de client universel : le navigateur, avec ses propres limites (conf., mises à jour, plugins…)]

Chaque institution installait son logiciel sur ses serveurs, avec ses DB. L'utilisateur final passait via un client qui produisait l'interface utilisateur.

Plateformes multi-tenant

1 instance → plusieurs users. TT le monde utilise la même version. Permet d'envisager l'ensemble des données comme un tout, de séparer des parties, d'en partager d'autres entre users.

Distribution globale, bascule et redondance sur différents datacenters, sur différents continents. Existe avant LSP dans domaine des bib. :

  • les logiciels de gestion de contenu numérique
  • discovery : Summon, EBSCO Discovery Service, Primo Central
  • différents logiciels de bib :
  • 360 de ProQuest
  • EBSCO A-Z, LinkSource, etc.
  • LSP : Alma, WorldShare Management Services, Intota

Bénéfices dans domaine bib. :

  • coût marginal d'un nouveau client pour le fournisseur
  • maintenance faite une fois, appliquée globalement
  • économie en pers. pour le fournisseur…
  • simplification du déployement des patchs, pour le fournisseur…
  • évolutions, mise à jour facilitée
  • possibilité d'activer optionnellement des feats en tests, avant mise en prod.

Du point de vue des bib. elles-mêmes :

  • la tech. est gérée par le fournisseur, allège la tâche du pers. de la bib.
  • carrément pas besoin de personnel technique, pas d'adminsys.
  • parfois besoin d'un bibsys, pour institution de grande taille pour config., chargement des données, interactions avec le système local.

Du point de vue de bib. la différence entre SaaS ou multi-tenant est subtile :

  • multi-tenant peut proposer des fonctions intégrées comme KB [pourquoi particulièrement les multi-tenant ?]
  • mt offre un processus de conf. de plus haut niveau [?]
  • scalability…

Mais au fond, peut de différences entre SaaS et mt, moins qu'entre cloud et selfhosted.

Interfaces Web

Interfaces Web != pas de logiciels en local sur les serveurs ou desktop… sauf un navigateur, ok.

Pas de mise à jour du client, ni des serveurs locaux.

Architecture orientée architecture

? programmation objet ? Développement par modules ? Méthodes agile ? → services-oriented approach

APIs : extension et interopérabilité

Réutilisation des données dans d'autres services (stats, analyse, …) ou gestion des données (modif globales, autres tâches pas prévues nativement dans l'outil).

Gestion des droits et accès aux APIs. [bah, oui]. Doit être bien documenté. L'APIs et les développements.

Interopérabilité

Avec :

  • ERP
  • système de la compta
  • gestion des dossiers étudiants
  • LMS

Le tout avec APIs.

Le LIS qu'une partie du système d'information de l'institution. Le LIS utilise les données d'autres partie du SI : dossiers étudiants, RH. Acquisition et compta.

Modèle de l'abonnement

Du modèle de licence au modèle de l'abonnement.

SaaS : abonnement mensuel en rapport avec la taille et la complexité de l'orga. 1re année plus chère : migration et paramétrage.

Abo + chère que licence, mais il faut ajouter infra + RH.

Un groupe de produits en évolution

LSP ne sont plus des next-gen sys mais produits bien établis, implémentés dans des 100n de bibs. A commencé en 2009. Début des implémentations en 2010. Fin 2014, presque 1000 bibs y ont migré.

Dans le cycle d'adoption
  • Alma et WS en prod depuis 2012, ont bcp progressé.
  • KualiOLE : en prod dans 2 bib., gère seulement l'imprimé, prochaine version en prod début 2015 (annoncé à l'époque).
  • Intota : pas terminé, seulement le numérique.
  • Sierra : mix LSP et ILS, sorti en 2012, ~500 bib. en prod.

Beta testers, early adopters… ? A chacun sa prise de risque.

Du dev à l'implémentation

Évaluer la maturité d'un produit :

  • Fin du dev initial. Pas encore complet, mais au moins un niv. de complétude satisfaisant…
  • Première phase de production. Au moins implémenté par qlqes bib. même petites, ont laché l'ancien système.
  • Déployement en masse. Plusieurs centaines de bib. en prod.

Produits en constante évolution, déjà le cas des ILS.

mt → évolution graduelle, plutôt qu'en “palliers” dans architecture client-serveur. [ne dépend pas forcément de l'architecture…].

Sources pour évaluer implémentation et réception
  • Library Systems Report
  • libraries.org, les Library Technology Guides
  • Library automation Perceptions Survey [voir: 2015
Des timeline différenciées

voir : timeline sur librarytechnology.org.

Stratégies de dev : Greenfield VS Brownfield

Comment peut-on dev un truc aussi complexe qu'un LSP (est-ce vraiment aussi complexe ?) ? Dépend de plusieurs facteurs :

  • Taille de l'orga qui dev
  • nbr de dev

La diff entre brown et greenfield, c'est si le dev reprend des compsants déjà existants. Du job déjà fait, mais des contraintes.

Brownfield avance plus vite, mais moins innovant, puisque reprise d'éléments existants.

WS : greenfield. S'appuie sur le contenu de WC. + WorlCat Local comme discovery, puis WorlCat Discovery Service.

Alma : greenfield. Ne reprend pas travail existant de Voyager, Aleph, SFX… Reprise de la KB, mais pas le code. + Primo et Primo Central. Primo a aussi été un greenfield project.

Kuali OLE : approche hybride. La partie bib. est complètement nouvelle, mais reprend les parties de Kuali Rice et Kuali Financial System, qui n'est pas prévu pour du mt, mais KualiCo redéveloppe cette partie.

Intota : s'appuie sur l'existant plus dev de nouveau code. Continue le dev des produits de Serials, récent dans le domaine, donc tout en mt. Intota comprend 360 Link, un module des gestion des ressources numériques.

Sierra : s'appuie sur Millenium + nouvelle tech. Développement plus rapide.

SirsiDynix : hybrid. Son BLUEcloud suite peut être considéré comme LSP. Déployé en mt, gestion du numérique et de l'imprimé, interfaces Web. Repose sur le ILS de SirsiDynix : Symphony ou Horizon.

lectures/ltr-lsp.txt · Dernière modification: 2018/07/29 09:08 (modification externe)