This weekend (13-16 November), I’ll be in Brussels attending OpenCon – a particularly lively conference about open access, open data and open research, which is aimed primarily at early-career researchers. (It was my privilege to give a talk at the Berlin 11 Satellite conference in 2013 that was the direct predecessor of OpenCon.)
Index Data is looking for developers to be part of our operations and support team.
Index Data is looking for a software developer for their Copenhagen office.
Today, it was 20 years ago that Adam Dickmeiss and I founded Index Data together in Copenhagen. There was a bottle of champagne, and our parents shared the moment with us along with our wives, because, honestly, we were little more than big kids at the time. We were a little scared, but we were also in the fortunate position of being young, still without kids or debt. Oh, and our wives had steady jobs. Let the adventure begin!
In our introduction to Smart Widgets, I said that part of our purpose in developing the technology was to move away from the search box as the primary paradigm for accessing information: To give librarians more tools to organize and present information for their consumers/patrons. But the widgets can also be used to IMPROVE the capabilities of the search boxes that we already have – to offer new functions beyond what your existing software is capable of. In this post, we will show a couple of different examples of how Smart Widgets can be used to add functionality to Koha, but the same principles apply to any system that allows you to customize the HTML structure of a search results page.
This is the first of a series of blog posts in which we will talk about a concept that we have been developing over the past few years. We call it ‘smart widgets’ to distinguish our approach to widgets from the almost ubiquitous notion of ‘widgets’ meaning little search boxes that you insert into your page, but which ultimately send your users to some remote site.
One of the problems we’ve had over and over at Index Data is that we build all these cool back-end tools – things like the metasearching middleware Pazpar2 – but then don’t have a good way to show them off. We’ve never really focussed much on building UIs, so we have to do demos that go like this:
We’re in the business of making access to information easier for people and, most of all, for SOFTWARE that in turn makes that information available to people. A lot of our software is based around a kind of switchboard or functional ‘hub’ model which means that when we extend a capability in ONE area, new possibilities open up in other areas that we don’t necessarily even think about ourselves.
It’s always fun to see someone do something really neat with your software. This elegantly designed search interface for Asia studies makes excellent use of Pazpar2. I particularly like the clever use of a bar chart for the date facet. Nice work!
It has been quiet on the pazpar2 front lately, but I will make amends with this blog post.
Lately I have been working on a Harvester that would harvest into a Local Unified Index (LUI). The LUI has been implemented with Solr.
This means we can implement Integrated Search, which is our name for doing both searching remote targets (meta-searching) and a Local Unified Index (LUI), aka Central Index.
Code4lib 2012, Seattle
I was the lucky winner of the Index Data lottery (no actual lottery took place) to go to Code4lib 2012. I was a (Code4lib) Newbie, so I didn’t really know what to expect, but reading Jakub’s blog about his experiences, it sounded like great fun.
It was also my first time in Seattle, so I did take some extra days on both ends to do some exploring. Arriving on Saturday to sunny and warm weather (15 degrees Celsius warmer than Copenhagen, nice!), Seattle did its best to welcome me.
Most of the science of Information Retrieval centers around being able to find and rank the right set of documents in response to a given query. We spend much time arguing about technical details like ranking algorithms and the benefits of indexing versus broadcast searching. Every Information Professional I know both deifies and fears Google because they get it right most of the time – enough so that many people tend to assume that whatever pops to the top of a Google search MUST be right, because it’s right there, in the result screen.
Index Data has posted a statement of interest to the DPLA (Digital Public Library of America) beta sprint. We are submitting this together with two academic partners.
We are often asked about where we stand on the discussion of central indexing versus broadcast metasearching. Our standard answer: “You probably need some of both” always calls for further explanation. Some time ago, I wrote this up for a potential business partner. If it sounds a little like a marketing spiel… guilty as charged. I hope the content will still seem interesting to some folks thinking about these issues. While our specific approach and technology may be ours alone, the technical issues described here are pretty universal.