notes

Outils pour utilisateurs

Outils du site

Piste:
lectures:ltr-lsp

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision 		Révision précédente
lectures:ltr-lsp [2015/11/25 16:59]
igor correction syntaxe 		lectures:ltr-lsp [2018/07/29 09:08] (Version actuelle)
Ligne 5: Ligne 5:
 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 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
  
-{{:lectures:ltr-library-service-platforms.pdf|}} - [[https://www.zotero.org/igor.m/items/itemKey/8KQDXEJU|Zotero]]+{{:lectures:ltr-library-service-platforms.pdf|PDF}} - [[https://www.zotero.org/igor.m/items/itemKey/8KQDXEJU|Zotero]]
  
 ===== Notes ===== ===== Notes =====
Ligne 35: Ligne 35:
   * Spydus 9 de Civica, pas présent aux USA, pourtant peut être pertinent.   * Spydus 9 de Civica, pas présent aux USA, pourtant peut être pertinent.
  
-===== Qu'est-ce qu'un LSP ? =====+=== 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. 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.
Ligne 52: Ligne 52:
 Désormais accepté par communautés des bib. et des vendeurs. Désormais accepté par communautés des bib. et des vendeurs.
  
-==== Perspective historique : consolidation des fonctionnalités ====+=== 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. 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.
Ligne 78: Ligne 78:
 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... 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 ====+=== Définition et caratéristiques ===
  
 LSP : LSP :
Ligne 93: Ligne 93:
   * KB   * KB
  
-==== Caractéristiques fonctionnelles ====+=== Caractéristiques fonctionnelles ===
  
-==== Gestion des formats imprimés et électroniques de contenus ====+== 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. Unifie leur gestion : des ensembles, //workflows// communs. Devrait inclure à l'avenir les archives, archives institutionnelles, gestion des données.
  
-=== Remplacement des différents outils ===+== Remplacement des différents outils ==
  
-=== Gestion étendue des métadonnées ===+== 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... Support de plusieurs formats : MARC, Dublin Core, standards XML. Linked data, BIBFRAME ne sont pas encore implémentées...
  
-=== Workflows d'acquisition ===+== Workflows d'acquisition ==
  
 Achat, abonnement, licence, dans le même logiciel. À la différence des ILS. Achat, abonnement, licence, dans le même logiciel. À la différence des ILS.
  
-=== KB ===+== 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. 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 ===+== 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 ? 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 ===+== Organisation conceptuelle ==
  
 ? ?
  
-=== Discovery ===+== Discovery ==
  
-S'y intègre. LSP ne proposent pas d'interface de recherche.+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é ?].
  
-FIXME+=== 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. : 
 + 
 +  * [[https://www.worldcat.org/|worldcat.org]] 
 +  * les logiciels de gestion de contenu numérique 
 +  * //discovery// : Summon, EBSCO Discovery Service, Primo Central 
 +  * différents logiciels de bib : 
 +  * [[https://www.biblionix.com/products/apollo/|Apollo de Bblionix]] 
 +  * [[http://www.proquest.com/products-services/360-Core.html|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. 1<sup>re</sup> 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: [[http://librarytechnology.org/perceptions/2014/|2015]] 
 + 
 +== Des timeline différenciées == 
 + 
 +voir : [[http://librarytechnology.org/chron/libraryservicesplatforms.pl|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.1448467157.txt.gz · Dernière modification: 2018/07/29 09:08 (modification externe)

Outils de la page

Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC Attribution 4.0 International
CC Attribution 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki