From: Steve Oberg <[log in to unmask]>
Date: Thu, 27 Jun 2013 23:15:31 +0000

I would second this observation that KBART is woefully lacking in
vendor support. We've been on WorldCat Local for a bit over two years.
Its reliance on KBART is great but not that helpful if we have to
spend precious time fiddling with file uploads. I don't see the value
of KBART unless it's widely adopted. In the absence of widespread
adoption I'd plunk for a simple .csv or tab-delimited file format
instead.

Keeping knowledge bases updated is not an easy task even for smaller
institutions like mine. And if, again like mine, you have at least two
big knowledge bases (besides WorldCat Local, we also use SFX) to
track, in addition to traditional cataloging in a MARC-based system
(in our case, Voyager), one rightly begins to feel like throwing in
the towel. Not only that, for WorldCat Local you have the ability to
sign up for PubGet to automate some of this updating process for you,
yet PubGet is not comprehensive as a data source.

My point is, if we have a logical goal to provide seamless, consistent
access to content for our users *regardless of access path* they might
take, the task is made quite difficult in the best of circumstances.

Of course this is why many libraries put their hope in the great hope,
er, I mean, discovery services or interfaces. But discovery
services/interfaces are only as good as the data behind them. I think
it was Roy Tennant who popularized the phrase "putting lipstick on a
pig" in reference to revamping OPAC interfaces several years ago. I
think the same applies to discovery services.

Steve

Steve Oberg
Assistant Professor
Electronic Resources and Serials
Buswell Memorial Library
Wheaton College
Wheaton, IL  60187


On Jun 27, 2013, at 4:57 PM, LIBLICENSE <[log in to unmask]> wrote:

> From: "Hamaker, Charles" <[log in to unmask]>
> Date: Thu, 27 Jun 2013 05:38:30 +0000
>
> We are moving to OCLC's WMS system, which makes extensive use of KBART
> files. We have been using for about two years Ebsco's EDS.
>
> We are finding that the majority of our e-providers do not use KBART
> format and we have to go through various contortions to get those
> files into a form that the WMS system can use.
>
> Could I make a plea for both the more widespread availability of KBART
> files (transforming Mrc files to KBART is not fun!)  and the setting
> up of regular feeds from publishers with the various discovery
> services  of e content of their metadata?
>
> A number of  providers of e-content are also holding back or not
> cooperating much in p;providing  the discovery services metadata that
> could  be utilized  in those systems, thus Amira's emails.
>
> As a result these search systems often use very scant metadata as
> Amira Aaron has rightly pointed out, or in what I consider the worst
> of situations, the old Z39.50 engines  provide services to Discovery
> users. Surely publishers want their data exposed with more fidelity
> and relevancy to the search, than Z engines provide. It makes it look
> like you don't have content you really do when Z interfaces are the
> main engines of discovery.
>
> P.S. We have been quite impressed with both the WMS discovery system
> and EDS. They do a great job with the content they can index directly.
> And every time we've looked at Summons, have been impressed as well. I
> admit i'm not as familiar with other of the Discovery services.  But
> all these services which serve libraries rely on various levels of
> metadata and regular feeds at that, to provide their services. I hope
> more e-content providers will continue to come on board so these
> systems can become ever more robust.
>
> I realize this can be a sensitive subject, no provider wants to lobby
> publicly or admit to limitations in their systems, so it takes
> librarians speaking up. to focus on the issue of sufficient provision
> of metadata or full text where appropriate supplying the discovery
> services.
>
> Chuck Hamaker