2. The Current Landscape
• Specifically, if a student has a research assignment given to
them, how do they complete it? Let’s say the assignment says
they need to use at least 10 academic sources to back up their
arguments.
• Step-by-step. “They go here. Then they go there.”
• If a faculty member wanted to include library resources in
their class site within a CMS, how would they do this?
• Step-by-step.
5. The State of the Library Silo
• Rich resources
• A filter for academic information
• “Getting Started” reference materials
• Research librarians
• Writing assistance and citation help
• Technology assistance
• Literally millions of dollars tied up in access to resources…
7. Some attempts at de-silo’ing
• Discovery Services
• EBSCO Discovery Service
• ProQuest Summon
• ExLibris Primo
• OCLC WorldCat Local
• III Encore with Synergy
• SirsiDynix e-Resource Central
10. RSS as an initial attempt
• Many library resources provided RSS feeds for new articles
• Difficult setup for non-geeks…
• …not a flop, but not widely adoped.
• …and a limited audience.
• …but it brought library resources into a workflow, not the
other way around.
11. Workflow as the Destination
• We used to envision people coming to the library… bringing
their workflows into the library
• …when we should have been developing ways for the library
to enter their workflow and going to them.
16. Envisioning a ‘Reading List’
Tool
• So we’ve got access to this massive set of academic
resources…
• …what would be the best way to improve and integrate with a
professor’s workflow?
17. Envisioning a ‘Reading List’
tool
• The LTI Protocol
• A standard set of data that is passed along to other
applications to use… a ‘mini-API’ so to speak
• Passes along username, role in the course, course id, even which
link in the course they clicked, etc
Eric’s Awesome
Reading List Website
18. Envisioning a ‘Reading List’
tool
• Build a new website people embed into their CMS. When it
loads…
• …it knows which course its in, and if the person interacting with it
is a student or instructor
• If it’s an instructor, display a search box that sends a query to
that institution’s EBSCO Discovery Service API
• Brings back results. The website allows professors to mark the
items they like.
Eric’s
Awesome
Reading List
Website
19. Envisioning a ‘Reading List’
• When a student logs into and clicks the embedded link…
• It knows it’s a student from this course, so it displays a list of links
that the professor marked.
• Brings formerly silo’d content into both student and faculty
workflow.
• No additional authentication, no hassle
Eric’s
Awesome
Reading List
Website
22. Other APIs
• EBSCO Discovery Service
• Tie “marked resources” into university authentication, provide
“My Research” in student portal
• LibAnswers API - FAQ Service
• Unified Help Desk Platform for Library and IT questions
• ILS APIs – Book Checkouts / Account Management
• “My Checked Out Books” and “My Fines”
• Learning Analytics
• “Student X” downloaded 100 academic articles via the library and
got a 4.0 GPA and matriculated…
• “Student Y” downloaded only 2 and got a 1.5 GPA before
dropping out.
23. Discussion Questions when
you’re back on campus
• When could our community benefit from the library?
• Where are they when that need occurs?
• What tools (APIs) do we have that we could use?
• Do our vendors provide these APIs? (Should this be an
evaluation point?)
24. Discussion Questions
• Do libraries need to employ programmers? Or are they okay
with non-Geeks?
• What would be the best way to begin conversations around
using the library as an API? It’s not unheard of to have
librarians that would prefer to remain the gatekeeper…
• How can we partner with vendors to develop useful API
applications?
25. An Invitation
• Build an LTI-compliant tool for EBSCO Discovery Service’s API
to provide advanced functionality in Moodle, Blackboard, or
D2L
• Your library must subscribe to EDS for credentials
• I will do bulk of heavy lifting, but would need a partner to confirm
CMS setup
• Willingness on part of the library and CMS administrators
26. Photo Credits
• “Yellow Sailboat” by mlibrarianus @ flickr.com (CC BY-NC-SA
2.0)
• “The Treasury” by archer10 @ flickr.com (CC BY-SA 2.0)
• “Distant Silos” by stevenc1015 @ flickr.com (CC BY-NC 2.0)
• “Tool Belt” by amanki @ flickr.com (CC BY-NC-SA 2.0)
Hinweis der Redaktion
Introductions – ask how many librarians are here. How many geeks? The asterisk is there because I was Head of Library Systems at St. Edward’s University. Currently I serve as the Geek/Non-Geek liaison as a sales engineer.
Before we dive into the library as an API, and what they would look like and what APIs entail, I’d like to talk about how libraries exist today. To do this, I’d like us to do a quick mental exercise, which may be difficult for some of us, but let’s try. I’d like this half of the room to tackle the first question, and the other half to tackle the second. I anticipate the responses will be similar: the end user has to *go* to the library, go outside of their normal workflow, make a special trip. They have to search separate resources, download articles, and return to incorporate them into their site.
In a world of information, the library houses a silo of information. It is situated with and among other silos of the academic institution: a writing center, an IT help desk, academic success units, faculty, a course management system, e-mail, facebook, etc. Even if you find your way into the library, you’ll encounter sub-silos in the form of academic databases, research guides, reference help, etc.
Here’s an example of a leading university library website. How many ways to search can you count? What other resources are there? And you only use these things if you know to come to the library site in the first place!
Summarize the current situation.
Because this picture is awesome.
Clever libraries are using discovery services to simplify the silo’d experience while still funneling advanced researchers to specialized information. Caveat emptor, I work for the first one listed, specifically on their Discovery product.Discovery products attempt to pull together the myriad resources a library has into one search experience. The difficulty services like this face are the apples-to-oranges comparisons they sometimes need to make when searching disparate types of resources – and the different types of searches they might have: the novice researcher looking for a starting point to the faculty member conducting a literature review. In either case, it allows libraries to do this:
One big search box.
Despite simplifying on the inside, we are still an outside stop in the research process – one often forgotten until a bad grade is received and time is wasted.
One of the first attempts libraries made in trying to escape our own physical and digital walls was the provision of RSS feeds for journal tables of content. When new issues of a journal would come out, or a new article matching some predefined search was published, RSS alerts could get a faculty member’s attention without them having to ‘check in’ at the library… but there were drawbacks.
Despite that, it was the first thinking libraries had done to consider how they might be a part of existing workflows, as opposed to workflows adapting to include them. We began thinking less like the stereotyped Geek (he’s the product, use it!) and more like our users.The questions became: When? Where? And when we answered those questions, the question became how? For example, we realized students turn to their professors, course syllabi, friends, Google, the IT helpdesk… just about everyone but the librarian… when they need research help. They will visit their course website … but not always the library website. So.. How do we create a rich research experience within the context of the CMS course? Something contextual to the course itself – not just an out-of-context link to the library?
How many are familiar with API? Ask for their definition.
Distinguish EBSCOhost and Blackboard as two separate entities – if EDS provides an API, that means people who develop modules, plugin, and the BB application could tap in to the resources you see here – without ever kicking someone to the EDS interface.
Here’s an example I just finished working on – pulling EDS content into ‘Project Blacklight’. Project Blacklight is its own application. It’s open source, written in Ruby on Rails, and some big name libraries are beginning to use it to index their catalogs. They aren’t satisfied with the online catalog vendors provide; Blacklight allows them to add facets – ways to slice and dice the catalog – bookmarks features, history, a login that connects with university authentication, and a better search engine.
My project was allowing libraries who are implementing Blacklight to include an “Articles” section that pulls from EDS content. This is the same content you saw a few slides ago, but brought into the Blacklight application. APIs allowed this. When a user does a search – it dynamically sends an API request to EDS, and EDS sends back results, what facets that could be used to slice and dice, highlighted terms, even icons. This is beneficial for end users in a couple of ways – first is a single interface. No new tools to learn, no new places to look to accomplish certain tasks. This becomes the research tool, not one of hundreds of separate research tools out there.
Let’s push further. It can be more than the interface. Let’s consider the workflow of creating course readings – we can use the API to improve upon this. The question becomes, how do we provide access to this rice set of resources at the library, but keep it here in blackboard.
The answer is probably more detailed than a non-Geek would want, but it involves building an application that understands who its visitors are and pulls in EDS content. For example, when you log into Netflix, it knows you. It knows what time of day you’re logging in, it knows where you’re logging in from, and it knows the movies you’ve most recently seen. When you look at a Netflix dashboard, it is obviously aware of who you are and your tastes and responds accordingly. In fact, it goes further by knowing lots and lots of people like you. It uses that data – information from elsewhere – pieces it together with your tastes, and comes up with just the right suggestion at the right moment.So, we do have a website that knows a lot about you – our CMS. When you log in to Blackboard, for example, and you are in a course site, BB knows quite a bit about you. It knows what institution you belong to. It knows what course you’re looking at. It knows your name and ID number. It knows if you’re a professor or a student. It knows your grades. BB, and other CMSs like Moodle and D2L, have implemented a mini-API to share this information with other websites that might become embedded in the CMS. In other words, if you choose to embed a certain website into your BB course, you have the option of passing along all of that information about the user each time a user accesses the site via BB. John Doe logs in to BB, clicks on the link to load the site, and the web site loads fully customized to John Doe’s permissions and context.
Knowing that, let’s think about Professor X. He clicks on the link to the site and it loads, saying, “Welcome, Professor X! I see you’re in your course site for BOTANY 101. Would you like to add items to the reading list?” And it gives a search box that pulls information from EDS. Each item in the results list has a “Add to Course Readings” button that when clicked, adds it to the course reading list.Done. No going to the library website. No downloading PDFs. No worrying about copyright. No technical upload/download process.
No let’s consider “Student Y” who logs in to the same course site. He clicks on the SAME LINK. The website loads and says, “Oh, hi, Student Y! Here are the articles, ebooks, and streaming movies your professor has selected for you!” No search box because it’s a student accessing the site. Just links that connect the student to library resources. No navigating to the library website, no leaving the learning environment.