Notes from group discussion after presentation, 5/26/10

(still subject to revision at this point)

Also available: Recording of presentation / discussion
Here's a link to the student audio that Matt plays during the presentation: http://www.rpi.edu/~benzim/fedsearch/googleIt.wmv

  • Tammy: We don’t have tons of money, so we have to be judicious about we do.
  • Tammy: Has anyone used a federated search engine?
    • Colette:
      • Dialog used to search multiple databases back in the day.
      • Tammy: does Dialog still have it?
      • [...inaudible...]
  • Colette: What are the costs? Do you pay per connector? (Note: Connectors – the bits of software that allow you to connect to different databases.)
    • Katie: We don’t know any specifics about costs yet – they don’t give you any information on the PR sites, we haven’t talked to any implementers. (note: and we probably couldn’t get any information from other libraries anyway on commercial product costs – nondisclosure agreements?)
    • Katie: Back when I was at Grinnell and we were looking at fed search (~3 years ago), the vendor we were working with (don’t remember who) did charge per connector. They charged more if they had to develop the connector from scratch than if they already had one developed.
  • Colette: are the connectors customized based on who the federated search vendor is?
    • Katie: I think so – connector has to talk to the database as well as the federated search software, and the fed search software behaves differently for different vendors. LibraryFind has a starter list of connectors in XML format. With open source products, the user community is responsible for maintaining the connectors, and they can be hard to keep up with as vendors change their interfaces often.
  • Bob: Did you look at Encore or other Innovative products?
    • Katie. Not really. We started out focusing on federated search products, but the further we got along, the more we realized that federated search and discovery services (like Encore) are kind of intertwined. [Note: if we continue to investigate these, we’ll want to look closer at Encore and other discovery layers.]
    • Tammy: the wiki has a list of services we’ve looked at (to some degree) but we didn’t try to be comprehensive.
    • Bob talked about Connect NY’s use of Encore, and University of Rochester’s Extensible Catalog project. Extensible Catalog project is just now getting to the point where it can be evaluated.
    • Katie: Research Pro (Innovative’s federated search product) does plug into Encore.
    • Bob had been putting Encore in our capital request for a few years, but it hadn’t been approved.
  • Tammy: whether or not the money is there right now, we want to keep up our knowledge of where these things are at so when/if the money comes around, we’ll be ready.
  • Tammy: Gary Schwartz asked an interesting question when we previewed this presentation for him, Will Gill, and George: “What do you get by investing in this technology, and what do you lose if you don’t invest in it?” He looks at decisions they have to make in their dept. this way.
  • […inaudible...]
  • Bob: Cost of not doing this might be lack of discovery / use of these resources that we purchase.
  • Tammy: as a committee, we’re trying to stay fairly neutral, to get the pulse of the library on this, but my feeling personally is that you can risk not only not using your collections to their utmost, but also loss of users. People who just stop coming to the library because Google Scholar is good enough for them, not realizing that there are great resources in Digitool or our other resources – not knowing what they’re missing. We might be losing the younger element of our users.
  • [Q: inaudible]
    • Katie: Google Scholar knows what we have in fulltext, and there are SFX links there. (Note: (clarification after discussion) but Google Scholar can only provide SFX links to stuff that shows up in Google Scholar. Just because it's in SFX doesn't mean you can find it in Google Scholar.)
  • John: User patterns for different user groups – how would undergrads vs. experienced users (who do know the databases and their tricks / specialized features) use federated search differently? What are their needs?
    • Tammy: Just because you offer one-stop shopping doesn’t mean you take away the specialized searching.
    • Katie: people may have looked at this question in the literature. We didn’t delve too deeply into this yet, but my sense is that it’s still developing and that also it would depend a lot on how you situate federated search on your webpage.
    • […inaudible…]
  • John: You’re paying for this, but is it a tool for undergraduates vs. an advanced research tool? Keeping that in mind, what kind of resources would we be willing to allot to this?
    • Matt: My feeling is that it’s not just undergrads looking for a single search box: grad students, too, as well as younger faculty. Saw this in the usability studies I did here. Faculty sometimes tell students “go to Google Scholar”, rather than the library specifically.
  • Katie: Also worth mentioning: how do you balance spending on resources that allow you to discover resources (like Web of Science) vs. things that have fulltext in them. This is part of this issue – it might help people find things they wouldn’t have found otherwise, but if you do it, the money has to come from somewhere. It always costs something – money or staff time. It’s an open issue.
  • Tammy: For anyone who does a lot of time on the circ or ref desk, how often are people looking for a single search box? Or are they pretty willing to look at several different resources?
    • Fran: there is a whole issue of web design, and this is also an instruction issue. We have to keep the educational piece in mind. They may be happy with one-stop shopping, but are they getting what they need?
  • Colette: there’s a whole area of resources (business and company information, etc., that probably wouldn’t be included. How do you handle that?
  • Linda: That is my concern also – Material that may be excluded)
  • Irv: problem that the the naïve user has – very general user. People only know specific vocabulary once they're a more expert user. Danger of using a tool that doesn’t tell you where things are coming from (source database, in a federated search). People don’t know what they’re using/searching (or should be)
    • Matt: If you have a system that does show where the results are coming from , it’s teaching the user at the same time. They’re learning where they’re getting a lot of hits, or what’s most relevant. Addressing Colette’s q: some kinds of data might not be searchable in a federated search interface, but pointers to it could be. If I need to find SIC codes, I enter SIC codes – it might not get me the information directly, but it might take me to the guide that you created that tells you how to get the information.
  • John: one quality that I’d want is a product that serves both seasoned users and undergrads. I think we’ve shown that this is possible. A geologist could simultaneously search those 5 databases they always go to individually.
    • Katie: It’s a really good overarching goal. If this is important to us, we’d have to decide what it would mean for a product to be useful to both new and experienced researchers, in terms of specific qualities/functionality.
  • Fran: Going back to what Bob said, the articles on the wiki are interesting. There was one example of New England law libraries building a tool together to meet their needs. Maybe we could build things through a consortium? Have a central administrator, share costs/labor. Could we work with Rochester or ConnectNY?