Okay - I'll hop in - but - will refrain from going on and on about how
great Summon is to spare everyone from the corporate sales shpeal.
I think there are 2 important ideas to keep in mind here:
First - Summon's goal is to provide a web-scale unified index of the
full breadth of the library's offerings. This means including your
library catalog marc records as well as you library's IR and digital
library content in the index. Any content that you provide access to
for your patrons should be discoverable via a single search box.
Second - While Summon delivers a hosted User Interface along with the
service - we are offering other options that Jonathan pointed out.
The ruby based UI will be open sourced so you can host and modify to
your hearts content. The API allows connectivity with other discovery
interface systems: VuFind, AquaBrowser, etc.
So with this - I don't see a powerful reason to need to have your own
locally hosted unified index. Which in my mind is a win-win. You
and your fellow staff can spend your time and effort on making the
greatest user interface for your discovery application at your library
possible with out having to spend time and resources on backend
infrastructure and support.
P.s. I'd be happy to take any specific Summon questions offline if
anyone is interested.
Andrew
On 6/17/09, Jonathan Rochkind <rochkind_at_jhu.edu> wrote:
> Diane I. Hillmann wrote:
>>
>> I agree with this, but I think it's important to recall that Summon is
>> designed to be the whole enchilada--not just an invisible middle man
>> supporting a variety of user interfaces. I believe their strategy is to
>> market the whole experience, soup to nuts, including the library's MARC
>> data. I frankly can't imagine that they'd be all that interested in
>> providing data only to other services, but it's certainly worth asking.
>>
>
> In a departure from Serial Solutions typical business model, the Summon
> front-end will be provided as open source software, and the customer
> will be free to swap out the front-end for any other hypothetical
> front-end, using the same Summon APIs that the "out of the box" (open
> source) front-end uses.
>
> So Serial Solutions is already behaving a bit differently than usual,
> and is already open to the underlying service being displayed in other
> contexts through software not their own.
>
> But they as of yet have no plans to provide the _data_ to be reindexed
> in your own index, as opposed to access to an underlying API to access
> SS's index. In addition to potential worries about de-valuing their
> own service, there are technical challenges to providing a data service.
> I suspect the latter is more of an issue for SS right now than the
> former, based on the way they've structured the front-end in an open way
> already.
>> One of the things you probably wouldn't get with that pre-normalized
>> data is any transparency about what they've done to it, and I think
>> that's a huge problem, especially if you want to integrate even more
>> data with what you already have.
>>
> True enough. But I'm not sure you need transparency about _how_ they've
> prepared the data, so much as you need documentation on what to expect
> in the produced data. You might prefer the details about how they've
> processed it, but there are trade-offs to paying a vendor for a
> proprietary product vs doing it yourself. Plusses and minuses on both
> sides. With such an expensive and difficult undertaking though, I think
> it will ultimately come down to cost effectiveness. I'm not sure that
> transparency in _how_ they've processed the data is neccesary to use the
> resulting product in a high quality local combined index.
>
--
Sent from my mobile device
Received on Thu Jun 18 2009 - 15:51:43 EDT