Collections database standards?
jmh3 at CORNELL.EDU
Thu Nov 18 18:01:56 CST 1993
John Shipman says:
>> The folks at MSB gave me a copy of MUSENEWS number 9, from the
>> MUSE database project at Cornell. I was interested to read there
>> that the NSF is interested in data sharing among collections. It
>> looks to me like MUSE is an important part of this effort.
>> I'm afraid, though, that attempts to solve data interchange
>> problems by urging everyone to use the same package are probably
>> doomed. Each database package has its loyalists. Who can blame
>> them, considering how much investment there is in learning a
>> modern database system?
And Jim Croft responds:
>This path has been trudged many times, and you are absolutely right.
>The database platform these day is not important - what is critical is
>the database design and the standards used for encoding and storing
Of course, in terms of data exchange, it *probably* doesn't matter what
database package is used (but see below). But, there are other issues that this
simpification tends to obscure.
For example, what if, say, each of 25 separate institutions decided to build
their own museum management system. I dare say all of these institutions would
apply to NSF for support to develop "their" package. Typical costs might be
$100,000 (US) or more. And, as has happened time and again, those packages die
a messy death when the local person responsible for them up and moves away.
Clearly, the NSF has an interest in the natural history museum community coming
up with common solutions. Not only do they save money, but the dialog that
such efforts maintain assures that issues such as data design and
standardization don't give way to local shortcuts.
Perhaps more importantly, this question raises one of the issues that I can't
resist commenting on (for fairly obvious reasons). People keep talking about
"database packages" as if those were collection managment systems. In fact, no
database package comes ready to manage a collection.
It is the programming of collection processes, user interactions, audit trails
of identifications, classifications, loan systems, labels and reports, etc.
that makes a usable system. The underlying "database package" is almost
irrelevant. One buys a database package, then you build the collection
management system. It is the later that is both difficult and timeconsuming.
Where the choice of database package matters is when the weaknesses of that
software pushes developers to cut corners on functionality or adherance to
community standards. (I can provide examples if they don't readily come to
mine, think Ashton-Tate).
Finally, let me say that I continually see statements about the relative "ease"
of data exchange. Perhaps this is true for relatively simple data stored in
flat files. But in modern museum systems with relational structures including
dozens of individual tables, it is far from clear that the exchange of data is
straight forward. We don't have a way to encapsulate both the data and the
data structure that records the information about a museum specimen.
The Vertebrate Collections and The MUSE Project, Cornell University
Building 3, Research Park
83 Brown Road
Ithaca, NY 14850
Email: jmh3 at cornell.edu
More information about the Taxacom