Bernhard Eversberg wrote:
> Karen Coyle wrote:
>>
>> ... What is broken is that
>> librarians today are not using the best tool for the job. Upgrading to
>> the appropriate modern tool will serve to integrate libraries with the
>> rest of modern information services and sources.
> And what *is* the "best tool for the job"?
> Sorry, Karen, but in all the rest of your posting you fail to tell us
> that.
Each job has its own best tool. Right now, I think that a formal,
web-based vocabulary is the best tool for the underlying library data
standard. This would use RDF and OWL.
> That means there cannot be the one "best tool".
> It is a sober fact that an enormous amount of software and thus a
> lot of our business depends on MARC as it is. This can only change
> at enormous cost.
We should actually calculate this cost. If the underlying data elements
remain pretty much the same (and I think they will), then translating
back and forth between formats is trivial. You can take, as someone
recently told me, 8 million LC MARC records and convert them to XML in
minutes, not hours, on a fairly normal computer. Today, most library
systems being sold use MARC XML as input so that they can easily handle
Unicode. The MARC21 records get converted on the way into the system,
and again this is a step that is just a blip in the processing time.
(Big time goes to indexing, not conversion.) The fields are all handled
by tables and new fields can be added to the tables without
reprogramming anything. What would it take to add a lot of new fields
because we're expanding beyond the fields of MARC21? Very little for
input. The work is in adding those data elements to the user interface
and making use of them. But software like Aquabrowser seems to handle
this pretty well without programming. My guess is that we are going to
improve our catalogs incrementally, and that the cost of these changes
will not be enormous, nor will it be much more than the cost of changes
to MARC.
> Communication with the outside world does not require us to move
> away from MARC or *them* to embrace it. We need to be able to
> deliver data in XML and DC when and where there is a need, and accept
> data thus coded. This is possible while sticking with MARC for
> everything else. Although it certainly isn't the best conceivable tool
> for much of what we are doing.
We have to do more than deliver data. We have to get out of the dark
into the light. We can already export just about any format of record
from our databases, but still there is very little discovery of our data
by non-library applications. The first step in getting out of the dark
is to publish our data elements in a machine-readable format compatible
with web applications so that people can make use of our basic
bibliographic standard. Then we need to "expose" our data for use with
APIs, much like Amazon does when it allows you to embed covers in your
web site or to pull over reviews to a web page. It's not rocket science,
it's a great service, and it's just a matter of doing things
differently. What's the problem?
>
> So, it isn't the tools we should be spending time on now but the content
> of our data. Which is what RDA development is about, and the new
> commitment to an alliance with the DC movement and toward international
> interoperability may well be the only realistic chance at the moment to
> get things going on the large scale.
The commitment to DC comes about because DC wants it. In fact, the work
that will be done there will not be DC-centric but RDA-centric. Then the
DC community will go off and do what it wants with it, but RDA will be
the real winner. There will be a "pure" RDA vocabulary that anyone can
use, not just DC.
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
Received on Wed May 30 2007 - 08:48:12 EDT