Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie Catalog Management in the Cloud: Two Years In
Ähnlich wie Catalog Management in the Cloud: Two Years In (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Catalog Management in the Cloud: Two Years In
- 1. Image from: www.itportal.com Catalog Management in the Cloud: Two Years In Catalog Management IG Meeting, ALA Annual June 25, 2016 Stacie Traill and Betsy Friesen University of Minnesota
- 2. Topics Systems environment in 2011 Environment prior and at go live in 2013 Differences between Aleph and Alma Highlights and challenges with Alma
- 3. Minnesota Environment in 2011 Aleph servers near end-of-life Encouragement to move to the cloud Solicitation to be early adopter Environment scan: Alma vs ??? Aleph functionality as Alma baseline
- 4. Minnesota Environment in 2013 Topology just for Minnesota Migration processes were works-in-progress Functionality in development -- lots of it Issues with user interface
- 5. Aleph vs. Alma • Local-hosted servers and maintenance • Support required from central IT • Server access allowing views of logs and running of complex queries • Local Aleph client and maintenance • Local devoted system support team = 5 FTE • Service packs and upgrades requiring major testing effort • Mature system • Software as a service (Cloud = no local servers) • No support -- AT ALL -- required from central IT • No server access allowing views of logs and running of complex queries • No support required by library computer support • Local devoted system support team = 1 FTE • Monthly releases where testing has diminished over time • Infant system www.babble.com
- 6. Alma Alma functionality is still a moving target ... But it is less so, 2 1/2 years in.
- 7. Searching and set creation • Fairly robust set of indexes available, with ability to search MARC elements not indexed via a special process. • Complex queries are easy to save and use as the basis for batch processes • Sets of records can be created by uploading lists of identifiers. • Browse indexes not originally included; browse recently developed, but not really usable yet. • Little local control over indexing (except 9XX fields). Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 8. Batch changing bibliographic records • Good flexibility in normalization rules/processes. • Rule design and single-record testing available to all catalogers. • Straightforward logic and syntax means learning curve is not too steep. • Many things still easier in MarcEdit. • Processing speed can be an issue for large batches. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 9. Batch loading/importing bibliographic records • Import profiles easy to set up • Custom bib record editing easy to incorporate and fairly flexible • Merge routines easy to customize • Job reports useful and detailed, allowing download of failed and skipped records • Import profiles can be shared with the Alma community • Item mapping not as complete as it should be (especially for material types) Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 10. Demand/Patron-Driven Acquisition (DDA/PDA) • Good built-in tools for importing DDA records and acquisitions data. • Ability to pause, terminate, clean up, or cancel DDA profiles with a single command. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 11. Publishing and Exporting Metadata • For Primo: Alma shows last published version of the record, making troubleshooting discovery layer problems much easier. • General publishing is flexible and powerful. • Basic bib record batch export is simple and usually very fast. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 12. E-resource management • Link resolver/knowledge base combined with traditional ILS confusing at first, but ultimately much more efficient. • Explicit hierarchical structure helpful for managing bib data as well as KB/linking. • No separate steps beyond activation to get basic discovery metadata for titles in KB collections. • Lack of flexibility in linking acquisitions records has been a challenge. • Currently no ability to batch update Community Zone bib records. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-smile.svg CC-BY-SA 3.0
- 13. APIs • Alma offers an extensive and growing set of APIs that can address most of its data and processes. • With some programming skill, many things are possible. • Limits on number of daily API calls. • Programming skill required to take full advantage. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-dunno.svg CC-BY-SA 3.0
- 14. Authority Control • No need to maintain authority files ourselves, but authority file maintenance not always accurate. • Basic heading matching and flipping jobs run daily but need careful monitoring. • Initial implementation was poor. • Inability to browse headings means we do that elsewhere. • Name heading flips too “greedy” (flipping occurs based on $a match only). • An area of ongoing concern and communication. • “Works well 98% of the time.” Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-dunno.svg CC-BY-SA 3.0
- 15. Analytics (reporting) • Much MARC data not available in Alma Analytics, making many reporting tasks much harder than they should be. • A completely different, often counterintuitive, system to learn. • All staff can have access to Alma Analytics, making it much easier for individuals to create their own simple, small, ad-hoc reports. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-sad.svg CC-BY-SA 3.0
- 16. Cataloging UI (Alma Metadata Editor) • Very frustrating for staff since Day 1, and not greatly improved since. • Lots of mousing and clicking, and some inconsistent behavior. • Client-based macro approach doesn’t work well. • Not as full-featured as Aleph cataloging module or OCLC Connexion Client. • Version history for bib and holdings records readily available. • MARC standard documentation loads contextually per field. Image by Chris, https://commons.wikimedia.org/wiki/File:SMirC-sad.svg CC-BY-SA 3.0
Hinweis der Redaktion
- Thank you for coming to our session. I’m Stacie Traill, Metadata Analyst at the University of Minnesota Libraries. Betsy Friesn, director of our cataloging and systems department, had a conflict and couldn’t be here today. Minnesota has been on Alma for 2 ½ years. Today, I’ll talka about our environment at the time we decided to choose Alma and just prior to and at switch to production at the end of 2013. I’ll also cover a few of the differences between Aleph and Alma and some of the highlights and challenges of catalog management in the cloud.
- In 2011, Minnesota had already been on Aleph for nine years. A few staff worked on focus groups with Ex Libris on their yet-to-be-name Unified Resource Management system for the previous two years. Our Aleph servers were approaching end of life. We knew we would also need to update to the next version of Oracle as well. Meanwhile, the University’s chief information officer encouraged departments to move services/systems to the cloud, if possible, to reduce infrastructure costs. At about the same time, Ex Libris approached us to be an early adopter of their cloud based system. A quick environmental scan of next generation systems led us quickly back to Alma. This was followed by a more extensive look at functionality on the Alma roadmap. Obviously, this resulted in us moving forward with contract negotiations. We approached our move to Ex Libris next-gen system as a major upgrade to Aleph. Thought, we knew that we were entering into a agreement for a brand-new system, we also assumed that Aleph functionality would be baseline for the us, by the time we went live. That turned out to be a rather mixed bag, as you will hear in a few minutes In the fall of 2011, Minnesota joined the three development partners (Princeton, Purdue and Boston college) + 10 other early adopters to have the ability to affect development of Alma
- Topology: As we were so often told, Minnesota is a complex institution. Being an Ex Libris customer already, we thought the company understood our multi-campus situation. We may have put too much faith in that belief. ExL needed to delay our migration by 6-months to create a topology just for us. I’ll talk about those challenges in a few minutes. Suffice it to say under ten institutions in the world have this architecture. Justifying resources for so few institutions is a challenge for Ex L, but the institutions shouldn’t have shoulder the burden. Migration processes were works in progress. The migration itself went very smoothly, but getting there was interesting. -- Spreadsheets via email for hundreds of thousands of eresources -- Spreadsheets for libraries/locations caused dirty data when combined with Aleph tables.We didn’t understand they were taking Aleph data It is unfortunate, that there was not a simpler migration path for data moving from an Ex Libris system to migrate to another Ex Libris system. Development of functionality: Since Alma was being built from square one, we knew there would likely be initial loss of functionality, but we hadn’t expected the loss of some of the lessons learned by Ex Libris via their other products, like link resolving and authority control. All functionality has improved but, of course, it isn’t as fast as any one institution would like it to be when waiting for what they want User interface: Early on Ex Libris staff said that they knew that there were significant user interface problems, causing usability issues but wanted to get functionality running first. After 4 years in production, Ex Libris is finally putting significant effort into an improved UI.
- Local-hosted servers and maintenance with many local customizations/ Software as a service (Cloud = no local servers) which is more of a one size fits most. Support required from central IT in the role of DBA, server maintenance, etc. / No support -- AT ALL -- required from central IT Server access allowing views of logs to allow troubleshooting and no SQL to run complex queries / Just the opposite for Alma --No server access allowing views of logs and running of complex queries; while that might cut down on work; the loss of control does increase wait time while Ex Libris tries to figure out what went wrong. Giving up precise SQL querying may be one of greatest losses. Alma analytics to allow broader access to the data (no server access necessary), all of the the data elements and joins are not available to us. Local Aleph client and maintenance for every upgrade or problem with client /No support required by library computer support with the exception of Spineomatic installation and maintenance Local devoted system support team = 5 FTE / Local devoted system support team = 1 FTE The key here is ‘devoted’. We don’t have system administrator needs anymore. We gave up a staff line following a retirement, because it seemed that we really didn’t need as many devoted systems staff, but that was before it became clear about the dependency we would have on APIs to accomplish some of the work that we could do by batch in Aleph. Service packs and upgrades requiring major testing effort, especially for major upgrades, but this testing was typically carried out by systems staff / Alma has monthly releases. Testing was distributed to operational groups. Significant testing has diminished over time. The cycle is too fast to do in depth testing. And finally … a move from a Mature system to an Infant system … maybe pre-school now. Probably a harder transition for those more involved in the workings of the system than many of our Alma users. Most s taff were able to do most of their work within a couple of months.
- Alma functionality is still a moving target, but it is less so 2 ½ years in. Let’s talk about some of the highlights and challenges of that functionality in the area of catalog management.
- Although browse still isn’t really usable, it turns out we need it a lot less than we thought we did (except for authority work).
- Wish list: ability to use regular expressions in normalization rules, ability to easily sort subfields within a field.
- Batch loading in Aleph required backend server access and many more steps; there was also less flexibility for record edits and merge routines.
- Alma General publishing offers many options for extracting bibliographic metadata, both on-demand and scheduled. File format (MARC binary or XML), ability to include data from both physical and electronic inventory, custom normalization routines. Uses: Providing metadata to HathiTrust and Google; OCLC Reclamation; local digitization projects; other reporting and metadata transformation needs.
- Huge change for us from previous environment with e-resource management spread across three systems (Aleph/SFX/Verde); few staff had access to SFX and Verde, so much more duplicate entry/maintenance.
- Haves/have-nots? Institutions with developers on staff (or lots of staff with strong coding skills) are better positioned to take advantage of efficiencies offered by APIs.
- Slow response to what was initially a large number of reported issues; EL didn’t learn from experience with Aleph. Felt like we were reinventing the wheel.
- It’s possible to get at all MARC data between Alma itself AND Alma analytics, but that’s time-consuming and requires a fairly sophisticated understanding of what’s possible on both sides, as well as skill to combine data from multiple sources.
- Final verdict: Good things: offer lots of flexibility, and/or workflows well-designed to match library needs Less good things: little or no flexibility, workflows/functions designed without full understanding of needs Things are going pretty well …. Most of the time