The reason I'd want my own local index is so I can work on adding
features that depend on the index that are not yet in Summon, not be
constrained by the features that Summon currently offers.
For instance, a hieararchical display of LCSH (instead of just a one
dimensional list facet), based on the LCSH actually in the catalog.
Or the ever-allusive 'browse list'. Or a 'view what's on the virtual
shelf next to this item' (ie, a browse by call number), using cover
images. Or, for results with geographical location information, plot
them on a map.
Andrew Nagy wrote:
> 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.
>>
>>
>
>
Received on Thu Jun 18 2009 - 16:21:44 EDT