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.

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?