You are here
- Carmen Mitchell, carmenmitchell at gmail (@carmendarlene)
code4lib 2012, Wednesday, February 8 2012, 11:15-12:00
a.k.a. "Human Search Engine". A chance for you to ask a roomful of code4libbers anything that's on your mind: questions seeking answers (short or long), requests for things (hardware, software, skills, or help), or offers of things. We'll keep the pace fast, and the answers faster. Come with questions and line up at the start of the session and we'll go through as many as we can; sometimes we'll stop at finding the right person or people to answer a query and it'll be up to you to find each other after the session. Third time at code4libcon! (Thanks to Ka-Ping Yee and Dan Chudnov for the inspiration/explanation, reused here in part.)
Relevance Ranking in the Scholarly Domain
- Tamar Sadeh, PhD, Ex Libris Group, email@example.com
code4lib 2012, Tuesday 7 February 2012, 13:20-13:40
The greatest challenge for discovery systems is how to provide users with the most relevant search results, given the immense landscape of available content. In a manner that is similar to human interaction between two parties, in which each person adjusts to the other in tone, language, and subject matter, discovery systems would ideally be sophisticated and flexible enough to adjust their algorithms to individual users and each user’s information needs.
When evaluating the relevance of an item to a specific user in a specific context, relevance-ranking algorithms need to take into account, in addition to the degree to which the item matches the query, information that is not embodied in the item itself. Such information, which includes the item’s scholarly value, the type of search that the user is conducting (e.g., an exploratory search or a known-item search), and other factors, enables a discovery system to fulfill user expectations that have been shaped by experience with Web search engines.
The session will focus on the challenges of developing and evaluating relevance-ranking algorithms for the scholarly domain. Examples will be drawn mainly from the relevance-ranking technology deployed by the Ex Libris Primo discovery solution.
Kill the search button II - the handheld devices are coming
- Jørn Thøgersen, Statsbiblioteket/State and University Library, Aarhus, Denmark. firstname.lastname@example.org
- Michael Poltorak Nielsen, Statsbiblioteket/State and University Library, Aarhus, Denmark. email@example.com, (aka the Danes - some of them).
code4lib 2012, Tuesday 7 February 2012, 13:40-14:00
Web based library search engines are traditionally operated using keys, input fields, buttons, and links. Being equipped with touch screens, accelerometers, GPS's, and cameras, smartphones and tablets offer a whole new range of input options.
In this talk we'll demonstrate some of our ideas of how to utilise these new input options interacting with a search engine. The basic idea is to have no traditional GUI input elements, but only use touch interactions (pinch, zoom, swipe, long-press, etc) and gestures (shake, tilt, turn, etc.). Using these interactions, we’ll demonstrate how to:
- do searches
- toggle search result views
- switch pages
- request materials, add to favourites
- interact with your stuff, renew items
We'll also show you some (conceptual) ideas about using the device camera for locating and checking out materials.
On a general level, what we are trying to achieve is a move away from a web based paradigm and establish new ways of interaction better suited to the new devices and on their own terms. The demonstration will feature working mobile prototypes including both native apps (iPhone) and web apps. In both cases they will run on live data from our OPAC on www.statsbiblioteket.dk/search/
This talk is actually also a continuation of our Code4Lib 2010 talk called "Kill The Search Button" (http://code4lib.org/conference/2010/schedule), which we unfortunately never got around to do, due to a Danish blizzard.
Practical Agile: What's Working for Stanford, Blacklight, and Hydra
- Naomi Dushay, Stanford University Libraries, ndushay at stanford dot edu
code4lib 2012, Wednesday, February 8 2012, 14:00-14:20
Agile development techniques can be difficult to adopt in the context of library software development. Maybe your shop has only one or two developers, or you always have too many simultaneous projects. Maybe your new projects can’t be started until 27 librarians reach consensus on the specifications.
This talk will present successful Agile- and Silicon-Valley-inspired practices we’ve adopted at Stanford and/or in the Blacklight and Hydra projects. We’ve targeted developer happiness as well as improved productivity with our recent changes. User stories, dead week, sight lines … it’ll be a grab bag of goodies to bring back to your institution, including some ideas on how to adopt these practices without overt management buy in.
Lies, Damned Lies, and Lines of Code Per Day
- James Stuart, Columbia University, firstname.lastname@example.org
code4lib 2012, Wednesday, February 8 2012, 13:40-14:00
We've all heard about that one study that showed that Pair Programming was 20% efficient than working alone. Or maybe you saw on a blog that study that showed that programmers who write fewer lines of code per day are more efficient...or was it less efficient? And of course, we all know that programmers who work in (Ruby|Python|Java|C|Erlang) have been shown to be more efficient.
A quick examination of some of the research surrounding programming efficiency and methodology, with a focus on personal productivity, and how to incorporate the more believable research into your own team's workflow.
In-browser data storage and me
- Jason Casden, North Carolina State University Libraries, email@example.com
code4lib 2012, Wednesday, February 8 2012, 13:20 - 13:40
When it comes to storing data in web browsers on a semi-persistent basis, there are several partially-adopted, semi-deprecated, product-specific, or even universally accepted options. These include models such as key-value stores, relational databases, and object stores. I will present some of these options and discuss possible applications of these technologies in library services. In addition to quoting heavily from Mark Pilgrim's excellent chapter on this topic, I will weave in my own experience utilizing in-browser data storage in an iPad-based data collection tool to successfully improve performance and data stability while reducing network dependence. See also: HTML5.
Indexing big data with Tika, Solr & map-reduce
- Scott Fisher, California Digital Library, scott.fisher AT ucop BORK edu
- Erik Hetzner, California Digital Library, erik.hetzner AT ucop BORK edu
code4lib 2012, Wednesday, February 8 2012, 13:00-13:20
The Web Archiving Service at the California Digital Library has crawled a large amount of data, in every format found on the web: 30 TB, comprising about 600 million fetched URLs. In this talk we will discuss how we parsed this data using Tika and map-reduce, and how we indexed this data with Solr, tweaked the relevance ranking, and were able to provide our users with a better search experience.
NoSQL Bibliographic Records: Implementing a Native FRBR Datastore with Redis
- Jeremy Nelson, Colorado College, firstname.lastname@example.org
code4lib 2012, Wednesday, February 8 2012, 10:55-11:15
In October, the Library of Congress issued a news release, "A Bibliographic Framework for the Digital Age" outlining a list of requirements for a New Bibliographic Framework Environment. Responding to this challenge, this talk will demonstrate a Redis (http://redis.io) FRBR datastore proof-of-concept that, with a lightweight python-based interface, can meet these requirements.
Because FRBR is an Entity-Relationship model; it is easily implemented as key-value within the primitive data structures provided by Redis. Redis' flexibility makes it easy to associate arbitrary metadata and vocabularies, like MARC, METS, VRA or MODS, with FRBR entities and inter-operate with legacy and emerging standards and practices like RDA Vocabularies and LinkedData.
Stack View: A Library Browsing Tool
- Annie Cain, Harvard Library Innovation Lab, email@example.com
code4lib 2012, Wednesday, February 8 2012, 10:35-10:55
In an effort to recreate and build upon the traditional method of browsing a physical library, we used catalog data, including dimensions and page count, to create a virtual shelf.
Building research applications with Mendeley
- William Gunn, Mendeley firstname.lastname@example.org (@mrgunn)
code4lib 2012, Wednesday, February 8 2012, 09:55-10:15
This is partly a tool talk and partly a big idea one.
Mendeley has built the world's largest open database of research and we've now begun to collect some interesting social metadata around the document metadata. I would like to share with the Code4Lib attendees information about using this resource to do things within your application that have previously been impossible for the library community, or in some cases impossible without expensive database subscriptions. One thing that's now possible is to augment catalog search by surfacing information about content usage, allowing people to not only find things matching a query, but popular things or things read by their colleagues. In addition to augmenting search, you can also use this information to augment discovery. Imagine an online exhibit of artifacts from a newly discovered dig not just linking to papers which discuss the artifact, but linking to really good interesting papers about the place and the people who made the artifacts. So the big idea is, "How will looking at the literature from a broader perspective than simple citation analysis change how research is done and communicated? How can we build tools that make this process easier and faster?" I can show some examples of applications that have been built using the Mendeley and PLoS APIs to begin to address this question, and I can also present results from Mendeley's developer challenge which shows what kinds of applications researchers are looking for, what kind of applications peope are building, and illustrates some interesting places where the two don't overlap.