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 Wed Jun 17 2009 - 14:35:17 EDT