I'll chime in, since this is something we've been kicking around here for a bit.
Do we need a "Next Generation Library Management System? It seems to
me that a lot of the dissatisfaction we have with out ILS systems
stems from the fact that they're too integrated. The amazing things
some people have been doing with NGCs have been built on the idea that
we can't wait for our monolith (ie single ILS) to catch up.
Anyone who has used more than one or two of the major ILS systems will
probably tell you that some are better at one thing, but not others,
so in an ideal world they might use III's cataloging and webpac
modules, but want to do serials check-in in Aleph and circ through
Voyager. (I'm making this example up randomly.) Or even better, they
might want to do their original cataloging in III, but have
paraprofessionals use Follett's Catalog Plus interface, which kindly
hides all the scary MARC tags.
So why not? I'm not a database guy, but it seems to me that if a
standard database scheme was created to store all the types of data an
ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
on any company's circ software, assuming it knew how to read and write
to our database? In terms of what the user wants to accomplish,
aren't the basic tasks pretty much predictable?
What other obstacles exist to freeing ourselves entirely from the ILS
model? This isn't rhetorical; I don't know the answer.
And to actually answer the question Owen posed... since I'm a
cataloger, I'll name a few of the must-haves for a Next Generation
Cataloging Interface:
-The option to automatically put in ISBD punctuation (I love the
concept, but would probably turn it off since my fingers put in the
punctuation without my brain being involved)
-Auto-completion in any authority controlled field. Better yet, local
auto-completion through loaded authority records enhanced by an API
that searches LC's authority files as well. OCLC almost has this down
correctly, but it has a few problems.
-Built-in, context aware MARC documentation with examples. OCLC
almost got it right, I don't want to have to leave my cataloging space
to browse their website. Show it to me right there where I'm going to
use it.
-Spell-check that's customizable by field.
-Drop down menus for every tag, subfield, etc, that uses encoded data
(or something more user friendly, like pop-up windows for large lists
of relator codes, country codes and such). Don't send me to loc.gov
to scroll through their list. Bring their list to me and let me click
on the data I want to insert.
-EASY delimiters. Or better yet, standardize the stupid thing. Don't
give me an F-key or a Ctrl+Something to insert a subfield. III got it
right with the vertical bar. If I accidentally insert III's delimiter
into OCLC or Voyager, I don't screw anything up. Trying to use OCLC's
delimiter keystroke (Ctrl+d) in Voyager puts me in diacritics mode.
Voyager uses function keys. No one likes Function keys; they're not
mnemonic and they're not standardized across software packages, which
is a problem when you use more than one piece of software to do the
same task, like cataloging in Voyager and OCLC.
I really can't stress enough how important it is to make entering any
kind of controlled information (be it authorized forms of headings or
encoded data) easier. As I read complaints about MARC, I find that
some of them are legitimate, and others really aren't about MARC at
all, but about cataloging. People don't use all the nifty encoded
fields in the 0XXs because they take too long to look up, especially
when most systems don't even use the data in any useful way. And this
becomes cyclic. Software doesn't use the 0XXs because so few records
have them. Make it easy and you won't have to convince too many
catalogers to start putting that data into records even if their
current systems won't use it, or it'll only apply to a small
percentage of records for now.
--
Mark Sandford
Special Formats Cataloger
William Paterson University
(973)270-2437
sandfordm1_at_wpunj.edu
Received on Mon Oct 22 2007 - 10:36:26 EDT