Lipstick on a Pig: Integrated Library Systems


Published on

Lecture slides for LIS 644, "DIgital Trends, Tools, and Debates"

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Lipstick on a Pig: Integrated Library Systems

  1. 1. Lipstick on a Pig: Integrated Library Systems 30 November 2010
  2. 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. 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: • or Compfight: • or Flickr Storm: • Music: search for “podsafe music” • Brilliant for decorating presentations and podcasts • Remember to give back!
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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: 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. 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?