I’m having a dialogue with Serials Solutions and I expect to get a response to publish here.

So we ‘provide’ both. You can use native interfaces if you want — and our meta-search tool tries to give you options to do so, not hide them from you. But many users at many times will prefer meta-search, despite it’s limitations. They largely prefer it because it’s more convenient — no need to learn a specialty interface, no need to understand what native tool does what.

If we can make it even more convenient, while ALSO making it work better… everyone wins. And those native interfaces are still there just as they ever were. That’s the promise of Summon, to me. I think they have a good chance of pulling it off.

Maybe a federatedseachblog interview with someone from Summon?

One of my predecessors in my position, now retired, insisted many years ago that the only way “cross database searching” would work is if the content was indexed locally. I agreed, but was sure that could never happen because of course the publishers and vendors would never play together. Now that it appears to be a possibility, I’m very eager to see how it plays out.

I agree again with Jonathan on the issue around comprehensive coverage. Summon (and to my mind all federated search) is a *discovery* tool, not a replacement for the native interfaces and content providers. The researchers who need to dive deeply into their areas of specialization will still use individual databases, but for the majority of searchers I think the 80% (just an example number) of coverage that Summon would provide would be just fine. I also think that if Summon does a good job out of the gate, they’ll attract more content providers, snowballing their content coverage.

There are more too. I’m not sure how much experience Deep Web Tech has in the academic scholarly search arena, but it really does have it’s own special complexities, beyond just, say, aggregating different silos of data or web pages from within a certain federal agency or whatever.

I haven’t actually done an analysis to see exactly why each of those resources can’t be federated. Again, see limited resources. But in the academic market, this is typical, I don’t believe my vendor has significantly smaller (or larger) coverage than other vendors in the market. We have lots of websites from small vendors, often non-profit association vendors, that just don’t have a lot of functionality, even though they have important content.

Of course there’s value in letting the user choose what to search. My point is not taking that away. My point is that their choices are _neccesarily_ constrained by what is _available_ in the unified search interface. If you switch to a different set of content, you’re maybe going to take away some people’s favorite content, and give other people their favorite content they didn’t have before. The net effect on your user community may be a wash. Of course we’d LIKE to provide all content in the world, but meanwhile back to reality.

One of the tricks of letting people choose ‘what they want’, is that when we’re talking hundreds of specialty licensed databases whose names are not household terms — the typical user has no idea what any of these are, or how to pick from them. Add to that, in a broadcast search environment, the units of selection are neccesarily the individual ‘databases’ or ’search engines’ or ‘resources’ — collections of content chosen by someone else already, that can then be mixed and matched in bulk.

The promise of the Summon approach is that you can choose content according to entirely different categories, at the _journal title_ level, crossing the boundaries of different existing ‘databases’. Summon hopes to make just such subject-selected categories of individual journals. And presumably allow librarians (or individual users) to create their own too. You aren’t constrained to just mixing and matching pre-existing collections, you can slice through what existing vendors happen to have chosen as collections.

Indeed if they can full text to index, they’ll be able to do more htan just metadata. I believe they DO have full text where they can get it, and just metadata in other places. Depending on what the source has or is willing to give them. Of course, even with broadcast search, _some_ remotely searched databases may just contain metadata anyway, others may contain fulltext. But yeah, it all depends on what Summon can get, and how well they can do with it. The proof will be in the pudding, but I don’t think this particular issue is the most likely weak point.

I agree that two seperate tabs, one for ‘indexed’ content, and one for ‘broadcast search’ content, is probably the only decent way to offer both without bringing indexed content down the lowest common denominator of broadcast search. The trick here is it’s going to make no sense to users why some content is only avail in one tab, and other content is only in the other, and others might be in both.

If I had to choose only one of these tabs, either because it was too confusing to the users to have both, or more likely because I didn’t have the resources to maintain both (it’s going to be more expensive in terms of local maintanance and/or costs to vendors to have both) — I’d pick whatever one worked best, naturally.

Which works best will be something we’ll find out once Summon is done. But if it’s not Summon at first — my prediction is that it will be the Summon approach eventually. They might have to fine tune some things, we might need to wait until more content providers are willing/capable to share their metadata and/or indexable fulltext with a vendor like SerSol. But the Summon approach is the one with long-term legs on it in my opinion, it’s the one I’d put my money behind in the long term.

This analysis applies mainly the academic scholarly research market — with a main focus on with searching the scholarly peer reviewed literature. That’s the market/use-case/environment I’m familiar with, and it has some special challenges that may not apply to other meta-search applications. Like the need to include a significant portion of the scholarly universe in order to serve it’s function, a scholarly universe which is split over hundreds if not thousands of publishers, platforms, aggregators, and other vendors. Also the absolute need to get structured citation metadata for the scholarly article ‘hits’, so it can be passed off to a ‘link resolver’ to actually deliver the article to the user (often from a different source than the citation was found in).