Lipstick on a Pig: Integrated Library Systems
2 likes•1,334 views
This document discusses communication strategies for library colleagues, including writing concisely and focusing on the purpose and audience. It also summarizes tools like Creative Commons licensing and maintaining an online presence. Finally, it examines software development models and challenges facing library systems, including integrating library data and collections onto the open web.
Lipstick on a Pig: Integrated Library Systems
- 1. Lipstick on a Pig: Integrated Library Systems 30 November 2010
- 2. Tip of the week: Communication • Writing for your library colleagues is not like writing academic papers. • No required pagecounts, and no points for prolixity • Nobody cares about your erudition. (Lit review only to make a serious point, or to leverage peer pressure.) • Get to the point. Fast. • “Executive summary” for people who won’t read it all (which is most of them!). • Bullet points are good. Compound-complex sentences and ten- dollar words are bad. • Always ask:What is the purpose of this thing I am writing? Who cares? • Communicate? Persuade? Train? • Upbeat matters. Even if you’re frustrated, tired, fed up.
- 3. Tool of the week: Creative Commons • Creators who license their creations for reuse; no need to ask permission • But observe any conditions on the license! • Images: http://flickr.com/creativecommons/ • or Compfight: http://compfight.com/ • or Flickr Storm: http://zoo-m.com/flickr-storm • Music: search for “podsafe music” • Brilliant for decorating presentations and podcasts • Remember to give back!
- 4. Tool of the week: Online presence • Yes, you need to worry about your egoGoogle. • You also need to worry if you don’t have one. • Are you missing a chance to stand out in a competitive field? • Once you’re on the job market,THEY ALL HAVE MLS-ES. • You’ll have to take the bad with the good... and only you can decide what’s worth it. Consider: • Professional network (assists, job leads, conference buddies) • What fits your way of presenting yourself (blog, Flickr,YouTube, Ravelry, FriendFeed, Facebook, LinkedIn, SlideShare) • Whether and how to pull all of it together into a portfolio.
- 5. Weekly reflection (for next week’s discussion) • Google yourself. Could you find yourself? Do you have Googlegangers? • Any surprises, good or bad? • Is this what you want a potential employer knowing about you? • If not, what do you plan to do about it? • Are you satisfied with your own online privacy?
- 6. Software development models: why you care • How your software was built affects: • how much you pay for it, up-front and ongoing • which chunk of budget those costs come from • how much you can do with and to it • how much it will cost to support and train people on it • how much control you have over your data and how your data are presented to your patrons • how good it is • There is no one right answer.There are only tradeoffs, which you need to understand.
- 7. Building it yourself • Some libraries deliberately and intentionally develop their own software. Go them! • Some libraries do it by accident! • One bright tinkerer whomps something up. • The library comes to depend on it. • ... and then the tinkerer leaves. Oops. • ... or the computing world changes such that the whomped-up thing no longer works. Oops. • Tinkerers are great. But make them document. And have a plan for transitioning off the whomped-up thing!
- 8. Off-the-shelf software • What you buy in the TechStore • Made by for-profit companies • Though small developers and shareware makers are still out there! • Certain expectations of performance, stability, polish, documentation • May vary somewhat depending on customer base • May rely on proprietary file formats for customer lock-in • Pricing: usually “per seat” or “site licensed”
- 9. Vendor software • Usually springs up in niches where off-the-shelf software can’t sell enough seats • ... e.g. ILS software for libraries! Also learning-management systems! • You pay to run the software AND for a certain level of customer service • Installation help • Employee training, user groups, conferences • Technical support (up to and including vendor-run servers) • You’ll still need local tech staff, often! • Installing and customizing these things is a HASSLE. • But there will be strict limits on what you can do.
- 10. Use the source, Luke! • “Source code” = the instructions that humans write for computers to follow • “Compiled code” or “binary code” = source code that has been munged to be directly understandable by the computer • Not interpretable by humans any more! • This is the only form in which proprietary software is distributed (usually), and why you can’t peek under its hood. • “Compiler,” “interpreter,” “virtual machine” all bits and pieces of the source-code to compiled-code transformation.
- 11. Open-source software • The source code is open! • You can (legally) download and install it without paying. • You can (legally) read it. • You can (legally) change it. • You can (legally) resell it (sometimes with caveats). • Developers “license” their code under one of a number of open-source licenses • Commonest: GNU General Public License (GPL), which has a sting in its tail • Also notable: BSD license, Artistic License • OSI maintains a vetted list of open-source licenses.
- 12. Brief digression: open source, open standard, open access • Open source: refers to SOFTWARE • Open standard: refers to RULES for protocols, file formats, software specs, etc. • “Reference implementation:” software that shows how software that complies with a particular standard should work • Example:W3C’s Amaya browser • Open access: refers to the SCHOLARLY LITERATURE
- 13. I’m not a programmer.Why should I care about the source? • Do you benefit when other people hack on the software? • With open source, quite possibly yes. • If there’s a good API, quite possibly yes. • With API-less proprietary software, rarely and only indirectly. • What happens when a software company goes out of business? Or kills a product? • Proprietary software: decay and obsolescence. • Open-source software: new companies, forks, options. • Security • Security-through-obscurity doesn’t work. No software is perfectly secure, but OSS has a good track record of fast patches.
- 14. Should I use open-source or proprietary software, Dorothea? • It depends.There are tradeoffs. • $$$ vs. staff time/expertise:“free as in kittens” • Ease of use/installation vs. control • Professional support vs. ad-hoc online communities • You can’t always know what your experience will be. • Some vendor support is horrible. Some is great. Some online communities are horrible. Some are great. • Some open-source projects move fast. Some don’t. Some vendors move fast. Most don’t (most can’t!). • Only you understand your library’s situation. • ASK AROUND before you invest, either way.
- 15. The worst of OSS: DSpace • Few developers (and until recently, all volunteers), so change is slow. • Arrogant developers, so change is out-of- touch with actual user needs. • Why did publicly-accessible statistics takeYEARS? • This has gotten better of late. It’s still not perfect. • Architecture deeply hostile to casual hacking, so innovation is slow. • APIs? What APIs? Plugins? Who needs plugins? And why should we have a space to share code? • Usability? This is open-source software! We don’t need no stinkin’ usability!
- 16. The worst of vendor software: ILSes • Migration is a huge hassle, so vendors lock in customers and have little further incentive to serve them. • Heinous hardware-price markup • Totally opaque data models; few APIs; licenses that forbid tinkering • Horrendous customer support • Stunningly slow to innovate (partly our fault!)
- 17. What’s an ILS? • Integrated Library System • THE system that handles library operations. • “Modules” • Acquisitions • Cataloguing • OPAC • Circulation/patron management • Also: serials, metasearch, e-resource managers (sometimes), link resolvers... separately or bundled • Underneath: heap big relational database!
- 18. State of the market • Big consolidations in mid-decade • Players: Endeavor (Voyager), Ex Libris, Sirsi/Dynix (Horizon) • Up-and-coming open-source packages • Koha: geared toward public libraries • Evergreen: geared toward library consortia, is building code for academic libraries (e.g. serials management) • eXtensible Catalog Project: University of Rochester • Some service innovation • WorldCat Local • LibraryThing for Libraries • Typical ILS replacement cycle: 5 to 10 years
- 19. Lipsticking the pig • Libraries turned to outside vendors, homegrown solutions • NCSU: adopted Endeca, who are a web-commerce firm • UVa: Solr/Flare/Blacklight (ha ha ha) • Scriblio,VuFind, etc. • What were they looking for? • USABILITY! • Faceted searching/browsing • Better associations among records (quasi-FRBRization) • Better correlation between user language and controlled vocabularies • Generally: making the data work harder!
- 20. More pieces: Link resolvers and OpenURL • You have a citation. How do you find out if the library has the article among its e-resources? • OpenURL: protocol for checking citation information against a library’s list of vendor- provided e-journals and article databases • Pack citation info into a URL or a teeny XML document • Link resolver: gizmo that takes in an OpenURL and returns list of available copies. • SFX (Ex Libris) current market leader
- 21. Still more pieces: e-resource management • You just bought a Big Deal. How do you update holdings and URLs in your OPAC? How do you update your link resolver? • How do you keep track of who bought what out of which fund? Or who to call when something breaks? Or usage stats? • Market leader: Serials Solutions • Service (auto-holdings-updating), not just product. • Open-source (though dependent on MS Access) entrant: ERMes
- 22. Catalog vs.“resource discovery” • What’s actually in an OPAC? • Print books, maps, sheet music • Title-level serials • Maybe govdocs, theses/dissertations, collection records for stuff in special collections • What’s not? • The rest of the world! Including digital collections, stuff on the web, article-level access to journals, finding aids... • The information world is bigger than it used to be! • So is the ILS/OPAC an INVENTORY tool, or a DISCOVERY tool? • And what is our inventory, really?
- 23. First-cut solution: Metasearch • How many databases are you willing to search? With all their different interfaces? • Metasearch to the rescue! or something. • Single search interface presented to the user. • Sends user’s query to various databases; receives, processes (deduping, relevance ranking), and presents the results. • Some databases use search protocols like Z39.50 and SRU/ SRW. Others have to be screenscraped. • Lousy solution. • Slow, not always good at processing results, coverage not always the best, search bells and whistles gone.
- 24. Next try: Building local index for search • Tricky to do! • Which data sources can you legally build your index from? • Of those, how many have an API? Or will you be stuck screenscraping HTML? • Or do you have to work with your link resolver? • See also: Google Scholar • Essentially this is what GS does.They make special arrangements to crawl publisher sites, even behind firewalls.
- 25. Now:“web-scale” discovery • OPAC layers (or ILS replacements, or ILS add- ins) that purport to offer one-stop shopping: OPAC, digital collections, serials, etc. • Serials Solutions: Summon • WorldCat Local • Ex Libris: Primo Central • EBSCO: EBSCO Discovery Service (EDS) • First question: is this a SEARCH TOOL or a CONTENT DATABASE or both? • Next question: coverage? • PlayersVERY close-mouthed about serials coverage.
- 26. The future of MARC • Bluntly: it doesn’t have one. • As a file format, it’s LONG past its sell-by date. • Does not fit into the mashup universe at all. • Making it work with current-gen technology is a tremendous resource drain. • In hindsight, decisions made so that MARC could easily output human-readable catalog cards are hurting us badly now that catalog cards aren’t what we want any more. • That said, we have a lot of data in it. • If you become a cataloger, you will be involved in a mass data migration. Have fun! (Believe me, I feel your pain.) • Migration to what? Well, that’s the question. • The answer is probably multiple. But RDA is part of the answer.
- 27. What is RDA? • Resource Description and Access • the next analogue to AACR2 • Does not assume MARC or ISBD underneath! • Diane Hillmann, others actively working on linked-data/RDF expressions. • Claimed benefits • Expand the universe of what is describable • Spend less time on rules pilpul, punctuation, and other cruft • Less emphasis on “record,” more on linkages • Ability to make our records work with/for outside world • FRBRization
- 28. Right, so what’s FRBR? • Functional Requirements for Bibliographic Records • Relational data model for catalog records. • Recognizes that not all parts of a bibliographic record describe the same thing • Author: of a “work” • Page count: of an “edition” • “FRBRizing” a catalog means drawing all those relationship arrows between records, and then doing something with them for patrons. • We can do this mechanically. Sort of. Some of it.
- 29. Next problem:Who owns our records? • OCLC controls union catalog in the US. • But OCLC didn’t author most of the records! • Huge, ongoing flap about who can use/remix those records, with or without permission. • Open-records initiatives springing up • Open Library • Michigan: http://blog.okfn.org/2010/11/29/open- bibliographic-data-how-should-the-ecosystem-work/ • To be clear: legal restrictions on reuse and mashups damage librarianship’s presence online.We can’t afford not to settle this.
- 30. Last problem: How does our data fit into the Web? • This is not entirely a catalog problem. • What about our digitized collections? Born-digital holdings? Finding aids? Usage data? Authority data? • What are our APIs? • To what extent do we NEED local catalogs? • Uncomfortable but necessary question! Do we need to reinvent Google? If so, how do we exchange records for stuff that isn’t in our ILS? • Are we overinvested in the ILS? • How do we facilitate appropriate reuse of our data? Do we/can we bar inappropriate reuse?