Current Liblicense Archive - Re: KBART anyone?

List archives since November 2011, after the list migrated to the Center for Research Libraries.


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LIBLICENSE-L Home

LIBLICENSE-L Home

LIBLICENSE-L  June 2013

LIBLICENSE-L June 2013

Subject:

Re: KBART anyone?

From:

LIBLICENSE <[log in to unmask]>

Reply-To:

LibLicense-L Discussion Forum <[log in to unmask]>

Date:

Thu, 27 Jun 2013 23:06:54 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (86 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options



Archives

October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011

RSS1