Collections database standards?

[Julian Humphries]

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
>data.
>
but:
<soapbox on>

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.

<soapbox off>

Julian Humphries
The Vertebrate Collections and The MUSE Project, Cornell University
Building 3, Research Park
83 Brown Road
Ithaca, NY  14850

Voice: 607-257-8143
Fax:   607-257-8109
Email: jmh3 at cornell.edu