LIBLICENSE-L Archives

LibLicense-L Discussion Forum

LIBLICENSE-L@LISTSERV.CRL.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
LIBLICENSE <[log in to unmask]>
Reply To:
LibLicense-L Discussion Forum <[log in to unmask]>
Date:
Mon, 1 Jul 2013 19:00:54 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
From: Owen Stephens <[log in to unmask]>
Date: Mon, 1 Jul 2013 06:33:36 -0500

I'm currently working on a couple of projects in this area:

GOKb http://gokb.org - a freely available data repository (the Global
Open Knowledgebase) that will contain key publication information
about electronic resources as it is represented within the supply
chain from content publishers to suppliers to libraries.

KB+ http://www.kbplus.ac.uk/kbplus/ - a shared community service for
UK Universities to share and manage data on electronic resources and
other subscribed resources (being run by Jisc Collections in the UK -
Jisc are also partnering in the GOKb project).

In both projects we are collecting lists from publishers and
processing them into the knowledge bases to then share the information
back to the community - as well as drawing on the community to
continually improve and enhance the data available.

We generally use KBART files if we can get them, but we find that many
publishers don't use this format, and indeed where KBART is used there
can be inconsistencies in how it is used. I'd stress that KBART is
just a simple tab-delimited file format with guidelines (it's worth
remembering that KBART is a set of 'guidelines' rather than a
standard) on what information to include and how to format some
fields. The use of KBART has some strong advantages for us in terms of
standard ways of treating the files, but being a 'flat' file structure
(one row in the file per journal title) it has some limitations as
well.

When we first started work on getting data into these systems we used
KBART as a starting point for our import format. However we quickly
found limitations of this - we often had more data available to us
that KBART supported - and the same is true when we come to export
data from these systems. We feed back our findings to the appropriate
KBART working groups.

There should be data available from the GOKb project later this year,
but you can already download data gathered by the KB+ project from
http://www.kbplus.ac.uk/kbplus/publicExport (including KBART formatted
version). The focus for KB+ is agreements for UK Universities - but it
does include packages that are offered more widely as well (e.g.
Project Muse, JSTOR). GOKb will be (as might be expected) global in
its scope.

Hope this is of some interest,

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: [log in to unmask]


>>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.

ATOM RSS1 RSS2